Re: typedef void * (*lua_Alloc) caching

[C++ RTMP Server <crtmpserver@...>]

On Apr 5, 2011, at 9:20 PM, Dimiter malkia Stanev wrote:

> 	Providing (*lua_Alloc) would make sense for certain applications, and probably not for others. Making lua to call directly malloc/free/etc. would just make programmers change that (source wise, or through linker tricks).
> 
> 	In general you can't say which memory manager is better than the other.
> 
> 	For example a game with well tested levels, can accumulate enough watermarks for what kind of allocation/sizes are needed, and preallocate buckets for each level. That would beat any general allocation algorithm, but you can't use it for anything else than your game, and a lot of QA is needed to collect the memory watermarks for each allocation size (or combined sizes).
exactly my point :) particular mempool for particular app :)


> 
> On 4/5/2011 7:01 AM, C++ RTMP Server wrote:
>> 
>> On Apr 5, 2011, at 4:43 PM, GrayFace wrote:
>> 
>>> On 04.04.2011 15:03, C++ RTMP Server wrote:
>>>> I have done extensive tests with mem allocations and the things are looking pretty ugly when allocating/deallocating mem which is not PAGE_SIZE aligned. When one requests 564 bytes for example, the allocator will alloc PAGE_SIZE increments anyway (which is usually 4096 bytes). So is a total waste of resources NOT to use that buffer in the future: just make it PAGE_SIZE and re-use it when the time comes. Even with this little optimization the things are looking far brighter.
>>> 
>>> I'll never believe that the default allocator doesn't reuse this buffer.
>> Is not a matter of re-using the buffer. Of course it re-uses it!. The interesting part is how fast it can give you the new mem region. Standard allocators are written with multi-thread in mind (locks/mutexes/semaphores are used). You can have single-threaded mempool which is much much faster. What I'm trying to say here is that in some particular cases (like mine, with single-threaded app), I'm shooting a fly with the tank using standard malloc/free.
>> Also, the tests shown and the ones made by me clearly underlines that with mempool is faster than without it. Much faster!
>> 
>>> 
>>>> I totally agree: sometimes the compiler can do wonders and the app runs much smoother without mempool. But that can be experimented and the mempool can be (de)activated at compile time depending on the target platform used.
>>>> 
>>>> What I learned so far, is that solely relaying on the mem allocator and abuse it thinking that will cope with all the possible situations, is a very bad practice. mem alocators are not gods :)
>>> 
>>> Mempool is just another mem allocator, isn't it? Or rather just one of approaches used by mem allocators. For example, http://goog-perftools.sourceforge.net/doc/tcmalloc.html basically uses this approach as I understand.
>> I'm not a big expert, but it looks like it. All I did is to create real-world scenarios using my particular env and saw that is working faster. Also confirmed by the first link I gave here
>> 
>>> 
>>> As for Lua, it has very few statically-sized structures, meaning they can be efficiently allocated with exact size. Vectors are usually grown by multiplying size by 2, which may or may not be of use for memory allocator. However, for the most part I guess Lua is a pretty ordinary 'client' of mem allocator.
>>> 
>>> P.S. I'm also new to the subject.
>> 
>> Suppose I'm wrong and the standard allocator (whatever that might be) on the target machine is considered the big daddy in terms of performance, than why bother implementing lua_alloc function!? Why not remove it and just relay on the platform-indepedency layer of lua to pick up the correct allocator. It would be definitely easier :) What would be the purpose of lua_alloc function?
>> 
>> Cheers,
>> Andrei
>> 
>>> 
>>> --
>>> Best regards,
>>> Sergey Rozhenko                 mailto:sergroj@mail.ru
>>> 
>>> 
>>> 
>> 
>> ------
>> Eugen-Andrei Gavriloaie
>> Web: http://www.rtmpd.com
>> 
>> 
>> 
> 
> 

------
Eugen-Andrei Gavriloaie
Web: http://www.rtmpd.com