On Thu, 25 Sep 2008, Maurilio Longo wrote: Hi Maurilio,
> > Thank you very much for the information. It means that dlmalloc.c > > will have to be updated to use native OS2 API in the future if it > > works as expected for Windows users. > > Probably you are the best person to make it in such case :-) > I was looking at dlmalloc, so I decided to try the test program from Pritpal > (message of september, 18th), on OS/2, latest cvs code, hbrun with vmmt linked > in I can add nearly 816000 items before I get a realloc error. > 809000 > 810000 > 811000 > 812000 > 813000 > 814000 > 815000 > 816000 > Unrecoverable error 9009: hb_xrealloc can't reallocate memory > Called from AADD(0) > Called from MAIN(6) in pcode.hrb > Called from HB_HRBRUN(0) > Called from _APPMAIN(114) in ../../hbrun.prg > Now it has to be said that on OS/2 a program can allocate a maximum of 512Mb > (actually you top around 450-500Mb) because this is the virtual address space > assigned to each process. The problem is that this code _ALLOCATES_ such huge amount of memory when in fact it needs much more. It's caused by uneficient memory manager. When this program finish after 1'000'000 iterations then MEMORY( HB_MEM_USEDMAX ) shows 48'176'447. This is totatl memory allocated by Harbour. The rest is MM overhead. Memory conservative MM should not allocate more then ~twice memory ~ 100MB. Good MM with automatic preallocation for future resising but also tuned to safe memory should allocate about three times more memory ~150MB. In my Linux box for such test it's 144MB. _Exactly_ 3 times more (classic algorithm). And results are very close to DL-MM results. The default MM in GCC for OS2 is not clever enough to rach such results and allocates much more memory then necessary probably also highly reducing performance because it suggest that array resize (AADD()) forces two often phisical memory realloction of array body to newly alocated blocks. > It is possible to use more memory calling specific APIs, but a pointer to a > block into this memory, called 'high memory', cannot be passed to all OS/2 > APIs. So it is of limited use. OK, fine. Each OS has such limit. F.e. to speed up Linux system you can limit maximum process memory to 1GB and in such case system can use fixed addreses for kernel and user space so switchin between them (calling any kernel level function) does not force memory descriptor overloading. Very nice feature which give real high speed imporvement. But it's not the problem we are talking about. The real problem is that MM you used allocated more then ~150 of physical memory for this _whole_ test. In the place where it fails for you DL-MM should not need more then ~120MB. > That said, I think that porting dlmalloc to OS/2 is a waste of time without, > probably, any real advantage in terms of speed or stability (I see from > dlmalloc.c that it is not well suited for mt programs since it uses a global > lock which can become the bottleneck). > Those above are my two cents :) I think that you haven't noticed where is the problem and you take wrong conclusions. The MM behavior is also important for us to take decision about out own prealocations, f.e. in array add. Looks that good MM can made it very efficiently respecting also other memory requirements so we do not have to implement it ourselves for only chosen things, f.e. arrays body reducing the MM choices. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
