5 ms·

Pallene unfortunately is only a subset of Lua, i.e. you cannot simply take a Lua program and compile it with Pallene. The use case of this language is not obvio

by Rochus 2y ago

Pallene unfortunately is only a subset of Lua, i.e. you cannot simply take a Lua program and compile it with Pallene. The use case of this language is not obvious to me, since if I have to re-implement the performance-critical parts of the Lua program anyway, I can just as good implement it in C using the Lua C API. Thus the claim of the Pallene authors is a bit misleading. Concerning LuaJIT performance, I have done a lot of measurements over the years (see e.g. https://github.com/rochus-keller/Oberon/blob/master/testcases/Are-we-fast-yet/Are-we-fast-yet_results_linux.pdf https://github.com/rochus-keller/Oberon/blob/master/testcase...) and would rather say that its performance is about factor four worse on average than an equivalent C++ -O2 compiled program. For some exceptional use cases it might perform as good as C, but not in general (one reason is the missing tracing JIT support for closures).

kragen 2y ago
interesting, thank you for sharing your experience! in the example case my pixfunc is in fact not a closure, just a pure function, but it sounds like the performance would collapse if i made it a closure (you can of course compile specialized versions of the inner loop for each fractal in c; 'just' use the preprocessor) it seems plausible to me that it would be more convenient to reimplement a lua function in pallene rather than in c, especially for 'shallow' functions where the code for passing arguments and return values back and forth on the stack to lua is a substantial percentage of the total function code but there's still the question of how good or bad the performance of the code generated by the pallene compiler is! it might be worth rewriting the code in c if gcc or clang produces faster code than pallene does, even if rewriting it in pallene would be easier
- Rochus 2y ago
  The problem is actually FNEW. If you create your function on top-level and leave it as is then FNEW is only used once. But if you require e.g. nested functions, then each call to FNEW will terminate the trace. My measurement with the Smalltalk and SOM implementations using LuaJIT showed that the benchmark essentially remains in the interpreter most of the time for that reason. > it seems plausible to me that it would be more convenient to reimplement a lua function in pallene rather than in c If just Pallene would be more similar to Lua. But essentially it's a different language which just resembles Lua a bit. So you could use any language compatible with the Lua C API if you don't like C (instead of learning Pallene). You have to rewrite the performance critical parts anyway. Personally I prefer LuaJIT, since everything is Lua, and if you know enough details and do measurements, the performance is no longer a surprise. > how good or bad the performance of the code generated by the pallene compiler is There is no reason to assume that Pallene is faster than LuaJIT if things like the ones mentioned above are considered.
  - kragen 2y ago
    that must have been a huge disappointment when you ran into that problem with som! are you planning to write your own jit compiler, or is there still a way you can leverage luajit?
    - Rochus 2y ago
      I ran into stability problems with the Oberon+ FFI which I was not able to solve with the LuaJIT bytecode generator; so I switched to Mono, which even has a much better debugging infrastructure, and for speed I also implemented a C transpiler, the result of which is very close to the native C++ implementation. SOM was mostly an effort to find out how close we can come to Cog with a LuaJIT backend, as a follow-up to my Smalltalk LuaJIT adventure.
      - kragen 2y ago
        i see! hmm, are you going to have to switch to .net core now? or are mono users succeeding in banding together to handle security updates in precisely the way python 2 users have failed to?
        Rochus 2y ago
        I'm not using the dotnet framework, just the clr, and for the use cases covered by Oberon+ security is of little concern. The project is still regularly updated, see https://github.com/mono/mono/commits/main/ https://github.com/mono/mono/commits/main/.
        neonsunset 2y ago
        Please don't use this Mono flavour as it is still outdated. If possible, please use the Mono runtime that lives in https://github.com/dotnet/runtime/tree/main/src/mono https://github.com/dotnet/runtime/tree/main/src/mono Ideally, CoreCLR will give you much better performance, ability to AOT compile your binaries to native executables and will remove the need for multiple back-ends.
hugomg 2y ago
> I can just as good implement it in C using the Lua C API Pallene beats C when the code uses many Lua data structures. Acessing Lua data from C via the Lua-C API has significant overhead that can erase the gains from rewriting into C. Also, rewriting from Lua to Pallene is much less work than rewriting it in C. Although Pallene is only a subset of Lua, the idea is that you use it together with Lua. It's not meant to replace Lua entirely.
- Rochus 2y ago
  > Pallene beats C when the code uses many Lua data structures. How can it beat C if it just transpiles to C? And accessing string named fields in a table is still done via hashing, even in Pallene, isn't it? > Also, rewriting from Lua to Pallene is much less work than rewriting it in C. Staying in LuaJIT is even less work.
  - kragen 2y ago
    > Staying in LuaJIT is even less work. maybe! tracking down unexpected performance regressions is more work than correcting type errors reported by compiler errors, and your luajit results suggest that typically a c subroutine (and perhaps consequently a pallene subroutine) will enjoy a 4× speed advantage over the luajit version, which might save you a lot of optimization work elsewhere
    - Rochus 2y ago
      > tracking down unexpected performance regressions is more work In particular you have to know a lot of technical details about LuaJIT, which essentially contradicts the benefit of using Lua in the first place. In my case I used LuaJIT as a backend, directly generating bytecode considering LuaJIT internals as far as possible. But it's still much slower than e.g. Mono. > your luajit results suggest that typically a c subroutine (and perhaps consequently a pallene subroutine) will enjoy a 4× speed advantage The Lua implementation of Are-we-fast-yet apparently doesn't consider LuaJIT internals, but is just pretty ideomatic Lua not optimized for speed. So it doesn't represent what is possible with LuaJIT performance-wise, but gives a good impression how LuaJIT performs in general applications.

by Rochus 2y ago

kragen 2y ago

interesting, thank you for sharing your experience! in the example case my pixfunc is in fact not a closure, just a pure function, but it sounds like the performance would collapse if i made it a closure (you can of course compile specialized versions of the inner loop for each fractal in c; 'just' use the preprocessor) it seems plausible to me that it would be more convenient to reimplement a lua function in pallene rather than in c, especially for 'shallow' functions where the code for passing arguments and return values back and forth on the stack to lua is a substantial percentage of the total function code but there's still the question of how good or bad the performance of the code generated by the pallene compiler is! it might be worth rewriting the code in c if gcc or clang produces faster code than pallene does, even if rewriting it in pallene would be easier

Rochus 2y ago
The problem is actually FNEW. If you create your function on top-level and leave it as is then FNEW is only used once. But if you require e.g. nested functions, then each call to FNEW will terminate the trace. My measurement with the Smalltalk and SOM implementations using LuaJIT showed that the benchmark essentially remains in the interpreter most of the time for that reason. > it seems plausible to me that it would be more convenient to reimplement a lua function in pallene rather than in c If just Pallene would be more similar to Lua. But essentially it's a different language which just resembles Lua a bit. So you could use any language compatible with the Lua C API if you don't like C (instead of learning Pallene). You have to rewrite the performance critical parts anyway. Personally I prefer LuaJIT, since everything is Lua, and if you know enough details and do measurements, the performance is no longer a surprise. > how good or bad the performance of the code generated by the pallene compiler is There is no reason to assume that Pallene is faster than LuaJIT if things like the ones mentioned above are considered.
- kragen 2y ago
  that must have been a huge disappointment when you ran into that problem with som! are you planning to write your own jit compiler, or is there still a way you can leverage luajit?
  - Rochus 2y ago
    I ran into stability problems with the Oberon+ FFI which I was not able to solve with the LuaJIT bytecode generator; so I switched to Mono, which even has a much better debugging infrastructure, and for speed I also implemented a C transpiler, the result of which is very close to the native C++ implementation. SOM was mostly an effort to find out how close we can come to Cog with a LuaJIT backend, as a follow-up to my Smalltalk LuaJIT adventure.
    - kragen 2y ago
      i see! hmm, are you going to have to switch to .net core now? or are mono users succeeding in banding together to handle security updates in precisely the way python 2 users have failed to?
      - Rochus 2y ago
        I'm not using the dotnet framework, just the clr, and for the use cases covered by Oberon+ security is of little concern. The project is still regularly updated, see https://github.com/mono/mono/commits/main/ https://github.com/mono/mono/commits/main/.
        neonsunset 2y ago
        Please don't use this Mono flavour as it is still outdated. If possible, please use the Mono runtime that lives in https://github.com/dotnet/runtime/tree/main/src/mono https://github.com/dotnet/runtime/tree/main/src/mono Ideally, CoreCLR will give you much better performance, ability to AOT compile your binaries to native executables and will remove the need for multiple back-ends.

hugomg 2y ago

> I can just as good implement it in C using the Lua C API Pallene beats C when the code uses many Lua data structures. Acessing Lua data from C via the Lua-C API has significant overhead that can erase the gains from rewriting into C. Also, rewriting from Lua to Pallene is much less work than rewriting it in C. Although Pallene is only a subset of Lua, the idea is that you use it together with Lua. It's not meant to replace Lua entirely.

Rochus 2y ago
> Pallene beats C when the code uses many Lua data structures. How can it beat C if it just transpiles to C? And accessing string named fields in a table is still done via hashing, even in Pallene, isn't it? > Also, rewriting from Lua to Pallene is much less work than rewriting it in C. Staying in LuaJIT is even less work.
- kragen 2y ago
  > Staying in LuaJIT is even less work. maybe! tracking down unexpected performance regressions is more work than correcting type errors reported by compiler errors, and your luajit results suggest that typically a c subroutine (and perhaps consequently a pallene subroutine) will enjoy a 4× speed advantage over the luajit version, which might save you a lot of optimization work elsewhere
  - Rochus 2y ago
    > tracking down unexpected performance regressions is more work In particular you have to know a lot of technical details about LuaJIT, which essentially contradicts the benefit of using Lua in the first place. In my case I used LuaJIT as a backend, directly generating bytecode considering LuaJIT internals as far as possible. But it's still much slower than e.g. Mono. > your luajit results suggest that typically a c subroutine (and perhaps consequently a pallene subroutine) will enjoy a 4× speed advantage The Lua implementation of Are-we-fast-yet apparently doesn't consider LuaJIT internals, but is just pretty ideomatic Lua not optimized for speed. So it doesn't represent what is possible with LuaJIT performance-wise, but gives a good impression how LuaJIT performs in general applications.