5 ms·

Self wasn't sufficiently fast? Craig Chambers's compiler [0] had to be careful around recursive inlining* but it's not that bad, and the compiler definitely cam

Self wasn't sufficiently fast? Craig Chambers's compiler [0] had to be careful around recursive inlining* but it's not that bad, and the compiler definitely came around in less than 30 years of Self or Smalltalk existing (even if you start counting from Smalltalk-72). A sibling comment mentions that Smalltalk-80 played tricks with inlining some block methods such as ifTrue: and whileTrue: in the bytecode, but Self pulled nothing like that. [0] http://www.wolczko.com/tmp/ChambersThesis.pdf#page=72 http://www.wolczko.com/tmp/ChambersThesis.pdf#page=72 *Although maybe too careful - the important parts are that you don't inline forever, so some degree of recursive inlining is okay (and would help in the factorial example), and that you have a good reason to inline.

Rochus 3y ago
> Self wasn't sufficiently fast? Self apparently is sufficiently different from Smalltalk-80 so that even today JS engines (which are descendants of the Self engine) are still significanly faster than Cog/OpenSmalltalk. Remember that also Python is known to be pretty resistant to performance improvements. So some languages/VMs apparently are more amenable than others. In my referenced report you can see that there is still nearly a factor two between Pharo (using OpenSmalltalk) and Node.js (using V8). But Pharo is at least faster than LuaJIT, which again is about factor 220 faster than a Smalltalk interpreter which does the caching and inlining described in the Bluebook. So Cog/OpenSmalltalk went a long way to finally be the fastest Smalltalk engine around. A comparison with Smalltalk 72 makes little sense because it was a completely different language and engine. > Smalltalk-80 played tricks with inlining some block methods such as ifTrue: and whileTrue: That was just because a convention on lexical level made it possible. Otherwise it's very difficult because a block is just an object and executing it is just a method call on this object via dynamic dispatch; it's not trivial to find out what to inline. If you're interested in the machinery behind the scenes, here are a couple of tools which facilitate an analysis: https://github.com/rochus-keller/Smalltalk https://github.com/rochus-keller/Smalltalk.
- matheusmoreira 3y ago
  > Remember that also Python is known to be pretty resistant to performance improvements. People certainly say that a lot. This thread for example: https://news.ycombinator.com/item?id=38923741 https://news.ycombinator.com/item?id=38923741 > The take that CPython should be a reference implementation and thus slow always aggravated me What is the actual reason for that? How do other languages avoid falling into that trap? That thread gave me the impression the source of the problem is direct linkage to C extensions instead of native high level foreign interfaces. The resulting code is too tightly coupled to CPython internals which prevents optimization. Is this right?
  - Rochus 3y ago
    > What is the actual reason for that? Don't know, can only speculate. From what I observed, I would conclude that no one has had the right idea so far of how to do this. With Self it took a few years, with Smalltalk - as has now been shown - forty years, and with the surprise that AST interpreters with Graal are faster than bytecode interpreters. Someone will probably have a brilliant idea for Python in a few years' time.
- hayley-patton 3y ago
  > So some languages/VMs apparently are more amenable than others. I thought Self was supposed to be harder to optimise due to using prototypes, accessor methods rather than distinguishing instance variable access, and generally fewer other tricks. Frankly I don't know what the problem is here, but if it was a language issue, then Self should be slower than Smalltalk - you are suggesting that it'd be the other way around, and I don't see why that'd be the case. Mario Wolczko implemented Smalltalk in Self, yielding a faster Smalltalk than the commercial offerings <http://www.merlintec.com/download/mario.pdf http://www.merlintec.com/download/mario.pdf>. The are-we-fast-yet repo has benchmarks for SOMns (SOM modified to run Newspeak, using Truffle for compilation) which outperforms Node <https://github.com/smarr/are-we-fast-yet/blob/master/docs/performance.md https://github.com/smarr/are-we-fast-yet/blob/master/docs/pe...>. > Otherwise it's very difficult because a block is just an object and executing it is just a method call on this object via dynamic dispatch; it's not trivial to find out what to inline We have an object which we know everything about, because we construct it in the method. We know it's a block, and we know what #value will do, which seems like a pretty strong signal to inline. Even without knowing what blocks are, inlining #ifTrue:, #whileTrue: and such is a good move as those methods are very small.
  - Rochus 3y ago
    > you are suggesting that it'd be the other way around, and I don't see why that'd be the case. That's just what I observed, and I concluded from the observations that Smalltalk - like Python - must be more difficult to JIT compile than Self or JS for some reason. I asked Stefan Marr for his most recent measurement results, and he was so friendly to post some reports: https://github.com/smarr/are-we-fast-yet/issues/85 https://github.com/smarr/are-we-fast-yet/issues/85. As it seems the Graal/Truffle based implementation of SOM (a Smalltalk dialect) is now as fast as Node.js (V8), at least the AST version on the Graal enterprise edition; the Graal community editions of the SOM VMs are still slower though (about the same performance as Cog/OpenSmalltalk by estimate).
    - mpweiher 3y ago
      SOM stands for "Simple Object Machine". It is not a high performance implementation, nor is it intended as one. Subhead: "A minimal Smalltalk for teaching of and research on Virtual Machines." Key characteristics: "clarity of implementation over absolute performance" Straight from the SOM home page: http://som-st.github.io http://som-st.github.io
