Opened 4 years ago

Closed 3 years ago

#11808 closed task (worksforme)

nofib's cryptarithm1 regresses due to deferred inlining of Int's Ord operations

Reported by: bgamari Owned by:
Priority: high Milestone: 8.0.2
Component: Compiler Version: 8.0.1-rc3
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Commit d1179c4bff6d05cc9e86eee3e2d2cee707983c90 apparently causes a ~5% regression in runtime in nofib's cryptarithm1 benchmark. Need to work out why.

Change History (4)

comment:1 Changed 4 years ago by simonpj

Check out allocation figures.. do they budge?

comment:2 Changed 4 years ago by bgamari

I have not been able to reproduce the regression locally, unfortunately. I did a nofib run prior to merging the commit which as far as I remember didn't show any major regressions; moreover my attempt at reproducing the issue this morning came up (or rather, the change supposedly improved runtime by 1.7%, although I don't believe this is significant).

Regardless, according to ghc-speed (which you can reveal by clicking on the = button in the top right corner) the patch didn't change allocations. Judging by the history of this benchmark it seems to be quite unstable. This could be due to a number of things, including caching effects.

comment:3 Changed 4 years ago by bgamari

Milestone: 8.0.18.0.2
Priority: highesthigh

comment:4 Changed 3 years ago by thomie

Resolution: worksforme
Status: newclosed

This was the change that perf.h.o reported:

nofib/time/cryptarithm1 	0.401	+ 4.99%	0.421	seconds

Since cryptarithm1's runtime is currently under 0.4 seconds again on perf.h.o, I think it's safe to close this ticket, and call it an anomaly.

nofib/time/cryptarithm1 	0.397	=	0.397	seconds
Note: See TracTickets for help on using tickets.