This is a fantastic answer. Thanks Clement! Alexandre
> Le 17 févr. 2015 à 06:06, Clément Bera <[email protected]> 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-with-nativeboost-ffi/ > . 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 <[email protected]>: >> 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 >
