On 06 Feb 2014, at 19:51, kilon alios <kilon.alios@gmail.com> wrote:

thats very good news , 64 bit is rather close now which mean even more C libraries available for Pharo and loads of GB of memory to exploit.

yes, but just *closer*… we'll still need the 64bits FFI :)

On Thu, Feb 6, 2014 at 7:19 PM, <btc@openinworld.com> wrote: Clément Bera wrote:

...

Hello pharoers,

The new Cog memory manager, Spur, is simply *amazing*. I saw at FOSDEM that some of you were interested in it, but unfortunately you were lacking information about it.

I wrote a one page article that sums up Spur's new features so every one can know what will be better. There's no VM technical details here, it's just about what will change for a regular pharo user.

http://clementbera.wordpress.com/2014/02/06/7-points-summary-of-the-spur-mem...

Let me know if you think I forgot yet another feature.

If you have questions, I'll try to answer, but ask Eliot, he implemented Spur so he can answer your questions much better than I can :-).

Regards,

Clément

In what way would the speed-up for Characters being immediate improve Unicode performance, and/or would it be worthwhile having an immediate representation of UnicodeCharacters? I found Roassal to go an order of magnitude slower when displaying labels with Unicode (but there may be many reasons for that) ?

cheers -ben

On 06 Feb 2014, at 20:49, kilon alios <kilon.alios@gmail.com> wrote:

Igoooooor where are you ? :D

I am in no hurry personally , but its great to see the VM moving towards the right direction and see taking Pharo with it. And the other enhancements are really nice too.

I wonder if GC control will be given, to assign objects to different part of the memory of the VM. So this way you can have objects that are more, or higher prioritised garbage collected. Maybe this way, user/coder given more freedom to customise performance. Will that be possible ?

nope, just object pinning. afaik, what you ask for is not possible in any GC, because precisely the idea is to abstract you from that :)

On Thu, Feb 6, 2014 at 9:22 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

On 06 Feb 2014, at 19:51, kilon alios <kilon.alios@gmail.com> wrote:

...

thats very good news , 64 bit is rather close now which mean even more C libraries available for Pharo and loads of GB of memory to exploit.

yes, but just *closer*… we'll still need the 64bits FFI :)

...

On Thu, Feb 6, 2014 at 7:19 PM, <btc@openinworld.com> wrote: Clément Bera wrote:

...

Hello pharoers,

The new Cog memory manager, Spur, is simply *amazing*. I saw at FOSDEM that some of you were interested in it, but unfortunately you were lacking information about it.

I wrote a one page article that sums up Spur's new features so every one can know what will be better. There's no VM technical details here, it's just about what will change for a regular pharo user.

http://clementbera.wordpress.com/2014/02/06/7-points-summary-of-the-spur-mem...

Let me know if you think I forgot yet another feature.

If you have questions, I'll try to answer, but ask Eliot, he implemented Spur so he can answer your questions much better than I can :-).

Regards,

Clément

In what way would the speed-up for Characters being immediate improve Unicode performance, and/or would it be worthwhile having an immediate representation of UnicodeCharacters? I found Roassal to go an order of magnitude slower when displaying labels with Unicode (but there may be many reasons for that) ?

cheers -ben

Hi Ben, On Thu, Feb 6, 2014 at 9:19 AM, <btc@openinworld.com> wrote:

Clément Bera wrote:

Hello pharoers,

The new Cog memory manager, Spur, is simply *amazing*. I saw at FOSDEM that some of you were interested in it, but unfortunately you were lacking information about it.

I wrote a one page article that sums up Spur's new features so every one can know what will be better. There's no VM technical details here, it's just about what will change for a regular pharo user.

http://clementbera.wordpress.com/2014/02/06/7-points-summary-of-the-spur-mem...

Let me know if you think I forgot yet another feature.

If you have questions, I'll try to answer, but ask Eliot, he implemented Spur so he can answer your questions much better than I can :-).

Regards,

Clément

In what way would the speed-up for Characters being immediate improve Unicode performance, and/or would it be worthwhile having an immediate representation of UnicodeCharacters? I found Roassal to go an order of magnitude slower when displaying labels with Unicode (but there may be many reasons for that) ?

