Run Spur run!!

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Run Spur run!!

Max Leske
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! :)
Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

Sven Van Caekenberghe-2
Nice indeed.

Thanks for keeping us all the loop, Max, and for all your work as well.

Looking forward to the new stuff !

> On 23 Oct 2014, at 21:40, Max Leske <[hidden email]> 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! :)


Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

Tudor Girba-2
This is amazing. If we add to it that we will be able to have significantly larger images ... dreaming ... :)

Doru

On Thu, Oct 23, 2014 at 9:47 PM, Sven Van Caekenberghe <[hidden email]> wrote:
Nice indeed.

Thanks for keeping us all the loop, Max, and for all your work as well.

Looking forward to the new stuff !

> On 23 Oct 2014, at 21:40, Max Leske <[hidden email]> 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! :)





--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

Max Leske
In reply to this post by Sven Van Caekenberghe-2

> On 23.10.2014, at 21:47, Sven Van Caekenberghe <[hidden email]> wrote:
>
> Nice indeed.
>
> Thanks for keeping us all the loop, Max, and for all your work as well.
>
> Looking forward to the new stuff !

:) thanks!

>
>> On 23 Oct 2014, at 21:40, Max Leske <[hidden email]> 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! :)
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

HilaireFernandes
In reply to this post by Tudor Girba-2
Le 23/10/2014 21:49, Tudor Girba a écrit :
> This is amazing. If we add to it that we will be able to have
> significantly larger images ... dreaming ... :)
>

Hey, but some time you also need smaller one ;-)

--
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu


Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

stepharo

On 24/10/14 10:31, Hilaire wrote:
> Le 23/10/2014 21:49, Tudor Girba a écrit :
>> This is amazing. If we add to it that we will be able to have
>> significantly larger images ... dreaming ... :)
>>
> Hey, but some time you also need smaller one ;-)
Guille got a 11k image :) so we are getting there too :)

>


Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

sebastianconcept@gmail.co
In reply to this post by Max Leske
remarkable!!!

congratulations for the impressive results

thanks for sharing!

sebastian

o/

> On 23/10/2014, at 17:40, Max Leske <[hidden email]> 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! :)

Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

kilon.alios
very nice

so any more information to this, how exactly this optimization works and which kind of data will benefit from this ? 

On Fri, Oct 24, 2014 at 3:47 PM, Sebastian Sastre <[hidden email]> wrote:
remarkable!!!

congratulations for the impressive results

thanks for sharing!

sebastian

o/

> On 23/10/2014, at 17:40, Max Leske <[hidden email]> 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! :)


Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

Max Leske

On 24.10.2014, at 15:06, kilon alios <[hidden email]> 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 Sista talk at ESUG (2 parts):

Eliot’s Spur talk at ESUG (3 parts):


On Fri, Oct 24, 2014 at 3:47 PM, Sebastian Sastre <[hidden email]> wrote:
remarkable!!!

congratulations for the impressive results

thanks for sharing!

sebastian

o/

> On 23/10/2014, at 17:40, Max Leske <[hidden email]> 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! :)



Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

kilon.alios
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 <[hidden email]> wrote:

On 24.10.2014, at 15:06, kilon alios <[hidden email]> 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 Sista talk at ESUG (2 parts):

Eliot’s Spur talk at ESUG (3 parts):


On Fri, Oct 24, 2014 at 3:47 PM, Sebastian Sastre <[hidden email]> wrote:
remarkable!!!

congratulations for the impressive results

thanks for sharing!

sebastian

o/

> On 23/10/2014, at 17:40, Max Leske <[hidden email]> 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! :)




Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

Eliot Miranda-2
In reply to this post by Max Leske


On Oct 24, 2014, at 6:12 AM, Max Leske <[hidden email]> wrote:


On 24.10.2014, at 15:06, kilon alios <[hidden email]> wrote:

very nice

so any more information to this, how exactly this optimization works and which kind of data will benefit from this ? 

Just to be clear, the speed up measured here is due to Spur.  Sista is in development and should produce even larger speed ups than the ~ -40% speed ups Spur achieves.

