Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 8:03 PM +0200 5/27/03, Leopold Toetsch wrote: >>... . We need some tests, from which size memory is >>cleard for malloc and memalign.
>>I tossed the memset for now and saved ~450.000 L2-misses or ~0.2 s. > While I didn't see any memsets in smallobject.c, I'm really, *really* > uncomfortable counting on implied behavior. First, I did write above sentence - "We need some tests...". Second, in malloc.c (UTSL) its clearly stated that mmap() does yield zeroed memory. So, for linux and this size of allocation its save to assume that the memset is not necessary. That's it. LEA (and glibc) malloc have the same assumptions. The memset() is in #22337. Dan Sugalski <[EMAIL PROTECTED]> wrote: > It seems that what we really ought to do is make zero-page memory > allocation system specific, or jsut rely on calloc and hope that the > underlying system libraries do that as efficiently as they can. We currently have malloc and calloc used. Some of the smaller malloced items are cleared then with low impact. But what we really need (for my patch) is zeroed and aligned (rather big) memory and we need this fast. The current (CVS) does calloc #define POOL_MAX_BYTES 65536*128 for the biggest pools (used in stress tests). Actually this should read arena and ARENA_MAX_BYTES, BTW, its a per pool->arena size limit. This memory is already cleared by the operating system. I did (some months ago) submit a test program, from which size on mem is returned cleared. The problem is not, "counting on implied behaviour", the problem, is can we have a memalign() for a specific size, that yields zeroed memory, where size is rather big - in regions where calloc() AFAIK all return zeroed memory. If calloc() would use memset() to clear the memory you could forget all performance. $ man memalign No manual entry for memalign :-(( leo
