Re: ffi.new vs ffi.C.malloc speed
- From: Ronan Collobert <ronan@xxxxxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Wed, 10 Oct 2012 17:53:47 +0200
> If this is from the same code path, you could simply allocate the
> smaller ones with ffi.new() and the others with malloc. From the
> users point of view the resulting objects behave the same.
Yep I could -- Javier just mentioned this also. The problem is then where to
put the threshold. 64 bytes is really small for us ;) [in the benchmark i was
using a small array only to show the difference in allocation/deallocation
speed without swamping my computer]
Say my threshold is 40000 bytes (which starts to be reasonable. it is 10K
floats). Because of the 2GB memory management limitation, I can only allocate
53K of these. In practice, it is not enough... users always come up this crazy
algorithms ;)
But do not worry for this, I will deal with it -- I wanted to know (1) if I
missed something and (2) what were your future plans there, which you just
mentioned.
> Calling a finalizers means setting up a frame etc. and calling
> into the VM to run the finalizer. That's costly. Sure, I can
> imagine a shortcut if the finalizer is a FFI C function (on my
> TODO list for 2.1), but it won't be free either.
Thanks for the clarification. I am glad it is on your todo list, he he...
> Also, the GC for LuaJIT 2.0 and 2.1 handle allocated objects very
> differently. There's no explicit 'free' call anymore with the new
> GC, which makes deallocation very cheap (sweep phase). For objects
> with finalizers one has to manage an explicit list. And traverse
> the list and check the objects at strategic points, too. None of
> that overhead is necessary for objects without finalizers.
Ok, that is clear. Again, thanks for the _cool_ work, I can't tell how much
luajit helps me for the next version of my software. It is lua^10.
Ronan
[And, btw, thanks for the quick reply]
Other related posts:
