Basic Block Layout in the NCG

[Kavon Farvardin]

> 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 <klebinger.andreas at gmx.a
> t>:
> > [...] 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20180506/311def59/attachment.sig>