- mpweiher 3y ago
  > JS engines (which are descendants of the Self engine) are still significanly faster than Cog/OpenSmalltalk. This is almost entirely a function of effort expended. Several trillion dollar companies have large teams working on JavaScript engines, usually multiple engines each. The OpenSmalltalk VM is a volunteer effort of a very small community, with the main JIT produced primarily by a single person. "The F4 Phantom...America's proof to the world that with a big enough engine, even a brick can fly" https://www.youtube.com/watch?v=XqUgUgiToNs https://www.youtube.com/watch?v=XqUgUgiToNs Fabio Niephaus hooked up Squeak to the GraalVM. https://github.com/hpi-swa/trufflesqueak https://github.com/hpi-swa/trufflesqueak Takes a while for the optimizer to reach a steady-state, but does it ever fly when it does. The Bouncing Atoms demo reaches around 10x the frame rate of the OpenSmalltalk VM. https://www.researchgate.net/publication/336086216_GraalSqueak_Toward_a_Smalltalk-Based_Tooling_Platform_for_Polyglot_Programming https://www.researchgate.net/publication/336086216_GraalSque...
  - Rochus 3y ago
    Thanks. See also https://news.ycombinator.com/item?id=39007778 https://news.ycombinator.com/item?id=39007778. The first compiler which introduced the concepts later used in Java and JS was also an effort by only one or two people in an academic setting. Even the V8 in its initial version (which already did a tremendous speed-up of JS) was essentially the work of two people. Cog/OpenSmalltalk was supported by many PhD projects, so it's by far not only a single person. Apparently there was a need for a fast Smalltalk VM, as there is a need for a fast, compatible Python VM. As it seems it took 40 years of research to make Smalltalk fast; Python got a bit faster, but is still much slower than JS, even with Graal.
    - mpweiher 3y ago
      Really, no. I know a lot of these people personally. Heck, I theoretically share(d) an office with one. And of course the way that Self's technology made it to Java's HotSpot, which is still tons faster than any JS, was via Anamorphic and Strongtalk. https://en.wikipedia.org/wiki/HotSpot_(virtual_machine) https://en.wikipedia.org/wiki/HotSpot_(virtual_machine) https://strongtalk.org https://strongtalk.org https://en.wikipedia.org/wiki/Strongtalk https://en.wikipedia.org/wiki/Strongtalk https://gist.github.com/landonf/9053062 https://gist.github.com/landonf/9053062 But of course Smalltalk was jitted long before that, with Peter Deutsch's VM. https://dl.acm.org/doi/10.1145/800017.800542 https://dl.acm.org/doi/10.1145/800017.800542 Higher performance VM/compiler technology was not enabled by Self's object model, it was necessitated by it. The system was just too slow otherwise. Squeak was never intended as a high performance Smalltalk implementation, it had different goals. When Squeak was created, an automatically generated bytecode VM was already tons faster than the fastest high-performance Smalltalk computers the creators had worked with at PARC, in particular the Dorado. This was considered more than fast enough for what they were trying to do, in particular because the bulk multi-media processing would be done by plugins (also often generated). Making a JIT for better performance was a non-goal. So using Squeak (and later OpenSmalltalk) as a comparison is just completely invalid. The Cog VM was started around 15 years after that, by a Smalltalk VM engineer who had already worked on jitted VMs professionally. http://www.mirandabanda.org/cogblog/microbio/ http://www.mirandabanda.org/cogblog/microbio/ And so using the Cog VM as some sort of benchmark as the "first fast" Smalltalk implementation is completely unrelated to reality.

