Hacks of Life

I hooked up LuaJIT to emacs for fun. Emacs recently released a new module system where you can build DLLs that are loaded dynamically: http://diobla.info/blog-archive/modules-tut.html

Getting LuaJIT to work on 64-bit OS X required building a custom emacs with linker flags -pagezero_size 10000 -image_base 100000000. This is unfortunate since obviously users will not take the time to build an emacs with custom linker flags. But more generally, this is an issue any time you want to embed LuaJIT in an application plugin rather than the application itself.

There's a bunch of scattered info about the issue:

https://gist.github.com/nddrylliog/8722197

http://hacksoflife.blogspot.fr/2012/12/integrating-luajit-with-x-plane-64-bit.html

https://en.blog.nic.cz/2015/08/12/embedding-luajit-in-30-minutes-or-so/

http://luajit.org/install.html

I was hoping there might be a way of sidestepping the issue somehow. If anyone has any ideas, it would be appreciated. LuaJIT has some nice speed improvements compared to standard Lua, but more importantly it has a pretty amazing FFI library. The C declaration parser in particular is valuable.

(Yes, I know it's pointless to hook LuaJIT to emacs. It's mostly a "just because" project.)

Unfortunately dynamic buffer updates is one of the tricky parts to do right in OpenGL since you need to assume what the driver does under the hood, and the best technique depends on what GL version you're targeting, and what GL extensions are available.

I found this blog post very useful: http://hacksoflife.blogspot.de/2012/04/beyond-glmapbuffer.html

If you can afford to target bleeding edge OpenGL, the AZDO slides contain the current state of the art (there's a whole section about dynamic buffer updates somewhere in there): http://www.slideshare.net/CassEveritt/approaching-zero-driver-overhead?related=1

On WebGL, the established tricks like buffer orphaning don't work, and direct mapping isn't available. It seems best to simply do a bufferSubData and not care about double buffering etc (https://groups.google.com/forum/#!searchin/webgl-dev-list/floooh/webgl-dev-list/vMNXSNRAg8M/lu1NkJ22J_YJ)

my biggest annoyance with LuaJIT is the lack of 64-bit addressing, and there's no easy fix for this. Mike Pall said he'd fix it in LuaJIT 3.0 (with an overhaul of the GC), whenever that'll be.

http://hacksoflife.blogspot.com/2012/12/integrating-luajit-with-x-plane-64-bit.html

Edit: to clarify, this does not mean torch cant use more than 2GB, but native lua allocations cant be more than 2GB, so ffi-based or C based allocations (which is how torch tensors are allocated) have no such limits.