February 2015 - Pharo-users

Re: [Pharo-users] Small benchmark

by Andrea Ferretti

Thank you for the quick response! I will try what I get from the 4.0 VM, and of course publish the updated result once Pharo4 is out. Of course, you can add the benchmark and tweak it for your needs. Thank you for all the good work you are doing! Reaching a speed near pypy would be a real game changer! 2015-02-17 11:24 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > >> On 17 Feb 2015, at 11:06, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> Hello Andrea, >> >> The way you wrote you algorithm is nice but makes extensive use of closures and iterates a lot over collections. > > I was about to say the same thing. > >> Those are two aspects where the performance of Pharo have issues. Eliot Miranda and myself are working especially on those 2 cases to improve Pharo performance. If you don't mind, I will add your algorithm to the benchmarks we use because it really makes extensive uses of cases we are trying to optimize so its results on the bleeding edge VM are very encouraging. >> >> >> About your implementation, someone familiar with Pharo may change #timesRepeat: by #to:do: in the 2 places you use it. >> >> For example: >> run: points times: times >> 1 to: times do: [ :i | self run: points ]. >> >> I don't believe it makes it really harder to read but depending on the number of times you're using, it may show some real improvements because #to:do: is optimized at compile-time, though I tried and I got a -15% on the overall time to run only in the bleeding edge VM. > > That is a lot of difference for such a small change. > >> Another thing is that #groupedBy: is almost never used in the system and it's really *not* optimized at all. Maybe another collection protocol is better and not less readable, I don't know. >> >> >> Now about solutions: >> >> Firstly, the VM is getting faster. >> The Pharo 4 VM, to be released in July 2015, should be at least 2x faster than now. I tried it on your benchmark, and I got 5352.7 instead of 22629.1 on my machine, which is over x4 performance boost, and which put Pharo between factor and clojure performance. > > Super. Thank you, Esteban and of course Eliot for such great work, eventually we'll all be better off thanks to these improvements. > >> An alpha release is available here: https://ci.inria.fr/pharo/view/4.0-VM-Spur/ . You need to use PharoVM-spur32 as a VM and Pharo-spur32 as an image (Yes, the image changed too). You should be able to load your code, try your benchmark and have a similar result. > > I did a quick test (first time I tried Spur) and code loading was spectacularly fast. But the ride is still rough ;-) > >> In addition, we're working on making the VM again much faster on benchmarks like yours in Pharo 5. We hope to have an alpha release this summer but we don't know if it will be ready for sure. For this second step, I'm at a point where I can barely run a bench without a crash, so I can't tell right now the exact performance you can expect, but except if there's a miracle it should be somewhere between pypy and scala performance (It'll reach full performance once it gets more mature and not at first release anyway). Now I don't think we'll reach any time soon the performance of languages such as nim or rust. They're very different from Pharo: direct compilation to machine code, many low level types, ... I'm not even sure a Java implementation could compete with them. >> >> Secondly, you can use bindings to native code instead. I showed here how to write the code in C and bind it with a simple callout, which may be what you need for your bench: https://clementbera.wordpress.com/2013/06/19/optimizing-pharo-to-c-speed-wi… . Now this way of calling C does not work on the latest VM. There are 3 existing frameworks to call C from Pharo, all having pros and cons, we're trying to unify them but it's taking time. I believe for the July release of Pharo 4 there will be an official recommended way of calling C and that's the one you should use. >> >> >> I hope I wrote you a satisfying answer :-). I'm glad some people are deeply interested in Pharo performance. >> >> Best, >> >> Clement >> >> >> >> 2015-02-17 9:03 GMT+01:00 Andrea Ferretti <ferrettiandrea(a)gmail.com>: >> Hi, a while ago I was evaluating Pharo as a platform for interactive >> data exploration, mining and visualization. >> >> I was fairly impressed by the tools offered by the Pharo distribution, >> but I had a general feeling that the platform was a little slow, so I >> decided to set up a small benchmark, given by an implementation of >> K-means. >> >> The original intention was to compare Pharo to Python (a language that >> is often used in this niche) and Scala (the language that we use in >> production), but since then I have implemented a few other languages >> as well. You can find the benchmark here >> >> https://github.com/andreaferretti/kmeans >> >> Unfortunately, it turns out that Pharo is indeed the slowest among the >> implementations that I have tried. Since I am not an expert on Pharo >> or Smalltalk in general, I am asking advice here to find out if maybe >> I am doing something stupid. >> >> To be clear: the aim is *not* to have an optimized version of Kmeans. >> There are various ways to improve the algorithm that I am using, but I >> am trying to get a feeling for the performance of an algorithm that a >> casual user could implement without much thought while exploring some >> data. So I am not looking for: >> >> - better algorithms >> - clever optimizations, such as, say, invoking native code >> >> I am asking here because there is the real possibility that I am just >> messing something up, and the same naive algorithm, written by someone >> more competent, would show real improvements. >> >> Please, let me know if you find anything >> Best, >> Andrea >> >> > >