Spur should speed up all pure Smalltalk code by
- providing faster instantiation (including closures)
- providing faster at:put:
-providing faster GC (scavenging vs stackless scan-mark-compact)
- providing much faster become
- providing much faster wide string access via immediate characters


Clément’s Sista talk at ESUG (2 parts):

Eliot’s Spur talk at ESUG (3 parts):


On Fri, Oct 24, 2014 at 3:47 PM, Sebastian Sastre <[hidden email]> wrote:
remarkable!!!

congratulations for the impressive results

thanks for sharing!

sebastian

o/

> On 23/10/2014, at 17:40, Max Leske <[hidden email]> 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! :)

Eliot (phone)
Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

Clément Béra
In reply to this post by kilon.alios
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.
 

2014-10-24 15:20 GMT+02:00 kilon alios <[hidden email]>:
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 <[hidden email]> wrote:

On 24.10.2014, at 15:06, kilon alios <[hidden email]> 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 Sista talk at ESUG (2 parts):

Eliot’s Spur talk at ESUG (3 parts):


On Fri, Oct 24, 2014 at 3:47 PM, Sebastian Sastre <[hidden email]> wrote:
remarkable!!!

congratulations for the impressive results

thanks for sharing!

sebastian

o/

> On 23/10/2014, at 17:40, Max Leske <[hidden email]> 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! :)





Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

philippeback


Le 24 oct. 2014 15:51, "Clément Bera" <[hidden email]> a écrit :
>
> 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.

Amazing comes to mind...

Looks like a case of 1+1=much more than 2.

Keep up the good work, you guys are setting a high standard for us to match. It is truly inspiring !

Phil
>  
>
> 2014-10-24 15:20 GMT+02:00 kilon alios <[hidden email]>:
>>
>> 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 <[hidden email]> wrote:
>>>
>>>
>>>> On 24.10.2014, at 15:06, kilon alios <[hidden email]> 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 <[hidden email]> wrote:
>>>>>
>>>>> remarkable!!!
>>>>>
>>>>> congratulations for the impressive results
>>>>>
>>>>> thanks for sharing!
>>>>>
>>>>> sebastian
>>>>>
>>>>> o/
>>>>>
>>>>> > On 23/10/2014, at 17:40, Max Leske <[hidden email]> 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! :)
>>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

Thierry Goubier
In reply to this post by Clément Béra


2014-10-24 15:50 GMT+02:00 Clément Bera <[hidden email]>:
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 ?

Thierry
 

2014-10-24 15:20 GMT+02:00 kilon alios <[hidden email]>:
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 <[hidden email]> wrote:

On 24.10.2014, at 15:06, kilon alios <[hidden email]> 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 Sista talk at ESUG (2 parts):

Eliot’s Spur talk at ESUG (3 parts):


On Fri, Oct 24, 2014 at 3:47 PM, Sebastian Sastre <[hidden email]> wrote:
remarkable!!!

congratulations for the impressive results

thanks for sharing!

sebastian

o/

> On 23/10/2014, at 17:40, Max Leske <[hidden email]> 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! :)






Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

EstebanLM

On 24 Oct 2014, at 16:21, Thierry Goubier <[hidden email]> wrote:



2014-10-24 15:50 GMT+02:00 Clément Bera <[hidden email]>:
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. 

cheers, 
Esteban


Thierry
 

2014-10-24 15:20 GMT+02:00 kilon alios <[hidden email]>:
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 <[hidden email]> wrote:

On 24.10.2014, at 15:06, kilon alios <[hidden email]> 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 Sista talk at ESUG (2 parts):

Eliot’s Spur talk at ESUG (3 parts):


On Fri, Oct 24, 2014 at 3:47 PM, Sebastian Sastre <[hidden email]> wrote:
remarkable!!!

congratulations for the impressive results

thanks for sharing!

sebastian

o/

> On 23/10/2014, at 17:40, Max Leske <[hidden email]> 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! :)







Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

Eliot Miranda-2


On Fri, Oct 24, 2014 at 7:34 AM, Esteban Lorenzano <[hidden email]> wrote:

On 24 Oct 2014, at 16:21, Thierry Goubier <[hidden email]> wrote:



