On Fri, Oct 24, 2014 at 10:12 AM, Thierry Goubier <thierry.goubier@gmail.com
wrote:
Le 24/10/2014 19:07, Eliot Miranda a écrit :
On Fri, Oct 24, 2014 at 7:34 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 24 Oct 2014, at 16:21, Thierry Goubier
<thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
2014-10-24 15:50 GMT+02:00 Clément Bera <bera.clement@gmail.com <mailto:bera.clement@gmail.com>>:
The current x2 speed boost is due only to spur, not to sista. Sista will provide additional performance, but we have still things to do before production.
The performance gain reported is due to (from most important to less important): - the new GC has less overhead. 30% of the execution time used to be spent in the GC. - the new object format speeds up some VM internal caches (especially inline caches for message sends due to an indirection for object classes with a class table). - the new object format allows some C code to be converted into machine code routines, including block creation, context creation, primitive #at:put:, which is faster because switching from jitted code to C then back to jitted code generate a little overhead. - characters are now immediate objects, which speeds up String accessing. - the new object format has a larger hash which speeds up big hashed collections such as big sets and dictionaries. - become is faster.
All this is really cool :) And if I remember well, there is 64 bitness coming as well.
Will Spur also cover ARM ?
Spur is an object format, it does not have anything to do with underlying architecture (well, at least in theory⦠Eliot should be able to say more on this). Cog, in the other side is a jitter, and it has everything to do with the architecture so is difficult to have it running on ARM (but there is work on that direction, so we hope it will be there eventually).
It looks like there is a misunderstanding (probably not you, Thierry, but since Iâve seen it time to time, I take the chance to clarify): Spur is not a replacement for Cog, both are orthogonal (in fact, Spur runs in Stack vm too). Real new VM is not âSpurâ vm, is "Cog+Spur" vm.
+1. Spur changes the object representation, so it has a new heap layout, a new layout for objects, and a new garbage collector. Because the object format is simpler it allows the Cog JIT to generate machine code versions of more operations, in particular basicNew, basicNew: and closure and context creation. This is the main reason for the speedups in Cog+Spur. As far as the Stack VM goes if you see speedups for Stack+Spur vs Stack+V3 that's all due to the Spur object representation & GC, because there's no JIT.
Now at the moment the Cog JIT only has an x86 back-end in production. Tim Rowledge is working on finishing the ARM back end started by Lars Wassermann in the GSoC a few years ago. So soonish we should be able to have Cog+V3 or Cog+Spur on e.g. Android.
As part of 64-bit Spur I will be doing a back end for x86-64.
Which is then a 64bits Spur+Cog+Sista, right?
It should be able to be used for Spur+Cog or Spur+Cog+Sista. Depends how quickly I can write the 64-bit Spur and how quickly Clément can put Sista into production. And Doug McPherson is also in the mix, having written the ARM version of
the new FFI plugin, and is going to be building Stack ARM VMs and soon enough Cog ARM VMs.
Thanks for all those news, this is really great.
Yes, I'm very excited. It's so great to have strong collaborators like Clément, Ronie, Doug and Tim. But there's lots of room for more to join us. For a really cool project how about grabbing Bert Freudenberg's VMMakerJS Squeak-vm-on-JavaScript, extract the event handling and rendering part and connect it to the Cog VM via sockets to give us a really fast web plugin? -- best, Eliot