Feb. 17, 2015

Re: [Pharo-users] Small benchmark

by Sven Van Caekenberghe

> On 17 Feb 2015, at 11:06, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello Andrea, > > The way you wrote you algorithm is nice but makes extensive use of closures and iterates a lot over collections. I was about to say the same thing. > Those are two aspects where the performance of Pharo have issues. Eliot Miranda and myself are working especially on those 2 cases to improve Pharo performance. If you don't mind, I will add your algorithm to the benchmarks we use because it really makes extensive uses of cases we are trying to optimize so its results on the bleeding edge VM are very encouraging. > > > About your implementation, someone familiar with Pharo may change #timesRepeat: by #to:do: in the 2 places you use it. > > For example: > run: points times: times > 1 to: times do: [ :i | self run: points ]. > > I don't believe it makes it really harder to read but depending on the number of times you're using, it may show some real improvements because #to:do: is optimized at compile-time, though I tried and I got a -15% on the overall time to run only in the bleeding edge VM. That is a lot of difference for such a small change. > Another thing is that #groupedBy: is almost never used in the system and it's really *not* optimized at all. Maybe another collection protocol is better and not less readable, I don't know. > > > Now about solutions: > > Firstly, the VM is getting faster. > The Pharo 4 VM, to be released in July 2015, should be at least 2x faster than now. I tried it on your benchmark, and I got 5352.7 instead of 22629.1 on my machine, which is over x4 performance boost, and which put Pharo between factor and clojure performance. Super. Thank you, Esteban and of course Eliot for such great work, eventually we'll all be better off thanks to these improvements. > An alpha release is available here: https://ci.inria.fr/pharo/view/4.0-VM-Spur/ . You need to use PharoVM-spur32 as a VM and Pharo-spur32 as an image (Yes, the image changed too). You should be able to load your code, try your benchmark and have a similar result. I did a quick test (first time I tried Spur) and code loading was spectacularly fast. But the ride is still rough ;-) > In addition, we're working on making the VM again much faster on benchmarks like yours in Pharo 5. We hope to have an alpha release this summer but we don't know if it will be ready for sure. For this second step, I'm at a point where I can barely run a bench without a crash, so I can't tell right now the exact performance you can expect, but except if there's a miracle it should be somewhere between pypy and scala performance (It'll reach full performance once it gets more mature and not at first release anyway). Now I don't think we'll reach any time soon the performance of languages such as nim or rust. They're very different from Pharo: direct compilation to machine code, many low level types, ... I'm not even sure a Java implementation could compete with them. > > Secondly, you can use bindings to native code instead. I showed here how to write the code in C and bind it with a simple callout, which may be what you need for your bench: https://clementbera.wordpress.com/2013/06/19/optimizing-pharo-to-c-speed-wi… . Now this way of calling C does not work on the latest VM. There are 3 existing frameworks to call C from Pharo, all having pros and cons, we're trying to unify them but it's taking time. I believe for the July release of Pharo 4 there will be an official recommended way of calling C and that's the one you should use. > > > I hope I wrote you a satisfying answer :-). I'm glad some people are deeply interested in Pharo performance. > > Best, > > Clement > > > > 2015-02-17 9:03 GMT+01:00 Andrea Ferretti <ferrettiandrea(a)gmail.com>: > Hi, a while ago I was evaluating Pharo as a platform for interactive > data exploration, mining and visualization. > > I was fairly impressed by the tools offered by the Pharo distribution, > but I had a general feeling that the platform was a little slow, so I > decided to set up a small benchmark, given by an implementation of > K-means. > > The original intention was to compare Pharo to Python (a language that > is often used in this niche) and Scala (the language that we use in > production), but since then I have implemented a few other languages > as well. You can find the benchmark here > > https://github.com/andreaferretti/kmeans > > Unfortunately, it turns out that Pharo is indeed the slowest among the > implementations that I have tried. Since I am not an expert on Pharo > or Smalltalk in general, I am asking advice here to find out if maybe > I am doing something stupid. > > To be clear: the aim is *not* to have an optimized version of Kmeans. > There are various ways to improve the algorithm that I am using, but I > am trying to get a feeling for the performance of an algorithm that a > casual user could implement without much thought while exploring some > data. So I am not looking for: > > - better algorithms > - clever optimizations, such as, say, invoking native code > > I am asking here because there is the real possibility that I am just > messing something up, and the same naive algorithm, written by someone > more competent, would show real improvements. > > Please, let me know if you find anything > Best, > Andrea > >

