Thanks. Good answer.
kilon.alios wrote > It all comes down to what you mean by "efficient". Obviously if you want > top performance on multiple cores you dont use any of those languages > including Pharo. Thats prettty much the sole reason why C++ is still a > relevant language. > > Now if you want ok performance you could use those languages. > > However in real case scenarios if you are worried about multi core support > then you have performance issues that you have to make sure its not the > code that has to be blamed before the language. > > For example yesterday I was loading a PNG file via Python to display on > screen via OpenGL and I was getting very slow performance 2.7 second for > 1.5 mb PNG. So my assumption as always "super slow python". But I decided > to give a try to another Python library and expected no more than 1.5 - 2 > seconds load time for the same file. It loaded in 0.03 seconds and took > some time to collect my jaw from the floor. > > Of course the previous library used a "pure python" approach , the other > library was the usual C library wrapped for Python. > > So the library and the code plays a massive role, and I mention this > example because Pharo works in a very similar way. If you do the code in > pure Pharo, Elixir or whatever you will be hit by the performance whale of > dynamic languages. Dynamic typing comes with a high cost as does a live > coding enviroment. Pharo is very lucky in that it has a JIT VM espeically > optimised for its language, so generally you wont get the slow speeds I > got. But still C will once more run circles around a Pharo implementation > , > especially if its an optimised library. > > Thus we have the UFFI. Esteban has done an excellent job and works like a > charm for using C libraries. > > Now if C also is proven slow then multi core wont help you much. > > You need the big guns , which is another name for "GPUs". A powerful GPU > is > even hundrends time faster than the most powerful CPU because it has > thousands of cores. But those cores are designed to compute similar tasks > hence why we dont throw CPUs away which are more versatile. > > So if you plan to do similar computations through millions of objects, > multi core wont help you much, you need the big guns a very expensive and > powerful GPU to do the heavy lifting. > > GPUs used to specialise only on Graphics, but 3d has become so complex > that > nowdays they can do all sort of computations and they have dedicate APIs > for accesing thousands of cores via OpenCL and CUDA. > > Unsuprisingly they run mainly on C/C++. > > The good news is that through the UFFI is possible to access a GPU via > Pharo, Ronie has done this. > > But to my experience most people dont realise what an extremely complex > field performance is and how it widely fluctuates from scenario to > scenario. So there is no "turbo" button to press. > > Now if you ask "but how I do this with pharo". Well technically you dont > do > this with Pharo because Pharo is made to run on CPU. > > GPUs run their own executables which means you have to use special > compilers , good news is that they can do compiling on the fly too so > Pharo > can leverage that. Again Ronie's works is relevant here. > > If you want to avoid all the complexity and go for the simplest solution , > then avoid the GPU. Because GPUs are kinda insane in terms of complexity. > > The easiest way is to fire up multiple Pharo and have them communicate > with > each other via socket or shared memory. The OS when it starts a new > process > it usually asigns it a core that is idle to take advantage of your > multiple > cores. > > Summary: > The answer is "Pharo can do this by accessing the GPU which much faster > than CPU or can access multiple cores through multiple instances running > at > the same time". > > So yes you can have top performance Pharo code if run this way, it wont be > up to C standards but it will be blazzing fast none the less. > > On Mon, Oct 23, 2017 at 4:28 PM horrido < > horrido.hobbies@ > > wrote: > >> With today’s powerful multi-core processors, the demand for efficient >> software concurrency is high. We find strong support for such concurrency >> in >> the latest crop of “modern” languages such as Clojure, Elixir, Go, >> Haskell, >> and Scala. >> >> Whenever I present Smalltalk (Pharo) as a great language option, >> inevitably >> someone asks me about multi-core software concurrency. I have no response >> for them. >> >> Do I just say that if you need concurrency, Pharo is the wrong choice? >> After >> all, no programming language can be good at everything. You must always >> choose the right tool for the job. >> >> Do I say that doing concurrency right is very, very tough, even for the >> most >> experienced of developers? Let's focus on Pharo's strengths, instead. >> Sounds >> like an excuse. >> >> Can we safely ignore the multi-core reality? I welcome your feedback. >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
