> Cog VM -- Thanks and Performance / Optimization Questions
>
>
> To Everyone, thanks for your great work on Pharo and Squeak,  and to
> Eliot Miranda, Ian Piumarta, and all VM/JIT gurus, especially thanks
> for the Squeak VM Cog and its precursors, which I was keenly
> anticipating for a decade or so, and is really going into stride with
> the latest builds.
>
> I like to code with awareness of performance issues.  Can you tell or
> point me to some performance and efficiency tips for Cog and the
> Squeak compiler -- detail on which methods are inlined, best among
> alternatives, etc.  For example, I understand #to:do: is inlined --
> what about #to:do:by: and #timesRepeat and #repeat  ?  Basically, I
> would like to read a full overview of which core methods are specially
> optimized (or planned).
>
> I know about the list of NoLookup primitives, as per Object
> class>>howToModifyPrimitives,  supposing that is still valid?
>
> What do you think is a reasonable speed factor for number-crunching
> Squeak code vs C ?   I am seeing about 20x slower in the semi-large
> scale, which surprised me a bit because I got about 10x on smaller
> tests, and a simple fib: with beautiful Cog is now about 3x (wow!).
> That range, 3x tiny tight loop, to 20x for general multi-class
> computation, seems a bit wide -- is it about expected?
>
> My profiling does not reveal any hotspots, as such -- it's basically
> 2, 3, 5% scattered around, so I envision this is just the general
> vm/jit overhead as you scale up -- referencing distant objects, slots,
> dispatch lookups, more cache misses, etc.  But maybe I am generally
> using some backwater loop/control methods, techniques, etc. that could
> be tuned up.  e.g. I seem to recall a trace at some point showing
> #timesRepeat taking 10% of the time (?!).   Also, I recall reading
> about an anomaly with BlockClosures -- something like being rebuilt
> every time thru the loop - has that been fixed?  Any other gotchas to
> watch for currently?
>
> (Also, any notoriously slow subsystems?  For example, Transcript
> writing is glacial.)
>
> The Squeak bytecode compiler looks fairly straightforward and
> non-optimizing - just statement by statement translation.  So it
> misses e.g. chances to store and reuse, instead of pop, etc.  I see
> lots of redundant sequences emitted.  Are those kind of things now
> optimized out by Cog, or would tighter bytecode be another potential
> optimization path.  (Is that what the Opal project is targetting?)
>
> -- jbthiel
>