Home » Community » U++ community news and announcements » Core 2019
|
Re: Core 2019 [message #51935 is a reply to message #51934] |
Fri, 21 June 2019 20:28 |
Novo
Messages: 1371 Registered: December 2006
|
Ultimate Contributor |
|
|
My version of libc:
$ /lib/x86_64-linux-gnu/libc.so.6
GNU C Library (Ubuntu GLIBC 2.29-0ubuntu2) stable release version 2.29.
Regards,
Novo
|
|
|
|
|
Re: Core 2019 [message #51938 is a reply to message #51937] |
Sat, 22 June 2019 10:23 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
Well, from what I see, the real difference is that U++ "keeps" the address space...
Maybe you can strace both allocators and grep for mmap / munmap?
Also, profile after the CoWork would be nice to know.
Mirek
[Updated on: Sat, 22 June 2019 10:57] Report message to a moderator
|
|
|
Re: Core 2019 [message #51939 is a reply to message #51938] |
Sat, 22 June 2019 17:49 |
Novo
Messages: 1371 Registered: December 2006
|
Ultimate Contributor |
|
|
mirek wrote on Sat, 22 June 2019 04:23Well, from what I see, the real difference is that U++ "keeps" the address space...
Maybe you can strace both allocators and grep for mmap / munmap?
Also, profile after the CoWork would be nice to know.
Mirek
Attached.
Just mmap and munmap do not tell much.
glibc calls brk a lot as well.
Profile after the CoWork was posted in this message.
Regards,
Novo
|
|
|
|
|
|
|
|
|
Re: Core 2019 [message #51947 is a reply to message #51944] |
Mon, 24 June 2019 06:13 |
Novo
Messages: 1371 Registered: December 2006
|
Ultimate Contributor |
|
|
mirek wrote on Sun, 23 June 2019 04:19It would probably be worth to experiment with HPAGE constant... Can be any number >16.
I'm afraid I cannot afford to spend time on U++'s allocator anymore.
I'm switching to the glibc's one for the time being.
It would be great to see jemalloc and tcmalloc integrated into U++ because they are supposed to be better at avoiding fragmentation.
Regards,
Novo
|
|
|
|
|
Re: Core 2019 [message #51951 is a reply to message #51950] |
Mon, 24 June 2019 18:42 |
|
mirek
Messages: 14039 Registered: November 2005
|
Ultimate Member |
|
|
Novo wrote on Mon, 24 June 2019 17:36mirek wrote on Mon, 24 June 2019 03:22
Based on this, I do not see any defect or deficiency, except the choosen one (keep the memory).
Well, I do not think that taking from the system 4.6Gb when the app is allocating ~400Mb is acceptable.
Default behavior of glibc's allocator is optimized for huge enterprise-level apps, but with some manual tweaking it performs fine with small apps. jemalloc would perform even better, I believe.
Well, app actually IS allocating ~4.5 GB at the peak, that is what all indicators show - or have I got that wrong?
So it is really a question of priorities. Do we want to unmap that memory or keep it for the future use as mmap/munmap are quite expensive calls? This was the question I have asked and at that time the answer was: "we want to keep it". Now I am not so sure...
Looks like we need MemoryOptions and/or MemoryShrink...
Anyway, back to drawing board...
Mirek
|
|
|
|
|
|
|
Goto Forum:
Current Time: Sat Sep 21 03:01:58 CEST 2024
Total time taken to generate the page: 0.02934 seconds
|