Finding out minimal allocation unit
in [ADA]
|
From: Robert A Duff on 4 Apr 2007 13:16 Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS(a)ANDTHATm-e-leypold.de> writes: > Stefan Bellon <sbellon(a)sbellon.de> writes: > >> Martin Krischik wrote: >> >>> So I believe the OP wanted to know how to find out how much memory >>> for "new"ed object is allocated in total in order to know if extra >>> optimisation is needed. >> >> Exactly. :-) > > > I'm only guessing, but here is my approach for GNAT: GNAT is AFAIK > linked against libc (at least on Unix). On linux that is glibc, which > provides methods to catch/trace malloc() requests. My suggestion is > that you do that and look which sizes are actually requested from > malloc(). That won't quite give the right answer, because malloc() adds a couple of words or so to what was requested. - Bob
From: Stefan Bellon on 5 Apr 2007 02:12 Randy Brukardt wrote: > But that isn't really a meaningful question. It clearly depends on > the storage pool, and if the storage pool comes from somewhere else, > it may even depend on the OS version you are running. For instance, > the standard storage pool in Janus/Ada uses a standard Windows heap. > Those exhibit vastly different behavior on Windows 95 than Windows > 2000, and somewhat different on almost every version of Windows. I don't agree that it isn't a meaningful question because of that. Quite the contrary. _Because_ we realize that there are differences, we'd like to find out the allocation strategy in order to optimize for that. > Rule of thumb: if the behavior of the standard storage pool actually > makes a difference in your application, then don't use it! Ok, this is an alternative to think about. > Write your own storage pool that has the behavior you need. It's > relatively easy to do, especially if you have fixed size elements. > And then you can effectively use an array to allocate elements and > still have cheap insertion and deletion and reordering. I'm a bit unclear about how to do it. Do I implement the Allocate using the standard storage pool (i.e. using 'new') or do I interface it directly to the underlying C library (i.e. using 'malloc')? In both cases I still have the same problem as above. Are there examples of such a storage pool implementation around? -- Stefan Bellon
From: Martin Krischik on 5 Apr 2007 03:35 Stefan Bellon wrote: >> Write your own storage pool that has the behavior you need. It's >> relatively easy to do, especially if you have fixed size elements. >> And then you can effectively use an array to allocate elements and >> still have cheap insertion and deletion and reordering. > > I'm a bit unclear about how to do it. Do I implement the Allocate using > the standard storage pool (i.e. using 'new') or do I interface it > directly to the underlying C library (i.e. using 'malloc')? In both > cases I still have the same problem as above. First we need to know which platform you are using (compiler/OS). Then: how a storrage pool get's it memory is up to the pool designer. In your case you could allocate a large chuck of memory strait from the OS and then sub-allocate it using an algorithm optimised for your needs. You spoke of storing data inside an array - which suggest all elements have the same size. Then you optimised storrage pool won't need keep track of the allocation size - something a universal pool needs to do. Martin -- mailto://krischik(a)users.sourceforge.net Ada programming at: http://ada.krischik.com
From: Robert A Duff on 5 Apr 2007 09:07 Stefan Bellon <sbellon(a)sbellon.de> writes: > Randy Brukardt wrote: >> Write your own storage pool that has the behavior you need. It's >> relatively easy to do, especially if you have fixed size elements. >> And then you can effectively use an array to allocate elements and >> still have cheap insertion and deletion and reordering. > > I'm a bit unclear about how to do it. Do I implement the Allocate using > the standard storage pool (i.e. using 'new') or do I interface it > directly to the underlying C library (i.e. using 'malloc')? In both > cases I still have the same problem as above. There are many ways to do it. In your case, you have a large number of small objects. In that case, it would make sense to allocate large chunks of memory (possibly using "new"), and then have Allocate chop them up into small pieces on request. If all objects are the same size, then Deallocate can put things on a single free list. If you have a small number of different small sizes, you can have one free list per size. The chunks might be of type Storage_Array, or might be an array-of-<your-type>, depending on what's convenient. This is low level programming. If you mess up, you will have nasty bugs. > Are there examples of such a storage pool implementation around? I don't know. There should be. If I ever get enough spare time, I might create a library of useful pools, if such a thing doesn't already exist. - Bob
From: Markus E Leypold on 5 Apr 2007 04:55
Robert A Duff <bobduff(a)shell01.TheWorld.com> writes: > Markus E Leypold > <development-2006-8ecbb5cc8aREMOVETHIS(a)ANDTHATm-e-leypold.de> writes: > >> Stefan Bellon <sbellon(a)sbellon.de> writes: >> >>> Martin Krischik wrote: >>> >>>> So I believe the OP wanted to know how to find out how much memory >>>> for "new"ed object is allocated in total in order to know if extra >>>> optimisation is needed. >>> >>> Exactly. :-) >> >> >> I'm only guessing, but here is my approach for GNAT: GNAT is AFAIK >> linked against libc (at least on Unix). On linux that is glibc, which >> provides methods to catch/trace malloc() requests. My suggestion is >> that you do that and look which sizes are actually requested from >> malloc(). > > That won't quite give the right answer, because malloc() adds a couple > of words or so to what was requested. And I thought it would exactly be the extra padding the OP was interested in? Regards -- Markus |