What is the complexity of parallel parallel building of Smalltalk?

Question

Given the basic model of objects that are independent computing engines (storage is vars instances, CPUs are class methods) that respond to messages transmitted from one to another, it would seem that Smalltalk would be a natural approach for parallel processing of a massive number of cores. However, this is an area where Smalltalk is still very weak, responding to its own simulated multitasking features that do not use the hardware capabilities of modern processors.

Why is this? What are the main issues? Is volatility the key, or is it something more specific to Smalltalk?

Answer 1

First of all, recall that GemStone proves that Smalltalk can be expanded to support parallel computing. Of course, the question remains, because GemStone is a very complex system (think, for example, in the garbage collector!), And all other dialects do not behave this way.

Parallel computing requires thread-safe code; otherwise the race conditions will appear all the time. The problem is that creating thread-safe Smalltalk code can damage all complexity. Consider, for example,

OrderedCollection >> addLast: anObject lastIndex = array size ifTrue: [self makeRoomAtLast]. lastIndex := lastIndex + 1. ^array at: lastIndex put: newObject 

Interruption between these lines of code can lead to inconsistencies in the internal state of the receiver. Of course, this can happen with non-parallel execution, since Smalltalk supports interrupts. However, the way Smalltalk is used is limited to critical sections that occur less frequently and therefore are under control.

The reason why adding thread-safe code is not so natural in Smalltalk is because we have an image in Smalltalk. This means that for all processes there are many objects, including, for example, all classes, compiled methods, etc. The dynamic nature of Smalltalk, which is widely used by the system and its applications, makes things even more complicated.

In my personal experience, a good way to achieve multi-core capabilities in Smalltalk is to run various OS processes (headless instances) and coordinate them using semaphores and Smalltalk processes. With this approach, each OS process is represented in the main image (with a user interface) by the Smalltalk process. The connection between the main image and the headless processes can be based on sockets (or any other function). Of course, you pay the price when debugging. In fact, you end up tracking a lot of events in the log files and open the debuggers in the "silent" processes until you understand what went wrong. But this can be done not only as a demonstration, but also for a real "industrial strong" product.

Answer 2

Complexity? Is absent

Just run multiple instances of Pharo and transfer them through sockets or save their final data to a shared file. Your OS will manage each instance and send it to run in diffirent core. The OSProcess module offers such functionality and has successful implementations such as Hydra and RoarVM, the problem is that no one is using them.

In fact, the hardest part of parallelism is getting people to use it. Today's hardware applications rarely fall into 100% of a single core. I barely made Faro above 10%.

Like many dynamic programming languages, Smalltalk is a developer development language, not an application language.

If you really have such a serious processing problem, you should use languages ​​like C and C ++, which are very application-oriented. Not only is it harder to use this language, but even parallelism is very difficult to do correctly even in the right library. The hardware is very strange, wise in design, and there are a ton of bugs you should know about.

And that is why parallelism is better suited for these programming languages. Of course, you can create libraries in C / C ++ and use Pharo or other smalltalks. Python does this. Python and Pharo are very similar, as they use GIL and have green threads. It turns out that you have to join your threads back to the main thread so that the virtual machine has direct access to it, but there are ways to get around this, as I said, socket communication, pipes, files with shared memory and much more.

All parallel Python libraries are based on C / C ++.

Parallelism itself is a very complex question, even if you have parallelism, that your code will be as slow as running on a single thread and one core. But this is a common problem with application performance, the moment you want to release as much energy as you need to know how the equipment works.

Today, the hardware is supercomplex. Language is the least of your problems.

This is possible in Smalltalk, but frankly, there are not many people in it. I saw questions about parallelism on the Pharo mailing lists that I often visit the last two years, maybe once or twice. And even for concurrency it is very rare that someone asks a question about this.