Rochus 3y ago

> Self wasn't sufficiently fast? Self apparently is sufficiently different from Smalltalk-80 so that even today JS engines (which are descendants of the Self engine) are still significanly faster than Cog/OpenSmalltalk. Remember that also Python is known to be pretty resistant to performance improvements. So some languages/VMs apparently are more amenable than others. In my referenced report you can see that there is still nearly a factor two between Pharo (using OpenSmalltalk) and Node.js (using V8). But Pharo is at least faster than LuaJIT, which again is about factor 220 faster than a Smalltalk interpreter which does the caching and inlining described in the Bluebook. So Cog/OpenSmalltalk went a long way to finally be the fastest Smalltalk engine around. A comparison with Smalltalk 72 makes little sense because it was a completely different language and engine. > Smalltalk-80 played tricks with inlining some block methods such as ifTrue: and whileTrue: That was just because a convention on lexical level made it possible. Otherwise it's very difficult because a block is just an object and executing it is just a method call on this object via dynamic dispatch; it's not trivial to find out what to inline. If you're interested in the machinery behind the scenes, here are a couple of tools which facilitate an analysis: https://github.com/rochus-keller/Smalltalk https://github.com/rochus-keller/Smalltalk.

matheusmoreira 3y ago
> Remember that also Python is known to be pretty resistant to performance improvements. People certainly say that a lot. This thread for example: https://news.ycombinator.com/item?id=38923741 https://news.ycombinator.com/item?id=38923741 > The take that CPython should be a reference implementation and thus slow always aggravated me What is the actual reason for that? How do other languages avoid falling into that trap? That thread gave me the impression the source of the problem is direct linkage to C extensions instead of native high level foreign interfaces. The resulting code is too tightly coupled to CPython internals which prevents optimization. Is this right?
- Rochus 3y ago
  > What is the actual reason for that? Don't know, can only speculate. From what I observed, I would conclude that no one has had the right idea so far of how to do this. With Self it took a few years, with Smalltalk - as has now been shown - forty years, and with the surprise that AST interpreters with Graal are faster than bytecode interpreters. Someone will probably have a brilliant idea for Python in a few years' time.
hayley-patton 3y ago
> So some languages/VMs apparently are more amenable than others. I thought Self was supposed to be harder to optimise due to using prototypes, accessor methods rather than distinguishing instance variable access, and generally fewer other tricks. Frankly I don't know what the problem is here, but if it was a language issue, then Self should be slower than Smalltalk - you are suggesting that it'd be the other way around, and I don't see why that'd be the case. Mario Wolczko implemented Smalltalk in Self, yielding a faster Smalltalk than the commercial offerings <http://www.merlintec.com/download/mario.pdf http://www.merlintec.com/download/mario.pdf>. The are-we-fast-yet repo has benchmarks for SOMns (SOM modified to run Newspeak, using Truffle for compilation) which outperforms Node <https://github.com/smarr/are-we-fast-yet/blob/master/docs/performance.md https://github.com/smarr/are-we-fast-yet/blob/master/docs/pe...>. > Otherwise it's very difficult because a block is just an object and executing it is just a method call on this object via dynamic dispatch; it's not trivial to find out what to inline We have an object which we know everything about, because we construct it in the method. We know it's a block, and we know what #value will do, which seems like a pretty strong signal to inline. Even without knowing what blocks are, inlining #ifTrue:, #whileTrue: and such is a good move as those methods are very small.
- Rochus 3y ago
  > you are suggesting that it'd be the other way around, and I don't see why that'd be the case. That's just what I observed, and I concluded from the observations that Smalltalk - like Python - must be more difficult to JIT compile than Self or JS for some reason. I asked Stefan Marr for his most recent measurement results, and he was so friendly to post some reports: https://github.com/smarr/are-we-fast-yet/issues/85 https://github.com/smarr/are-we-fast-yet/issues/85. As it seems the Graal/Truffle based implementation of SOM (a Smalltalk dialect) is now as fast as Node.js (V8), at least the AST version on the Graal enterprise edition; the Graal community editions of the SOM VMs are still slower though (about the same performance as Cog/OpenSmalltalk by estimate).
  - mpweiher 3y ago
    SOM stands for "Simple Object Machine". It is not a high performance implementation, nor is it intended as one. Subhead: "A minimal Smalltalk for teaching of and research on Virtual Machines." Key characteristics: "clarity of implementation over absolute performance" Straight from the SOM home page: http://som-st.github.io http://som-st.github.io