Feb. 17, 2015

Re: [Pharo-users] Small benchmark

by ClÃ©ment Bera

Hello Andrea, The way you wrote you algorithm is nice but makes extensive use of closures and iterates a lot over collections. Those are two aspects where the performance of Pharo have issues. Eliot Miranda and myself are working especially on those 2 cases to improve Pharo performance. If you don't mind, I will add your algorithm to the benchmarks we use because it really makes extensive uses of cases we are trying to optimize so its results on the bleeding edge VM are very encouraging. About your implementation, someone familiar with Pharo may change #timesRepeat: by #to:do: in the 2 places you use it. For example: run: points times: times * 1 to: times do:* [ :i | self run: points ]. I don't believe it makes it really harder to read but depending on the number of times you're using, it may show some real improvements because #to:do: is optimized at compile-time, though I tried and I got a -15% on the overall time to run only in the bleeding edge VM. Another thing is that #groupedBy: is almost never used in the system and it's really *not* optimized at all. Maybe another collection protocol is better and not less readable, I don't know. Now about solutions: Firstly, the VM is getting faster. The Pharo 4 VM, to be released in July 2015, should be at least 2x faster than now. I tried it on your benchmark, and I got 5352.7 instead of 22629.1 on my machine, which is over x4 performance boost, and which put Pharo between factor and clojure performance. An alpha release is available here: https://ci.inria.fr/pharo/view/4.0-VM-Spur/ . You need to use PharoVM-spur32 as a VM and Pharo-spur32 as an image (Yes, the image changed too). You should be able to load your code, try your benchmark and have a similar result. In addition, we're working on making the VM again much faster on benchmarks like yours in Pharo 5. We hope to have an alpha release this summer but we don't know if it will be ready for sure. For this second step, I'm at a point where I can barely run a bench without a crash, so I can't tell right now the exact performance you can expect, but except if there's a miracle it should be somewhere between pypy and scala performance (It'll reach full performance once it gets more mature and not at first release anyway). Now I don't think we'll reach any time soon the performance of languages such as nim or rust. They're very different from Pharo: direct compilation to machine code, many low level types, ... I'm not even sure a Java implementation could compete with them. Secondly, you can use bindings to native code instead. I showed here how to write the code in C and bind it with a simple callout, which may be what you need for your bench: https://clementbera.wordpress.com/2013/06/19/optimizing-pharo-to-c-speed-wi… . Now this way of calling C does not work on the latest VM. There are 3 existing frameworks to call C from Pharo, all having pros and cons, we're trying to unify them but it's taking time. I believe for the July release of Pharo 4 there will be an official recommended way of calling C and that's the one you should use. I hope I wrote you a satisfying answer :-). I'm glad some people are deeply interested in Pharo performance. Best, Clement 2015-02-17 9:03 GMT+01:00 Andrea Ferretti <ferrettiandrea(a)gmail.com>: > Hi, a while ago I was evaluating Pharo as a platform for interactive > data exploration, mining and visualization. > > I was fairly impressed by the tools offered by the Pharo distribution, > but I had a general feeling that the platform was a little slow, so I > decided to set up a small benchmark, given by an implementation of > K-means. > > The original intention was to compare Pharo to Python (a language that > is often used in this niche) and Scala (the language that we use in > production), but since then I have implemented a few other languages > as well. You can find the benchmark here > > https://github.com/andreaferretti/kmeans > > Unfortunately, it turns out that Pharo is indeed the slowest among the > implementations that I have tried. Since I am not an expert on Pharo > or Smalltalk in general, I am asking advice here to find out if maybe > I am doing something stupid. > > To be clear: the aim is *not* to have an optimized version of Kmeans. > There are various ways to improve the algorithm that I am using, but I > am trying to get a feeling for the performance of an algorithm that a > casual user could implement without much thought while exploring some > data. So I am not looking for: > > - better algorithms > - clever optimizations, such as, say, invoking native code > > I am asking here because there is the real possibility that I am just > messing something up, and the same naive algorithm, written by someone > more competent, would show real improvements. > > Please, let me know if you find anything > Best, > Andrea > >

