On Sat, 28 Mar 2009, Angel Pais wrote: Hi,
> Here you have results on same computer 2 compilers. > see this: > xbase++ : > [ TOTAL ]________________________________247.17 246.80 -> 1.00 > ==================================================================== > [ total application time: ]...................................494.06 > [ total real time: ]..........................................494.06 > harbour + msvc: > [ TOTAL ]________________________________228.51 289.80 -> 0.79 > ============================================================================ > [ total application time: ]...................................706.25 > [ total real time: ]..........................................518.45 > Does it mean xbase++ are using 2 cores simultaneously ? > And Harbour ? It shows that both compilers have rather fatal scalability in this environment. xbase++ is a little bit better in scalability but the difference is minor. I can only guess that Harbour version was using dlmalloc. And of course I hope that you disabled memory statistic module in Harbour builds by: set HB_USER_CFLAGS="-DHB_FM_STATISTICS_OFF" Otherwise this test will not give any valuable information about Harbour performance. You cannot compare Harbour debug builds with final releases. It's not my intention and never will be to make optional debug code scalable. If the above is not true then please rebuild Harbour. You cut the line about memory statistic from above test so I do not know if FM stat was enabled. If you disabled memory statistic then please also think about using HB_FM_WIN_ALLOC instead of default HB_FM_DL_ALLOC. Probably default windows allocator used instead of dlmalloc can make some results better but it will not make any fundamental difference. IMHO in both cases the final results are fatal and unacceptable. I'm working only with Linux but I'll try to find some time to make some test with real windows and to create some much more friendly MT memory manager for this OS. Maybe also I'll invest time to resolve some other multiplatform problems. But I would like to know what memory manager was used in you Harbour builds. > Why total time and real time are equal on first test ? because I do not know function which in xbase++ returns process only time. In Harbour, CLIP and FLAGSHIP there is a function secondsCPU() which returns how much time OS invest in the process. The time is calculated for each process separately. It means that if some other process make some different operations, f.e. you are executing some ZIP compression or decompression then it should not effect application time and only real time will be bigger. Just simply OS calculates the total CPU time given to process separately to real OS time. If some other processes are active then the difference between CPU and real time is bigger. Of course due to hardware limitation executing simultanously many programs also increase the CPU time because modern computers use common L1, L2 and L3 caches for all CPUs and this caches are used for different execution contexts so are not as efficient as for single context but the difference is relatively small in comparison to increased real time in such case. In xbase++ and Clipper builds speedtst always use only one real time function to calculate the time: seconds(). If you know xbase++ wrapper to Win API GetProcessTimes() function the we should use it instead. In fact it will be good to also use get GetThreadTimes() in this test to see the exact CPU time for parallel execution but we will have to implant it also for other OS-es too. Now it's available only for OS2 builds in Harbour (thanks to Maurilio). Until we will not have common CPU usage functions we should compare only real time when we compare Harbour with xbase++. But of course the environment has to be comparable. It means that Harbour cannot be compiled with memory statistic module (default for SVN devel code) and you should use -gc3 to compile Harbour code (as we can see in this test pure PCODE/macrocompiled code evaluation is such many times slower in xbase++ then in Harbour that there is no sense to make any comparison) best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
