On Fri, 14 Nov 2008, Maurilio Longo wrote: Hi Maurilio,
> I did one more test and I've found that -bm has a great impact, on memory > mostly, speedtst ST: > T029 with -bm 22 sec. > T030 with -bm 25 sec. > T029 w/o -bm 1.6 sec. > T030 w/o -bm 2.0 sec. Exactly. It has horrible performance impact when thread safe memory manager is used. It will be really nice if we can port DL malloc to OS2 and use it instead. > > BTW, from watcom docs I read: > > The "bm" option must be specified since we are creating a multi-threaded > > application. If your multi-threaded application contains more than one > > module, > > each module must be compiled using the "bm" switch. > > So, it is not enough to buil hbvmmt with bm but all libs, but, doing so, > > what > > happens when I create an ST harbour program? That I'm, actually, always > > building MT executable? The same is true for most of other C compilers which have special switches for MT model, f.e. BCC. Such options usually effects some CRTL functions and when this option is set MT safe versions of functions are used instead of faster but non MT safe ones. Sometime it's a macro not compiler switch. F.e. in older Linux systems you should recompile whole Harbour code with _THREAD_SAFE macro (C_USR=-D_THREAD_SAFE). Please remember that sometimes it's hard to exploit the potential problem cause by non MT safe functions. It's necessary to execute them simultaneously by different threads and they have to change some critical data/resources. Simply test that everything is OK is not enough to say that the final binaries are really MT safe. Harbour uses only small number of CRTL functions so it may not be easy to exploit the problem. Some functions like str*(), mem*(), etc. are MT safe so it's not a problem. But some others like *printf()/*scanf() are quite often written in two versions (MT and ST) to maximize the performance for ST mode. If you do not inform compiler that you need MT safe version then it will use ST one. In Harbour functions which we should look for are: *printf()/*scanf(), stdio FILE functions, memory manager functions, inet and/or file functions if they are not directly redirected to OS. It will be good to add to OS2 Harbour port support for native OS file operations (HB_OS2_IO) just like we have it in Win32 (HB_WIN32_IO) to eliminate potential problem. stdio FILE functions are usually used in context which should not cause troubles. Usually allocating/freeing and other internal operations on FILE structures are MT safe if only one thread access given FILE structure and MT safe version introduce only internal protection for accessing FILE structure by more then one thread. The *printf()/*scanf() functions family may be such problem. Anyhow MT safe version here should not cause important for us speed overhead. The only one real problem is memory manager which have to be MT safe and which may cause huge speed overhead for final Harbour applications. We have such situation in OpenWatcom. MM causes the whole speed overhead you can see when -bm option is used. Here DL malloc though not perfect for MT programs due to pure scalability can be sufficient solution. But it will have to be ported to OS2. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