2014-10-24 15:50 GMT+02:00 Clément Bera <[hidden email]>:
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 <[hidden email]>:
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 <[hidden email]> wrote:

On 24.10.2014, at 15:06, kilon alios <[hidden email]> 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 Sista talk at ESUG (2 parts):

Eliot’s Spur talk at ESUG (3 parts):


On Fri, Oct 24, 2014 at 3:47 PM, Sebastian Sastre <[hidden email]> wrote:
remarkable!!!

congratulations for the impressive results

thanks for sharing!

sebastian

o/

> On 23/10/2014, at 17:40, Max Leske <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

Thierry Goubier
Le 24/10/2014 19:07, Eliot Miranda a écrit :

>
>
> On Fri, Oct 24, 2014 at 7:34 AM, Esteban Lorenzano <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>>     On 24 Oct 2014, at 16:21, Thierry Goubier
>>     <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>
>>
>>     2014-10-24 15:50 GMT+02:00 Clément Bera <[hidden email]
>>     <mailto:[hidden email]>>:
>>
>>         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?

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

Thierry




Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

Eliot Miranda-2


On Fri, Oct 24, 2014 at 10:12 AM, Thierry Goubier <[hidden email]> wrote:
Le 24/10/2014 19:07, Eliot Miranda a écrit :


On Fri, Oct 24, 2014 at 7:34 AM, Esteban Lorenzano <[hidden email]
<mailto:[hidden email]>> wrote:


    On 24 Oct 2014, at 16:21, Thierry Goubier
    <[hidden email] <mailto:[hidden email]>> wrote:



    2014-10-24 15:50 GMT+02:00 Clément Bera <[hidden email]
    <mailto:[hidden email]>>:


        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
Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

HilaireFernandes
In reply to this post by stepharo
Le 24/10/2014 14:02, stepharo a écrit :
>
> On 24/10/14 10:31, Hilaire wrote:
>> Le 23/10/2014 21:49, Tudor Girba a écrit :
>>> This is amazing. If we add to it that we will be able to have
>>> significantly larger images ... dreaming ... :)
>>>
>> Hey, but some time you also need smaller one ;-)
> Guille got a 11k image :) so we are getting there too :)

Fantastic !
For now I stopped the DrGeo maintenance on tablet for multiple reasons.
One of the reason was the growing image of Pharo 3 and the difficulty to
shrink it.

Hilaire

--
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu


Reply | Threaded
Open this post in threaded view
|

Re: Run Spur run!!

Thierry Goubier
In reply to this post by Eliot Miranda-2
Le 24/10/2014 19:50, Eliot Miranda a écrit :

>
>
> On Fri, Oct 24, 2014 at 10:12 AM, Thierry Goubier
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Le 24/10/2014 19:07, Eliot Miranda a écrit :
>
>
>
>         On Fri, Oct 24, 2014 at 7:34 AM, Esteban Lorenzano
>         <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>
>
>                  On 24 Oct 2014, at 16:21, Thierry Goubier
>                  <[hidden email]
>             <mailto:[hidden email]>
>             <mailto:thierry.goubier@gmail.__com
>             <mailto:[hidden email]>>> wrote:
>
>
>
>                  2014-10-24 15:50 GMT+02:00 Clément Bera
>             <[hidden email] <mailto:[hidden email]>
>                  <mailto:[hidden email]
>             <mailto:[hidden email]>__>>:
>
>
>                      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.

Ok.

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

Is that one really needed? I had the feeling web plugins were so last
year and that we could just do: Amber, or even a remote desktop client
in the web browser with Squeak/Pharo RDP support (which is a bit more
general than a really fast web plugin).

Moreover, I see that the only thing with potential linked to the web
today is to handle tablets/smartphones, and this is a bit why I'm asking
about ARM support (also embedding in small stuff, like Cortex M0-M4
stuff with BLE, solar cells and batteries). For now, the only use we
have for Smalltalk in there is as C code generation / deployment IDEs on
the desktop (aka B. Pottier Netgen), and as back-end on web deployment
with Seaside + others.

Thierry

12