On Tue, 24 Nov 2009, Mindaugas Kavaliauskas wrote: Hi,
> > * harbour/src/vm/fm.c > > * enabled HB_FM_DLMT_ALLOC by default in MT HVM if HB_FM_DL_ALLOC is > > also enabled > BTW, what is HB_FM_DLMT_ALLOC performance in comparison to native > Linux malloc() (in MT mode of cause)? It's not trivial to well compare performance of different memory allocators in MT mode. To give precise answer we should prepare some series of dedicated tests anyhow using speedtst.prg in different mode we can create basic tests and the performance seems to be quite good. In practice the same as with NEDMALLOC or PTMALLOC but this is nearly the same code so it's expected. DLMALLOC is compiled as part of Harbour core code with strong optimization switches and well optimized as part of hvmall.c so it's usually a little bit faster in all tests. SUSE Linux uses Hoard Memory Allocator which seems to be the best memory allocator for MT mode. In older SUSE builds I made some tests on x...@32 and it was always faster then DLMALLOC in ST and MT modes. Recently I've repeated test with SUSE 11.2 x...@64 and in ST mode DLMALLOC is faster but slower in MT mode. I guess that faster ST mode is mostly result of better optimizations when DLMALLOC is compiled as part of hvmall.c. In MT mode is slower but the difference is not very huge in concurrent access when HB_FM_DLMT_ALLOC is enabled, here are results you can compare: 1) ./speedtst DLMALLOC ST mode: [ total application time: ]....................................15.47 [ total real time: ]...........................................15.47 Hoard ST mode: [ total application time: ]....................................16.76 [ total real time: ]...........................................16.78 2) ./speedtst DLMT MT MODE: [ total application time: ]....................................19.58 [ total real time: ]...........................................19.59 Hoard ST mode: [ total application time: ]....................................18.50 [ total real time: ]...........................................18.50 3) ./speedtst --thread DLMT [ total application time: ]....................................26.65 [ total real time: ]............................................9.73 Hoard: [ total application time: ]....................................24.37 [ total real time: ]............................................8.68 4) ./speedtst --thread=3 --scale DLMT: [ TOTAL ]_________________________________ 59.95 29.64 -> 2.02 [ total application time: ]...................................147.05 [ total real time: ]...........................................89.60 Hoard: [ TOTAL ]_________________________________ 57.93 32.01 -> 1.81 [ total application time: ]...................................149.78 [ total real time: ]...........................................89.95 As you can see in the last test DLMT has even better scalability what allows to reduce the speed difference and DLMT was finally a little bit faster. Anyhow this test uses only 3 threads which very nicely play with DLMT and I expect that when much bigger number of threads is used on multi CPU hardware then Hoard will be more efficient i.e. in test (3) we have 56 threads and here Hoard is still faster. But of course it does not change the fact that DLMT results are really good. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
