On Tue, 07 Oct 2008, Phil Barnett wrote: Hi Phil,
> > Can you build Harbour in this system and then compiler and run > > harbour/tests/speetst.prg f.e.: > > hbmk -n -w -es2 -mt speedtst > > ./speedtst --exclude=mem --scale --thread:2 > > ./speedtst --exclude=mem --scale --thread:4 > > ./speedtst --exclude=mem --scale --thread:6 > > ./speedtst --exclude=mem --scale --thread:8 > Quad core Phenom 9600, 32 bit Fedora 9 > [EMAIL PROTECTED] tests]$ ./speedtst --exclude=mem --scale > ************************************************************************************************************************* [...] > excluded tests: 029 030 023 025 027 040 041 043 052 053 019 022 031 032 054 > 1 th. 2 th. factor > ============================================================================ > [ TOTAL ]_________________________________________ 24.75 30.95 -> 0.80 > ============================================================================ > [ total application time: ]....................................84.63 > [ total real time: ]...........................................55.70 Many thanks for your tests. The results are as wrong as in other tests but I forgot about one thing. Your CPU just like mine strongly interacts with simultaneous assign the same memory cell and the code which makes it in main HVM loop is covered by #ifndef HB_GUI ... #endif. To disable it you will have to rebuild Harbour with C_USR=-DHB_GUI or at least compile this tests with -gc3 - it causes that except codeblocks for the rest of code C code is generated not PCODE evaluated by main HVM loop. I would like to ask you about yet another test. The same but using Harbour recompiled with export C_USR=-DHB_GUI or with speedtst.prg compiled with -gc3 switch, f.e.: hbmk -n -w -es2 -gc3 -mt speedtst for i in 1 2 4 6 8; do ./speedtst --exclude=mem --scale --thread:$i; done AFAIR Enrico used to compile Harbour with -DHB_GUI so maybe also Intel CPUs does not like it though Maurilio tests doesn't suggested it. Before I'll remove this code from main HVM loop I would like to know the overhead it causes also for Intel. Viktor, I've seen your Darwin 64-bit results - thank you. Much better. If you have multi CPU machine then please compare the results of: ./speedtst --exclude=mem --scale --thread:2 when it's compiled with -gc3 and when whole Harbour is compiled with -DHB_GUI I would like to see results of 4 tests: ./speedtst --exclude=mem --scale --thread:2 done on the same multi Intel-CPU machine for: 1. standard Harbour build and speedtst compiled with -gc0 2. standard Harbour build and speedtst compiled with -gc3 3. Harbour compiled with C_USR=-DHB_GUI and speedtst compiled with -gc0 4. Harbour compiled with C_USR=-DHB_GUI and speedtst compiled with -gc3 It should give the answer what is the cost simultaneous memory assign by more then one threads. I know that is very high in my CPU. Maurilio said that there is small difference in his Intel machine on OS2 but I'm not sure if it was not local to his tests. I can see in Enrico results that it behaves better then my Phenom for [ T004: x := S_C ] where such situation is intentional but in this case the operation is covered by LOCK x86 machine instruction so the cost can be different then unprotected memory write. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
