Python, Ruby, Haskell - Они обеспечивают истинную многопоточность?

Ответ 1

1) Поддерживают ли Python, Ruby или Haskell истинную многопоточность?

Это не имеет никакого отношения к языку. Речь идет об аппаратном обеспечении (если на компьютере только 1 процессор, просто физически невозможно выполнить две инструкции одновременно), операционная система (опять же, если ОС не поддерживает истинную многопоточность, нет ничего вы можете сделать) и механизм выполнения/выполнения языка.

Если спецификация языка явно запрещает или применяет истинную многопоточность, это абсолютно не имеет никакого отношения к языку.

Все языки, о которых вы упоминаете, плюс все языки, упомянутые в ответах до сих пор, имеют несколько реализаций, некоторые из которых поддерживают истинную многопоточность, некоторые - нет, а некоторые из них построены поверх других механизмов выполнения который может поддерживать или не поддерживать истинную многопоточность.

Возьмите Ruby, например. Вот лишь некоторые из его реализаций и их модели потоков:

• MRI: зеленые нити, нет истинной многопоточности
• YARV: потоки ОС, нет истинной многопоточности
• Rubinius: потоки ОС, истинная многопоточность
• MacRuby: потоки ОС, истинная многопоточность
• JRuby, XRuby: потоки JVM, зависит от JVM (если JVM поддерживает истинную многопоточность, тогда JRuby/XRuby тоже, если JVM не делает, тогда ничего не может с этим поделать)
• IronRuby, Ruby.NET: как и JRuby, XRuby, но в CLI, а не на JVM

См. также мой ответ на другой аналогичный вопрос о Ruby. (Обратите внимание, что этот ответ больше года, и некоторые из них уже не точны. Rubinius, например, теперь использует настоящие параллельные собственные потоки вместо настоящих параллельных зеленых потоков. Кроме того, с тех пор несколько новых реализаций Ruby имеют такие как BlueRuby, tinyrb, Ruby Go Lightly, Red Sun и SmallRuby.)

Аналогично для Python:

• CPython: собственные потоки, нет истинной многопоточности
• PyPy: собственные потоки, зависит от механизма выполнения (PyPy может запускаться изначально или поверх JVM или поверх CLI или поверх другого механизма выполнения Python. Всякий раз, когда базовая платформа поддерживает истинную многопоточность, PyPy тоже.)
• Unladen Swallow: собственные потоки, в настоящее время нет истинного многопоточности, но исправление запланировано
• Jython: потоки JVM, см. JRuby
• IronPython: потоки CLI, см. IronRuby

Для Haskell, по крайней мере, Glorious Glasgow Haskell Compiler поддерживает истинную многопоточность с родными потоками. Я не знаю о UHC, LHC, JHC, YHC, HUGS или всех остальных.

Для Erlang оба BEAM и HiPE поддерживают истинную многопоточность с зелеными потоками.

2) Если программа содержит потоки, будет ли виртуальная машина автоматически назначать работу нескольким ядрам (или физическим ЦП, если на материнской плате больше 1 ЦП)?

Опять же: это зависит от виртуальной машины, операционной системы и аппаратного обеспечения. Кроме того, некоторые из упомянутых выше реализаций даже не имеют виртуальных машин.

Ответ 2

Реализация Haskell, GHC, поддерживает несколько механизмов для параллельного выполнения в многоядерной памяти с общей памятью. Эти механизмы описаны в "" Поддержка времени выполнения для многоядерного Haskell".

Конкретно, среда исполнения Haskell делит работу на N потоков ОС, распределенных по доступным вычислительным ядрам. Эти потоки N OS, в свою очередь, запускают потоки Haskell с небольшим потоком (иногда миллионы). В свою очередь, каждый поток Haskell может принимать работу за искровую очередь (могут быть миллиарды искр). Вот так:

Расписания выполнения выполняются на отдельных ядрах, переносятся работы и балансы нагрузки. Сборщик мусора также является параллельным, используя каждое ядро ​​для сбора части кучи.

В отличие от Python или Ruby, нет глобальной блокировки интерпретатора, поэтому для этого и по другим причинам GHC особенно хорош в сравнении с mulitcore, например. Haskell v Python в многоядерной перестрелке

Ответ 3

Компилятор GHC будет запускать вашу программу на нескольких потоках ОС (и, следовательно, на нескольких ядрах), если вы скомпилируете с опцией -threaded, а затем пропустите +RTS -N<x> -RTS во время выполнения, где <x>= количество потоков ОС, которые вы хотите.

Ответ 4

Текущая версия Ruby 1.9 (версия на основе YARV-C) имеет собственные потоки, но проблема GIL. Как я знаю, Python также имеет проблему GIL.

Однако как Jython, так и JRuby (зрелые реализации Java как Ruby, так и Python) обеспечивают встроенную многопоточность, отсутствие зеленых потоков и отсутствие GIL.

Не знаю о Haskell.

Ответ 5

Haskell работает с потоком, кроме того вы получаете pure функциональный язык - no побочные эффекты

Ответ 6

Для реального concurrency вы, вероятно, захотите попробовать Erlang.

Ответ 7

Я второй выбор Эрланг. Erlang может поддерживать распределенное высококонкурентное программирование из коробки. Не имеет значения, называете ли вы "многопоточность" или "многопроцессорная обработка". Два важных элемента для рассмотрения - это уровень concurrency и тот факт, что процессы Erlang не разделяют состояние.

Отсутствие общего состояния между процессами - это хорошо.

Ответ 8

Haskell подходит для всего. python имеет модуль processing, который (я думаю - не уверен) помогает избежать проблем с GIL. (так что это подходит для чего угодно).

Но мое мнение - лучший способ, который вы можете сделать, - выбрать самый высокий уровень возможного языка с системой статического типа для больших и больших вещей. Сегодня эти языки: ocaml, haskell, erlang.

Если вы хотите развить маленькую вещь - питон хорош. Но когда вещи становятся все больше - все преимущества python съедаются мириадами тестов.

Я не использовал ruby. Я все еще думаю, что рубин - это игрушечный язык. (Или, по крайней мере, нет оснований учить рубину, когда вы знаете python - лучше читать книгу SICP).