[Vm-dev] Re: [Pharo-dev] Run Spur run!!

Eliot Miranda eliot.miranda at gmail.com
Fri Oct 24 17:07:28 UTC 2014


On Fri, Oct 24, 2014 at 7:34 AM, Esteban Lorenzano <estebanlm at gmail.com>
wrote:

>
> On 24 Oct 2014, at 16:21, Thierry Goubier <thierry.goubier at gmail.com>
> wrote:
>
>
>
> 2014-10-24 15:50 GMT+02:00 Clément Bera <bera.clement at 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.

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.


> cheers,
> Esteban
>
>
> Thierry
>
>
>>
>> 2014-10-24 15:20 GMT+02:00 kilon alios <kilon.alios at gmail.com>:
>>
>>> thanks max, i completely forgotten about esug videos, looks like i found
>>> what to watch during the weekend :D
>>>
>>> On Fri, Oct 24, 2014 at 4:12 PM, Max Leske <maxleske at gmail.com> wrote:
>>>
>>>>
>>>> On 24.10.2014, at 15:06, kilon alios <kilon.alios at gmail.com> wrote:
>>>>
>>>> very nice
>>>>
>>>> so any more information to this, how exactly this optimization works
>>>> and which kind of data will benefit from this ?
>>>>
>>>>
>>>> Clément’s byte code set talk at ESUG:
>>>> http://www.youtube.com/watch?v=e9J362QHwSA&index=64&list=PLJ5nSnWzQXi_6yyRLsMMBqG8YlwfhvB0X
>>>> Clément’s Sista talk at ESUG (2 parts):
>>>>
>>>> http://www.youtube.com/watch?v=X4E_FoLysJg&list=PLJ5nSnWzQXi_6yyRLsMMBqG8YlwfhvB0X&index=76
>>>>
>>>> http://www.youtube.com/watch?v=gZOk3qojoVE&list=PLJ5nSnWzQXi_6yyRLsMMBqG8YlwfhvB0X&index=75
>>>>
>>>> Eliot’s Spur talk at ESUG (3 parts):
>>>>
>>>> http://www.youtube.com/watch?v=k0nBNS1aHZ4&index=49&list=PLJ5nSnWzQXi_6yyRLsMMBqG8YlwfhvB0X
>>>>
>>>> http://www.youtube.com/watch?v=sn3irBZE7g4&index=48&list=PLJ5nSnWzQXi_6yyRLsMMBqG8YlwfhvB0X
>>>>
>>>> http://www.youtube.com/watch?v=1Vg0iFeg_pA&list=PLJ5nSnWzQXi_6yyRLsMMBqG8YlwfhvB0X&index=47
>>>>
>>>>
>>>> On Fri, Oct 24, 2014 at 3:47 PM, Sebastian Sastre <
>>>> sebastian at flowingconcept.com> wrote:
>>>>
>>>>> remarkable!!!
>>>>>
>>>>> congratulations for the impressive results
>>>>>
>>>>> thanks for sharing!
>>>>>
>>>>> sebastian
>>>>>
>>>>> o/
>>>>>
>>>>> > On 23/10/2014, at 17:40, Max Leske <maxleske at gmail.com> wrote:
>>>>> >
>>>>> > For those of you who missed this on IRC:
>>>>> >
>>>>> > henriksp: estebanlm: Care to run a small bench Cog vs Spur for me?
>>>>> > [3:32pm] henriksp: int := ZnUTF8Encoder new.
>>>>> > [3:32pm] henriksp: [int decodeBytes:#[67 97 115 104 44 32 108 105
>>>>> 107 101 32 226 130 172 44 32 105 115 32 107 105 110 103 0]] bench.
>>>>> > [3:32pm] henriksp: had a 16x speedup with assembly implementation vs
>>>>> Cog, if it's 8x vs Spur, that's just really impressive
>>>>> > [3:44pm] Craig left the chat room. (Quit: Leaving.)
>>>>> > [3:53pm] Craig joined the chat room.
>>>>> > [4:08pm] VitamineD joined the chat room.
>>>>> > [4:20pm] estebanlm: checking
>>>>> > [4:21pm] estebanlm: Cog: 167,000 per second.
>>>>> > [4:22pm] estebanlm: Cog[Spur]: 289,000 per second.
>>>>> > [4:23pm] estebanlm: henriksp: ping
>>>>> > [4:33pm] tinchodias left the chat room. (Ping timeout: 245 seconds)
>>>>> > [4:33pm] tinchodias joined the chat room.
>>>>> > [4:34pm] henriksp: 70% more work done, nice!
>>>>> > [5:09pm]
>>>>> >
>>>>> >
>>>>> > Yay! :)
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141024/ac9a18dd/attachment-0001.htm


More information about the Vm-dev mailing list