Multi-core Software Concurrency

> On 23-10-17 15:27, horrido wrote:
>> 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.
>
> No, you tell them to use many images and/or vms. We can effectively use
> state-full micro services. Immutable data is still rather inefficient
> and in many cases we can avoid needing that.
>
> Stephan

> 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 <

> > 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
>>
>>