Feb. 17, 2015

Small benchmark

by Andrea Ferretti

Hi, a while ago I was evaluating Pharo as a platform for interactive data exploration, mining and visualization. I was fairly impressed by the tools offered by the Pharo distribution, but I had a general feeling that the platform was a little slow, so I decided to set up a small benchmark, given by an implementation of K-means. The original intention was to compare Pharo to Python (a language that is often used in this niche) and Scala (the language that we use in production), but since then I have implemented a few other languages as well. You can find the benchmark here https://github.com/andreaferretti/kmeans Unfortunately, it turns out that Pharo is indeed the slowest among the implementations that I have tried. Since I am not an expert on Pharo or Smalltalk in general, I am asking advice here to find out if maybe I am doing something stupid. To be clear: the aim is *not* to have an optimized version of Kmeans. There are various ways to improve the algorithm that I am using, but I am trying to get a feeling for the performance of an algorithm that a casual user could implement without much thought while exploring some data. So I am not looking for: - better algorithms - clever optimizations, such as, say, invoking native code I am asking here because there is the real possibility that I am just messing something up, and the same naive algorithm, written by someone more competent, would show real improvements. Please, let me know if you find anything Best, Andrea

Feb. 17, 2015

Re: [Pharo-users] Spec help in HelpBrowser

by Craig

From: nacho > >If you are interested in having some Spec documentation in the image. >I'm preparing some help for the HelpBrowser. It is mainly taken from >the Spec chapter that it's being written. >However if you want to take a look: ... Well done Nacho, I like this a lot. What you have started with is going to be useful to newbies. What I'd love to see is the next logical step of documentation of the more commonly used widgets. Craig

Feb. 17, 2015

Re: [Pharo-users] [ANN (Toy)]: Gold Rush

by Ben Coman

