9 ms·

Smalltalk blocks are a very elegant concept, but also expensive (i.e. a major reason for the comparatively low performance); all loops and conditions are essent

by Rochus 5y ago

Smalltalk blocks are a very elegant concept, but also expensive (i.e. a major reason for the comparatively low performance); all loops and conditions are essentially closure calls and inlining is difficult. I implemented different versions of Smalltalk VMs and conducted measurements (see e.g. https://github.com/rochus-keller/som/#concluding-experiments https://github.com/rochus-keller/som/#concluding-experiments). The same benchmark written in plain Lua compared to the SOM version (with just standard inlining) is more than factor seven faster.

cxr 5y ago
Is this a valid comparison? The S in SOM isn't supposed to stand for "speed". (The real S is arguably adversarial to that goal.) How does Strongtalk fare, for example? (NB: Just asking. I'm actually not a fan of closure-heavy code. I tend to root them out during code review.)
- samatman 5y ago
  I would say it's absolutely a valid comparison, although Lua doesn't encourage the object-messages style of programming, it cooperates excellently with it. My first hire for a project written in Lua had Smalltalk experience, and the way we extend Lua's metaobject protocol is heavily inspired by that and Ruby. But anything in Lua is ultimately built around tables, coroutines, and plain-old-closures; Lua chunks are in fact anonymous functions but they are very fast and easy to compile since chunks can't be moved. It does mean tolerating statement-orientation and built-in control flow; I can live with that.
- Rochus 5y ago
  I compared implementations of the benchmark which all run on the same LuaJIT VM. One implementation is just plain Lua using the loops and control flows provided by the language. Another implementation is written in SOM and transpiled to Lua; all SOM (i.e. Smalltalk) closures are faithfully translated to Lua closures (i.e. not using Lua loops and control flow). Yet another implementation does the same but directly LuaJIT bytecode is generated instead of Lua source code which enables some additional optimizations. The performance difference is very likely caused by the number of closures in use (it's a bit more complex than that, but the principle is the same). I didn't compare with Strongtalk, but with Pharo 7 and 8, which use the Open Smalltalk VM (i.e. Cog/Spur) that is the result of a multi-decade performance optimization effort by Eliot Miranda and team. As you can see in my results Pharo shows essentially the same performance as the plain Lua version on LuaJIT (the tracing version 2.0 of it took "only" seven years to develop in comparison). Here again the link to the report for convenience: http://software.rochus-keller.info/are-we-fast-yet_crystal_lua_node_som_pharo_i386_results_2020-12-29.pdf http://software.rochus-keller.info/are-we-fast-yet_crystal_l....

by Rochus 5y ago

cxr 5y ago

Is this a valid comparison? The S in SOM isn't supposed to stand for "speed". (The real S is arguably adversarial to that goal.) How does Strongtalk fare, for example? (NB: Just asking. I'm actually not a fan of closure-heavy code. I tend to root them out during code review.)

samatman 5y ago
I would say it's absolutely a valid comparison, although Lua doesn't encourage the object-messages style of programming, it cooperates excellently with it. My first hire for a project written in Lua had Smalltalk experience, and the way we extend Lua's metaobject protocol is heavily inspired by that and Ruby. But anything in Lua is ultimately built around tables, coroutines, and plain-old-closures; Lua chunks are in fact anonymous functions but they are very fast and easy to compile since chunks can't be moved. It does mean tolerating statement-orientation and built-in control flow; I can live with that.
Rochus 5y ago
I compared implementations of the benchmark which all run on the same LuaJIT VM. One implementation is just plain Lua using the loops and control flows provided by the language. Another implementation is written in SOM and transpiled to Lua; all SOM (i.e. Smalltalk) closures are faithfully translated to Lua closures (i.e. not using Lua loops and control flow). Yet another implementation does the same but directly LuaJIT bytecode is generated instead of Lua source code which enables some additional optimizations. The performance difference is very likely caused by the number of closures in use (it's a bit more complex than that, but the principle is the same). I didn't compare with Strongtalk, but with Pharo 7 and 8, which use the Open Smalltalk VM (i.e. Cog/Spur) that is the result of a multi-decade performance optimization effort by Eliot Miranda and team. As you can see in my results Pharo shows essentially the same performance as the plain Lua version on LuaJIT (the tracing version 2.0 of it took "only" seven years to develop in comparison). Here again the link to the report for convenience: http://software.rochus-keller.info/are-we-fast-yet_crystal_lua_node_som_pharo_i386_results_2020-12-29.pdf http://software.rochus-keller.info/are-we-fast-yet_crystal_l....