Hacker News Reader

Comment by lowry | Hacker News Reader

Most of the changes are removals of architectures other than x86_64. What a joke.

From the comment on commit which removed 50,000 lines of code: `The only supported platform is now Linux/x86-64 with JIT+FFI+GC64.`

And the readme: `Reduced code maintenance footprint ~50% by removing #ifdef features that are not required for Linux/x86-64 e.g. Windows support, 32-bit heap support, and non-x86 backends. This is a necessary short-term expedient to make the code maintainable while we bootstrap the project.`

I wonder how that 50,000 lines was broken down by feature...

To be fair, when I was using Lua a decade ago, LuaJIT mostly only supported Linux and x86-64. Mike was adding new architectures and variants on request and when people would pay him to do so, while the core was both mostly sufficient and still improving. Those 50,000 lines did come after x86-64, if you wanted to move the project in a different direction it seems sensible to strip them out, make your changes. As long as your changes a rent too drastic, it should be comparatively easy to put them back in.

Each architecture had a hand coded interpreter. The plan is to write a portable interpreter in C.

Are you willing to contribute to the port? Don't rubbish other peoples' work unless you've got something better to replace it with.

good point, but i think we can admit the title is weird if the only support is x86-64

RaptorJIT is good for writing applications like Snabb. Snabb is a networking framework that’s very low level: cycle-counting loops, device drivers, DMA, etc, in Lua. In this domain of high performance software networking the advantages of supporting other architectures don’t currently outweigh the costs.

That’s why it’s a low-level system programming language that prioritizes working very well on x86-64 over supporting other platforms like 32-bit heap, MIPS, Xbox, no FPU, etc. Just got bigger fish to fry right now.

> no FPU.

How much of a hit does floating point math take? I have a desire to build some realtime audio tools.

The wording is confusing it does support fpu it doesn’t support machines without fpu.

It seems pretty clear to me. It doesn't support "no fpu". It's a lazy way of putting it though and "Architectures without FPU" would have been clearer.

AFAIK it is not about float perf.

LuaJIT uses NaN-tagging to represent Lua values in memory to save space.

Float64 numbers can be left alone, and other types are represented as NaN with the pointer bits stashed in the mantissa part of the float. Only one, canonical NaN value is recognized as such by the language, the others are disguised 32 bit pointers.

On microcontrollers, you might as well change to lookup tables if you are trying to do something real-time with more than 100 operations per millisecond.

This varies by microcontroller obviously.. this comes from reimplementing GLSL shadertoy samples for a neopixel grid.

Realtime audio sounds like a good domain. You might also want to check out LuaRadio if you haven't already. http://luaradio.io/

Yeah, 32-bit, Xbox and no-FPU platforms can be dropped, but dropping FreeBSD, aarch64 and powerpc64 is kinda sad.

Does that mean ARM64 is still supported?

Reply on news.ycombinator.com