mpweiher 3y ago
> JS engines (which are descendants of the Self engine) are still significanly faster than Cog/OpenSmalltalk. This is almost entirely a function of effort expended. Several trillion dollar companies have large teams working on JavaScript engines, usually multiple engines each. The OpenSmalltalk VM is a volunteer effort of a very small community, with the main JIT produced primarily by a single person. "The F4 Phantom...America's proof to the world that with a big enough engine, even a brick can fly" https://www.youtube.com/watch?v=XqUgUgiToNs https://www.youtube.com/watch?v=XqUgUgiToNs Fabio Niephaus hooked up Squeak to the GraalVM. https://github.com/hpi-swa/trufflesqueak https://github.com/hpi-swa/trufflesqueak Takes a while for the optimizer to reach a steady-state, but does it ever fly when it does. The Bouncing Atoms demo reaches around 10x the frame rate of the OpenSmalltalk VM. https://www.researchgate.net/publication/336086216_GraalSqueak_Toward_a_Smalltalk-Based_Tooling_Platform_for_Polyglot_Programming https://www.researchgate.net/publication/336086216_GraalSque...
- Rochus 3y ago
  Thanks. See also https://news.ycombinator.com/item?id=39007778 https://news.ycombinator.com/item?id=39007778. The first compiler which introduced the concepts later used in Java and JS was also an effort by only one or two people in an academic setting. Even the V8 in its initial version (which already did a tremendous speed-up of JS) was essentially the work of two people. Cog/OpenSmalltalk was supported by many PhD projects, so it's by far not only a single person. Apparently there was a need for a fast Smalltalk VM, as there is a need for a fast, compatible Python VM. As it seems it took 40 years of research to make Smalltalk fast; Python got a bit faster, but is still much slower than JS, even with Graal.
  - mpweiher 3y ago
    Really, no. I know a lot of these people personally. Heck, I theoretically share(d) an office with one. And of course the way that Self's technology made it to Java's HotSpot, which is still tons faster than any JS, was via Anamorphic and Strongtalk. https://en.wikipedia.org/wiki/HotSpot_(virtual_machine) https://en.wikipedia.org/wiki/HotSpot_(virtual_machine) https://strongtalk.org https://strongtalk.org https://en.wikipedia.org/wiki/Strongtalk https://en.wikipedia.org/wiki/Strongtalk https://gist.github.com/landonf/9053062 https://gist.github.com/landonf/9053062 But of course Smalltalk was jitted long before that, with Peter Deutsch's VM. https://dl.acm.org/doi/10.1145/800017.800542 https://dl.acm.org/doi/10.1145/800017.800542 Higher performance VM/compiler technology was not enabled by Self's object model, it was necessitated by it. The system was just too slow otherwise. Squeak was never intended as a high performance Smalltalk implementation, it had different goals. When Squeak was created, an automatically generated bytecode VM was already tons faster than the fastest high-performance Smalltalk computers the creators had worked with at PARC, in particular the Dorado. This was considered more than fast enough for what they were trying to do, in particular because the bulk multi-media processing would be done by plugins (also often generated). Making a JIT for better performance was a non-goal. So using Squeak (and later OpenSmalltalk) as a comparison is just completely invalid. The Cog VM was started around 15 years after that, by a Smalltalk VM engineer who had already worked on jitted VMs professionally. http://www.mirandabanda.org/cogblog/microbio/ http://www.mirandabanda.org/cogblog/microbio/ And so using the Cog VM as some sort of benchmark as the "first fast" Smalltalk implementation is completely unrelated to reality.