Hi all,
On Sun, 21 Feb 2016 22:22:22 +0200
"Shlomi Fish shlomif_at_shlomifish.org [fc-solve-discuss]"
<fc-solve-discuss_at_yahoogroups.com> wrote:
> Hi all,
>
> On Sun, 14 Feb 2016 19:20:13 +0200
> "Shlomi Fish shlomif_at_shlomifish.org [fc-solve-discuss]"
> <fc-solve-discuss_at_yahoogroups.com> wrote:
>
> > Hi all,
> >
> > I carried on with my plan to test breaking some backward compatibility, but
> > luckily I have made it an optional compile-time define
> > ( -DFCS_BREAK_BACKWARD_COMPAT_1=1 in cc or CMake, --break-back-compat-1 in
> > the "Tatzer" configuration script. ) which is disabled by default. Turning
> > it on seemed to have improved performance of the standard 32K-in-parallel
> > test, but now it seems to make matters in a PGO/-flto run somewhat worse
> > (don't ask me why that is the case).
> >
>
> After testing the break-back-compat-1 flag in a standard "Tatzer -l ci7b" run
> (without profile-guided-optimisations/PGO), I discovered that it improved the
> performance of the solve-and-verify-benchmark quite a bit. So I remembered
> correctly that it was better this way.
>
> So it makes matters better without PGO and makes matters a little worse on
> average with PGO enabled. Now the question is - why?
>
I did another benchmark and this time with PGO, the code was
faster with the break-back-compat-1 flag applied. So all is good now.
:-)
— Shlomi
--
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
Chuck Norris/etc. Facts - http://www.shlomifish.org/humour/bits/facts/
Except for boastfulness, rashness is my only defect!
— Based on http://www.shlomifish.org/humour/TheEnemy/ .
Please reply to list if it's a mailing list post - http://shlom.in/reply .
Received on Tue Mar 08 2016 - 12:57:00 IST