Legend has it that after completing his mission, he returned to a future where performant JIT compilers have ensured world peace and the prosperity of mankind for thousands of years.
I've met Mike Pall in person. I've worked with him some since I helped facilitate a sponsorship from Google (https://opensource.googleblog.com/2010/01/love-for-luajit.ht...). A lot of his work on LuaJIT has been supported by various sponsorships (see: https://luajit.org/sponsors.html). This gives him a lot of freedom to work the way he wants to, instead of working as part of a larger organization.
Also note that the sponsorship page says that Mike is currently working on "unrelated projects", so apparently things besides LuaJIT are keeping him busy now.
I don't know that much about his background. I didn't get much of a chance to talk shop with him (which is too bad, I would have loved to pick his brain about all sorts of things). I also assume from the lack of info about him on the Internet that he's a somewhat private person, so I definitely wanted/want to respect that.
I'm not sure what the status is on either, though; they're obviously completely different implementations so it's not clear which one of these is preferable (also both authors seem to be busy with other stuff recently).
The new garbage collector should be based on well-researched and proven algorithms, together with a couple of thoroughly evaluated innovations, where appropriate. The real innovation should be in the specific mix of techniques, forming a coherent and well-balanced system, with meticulous attention to detail and relentless optimization for performance.
Sometimes I feel there's an inverse correlation between the strength of claims for the future and the end result.
Is there something about lua that makes it amenable to the performance of luaJIT? In priciple, would it be possible to get comparable performance out of something like pypy?
In other words: is getting pypy to perform like luajit "just" a matter of time/money/expertise, or are there technical considerations?
TBH that was the spirit of my question. I was wondering if there was something special about Lua (the language), and it seems like the answer is a resounding "no".
I'm not sure I could call that "resounding" - for one a PyPy dev disagreed with him in a sibling thread.
> Yes, you can go a long way without extra APIs etc, but sometimes there is info that's available, that's simply not there, because it's only in a programmers head.
24 comments
[ 0.29 ms ] story [ 59.7 ms ] threadhttps://github.com/LuaJIT/LuaJIT/commits/v2.1
Also note that the sponsorship page says that Mike is currently working on "unrelated projects", so apparently things besides LuaJIT are keeping him busy now.
- https://github.com/fsfod/LuaJIT/commits/gcarena - https://github.com/corsix/LuaJIT/commits/newgc
I'm not sure what the status is on either, though; they're obviously completely different implementations so it's not clear which one of these is preferable (also both authors seem to be busy with other stuff recently).
https://news.ycombinator.com/item?id=4053969
Github issue, which Mike said "is up for takers":
https://github.com/LuaJIT/LuaJIT/issues/38
Sometimes I feel there's an inverse correlation between the strength of claims for the future and the end result.
In other words: is getting pypy to perform like luajit "just" a matter of time/money/expertise, or are there technical considerations?
Well, nothing really. It's just a matter of engineering, i.e. man-years put into the VM and the compiler.
He has a few posts on Reddit regarding this subject: https://www.reddit.com/user/mikemike
What in your opinion keeps LuaJITs performance away from C/C++, i.e. what other "hard" things need to be solved?
So basically, I should donate to pypy...
> Yes, you can go a long way without extra APIs etc, but sometimes there is info that's available, that's simply not there, because it's only in a programmers head.
https://www.reddit.com/r/programming/comments/19gv4c/why_pyt...