Re: Basic Block Layout in the NCG

4% is far from being "big", look e.g. at https://dendibakh.github.io/ blog/2018/01/18/Code_alignment_issues where changing just the alignment of the code lead to a 10% difference. :-/ The code itself or its layout wasn't changed at all. The "Producing Wrong Data Without Doing Anything Obviously Wrong!" paper gives more funny examples.

This particular instance of performance difference due to aligning blocks/functions is not very surprising (it is mentioned in section 3.4.1.5 of the Intel Optimization Manual). I also think 4% on large, non-trivial programs is "bigger" than 10% on the tiny example in that blog post (especially since the alignment issues disappear above 1024 iterations of the loop). ~kavon On Sun, 2018-05-06 at 14:42 +0200, Sven Panne wrote:

2018-05-05 21:23 GMT+02:00 Andreas Klebinger :

...

[...] I came across cases where inverting conditions lead to big performance losses since suddenly block layout got all messed up. (~4% slowdown for the worst offenders). [...]

4% is far from being "big", look e.g. at https://dendibakh.github.io/ blog/2018/01/18/Code_alignment_issues where changing just the alignment of the code lead to a 10% difference. :-/ The code itself or its layout wasn't changed at all. The "Producing Wrong Data Without Doing Anything Obviously Wrong!" paper gives more funny examples.

I'm not saying that code layout has no impact, quite the opposite. The main point is: Do we really have a benchmarking machinery in place which can tell you if you've improved the real run time or made it worse? I doubt that, at least at the scale of a few percent. To reach just that simple yes/no conclusion, you would need quite a heavy machinery involving randomized linking order, varying environments (in the sense of "number and contents of environment variables"), various CPU models etc. If you do not do that, modern HW will leave you with a lot of "WTF?!" moments and wrong conclusions.

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs