4 ms·

> 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 method

> 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
  - Rochus 3y ago
    Thanks. I know SOM and Smalltalk pretty well and have implemented several VMs myself (see https://github.com/rochus-keller/Som/ https://github.com/rochus-keller/Som/ and https://github.com/rochus-keller/Smalltalk/ https://github.com/rochus-keller/Smalltalk/). SOM was originally designed and implemented by Bak and Lund at Aarhus university. It's very well suited for performance experiments and shares with Smalltalk the relevant features. There is an implementation of the Are-we-fast-yet suite for both SOM and Smalltalk.
    - mpweiher 3y ago
      I find that hard to believe given the various claims you’ve made. If it’s true, it makes those claims even more staggering. “Both SOM and Smalltalk” is a category error.
      - igouy 3y ago
        "Be kind. Don't be snarky. Converse curiously; don't cross-examine."
igouy 3y ago
> "yielding a faster Smalltalk than the commercial offerings" fwiw "However, there are a few limitations which would preclude its use as an industrial-strength implementation" p13

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
- Rochus 3y ago
  Thanks. I know SOM and Smalltalk pretty well and have implemented several VMs myself (see https://github.com/rochus-keller/Som/ https://github.com/rochus-keller/Som/ and https://github.com/rochus-keller/Smalltalk/ https://github.com/rochus-keller/Smalltalk/). SOM was originally designed and implemented by Bak and Lund at Aarhus university. It's very well suited for performance experiments and shares with Smalltalk the relevant features. There is an implementation of the Are-we-fast-yet suite for both SOM and Smalltalk.
  - mpweiher 3y ago
    I find that hard to believe given the various claims you’ve made. If it’s true, it makes those claims even more staggering. “Both SOM and Smalltalk” is a category error.
    - igouy 3y ago
      "Be kind. Don't be snarky. Converse curiously; don't cross-examine."

igouy 3y ago

> "yielding a faster Smalltalk than the commercial offerings" fwiw "However, there are a few limitations which would preclude its use as an industrial-strength implementation" p13