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 <s...@stfx.eu>: > >> On 17 Feb 2015, at 11:06, Clément Bera <bera.clem...@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-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 <ferrettiand...@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 >> >> > >
