February 2015 - Pharo-users

Re: [Pharo-users] how do I recompile a class in Pharo 3?

by Joachim Tuchel

I can only think of filing out and back in... Joachim Am 17.02.2015 18:25 schrieb Paul DeBruicker <pdebruic(a)gmail.com>: > > And a package, class heirarcy, etc.... > > > > Thanks for any tips > > > Paul > >

Feb. 17, 2015

Re: [Pharo-users] how do I recompile a class in Pharo 3?

by Esteban Lorenzano

TheClass recompile. TheClass withAllSubclassesDo: #recompile. TheClass package classes do: #recompile. cheers, Esteban > On 17 Feb 2015, at 18:25, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > > And a package, class heirarcy, etc.... > > > > Thanks for any tips > > > Paul >

Feb. 17, 2015

how do I recompile a class in Pharo 3?

by Paul DeBruicker

And a package, class heirarcy, etc.... Thanks for any tips Paul

Feb. 17, 2015

Re: [Pharo-users] Issues with code formatting

by Peter UhnÃ¡k

Hi, what version are you using? I see it in the settings under Code Browsing > Pretty Printing. Peter On Tue, Feb 17, 2015 at 3:17 PM, sergio_101 <sergio.rrd(a)gmail.com> wrote: > my pretty print is acting much differently than it used to. it seems to be > breaking every statement into a separate line. at some point, i remember > being able to adjust this via some system settings, but i am not finding > that anymore. is this called something different now, or am i just not > understanding how it works? > > thanks! >

Feb. 17, 2015

Re: [Pharo-users] Small benchmark

by Alexandre Bergel

This is a fantastic answer. Thanks Clement! Alexandre > Le 17 fÃ©vr. 2015 Ã 06:06, ClÃ©ment Bera <bera.clement(a)gmail.com> a Ã©crit : > > 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

Re: [Pharo-users] Small benchmark

by Thierry Goubier

Hi Clement, Eliot, this update prompted me to try as well Spur + Pharo, so I set up some sort of environment for that. I too had a FreeType related bug, solved by replacing the Source Code Pro font setting by Source Sans Pro in the code panes, but, otherwise it seems fine, opens faster, etc... I'm happy :) (platform is Ubuntu 14.10 64bits) Now I need to finish a Makefile for downloading all the latest sucessfull things from Jenkins. I have the image, now I need to setup for the vm as well. Thierry 2015-02-17 13:14 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > > > 2015-02-17 12:29 GMT+01:00 Andrea Ferretti <ferrettiandrea(a)gmail.com>: > >> Unfortunately, I was not able to run the benchmark at all on the >> latest Spur image+VM. >> >> As soon as I try writing anything in the Workspace, I get >> PrimitiveFailed: primitive #basicNew: in Array class failed. Since the >> stacktrace mentions font rendering, I thought it had something to do >> with the fonts not loaded and tried >> >> FreeTypeFontProvider current updateFromSystem >> >> (at least, I was able to paste it) but it seems it has nothing to do >> with it. For the records, I am on Ubuntu 14.04 running gnome shell. >> > > I am on Mac OS X 10.8 and it works for me. > > I had once this bug but when I reopened the Workspace it did not happen > again and I could not reproduce it anymore. > > Well this VM is an alpha version. Esteban is changing it very often so a > bug may have been introduced. The stable release should work better for > sure... > >> >> Looking forward to the next stable release! >> >> thank you again >> Andrea >> >> >> 2015-02-17 11:54 GMT+01:00 Andrea Ferretti <ferrettiandrea(a)gmail.com>: >> > 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

Issues with code formatting

by sergio_101

my pretty print is acting much differently than it used to. it seems to be breaking every statement into a separate line. at some point, i remember being able to adjust this via some system settings, but i am not finding that anymore. is this called something different now, or am i just not understanding how it works? thanks!

Feb. 17, 2015

Re: [Pharo-users] Small benchmark

by ClÃ©ment Bera

2015-02-17 12:29 GMT+01:00 Andrea Ferretti <ferrettiandrea(a)gmail.com>: > Unfortunately, I was not able to run the benchmark at all on the > latest Spur image+VM. > > As soon as I try writing anything in the Workspace, I get > PrimitiveFailed: primitive #basicNew: in Array class failed. Since the > stacktrace mentions font rendering, I thought it had something to do > with the fonts not loaded and tried > > FreeTypeFontProvider current updateFromSystem > > (at least, I was able to paste it) but it seems it has nothing to do > with it. For the records, I am on Ubuntu 14.04 running gnome shell. > I am on Mac OS X 10.8 and it works for me. I had once this bug but when I reopened the Workspace it did not happen again and I could not reproduce it anymore. Well this VM is an alpha version. Esteban is changing it very often so a bug may have been introduced. The stable release should work better for sure... > > Looking forward to the next stable release! > > thank you again > Andrea > > > 2015-02-17 11:54 GMT+01:00 Andrea Ferretti <ferrettiandrea(a)gmail.com>: > > 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] [ANN (Toy)]: Gold Rush

by Sean P. DeNigris

Ben Coman wrote > Should that be.... ? > ... pinch yourself. ;-p ----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-Toy-Gold-Rush-tp4806070p4806167.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 17, 2015

Re: [Pharo-users] Small benchmark

by Andrea Ferretti

Unfortunately, I was not able to run the benchmark at all on the latest Spur image+VM. As soon as I try writing anything in the Workspace, I get PrimitiveFailed: primitive #basicNew: in Array class failed. Since the stacktrace mentions font rendering, I thought it had something to do with the fonts not loaded and tried FreeTypeFontProvider current updateFromSystem (at least, I was able to paste it) but it seems it has nothing to do with it. For the records, I am on Ubuntu 14.04 running gnome shell. Looking forward to the next stable release! thank you again Andrea 2015-02-17 11:54 GMT+01:00 Andrea Ferretti <ferrettiandrea(a)gmail.com>: > 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