Re: [Pharo-dev] What will change in Pharo with Spur the new Cog memory manager ...
Clément wrote: 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... I'm a bit confused by the term 'big image'. I regularly use 1GB images with cog, and they stay responsive enough for development work. As long as there is enough free space that the full gc doesn't have to happen very often, it's ok. Current home machines work with 32 GB ram though, so I hope the gc can handle somewhat larger images? Stephan Eggermont
Re: [Pharo-dev] What will change in Pharo with Spur the new Cog memory manager ...
Clment 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-memory-manager/ 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, Clment 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
Re: [Pharo-dev] What will change in Pharo with Spur the new Cog memory manager ...
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. On Thu, Feb 6, 2014 at 7:19 PM, b...@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-memory-manager/ 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
Re: [Pharo-dev] What will change in Pharo with Spur the new Cog memory manager ...
Igoor 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 ? On Thu, Feb 6, 2014 at 9:22 PM, Esteban Lorenzano esteba...@gmail.comwrote: On 06 Feb 2014, at 19:51, kilon alios kilon.al...@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, b...@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-memory-manager/ 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
Re: [Pharo-dev] What will change in Pharo with Spur the new Cog memory manager ...
ah ok , shows how little I know about GCs :D On Thu, Feb 6, 2014 at 10:35 PM, Esteban Lorenzano esteba...@gmail.comwrote: On 06 Feb 2014, at 20:49, kilon alios kilon.al...@gmail.com wrote: Igoor 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 esteba...@gmail.comwrote: On 06 Feb 2014, at 19:51, kilon alios kilon.al...@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, b...@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-memory-manager/ 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
Re: [Pharo-dev] What will change in Pharo with Spur the new Cog memory manager ...
Hi Ben, On Thu, Feb 6, 2014 at 9:19 AM, b...@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-memory-manager/ 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) ? WideStringat: index Answer the Character stored in the field of the receiver indexed by the argument. ^ Character value: (self wordAt: index). Character classvalue: 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 WideStringat: 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 WideStringat: in Spur to read WideStringat: 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
Re: [Pharo-dev] What will change in Pharo with Spur the new Cog memory manager ...
2014-02-06 20:34 GMT+01:00 Sebastian Sastre sebast...@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.clem...@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-memory-manager/ 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
Re: [Pharo-dev] What will change in Pharo with Spur the new Cog memory manager ...
Sounds great!!! Alexandre Le 06-02-2014 à 11:48, Clément Bera bera.clem...@gmail.com a écrit : 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-memory-manager/ 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
Re: [Pharo-dev] What will change in Pharo with Spur the new Cog memory manager ...
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.clem...@gmail.com: 2014-02-06 20:34 GMT+01:00 Sebastian Sastre sebast...@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.clem...@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-memory-manager/ 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
