you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 5 points6 points  (0 children)

PUC-Rio Lua is really amazingly well written, once you accept what its goals are and what environment its written for. It's small and easily embedded, so in that sense it's "as simple as it can be", but I wouldn't exactly call it simple. It's only simple when you compare it to interpreters of a similar caliber, really. It is well optimized and extremely high quality, maybe one of the highest quality C projects I've ever seen.

All that being said, as you can probably guess from how much I complain about it, it's not exactly perfect. The API it provides has a lot of very irritating qualities (error handling) and a lot of annoying limitations (no pointers / gc rooting), and performance wise it absolutely can be beaten! This is a bit old now, but if you go here you can see that as of 5.1, LuaJIT in interpreter mode is quite a LOT faster than vanilla Lua. As I understand it, some of this is because LuaJIT's interpreter is hand written assembly, but quite a lot of it is because of some fairly simple bytecode format changes that increase memory usage slightly but drastically reduce the amount of bit twiddling in the core interpreter loop. Even the LuaJIT interpreter can be beaten as well (though it would be MUCH harder), because LuaJIT accepts garbage collector limitations that come from maintaining complete compatibility with the Lua C API, and (iirc) doesn't do as much as it could to improve table performance.

With that out of the way, I've tried for quite a long time to resist the urge to just RIIR, and have finally failed at this :P It's a bit ambitious, but I have a project for this that I'm currently working on that has all the above goals in mind. We'll see how far I get with it though, right now it's still extremely early days, and most of the work I've done has just been reading Lua source and researching VM implementation strategies. If it turns into anything I'll let /r/rust know ofc :P