4 ms·

(Side note: I'm happy to see that shilling your patreon is becoming a socially accepted norm. Best of luck with your work!) One thing I was surprised by: LuaJI

(Side note: I'm happy to see that shilling your patreon is becoming a socially accepted norm. Best of luck with your work!) One thing I was surprised by: LuaJIT doesn't compile on an M1. LuaJIT 2.1.0 technically compiles, but it core dumps whenever you have a syntax error, which makes it quite a bit less useful. A reason for this might be due to the lack of __threadlocal support in M1's (apparently, or so says clang). Is there some way this could be addressed in the Linux work? I'm not sure I have a coherent question here, but my goal is mainly (a) to express surprise that LuaJIT, of all things, doesn't run on an M1, and (b) to maybe suggest that it would be cool as heck to have it running in the Linux M1 work as a benchmark, if possible. I'd hate to see such a wonderful tool get left behind by the new arch.

ithkuil 6y ago
Have you tried to use the zld linker to build luajit?
otabdeveloper4 6y ago
LuaJIT is extremely impressive engineering, but also a giant pile of hacks and shortcuts. I'm not surprised.
tyingq 6y ago
>lack of __threadlocal support in M1 An informative post about this from the Zig folks: http://www.jakubkonka.com/2021/01/21/llvm-tls-apple-silicon.html http://www.jakubkonka.com/2021/01/21/llvm-tls-apple-silicon....
- comex 6y ago
  That's not a lack of support, it's just LLD, the LLVM linker, being broken. I hear LLD for Mach-O is being worked on again, after a long period of stagnation where it was sort of but not fully working. But the default linker on Apple platforms is still ld64.
  - tyingq 6y ago
    I'd give them a little more grace. It sounds like the M1 requires a different approach than other ARMV7 cpus, and that fact wasn't documented. Mimalloc had to trudge through the same thing: https://github.com/microsoft/mimalloc/issues/343 https://github.com/microsoft/mimalloc/issues/343
    - comex 6y ago
      Well, in theory, Zig doesn't need to care about the specific approach. In the LLVM IR that Zig produces, thread-local variables are still handled as an abstract "thread_local" flag on global variables. The platform-specific parts are handled by a combination of the IR-to-native-object-file translation done by LLVM, and the linking step. If both of those worked correctly, thread locals would "just work" on M1. The problem is that (a) Zig uses LLD for linking and (b) LLD is buggy. I'm not surprised that Zig is using LLD. Zig wants to be fully self-contained, able to cross-compile for any supported platform without requiring the user to install a toolchain for that platform. And they already use LLVM for code generation, so LLD for linking is the natural choice. It's a beautiful vision - really. Toolchain installation sucks. And the stuff they're doing with processing and bundling OS C headers [1] is quite innovative. It's just that using LLVM for everything is not a reality for Apple platforms yet. Hopefully it will be soon, once Apple whips LLD into shape. Edit: mimalloc is different; it reimplements thread-local storage by hand, using `asm` statements, rather than using native `thread_local` variables, presumably because the latter can be slow. [1] https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
      - shawnz 6y ago
        I think the parent poster is saying that LLD needs to take a different approach, not Zig. But it wasn't previously known what approach that would need to be, since M1 does it differently than other ARM CPUs. Therefore there's no expectation that LLD could have gotten it right.
        6y ago

ithkuil 6y ago

Have you tried to use the zld linker to build luajit?

otabdeveloper4 6y ago

LuaJIT is extremely impressive engineering, but also a giant pile of hacks and shortcuts. I'm not surprised.

tyingq 6y ago

>lack of __threadlocal support in M1 An informative post about this from the Zig folks: http://www.jakubkonka.com/2021/01/21/llvm-tls-apple-silicon.html http://www.jakubkonka.com/2021/01/21/llvm-tls-apple-silicon....

comex 6y ago
That's not a lack of support, it's just LLD, the LLVM linker, being broken. I hear LLD for Mach-O is being worked on again, after a long period of stagnation where it was sort of but not fully working. But the default linker on Apple platforms is still ld64.
- tyingq 6y ago
  I'd give them a little more grace. It sounds like the M1 requires a different approach than other ARMV7 cpus, and that fact wasn't documented. Mimalloc had to trudge through the same thing: https://github.com/microsoft/mimalloc/issues/343 https://github.com/microsoft/mimalloc/issues/343
  - comex 6y ago
    Well, in theory, Zig doesn't need to care about the specific approach. In the LLVM IR that Zig produces, thread-local variables are still handled as an abstract "thread_local" flag on global variables. The platform-specific parts are handled by a combination of the IR-to-native-object-file translation done by LLVM, and the linking step. If both of those worked correctly, thread locals would "just work" on M1. The problem is that (a) Zig uses LLD for linking and (b) LLD is buggy. I'm not surprised that Zig is using LLD. Zig wants to be fully self-contained, able to cross-compile for any supported platform without requiring the user to install a toolchain for that platform. And they already use LLVM for code generation, so LLD for linking is the natural choice. It's a beautiful vision - really. Toolchain installation sucks. And the stuff they're doing with processing and bundling OS C headers [1] is quite innovative. It's just that using LLVM for everything is not a reality for Apple platforms yet. Hopefully it will be soon, once Apple whips LLD into shape. Edit: mimalloc is different; it reimplements thread-local storage by hand, using `asm` statements, rather than using native `thread_local` variables, presumably because the latter can be slow. [1] https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
    - shawnz 6y ago
      I think the parent poster is saying that LLD needs to take a different approach, not Zig. But it wasn't previously known what approach that would need to be, since M1 does it differently than other ARM CPUs. Therefore there's no expectation that LLD could have gotten it right.
      - 6y ago