On Thu, 02 Oct 2008, Przemyslaw Czerpak wrote:
> Harbour in practice does not use any of such mutexes. Only some few small
> peaces of code are covered by them and it's small chance that two threads
> will be serialized. The cost of setting/releasing mutexes is the same for
> one and two threads so it's unimportant in such test.
> It has to be sth different.
And I've got the answer. At least on my computer it's a hardware issue.
In -gc[0-2] mode each threads makes:
if( ! --uiPolls )
hb_inkeyPoll();
in main HVM loop. Simple hack even acceptable in ST programs is killing
the performance in ST ones. Important is not hb_inkeyPoll() call (you can
comment it but it will not change the results) but --uiPolls.
Each thread decrements the same memory variable and it causes some horrible
synchronization issues between CPUs on multi CPU machines which kill the
performance. It's a hardware issue so I do not know how big overhead it
may cause on other machines. I'm very interesting in your results.
Please rebuild Harbour with -DHB_GUI macro or compile speedtst.prg with
-gc3 and compare results.
Definitely this hack with periodic hb_inkeyPoll() calling have to be
eliminated or at least updated for MT mode.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
