Python, Ruby, Haskell - Do They Provide True Multithreading?

Question

We plan to write a highly competitive application in any of the Very-High programming languages.

1) Do Python, Ruby or Haskell support true multithreading?

2) If the program contains threads, will the virtual machine automatically assign work to several cores (or physical CPUs if there are more than 1 CPU on the motherboard)?

True multithreading = multiple independent threads use resources provided by several cores (not only with one core).

False multithreading = threads emulate multithreaded environments, not relying on any features of their own OS.

Answer 1

1) Do Python, Ruby or Haskell support true multithreading?

This has nothing to do with language. We are talking about hardware (if there is only 1 processor on the computer, it is simply physically impossible to execute two instructions at the same time), the operating system (again, if the OS does not support true multithreading, there is nothing you can do) and the language execution / execution mechanism.

If a language specification explicitly prohibits or applies true multithreading, this has absolutely nothing to do with the language.

All the languages ​​you mention, plus all the languages ​​mentioned in the answers so far, have several implementations, some of which support true multithreading, some not, and some of them are built on top of other execution mechanisms that may or may not support true multithreading.

Take Ruby, for example. Here are just a few of its implementations and their stream models:

• MRI: green threads, no true multithreading
• YARV: OS threads, no true multithreading
• Rubinius: OS threads, true multithreading
• MacRuby: OS threads, true multithreading
• JRuby, XRuby: JVM threads, depends on the JVM (if the JVM supports true multithreading, then JRuby / XRuby too, if the JVM does not, then there is nothing you can do about it)
• IronRuby, Ruby.NET: like JRuby, XRuby, but in the CLI, not in the JVM

See also my answer to another similar question about Ruby . (Note that this answer is over a year old, and some of them are no longer accurate. Rubinius, for example, now uses real parallel native threads instead of real parallel green threads. In addition, since then several new Ruby implementations have such as BlueRuby, tinyrb , Ruby Go Lightly, Red Sun, and SmallRuby.)

Similarly for Python:

• CPython: native threads, no true multithreading
• PyPy: native threads, depends on the execution mechanism (PyPy can be run initially either on top of the JVM or on top of the CLI or on top of another Python execution mechanism. Whenever the underlying platform supports true multithreading, PyPy too.)
• Unladen Swallow: native threads, there is currently no true multithreading, but a fix is ​​planned
• Jython: JVM threads, see JRuby
• IronPython: CLI threads, see IronRuby

For Haskell, at least the Glorious Glasgow Haskell Compiler supports true multithreading with native threads. I do not know about UHC, LHC, JHC, YHC, HUGS or everyone else.

For Erlang, both BEAM and HiPE support true multithreading with green threads.

2) If the program contains threads, will the virtual machine automatically assign work to several cores (or physical CPUs if the motherboard has more than 1 CPU)?

Again: this depends on the virtual machine, operating system, and hardware. In addition, some of the implementations mentioned above do not even have virtual machines.

Answer 2

The Haskell implementation, GHC, supports several mechanisms for parallel execution in multi-core shared memory. These mechanisms are described in runtime support for multi-core Haskell .

Specifically, the Haskell runtime divides the work into N OS threads distributed across the available processing cores. These N OS threads, in turn, trigger Haskell threads with a small thread (sometimes millions). In turn, each Haskell thread can take work as a spark queue (there may be billions of sparks). Like this:

Execution schedules are executed on separate cores, work and load balances are transferred. The garbage collector is also parallel, using each core to collect part of the heap.

Unlike Python or Ruby, there is no global interpreter lock, so for this and for other reasons, GHC is especially good compared to mulitcore, for example. Haskell v Python in multi-core shootout

Answer 3

The GHC compiler will run your program on several OS threads (and therefore on several kernels) if you compile with the -threaded option and then skip +RTS -N<x> -RTS at runtime, where <x> = number OS threads you want.

Answer 4

The current version of Ruby 1.9 (a version based on YARV-C) has its own threads, but the problem is GIL. As I know, Python also has a GIL problem.

However, both Jython and JRuby (mature Java implementations of both Ruby and Python) provide built-in multithreading, no green threads, and no GIL.

I do not know about Haskell.

Answer 5

Haskell works with the stream, in addition you get a pure functional language - no side effects

Answer 6

For real concurrency, you probably want to try Erlang.

Answer 7

I am Erlang's second choice. Erlang can support distributed, highly competitive programming out of the box. It doesn't matter if you call "multithreading" or "multiprocessing". Two important elements to consider are the concurrency level and the fact that Erlang processes do not share state .

The lack of a general state between processes is good.

Answer 8

Haskell is right for everything. python has a processing module, which (I think not sure) helps to avoid problems with the GIL. (so that is suitable for anything).

But my opinion is the best way you can do is to choose the highest level possible language with a static type system for big and big things. Today these languages ​​are: ocaml, haskell, erlang.

If you want to develop a small thing - python is good. But when things get bigger - all the benefits of python are consumed by a myriad of tests.

I have not used ruby. I still think ruby ​​is a toy language. (Or, at least, there is no reason to learn ruby ​​when you know python - it is better to read the SICP book).