WideString>>at: index "Answer the Character stored in the field of the receiver indexed by the argument." ^ Character value: (self wordAt: index). Character class>>value: anInteger "Answer the Character whose value is anInteger." anInteger > 255 ifTrue: [^self basicNew setValue: anInteger]. ^ CharacterTable at: anInteger + 1. Currently characters are non-immediate and only the first 256 are unique. So every access of a character in a wide string requires an allocation of a character. In Spur, with immediate characters there is no instantiation. Further, because characters are simpler the JIT can produce machine-code to implement the primitives for WideString at: and at:put:, so WideString>>at: and WideString>>#at:put: will be primitive. So access will be very much faster. Here are some numbers measured on my 2.2GHz Core i7 MacBook Pro running 10.6.8. In current Cog | ws | ws := 'Hello world!' asWideString. [1 to: 100 * 1000 * 1000 do: [:i| ws at: 1]] timeToRun 2693 and | ws | ws := 'Hello world!' asWideString. ws at: 1 put: (Character value: 256). [1 to: 100 * 1000 * 1000 do: [:i| ws at: 1]] timeToRun 6100 If you redefine WideString>>at: in Spur to read WideString>>at: index "Primitive. Answer the Character stored in the field of the receiver indexed by the argument. Fail if the index argument is not an Integer or is out of bounds. Essential. See Object documentation whatIsAPrimitive." <primitive: 63> ^ Character value: (self wordAt: index). then | ws | ws := 'Hello world!' asWideString. [1 to: 100 * 1000 * 1000 do: [:i| ws at: 1]] timeToRun 711 and | ws | ws := 'Hello world!' asWideString. ws at: 1 put: (Character value: 256). [1 to: 100 * 1000 * 1000 do: [:i| ws at: 1]] timeToRun 761 These numbers are very noisy because I've got two images, Safari, Chrome and other things running. But you can see that in the case where the character is > 8 bits, the Spur code is > 8 times faster. -- best, Eliot

2014-02-06 20:34 GMT+01:00 Sebastian Sastre <sebastian@flowingconcept.com>:

Thanks for this information.

Great post.

So larger images would be no problem? let's say growing to 900MB?

I wouldn't say no problem, I would say that images up to 1 Gb should be usable and should behave much better than they used to due to the lack of full GC pauses. Now that's the theory we need to make it real and this summer we will see...

On Feb 6, 2014, at 12:48 PM, Clément Bera <bera.clement@gmail.com> wrote:

Hello pharoers,

The new Cog memory manager, Spur, is simply *amazing*. I saw at FOSDEM that some of you were interested in it, but unfortunately you were lacking information about it.

I wrote a one page article that sums up Spur's new features so every one can know what will be better. There's no VM technical details here, it's just about what will change for a regular pharo user.

http://clementbera.wordpress.com/2014/02/06/7-points-summary-of-the-spur-mem...

Let me know if you think I forgot yet another feature.

If you have questions, I'll try to answer, but ask Eliot, he implemented Spur so he can answer your questions much better than I can :-).

Regards,

Clément

Hi, The post is important for advertisement. Thanks Clément! The work is important for our future. Thanks Eliot! Doru On Fri, Feb 7, 2014 at 7:58 AM, Luc Fabresse <luc.fabresse@gmail.com> wrote:

Thanks Clement for the post and a big thank you to Eliot for Spur! Can't wait for pharo 4 running on Spur-based Cog ;-)

Luc

2014-02-07 Clément Bera <bera.clement@gmail.com>:

2014-02-06 20:34 GMT+01:00 Sebastian Sastre <sebastian@flowingconcept.com>

...

:

Thanks for this information.

...

Great post.

So larger images would be no problem? let's say growing to 900MB?

I wouldn't say no problem, I would say that images up to 1 Gb should be usable and should behave much better than they used to due to the lack of full GC pauses. Now that's the theory we need to make it real and this summer we will see...

...

On Feb 6, 2014, at 12:48 PM, Clément Bera <bera.clement@gmail.com> wrote:

Hello pharoers,

The new Cog memory manager, Spur, is simply *amazing*. I saw at FOSDEM that some of you were interested in it, but unfortunately you were lacking information about it.

I wrote a one page article that sums up Spur's new features so every one can know what will be better. There's no VM technical details here, it's just about what will change for a regular pharo user.

http://clementbera.wordpress.com/2014/02/06/7-points-summary-of-the-spur-mem...

Let me know if you think I forgot yet another feature.

If you have questions, I'll try to answer, but ask Eliot, he implemented Spur so he can answer your questions much better than I can :-).

Regards,

Clément

-- www.tudorgirba.com "Every thing has its own flow"