Live data from Hacker News

Building the fastest Lua interpreter automatically

sillycross.github.io

21–30 of 114 posts

Re: Building the fastest Lua interpreter automatically

#21
post #11

Nice to see Haskell make an appearance in an article about Lua and C/C++: > For example, at LLVM IR level, it is trivial to make a function use GHC calling convention (a convention with no callee-saved registers) This refers to the following section of [1] “cc 10” - GHC convention This calling convention has been implemented specifically for use by the Glasgow Haskell Compiler (GHC). It passes everything in registers…

Relatedly, it’s worth noting that there are really good bindings between Lua and Haskell [https://hslua.org/], used in e.g. Pandoc for plugins.

Re: Building the fastest Lua interpreter automatically

#23
post #22

What’s a stack spill?

A stack spill is passing parameters on the stack instead of in registers. It's unavoidable when the number of parameters exceeds the number of registers available for passing parameters (the parameters spill over onto the stack) or if the parameters don't fit into the registers.

Re: Building the fastest Lua interpreter automatically

#24
> Lua is concise yet supports almost every language feature one can find in dynamic languages

Having yet another terrible package manager? A non-existent ecosystem outside of checks notes game scripting and nginx? Reinvent-Everything where every developer everywhere has to reinvent everything poorly because the language is “concise” and “embeddable” and stuck in the 90s? Breaking changes between versions and interprets worse than the Python2/3 fiasco?

Yessir I do them me those “features”.

Re: Building the fastest Lua interpreter automatically

#25
post #18

Super interesting. I think using the name LuaJIT Remake steps on the toes of the existing LuaJIT and I would advise using a more original name. Anything distinctive would be better. Lua DeeJIT comes to mind, since the generator is called Deegen.

Yeah... Especially as it's not actually a JIT compiler (yet).

Re: Building the fastest Lua interpreter automatically

#26
post #23
post #22

What’s a stack spill?

A stack spill is passing parameters on the stack instead of in registers. It's unavoidable when the number of parameters exceeds the number of registers available for passing parameters (the parameters spill over onto the stack) or if the parameters don't fit into the registers.

AHHH thanks. Now that I know it's obvious from the name ;)

Re: Building the fastest Lua interpreter automatically

#29
post #11

Nice to see Haskell make an appearance in an article about Lua and C/C++: > For example, at LLVM IR level, it is trivial to make a function use GHC calling convention (a convention with no callee-saved registers) This refers to the following section of [1] “cc 10” - GHC convention This calling convention has been implemented specifically for use by the Glasgow Haskell Compiler (GHC). It passes everything in registers…

I didn't realise LLVM supported such a wide variety of calling conventions.

It would be cool if they supported OpenVMS/x86-64 calling convention–even not on OpenVMS. Why? Well, OpenVMS calling convention has this cool little feature which nobody else seems to have – the parameter count to a function is passed in a register. What this means–people always ask "how can a C variadic function know how many parameters it was passed?" And the usual answer is – you need to add an argument to explicitly pass an argument count (the computation of which can be automated using preprocessor voodoo), or you need to pass some kind of printf-style format argument, or a sentinel value (terminal NULL), or whatever. "Why can't we just have a va_count() which tells us how many arguments we were passed?" "Not possible, per the calling convention, the caller doesn't tell us."

However, for OpenVMS, there actually is such a thing as va_count() – it pulls it from that extra register (the "Argument Information Register"–which also encodes some info on their types, so you can know whether each parameter is passed in an integer register or a floating point one.) Anyway, if LLVM/Clang/etc supported OpenVMS calling convention on other platforms, they could enjoy va_count() too, you'd just have to declare that as the calling convention for your function.

Re: Building the fastest Lua interpreter automatically

#30
The author also worked on the Copy-and-Patch Compilation paper[1], I wonder if they are going to use the same idea for ones of tiers of the JIT idk if it would beat LuaJIT's JIT for code compilation speed but the machine code could be faster.

[1] https://arxiv.org/abs/2011.13127

Post reply on HN