lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Benchmarking: gcc-8 beats gcc-10 soundly?


From: Vadim Zeitlin
Subject: Re: [lmi] Benchmarking: gcc-8 beats gcc-10 soundly?
Date: Sat, 19 Sep 2020 22:02:46 +0200

On Sat, 19 Sep 2020 16:55:41 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 2020-09-19 15:48, Vadim Zeitlin wrote:
[...]
GC> >  Unfortunately there is no clear conclusion there, as gcc developers can't
GC> > reproduce the problem. They do say that -O2 has been changed in 10.x, so 
it
GC> > could be worth using -O3 with it and see if it helps. Should I/we do it or
GC> > will you test this yourself?
GC> 
GC> I already did it for 8.x, which needs
GC>   -Wno-vector-operation-performance
GC> (because of -Werror); it didn't make much difference there.

 My understanding is that it's not supposed to, as gcc < 10 used the same
inlining heuristics with -O2 and -O3. In gcc 10 they're different, which
might explain the regression.

GC> I'll try it with 10.x soon.

 Thanks, looking forward to the results!

GC> Sure, go right ahead. I have no objection to showing σ.
GC> I'll probably want to twiddle the output format to make
GC> it really compact, so that we can fit more information
GC> on one line--very roughly, something like this:
GC> 
GC> -  1.323e-02 s mean;      13009 us least of  76 runs
GC> +  μ=1.32e-02 σ=9.87e-01 min=13009us runs=76

 My only problem with this is that I'm not sure if we can rely on either
working wchar_t or UTF-8 output everywhere. E.g. the following u8.c
program:
---------------------------------- >8 --------------------------------------
#include <stdio.h>

int main()
{
    printf("\xce\xbc\n");
    return 0;
}
---------------------------------- >8 --------------------------------------
produces the expected output under Unix and in MinTTY, of course, but a
nice "╬╝" (U+256C U+255D if it gets mangled) in console window under MSW 7.
Recent MSW 10 do have UTF-8 support in the console, but it still seems more
trouble than it's worth to deal with it...

GC> which leaves room if you want to throw in kurtosis or
GC> whatever. But let me worry about formatting, because
GC> it's the math stuff that I think you really want to do
GC> (Welford's algorithm or whatever)

 Ah, this is how it's called. I've always referenced it just as "the
algorithm from TAoCP Vol 2 section 4.2.2", but this is definitely more
appropriate, thanks!

GC> and a patch that just adds some code to do those calculations is easy
GC> to accept because it won't have any perceptible effect until the format
GC> is changed to print it.

 I'll make one a.s.a.p., and maybe also run some benchmarks using it, while
I'm at it.

 Regards,
VZ

Attachment: pgpBOpXtlm_8J.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]