#5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: #15357 #15333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK):

I blame non-determinism in code layout or some other caching effect until I have a better hypothesis. These are the candidats we want to flag away for runtime measurements, especially real/eff, or make them actually do something meaningful.

They generally compile down to a loop of a handfull of instructions. So flipping an `if` (invert the condition, swap then and else expressions) can already lead to noteable differences as the cpu might need proccess one more instruction. For the really small loops we can also get counterintuitive behaviour. Eg I reduced on of them by one instruction and performance got slower because of instruction sheduling effects. Having an "effective runtime" modus that excludes these seems worthwhile. But I'm torn on excluding them by default. Ideally people would see these unexpected results. Then look at the generated code and be able to tell if the code is actually worse or if it's just one of these edge cases. But that requires a lot of low level knowledge, which not everyone has. So people might throw out perfectly good ideas/patches because of missleading nofib results. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/5793#comment:39 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler