Hi Przemek,
I've built mingw with -DHB_USE_TLS (the rest is default),
then I got 'undefined reference to '__emutls_get_address'
errors on linking. Such symbol doesn't BTW exist in MinGW
4.3.2 supplied libs.
AFAIR the work on TLS support for MinGW started at the begining of
summer so probably you should look at newest MinGW versions (probably
devel ones if you want to use it).
Despite my 'GCC432' markings, this was actually done
with the latest stable MinGW, which is 4.1.2, so I'll
make some tests with the latest available 4.3.2 non-official
build, maybe it already has it.
[ Update: Tried MinGW 4.3.2 with -DHB_USE_TLS, and I'm
still getting the same error as above. Maybe I'm doing
something wrong, which could well may be given the zillions
of factors involved. ]
- MSVS switches: (all default C mode)
- GCC switches: -O3 -fomit-frame-pointer -ffast-math -
march=pentiumpro
- BCC switches: -6 -OS -Ov -Oi -Oc -Q -tWM
-ffast-math in some cases increases the differences in FL arithmetic
so not all people like it.
I also suggest to check -march=pentiumpro. This CPU has extremely slow
16bit registers and it's possible that MinGW will try to make some
workarounds for it but I do not know if it really does it. Anyhow
I rather suggest to chose something more closer to hardware you are
using if you want to enable CPU optimization.
Okay and thanks, I'll simply remove both, as the .exe ought to
run on not just my system, but possibly on all hardware my app
may run (when I begin to use GCC live). I also removed -ffast-math
from future official MinGW builds.
[ Update: After removing both from 1.0.1 builds, I got _just slightly_
bigger binaries, and about identical performance. As a downside, now
I'm getting 44 errors in hbtest, due to failing Round() and Int()
tests: 914, 917-920, 923-925, 959, 962-965, 968-970, 987-990.
Actually the new MinGW results are the right ones, but the
expected results seem to be screwed up, showing 705032704 instead of
5000000000. Quite strange. ]
It also means that we will not improve the speed if we begin to pass
the pointer to HB_STACK between functions as parameter.
The problem is only with systems where TLS access is really expensive.
F.e. older Linuxes, some *nixes, some systems without TLS at all where
we will have to emulate it ourselves and looks that also in Windows
though here I'm not such sure the results for compilers with native
TLS support. At least few of then should give better performance. The
speed difference is simply too huge. I also made some tests but I run
MinGW and BCC programs in my Linux box using WINE and the overhead is
from 25% to 32%.
BTW. Viktor if possible then I would like to send you MinGW binaries
to compare results on your system with your native MinGW builds.
Okay, no problem.
[ As for OpenWatcom tests, maybe a bit later, I'd personally
rather choose the best from the mainstream compilers. ]
[ Lucky Linux/OS/2 users, I didn't expect Windows to suck this much.
Having said all that, maybe it'd just fine to enable MT by default on
those systems where there is no extra overhead beyond the one caused
by different C structures. ]
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
