6 ms·
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,
by 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 agothat 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 agoI 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 agoi 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 agoI'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 agoPlease 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.
- Rochus 2y agoThese are two different Mono implementations. The one maintained by MS has a different focus. I'm mostly interested in a lean, independent build and many different targets (e.g. Apple M1). The "much better performance" of CoreCLR is a fairy tale (see e.g. https://www.quora.com/Is-the-Mono-CLR-really-slower-than-CoreCLR/answer/Rochus-Keller https://www.quora.com/Is-the-Mono-CLR-really-slower-than-Cor...). Actually, Mono supported AOT even before the CoreCLR (but I don't need it, because I have a to C transpiler which produces cross-platform near-native performance).
- kragen 2y agothis is fantastic information, thanks!
- neonsunset 2y agoUnfortunately, there are a few issues with this quora post. First it is outdated - .NET is on an annual cadence and statements true for 3.1 or 5 have no impact on user experience today, second it focuses on edge case differences with log scale rather than the full picture. Also note that compiler improves significantly with each version - look at the difference between 3.1, 5 and 6. The differences between 6 and 8 are way more significant (DynamicPGO light-up, physical promotion for structs, etc.). And third there is more to the story than microbenchmarks. Again, there is a huge rift in performance between Mono and CoreCLR, and there are classes of optimizations Mono does not and will not do, like devirtualization. All optimization work goes into CoreCLR for multiple ISAs. Mono does not support AVX2 and AVX512, which core routines in .NET CoreLib rely on if available. It doesn't have a fancy if-conversion pass to merge branches and comparisons that CoreCLR does for ARM64, write barrier optimizations, etc etc. This is not a myth but what anyone who works closely with .NET or is a part of .NET teams will tell you. For example, look at https://aka.ms/aspnet/benchmarks https://aka.ms/aspnet/benchmarks select mono tab and pick coreclr and fortunes - you'll notice that Mono is more than five times slower than CoreCLR. And it is the Mono flavour which also sees performance improvements for the features that .NET adds or optimizations focused on targets served by Mono. Also, the independent build is not independent - it limps along Unity Technologies contributions until Unity finishes its move to CoreCLR, which they are in the process of.