We are planning to write a highly concurrent application in any of the Very-High Level programming languages.
我们正计划用任何高级编程语言编写一个高度并发的应用程序。
1) Do Python, Ruby, or Haskell support true multithreading?
1) Python、Ruby或Haskell支持真正的多线程吗?
2) If a program contains threads, will a Virtual Machine automatically assign work to multiple cores (or to physical CPUs if there is more than 1 CPU on the mainboard)?
2)如果一个程序包含线程，那么虚拟机是否会自动地将工作分配给多个内核(如果主板上有超过一个CPU，则分配给物理CPU)?
True multithreading = multiple independent threads of execution utilize the resources provided by multiple cores (not by only 1 core).
真正的多线程=多个独立的执行线程利用由多个核心提供的资源(而不仅仅是一个核心)。
False multithreading = threads emulate multithreaded environments without relying on any native OS capabilities.
假多线程=线程模拟多线程环境而不依赖于任何本机OS功能。
8 个解决方案
#1
33
1) Do Python, Ruby, or Haskell support true multithreading?
1) Python、Ruby或Haskell支持真正的多线程吗?
This has nothing to do with the language. It is a question of the hardware (if the machine only has 1 CPU, it is simply physically impossible to execute two instructions at the same time), the Operating System (again, if the OS doesn't support true multithreading, there is nothing you can do) and the language implementation / execution engine.
这与语言无关。这是一个硬件问题(如果机器只有一个CPU,它不能从物理上同时执行两个指令),操作系统(如果操作系统不支持真正的多线程,没有什么你可以做)和语言实现/执行引擎。
Unless the language specification explicitly forbids or enforces true multithreading, this has absolutely nothing whatsoever to do with the language.
除非语言规范明确禁止或强制使用真正的多线程，否则这与语言没有任何关系。
All the languages that you mention, plus all the languages that have been mentioned in the answers so far, have multiple implementations, some of which support true multithreading, some don't, and some are built on top of other execution engines which might or might not support true multithreading.
您提到的所有语言，加上到目前为止在回答中提到的所有语言，都有多个实现，其中一些支持真正的多线程，一些不支持，还有一些构建在其他执行引擎之上，这些引擎可能支持也可能不支持真正的多线程。
Take Ruby, for example. Here are just some of its implementations and their threading models:
例如,把Ruby。下面是它的一些实现及其线程模型:
- MRI: green threads, no true multithreading
- MRI:绿色线程，没有真正的多线程。
- YARV: OS threads, no true multithreading
- OS线程，没有真正的多线程
- Rubinius: OS threads, true multithreading
- Rubinius: OS线程，真正的多线程
- MacRuby: OS threads, true multithreading
- MacRuby: OS线程，真正的多线程。
- JRuby, XRuby: JVM threads, depends on the JVM (if the JVM supports true multithreading, then JRuby/XRuby does, too, if the JVM doesn't, then there's nothing they can do about it)
- JRuby, XRuby: JVM线程，取决于JVM(如果JVM支持真正的多线程，那么JRuby/XRuby也会这样做，如果JVM不支持，那么他们也无能为力)
- IronRuby, Ruby.NET: just like JRuby, XRuby, but on the CLI instead of on the JVM
- IronRuby,Ruby。NET:就像JRuby、XRuby一样，只是在CLI上而不是JVM上
See also my answer to another similar question about Ruby. (Note that that answer is more than a year old, and some of it is no longer accurate. Rubinius, for example, uses truly concurrent native threads now, instead of truly concurrent green threads. Also, since then, several new Ruby implementations have emerged, such as BlueRuby, tinyrb, Ruby Go Lightly, Red Sun and SmallRuby.)
请参见我对另一个关于Ruby的类似问题的回答。(请注意，这个答案已经有一年多的历史了，其中一些已经不再准确。例如，Rubinius现在使用真正的并发本地线程，而不是真正的并发绿色线程。此外，从那时起，出现了几个新的Ruby实现，如BlueRuby、tinyrb、Ruby Go light、Red Sun和SmallRuby。
Similar for Python:
Python的类似:
- CPython: native threads, no true multithreading
- CPython:本机线程，没有真正的多线程
- PyPy: native threads, depends on the execution engine (PyPy can run natively, or on top of a JVM, or on top of a CLI, or on top of another Python execution engine. Whenever the underlying platform supports true multithreading, PyPy does, too.)
- PyPy:本机线程，取决于执行引擎(PyPy可以本机运行，或者在JVM上运行，或者在CLI上运行，或者在另一个Python执行引擎上运行。每当底层平台支持真正的多线程时，PyPy也会支持。
- Unladen Swallow: native threads, currently no true multithreading, but fix is planned
- Unladen Swallow:本机线程，目前没有真正的多线程，但是正在计划修复
- Jython: JVM threads, see JRuby
- JVM线程，请参见JRuby
- IronPython: CLI threads, see IronRuby
- IronPython: CLI线程，参见IronRuby
For Haskell, at least the Glorious Glasgow Haskell Compiler supports true multithreading with native threads. I don't know about UHC, LHC, JHC, YHC, HUGS or all the others.
对于Haskell来说，至少格拉斯哥Haskell编译器支持使用本地线程的真正多线程。我不知道UHC, LHC, JHC, YHC, HUGS或者其他的。
For Erlang, both BEAM and HiPE support true multithreading with green threads.
对于Erlang, BEAM和HiPE都支持使用绿色线程的真正多线程。
2) If a program contains threads, will a Virtual Machine automatically assign work to multiple cores (or to physical CPUs if there is more than 1 CPU on the mainboard)?
2)如果一个程序包含线程，那么虚拟机是否会自动地将工作分配给多个内核(如果主板上有超过一个CPU，则分配给物理CPU)?
Again: this depends on the Virtual Machine, the Operating System and the hardware. Also, some of the implementations mentioned above, don't even have Virtual Machines.
同样:这取决于虚拟机、操作系统和硬件。此外，上面提到的一些实现甚至没有虚拟机。
#2
22
The Haskell implementation, GHC, supports multiple mechanisms for parallel execution on shared memory multicore. These mechanisms are described in "Runtime Support for Multicore Haskell".
Haskell实现GHC支持在共享内存多核上并行执行的多种机制。这些机制在“多核Haskell的运行时支持”中进行了描述。
Concretely, the Haskell runtime divides work be N OS threads, distributed over the available compute cores. These N OS threads in turn run M lightweight Haskell threads (sometimes millions of them). In turn, each Haskell thread can take work for a spark queue (there may be billions of sparks). Like so: 
具体地说，Haskell运行时将工作分为N个OS线程，分布在可用的计算核心上。这些N个OS线程依次运行M轻量级Haskell线程(有时是数百万个)。反过来，每个Haskell线程都可以为spark队列工作(可能有数十亿个sparks)。像这样:
The runtime schedules work to be executed on separate cores, migrates work, and load balances. The garbage collector is also a parallel one, using each core to collect part of the heap.
运行时调度工作将在单独的核心上执行、迁移工作和负载平衡。垃圾收集器也是一个并行的收集器，使用每个核心来收集堆的一部分。
Unlike Python or Ruby, there's no global interpreter lock, so for that, and other reasons, GHC is particularly good on mulitcore in comparison, e.g. Haskell v Python on the multicore shootout
与Python或Ruby不同，它没有全局解释器锁，因此，由于这个原因，以及其他原因，相比之下，GHC在mulitcore上表现得尤为出色，例如在多核枪战中，Haskell v Python
#3
16
The GHC compiler will run your program on multiple OS threads (and thus multiple cores) if you compile with the -threaded option and then pass +RTS -N<x> -RTS at runtime, where <x> = the number of OS threads you want.
如果您使用-thread选项进行编译，然后在运行时传递+ rt -N
#4
7
The current version of Ruby 1.9(YARV- C based version) has native threads but has the problem of GIL. As I know Python also has the problem of GIL.
当前版本的Ruby 1.9(基于YARV- C的版本)有本地线程，但有GIL的问题。我知道Python也有GIL的问题。
However both Jython and JRuby(mature Java implementations of both Ruby and Python) provide native multithreading, no green threads and no GIL.
然而，Jython和JRuby(Ruby和Python的成熟Java实现)都提供了本地多线程，没有绿色线程，也没有GIL。
Don't know about Haskell.
不知道Haskell。
#5
1
Haskell is thread-capable, in addition you get pure functional language - no side effects
Haskell是线程支持的，此外您还可以获得纯函数语言——没有副作用
#6
1
For real concurrency, you probably want to try Erlang.
对于真正的并发，您可能需要尝试Erlang。
#7
1
I second the choice of Erlang. Erlang can support distributed highly concurrent programming out of the box. Does not matter whether you callit "multi-threading" or "multi-processing". Two important elements to consider are the level of concurrency and the fact that Erlang processes do not share state.
我的第二选择是Erlang。Erlang可以支持分布式高并发编程。不管您是调用“多线程”还是“多处理”。需要考虑的两个重要元素是并发级别和Erlang进程不共享状态的事实。
No shared state among processes is a good thing.
进程之间没有共享状态是一件好事。
#8
-2
Haskell is suitable for anything. python has processing module, which (I think - not sure) helps to avoid GIL problems. (so it suitable for anything too).
Haskell适合任何东西。python有处理模块，这有助于避免GIL问题。(所以它也适用于任何事情)。
But my opinion - best way you can do is to select highest level possible language with static type system for big and huge things. Today this languages are: ocaml, haskell, erlang.
但是我的观点是——你能做的最好的方法是选择最高层次的语言，用静态类型系统来处理大而大的事情。今天的语言是:ocaml, haskell, erlang。
If you want to develop small thing - python is good. But when things become bigger - all python benefits are eaten by miriads of tests.
如果你想开发一些小的东西——python很好。但当事情变得更大时——所有python的好处都被测试的英里数吃掉了。
I didn't use ruby. I still thinking that ruby is a toy language. (Or at least there's no reason to teach ruby when you know python - better to read SICP book).
我没有使用ruby。我仍然认为ruby是一种玩具语言。(或者至少，当你了解python时，没有理由去教ruby——最好是阅读SICP书籍)。
#1
33
1) Do Python, Ruby, or Haskell support true multithreading?
1) Python、Ruby或Haskell支持真正的多线程吗?
This has nothing to do with the language. It is a question of the hardware (if the machine only has 1 CPU, it is simply physically impossible to execute two instructions at the same time), the Operating System (again, if the OS doesn't support true multithreading, there is nothing you can do) and the language implementation / execution engine.
这与语言无关。这是一个硬件问题(如果机器只有一个CPU,它不能从物理上同时执行两个指令),操作系统(如果操作系统不支持真正的多线程,没有什么你可以做)和语言实现/执行引擎。
Unless the language specification explicitly forbids or enforces true multithreading, this has absolutely nothing whatsoever to do with the language.
除非语言规范明确禁止或强制使用真正的多线程，否则这与语言没有任何关系。
All the languages that you mention, plus all the languages that have been mentioned in the answers so far, have multiple implementations, some of which support true multithreading, some don't, and some are built on top of other execution engines which might or might not support true multithreading.
您提到的所有语言，加上到目前为止在回答中提到的所有语言，都有多个实现，其中一些支持真正的多线程，一些不支持，还有一些构建在其他执行引擎之上，这些引擎可能支持也可能不支持真正的多线程。
Take Ruby, for example. Here are just some of its implementations and their threading models:
例如,把Ruby。下面是它的一些实现及其线程模型:
- MRI: green threads, no true multithreading
- MRI:绿色线程，没有真正的多线程。
- YARV: OS threads, no true multithreading
- OS线程，没有真正的多线程
- Rubinius: OS threads, true multithreading
- Rubinius: OS线程，真正的多线程
- MacRuby: OS threads, true multithreading
- MacRuby: OS线程，真正的多线程。
- JRuby, XRuby: JVM threads, depends on the JVM (if the JVM supports true multithreading, then JRuby/XRuby does, too, if the JVM doesn't, then there's nothing they can do about it)
- JRuby, XRuby: JVM线程，取决于JVM(如果JVM支持真正的多线程，那么JRuby/XRuby也会这样做，如果JVM不支持，那么他们也无能为力)
- IronRuby, Ruby.NET: just like JRuby, XRuby, but on the CLI instead of on the JVM
- IronRuby,Ruby。NET:就像JRuby、XRuby一样，只是在CLI上而不是JVM上
See also my answer to another similar question about Ruby. (Note that that answer is more than a year old, and some of it is no longer accurate. Rubinius, for example, uses truly concurrent native threads now, instead of truly concurrent green threads. Also, since then, several new Ruby implementations have emerged, such as BlueRuby, tinyrb, Ruby Go Lightly, Red Sun and SmallRuby.)
请参见我对另一个关于Ruby的类似问题的回答。(请注意，这个答案已经有一年多的历史了，其中一些已经不再准确。例如，Rubinius现在使用真正的并发本地线程，而不是真正的并发绿色线程。此外，从那时起，出现了几个新的Ruby实现，如BlueRuby、tinyrb、Ruby Go light、Red Sun和SmallRuby。
Similar for Python:
Python的类似:
- CPython: native threads, no true multithreading
- CPython:本机线程，没有真正的多线程
- PyPy: native threads, depends on the execution engine (PyPy can run natively, or on top of a JVM, or on top of a CLI, or on top of another Python execution engine. Whenever the underlying platform supports true multithreading, PyPy does, too.)
- PyPy:本机线程，取决于执行引擎(PyPy可以本机运行，或者在JVM上运行，或者在CLI上运行，或者在另一个Python执行引擎上运行。每当底层平台支持真正的多线程时，PyPy也会支持。
- Unladen Swallow: native threads, currently no true multithreading, but fix is planned
- Unladen Swallow:本机线程，目前没有真正的多线程，但是正在计划修复
- Jython: JVM threads, see JRuby
- JVM线程，请参见JRuby
- IronPython: CLI threads, see IronRuby
- IronPython: CLI线程，参见IronRuby
For Haskell, at least the Glorious Glasgow Haskell Compiler supports true multithreading with native threads. I don't know about UHC, LHC, JHC, YHC, HUGS or all the others.
对于Haskell来说，至少格拉斯哥Haskell编译器支持使用本地线程的真正多线程。我不知道UHC, LHC, JHC, YHC, HUGS或者其他的。
For Erlang, both BEAM and HiPE support true multithreading with green threads.
对于Erlang, BEAM和HiPE都支持使用绿色线程的真正多线程。
2) If a program contains threads, will a Virtual Machine automatically assign work to multiple cores (or to physical CPUs if there is more than 1 CPU on the mainboard)?
2)如果一个程序包含线程，那么虚拟机是否会自动地将工作分配给多个内核(如果主板上有超过一个CPU，则分配给物理CPU)?
Again: this depends on the Virtual Machine, the Operating System and the hardware. Also, some of the implementations mentioned above, don't even have Virtual Machines.
同样:这取决于虚拟机、操作系统和硬件。此外，上面提到的一些实现甚至没有虚拟机。
#2
22
The Haskell implementation, GHC, supports multiple mechanisms for parallel execution on shared memory multicore. These mechanisms are described in "Runtime Support for Multicore Haskell".
Haskell实现GHC支持在共享内存多核上并行执行的多种机制。这些机制在“多核Haskell的运行时支持”中进行了描述。
Concretely, the Haskell runtime divides work be N OS threads, distributed over the available compute cores. These N OS threads in turn run M lightweight Haskell threads (sometimes millions of them). In turn, each Haskell thread can take work for a spark queue (there may be billions of sparks). Like so:
具体地说，Haskell运行时将工作分为N个OS线程，分布在可用的计算核心上。这些N个OS线程依次运行M轻量级Haskell线程(有时是数百万个)。反过来，每个Haskell线程都可以为spark队列工作(可能有数十亿个sparks)。像这样:
The runtime schedules work to be executed on separate cores, migrates work, and load balances. The garbage collector is also a parallel one, using each core to collect part of the heap.
运行时调度工作将在单独的核心上执行、迁移工作和负载平衡。垃圾收集器也是一个并行的收集器，使用每个核心来收集堆的一部分。
Unlike Python or Ruby, there's no global interpreter lock, so for that, and other reasons, GHC is particularly good on mulitcore in comparison, e.g. Haskell v Python on the multicore shootout
与Python或Ruby不同，它没有全局解释器锁，因此，由于这个原因，以及其他原因，相比之下，GHC在mulitcore上表现得尤为出色，例如在多核枪战中，Haskell v Python
#3
16
The GHC compiler will run your program on multiple OS threads (and thus multiple cores) if you compile with the -threaded option and then pass +RTS -N<x> -RTS at runtime, where <x> = the number of OS threads you want.
如果您使用-thread选项进行编译，然后在运行时传递+ rt -N
#4
7
The current version of Ruby 1.9(YARV- C based version) has native threads but has the problem of GIL. As I know Python also has the problem of GIL.
当前版本的Ruby 1.9(基于YARV- C的版本)有本地线程，但有GIL的问题。我知道Python也有GIL的问题。
However both Jython and JRuby(mature Java implementations of both Ruby and Python) provide native multithreading, no green threads and no GIL.
然而，Jython和JRuby(Ruby和Python的成熟Java实现)都提供了本地多线程，没有绿色线程，也没有GIL。
Don't know about Haskell.
不知道Haskell。
#5
1
Haskell is thread-capable, in addition you get pure functional language - no side effects
Haskell是线程支持的，此外您还可以获得纯函数语言——没有副作用
#6
1
For real concurrency, you probably want to try Erlang.
对于真正的并发，您可能需要尝试Erlang。
#7
1
I second the choice of Erlang. Erlang can support distributed highly concurrent programming out of the box. Does not matter whether you callit "multi-threading" or "multi-processing". Two important elements to consider are the level of concurrency and the fact that Erlang processes do not share state.
我的第二选择是Erlang。Erlang可以支持分布式高并发编程。不管您是调用“多线程”还是“多处理”。需要考虑的两个重要元素是并发级别和Erlang进程不共享状态的事实。
No shared state among processes is a good thing.
进程之间没有共享状态是一件好事。
#8
-2
Haskell is suitable for anything. python has processing module, which (I think - not sure) helps to avoid GIL problems. (so it suitable for anything too).
Haskell适合任何东西。python有处理模块，这有助于避免GIL问题。(所以它也适用于任何事情)。
But my opinion - best way you can do is to select highest level possible language with static type system for big and huge things. Today this languages are: ocaml, haskell, erlang.
但是我的观点是——你能做的最好的方法是选择最高层次的语言，用静态类型系统来处理大而大的事情。今天的语言是:ocaml, haskell, erlang。
If you want to develop small thing - python is good. But when things become bigger - all python benefits are eaten by miriads of tests.
如果你想开发一些小的东西——python很好。但当事情变得更大时——所有python的好处都被测试的英里数吃掉了。
I didn't use ruby. I still thinking that ruby is a toy language. (Or at least there's no reason to teach ruby when you know python - better to read SICP book).
我没有使用ruby。我仍然认为ruby是一种玩具语言。(或者至少，当你了解python时，没有理由去教ruby——最好是阅读SICP书籍)。