Should that be.... ? "You can describe a piece of jewelry like:" | ring | ring := GoldJewelry new weight: 4.1 grams; carats: 18; price: 275 dollars; pinch yourself. On Tue, Feb 17, 2015 at 10:41 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I was in a jewelry store, and I realized how hard it is to figure out the > markup on gold jewelry, so I did a little code kata... > > Loads in 4.0 with: > Gofer it > smalltalkhubUser: 'SeanDeNigris' project: 'SeansPlayground'; > configurationOf: 'GoldRush'; > loadDevelopment. > > (#GoldRushSpecification asClass>>#testAcceptance) browse. > > "You can describe a piece of jewelry like:" > | ring | > ring := GoldJewelry new > weight: 4.1 grams; > carats: 18; > price: 275 dollars; > yourself. > > "And then see how much of a premium you're paying over the gold's melt > value > e.g.:" > ring markup should equal: ring price - expectedGoldValue. > ring percentOverSpot percent should equal: ring price / > expectedGoldValue - > 1. > > "If you inspect a GoldJewelry with GT Tools, you will see a special "Gold" > tab with the same calculated values (i.e. #markup and #percentOverSpot)" > ____________________________________ > > This was an interesting and fun test of Aconcagua, GT Tools, and Pharo 4.0 > :) > > n.b. it pulls the gold spot price off the web, updating daily. > > Have fun! > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/ANN-Toy-Gold-Rush-tp4806070.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Feb. 17, 2015

[ANN (Toy)]: Gold Rush

by Sean P. DeNigris

I was in a jewelry store, and I realized how hard it is to figure out the markup on gold jewelry, so I did a little code kata... Loads in 4.0 with: Gofer it smalltalkhubUser: 'SeanDeNigris' project: 'SeansPlayground'; configurationOf: 'GoldRush'; loadDevelopment. (#GoldRushSpecification asClass>>#testAcceptance) browse. "You can describe a piece of jewelry like:" | ring | ring := GoldJewelry new weight: 4.1 grams; carats: 18; price: 275 dollars; yourself. "And then see how much of a premium you're paying over the gold's melt value e.g.:" ring markup should equal: ring price - expectedGoldValue. ring percentOverSpot percent should equal: ring price / expectedGoldValue - 1. "If you inspect a GoldJewelry with GT Tools, you will see a special "Gold" tab with the same calculated values (i.e. #markup and #percentOverSpot)" ____________________________________ This was an interesting and fun test of Aconcagua, GT Tools, and Pharo 4.0 :) n.b. it pulls the gold spot price off the web, updating daily. Have fun! ----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-Toy-Gold-Rush-tp4806070.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 17, 2015

Re: [Pharo-users] [ANN] PUnQLite NoSQL database project updated

by Pierce Ng

On Sat, Feb 14, 2015 at 09:30:12AM +0100, Stephan Eggermont wrote: > db := PqDatabase open: 'test.db'. Try using a FQPN. See this post about Pharo.app's default working directory being "/" on OSX: http://forum.world.st/NBSQLite3-on-OS-X-Pharo-3-tc4800276.html#a4801485 Pierce

Feb. 17, 2015

Re: [Pharo-users] Roassal question

by Pierre Chanson

Thank you very much Werner ! :) actually it's not complicated at all, based on some other builders. But I realized how it can be useful as I really sometime need to see where some elements of my view are (and not in a relative position to one origin. Even if the position is relative to the canvas at least ^^). Having a quick look without placing popups or having to inspect elements. Maybe it can be used just during the elaboration of a layout for some or all the elements. I guess it's is working with any shapes, but it's ok if you go on holidays so I can take some time to improve it. The size of the thicks and the axis width can be set by default in proportion of the bigger element maybe, and it would be interesting to really have the shape and position of axis or number of them you want to, easily definable. Have a good vacations, Pierre > On 16 fÃ©vr. 2015, at 7:36 PM, Werner Kassens <wkassens(a)libello.com> wrote: > > Hi Pierre, > wow, you see me really impressed! yes, that is <g> what i was looking for, i see in your picture that it is possible to use floats, not only integers, exactly what i would need. i suppose i can also use rectangles that are not quadratic? i will go on vacation tomorrow and will be back in a week, hence trying out everything will have to wait for a moment, but i'd guess this is exactly what i need. >> So I integrated a RTAxisAdaptedBuilder in the last version of Roassal2 >> for that. >> >> The RTAxisAdaptedBuilderExample>>example2 would correspond to your >> rectangles problem. I just changed for now the size of the rectangles >> because my axis don't yet adapt to small rectangle size (and it does not >> look nice). > i do have some extremely small rectangles (iow i have to check how these things are displayed) mixed with bigger ones, but they are dispersed over a bigger region or hull, iow this would generally not be a problem for the axis scale. > Thank you very much, i am sincerely impressed > werner >

Feb. 17, 2015

Spec help in HelpBrowser

by nacho

If you are interested in having some Spec documentation in the image. I'm preparing some help for the HelpBrowser. It is mainly taken from the Spec chapter that it's being written. However if you want to take a look: MCSmalltalkhubRepository owner: 'IgnacioSniechowski' project: 'SpecHelp' user: '' password: '' Best Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Spec-help-in-HelpBrowser-tp4806055.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 16, 2015