Hi Przemek,
With GCC 4.4.0 the binaries got a bit larger when
using HB_STRICT_ALIGNMENT, but also measurably faster.
Built with 'hbmk2 speedtst.prg' (default -gc0)
HB_STRICT_ALIGNMENT: 38.25/39.11, 38.42/39.08
default : 43.39/44.03, 43.47/44.03
Brgds,
Viktor
On 2009.05.27., at 1:13, Przemyslaw Czerpak wrote:
On Mon, 25 May 2009, Szak�ts Viktor wrote:
Thanks. What should we do in default builds? Can we safely
pacify the warnings while keeping performance? Should we just
safely suppress these warnings?
I'm afraid that at least in few places GCC can strip out some of our
code or at least change the order of some instructions and wrong
binaries
will be created. It has to be fixed.
Please note that number of optimizations which use strict aliasing is
systematically growing up so even if I pacify the warnings for GCC4.4
it's possible that it won't help in GCC4.5 or newer.
So the only one clean solution is using code which operates on
bytes to create more complex numbers. It looks more complicated
but does not have to be much slower. It's even possible that it
will be faster then direct access with forced casting in some modern
CPUs. Some new CPUs which seems to work with wrong alignment also
generate exception when some complex numbers are read from memory
address with wrong alignment but default exception handler tries
to complete the operation using byte access. In such case explicit
byte access should be noticeable faster.
BTW have you tried to compare speedtst results for Harbour compiled
with and without HB_STRICT_ALIGNMENT macro?
The comparison should be done for -gc2 output. In -gc3 PCODE is
generated only for codeblocks.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
