Yes, but isn't there an important class of concurrent software where lightweight threads work on shared state? Isn't that the reason for "goroutines" in Go, and STM in Clojure, and actors in Scala? Stephan Eggermont-3 wrote

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

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

That's the GemStone model. It works well for our customers. On Oct 23, 2017 07:03, "stephan" <stephan@stack.nl> wrote:

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

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