Какие языки сценариев поддерживают многоядерное программирование? - PullRequest
11 голосов
/ 16 июня 2009

Я написал небольшое приложение на Python, и здесь вы можете увидеть, как диспетчер задач выглядит во время типичного запуска.
(источник: weinzierl.name )

Несмотря на то, что приложение идеально многопоточное, неудивительно, что оно использует только одно ядро ​​ЦП. Независимо от того, что большинство современных языков сценариев поддерживают многопоточность, сценарии могут работать только на одном ядре процессора .

Ruby, Python, Lua, PHP могут работать только на одном ядре. Это влияет даже на Erlang, который, как говорят, особенно хорош для параллельного программирования.

Есть ли язык сценариев, который встроил поддержка потоков, не ограниченных одним ядром?

Свернуть

Ответы оказались не совсем такими, как я ожидал, но ответ TCL подходит близко. Я хотел бы добавить perl, который (как и TCL) имеет потоки на основе интерпретатора.

Jython, IronPython и Groovy подпадают под эгиду объединения проверенного языка с проверенной виртуальной машиной другого языка. Спасибо за ваши подсказки в этом направление.

Я выбрал ответ Эйдена Белла как Принятый ответ . Он не предлагает конкретный язык, но его замечание было для меня наиболее проницательным.

Ответы [ 9 ]

5 голосов
/ 16 июня 2009

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

В любом случае, вы рассматривали TCL? Я думаю, он будет делать то, что вы хотите.

Поскольку вы включаете в свой список языки довольно общего назначения, я не знаю, насколько сложна для вас реализация. Я был бы удивлен, если бы одна из реализаций zillion Scheme не работала с нативными потоками, но, черт побери, я могу вспомнить только то, что раньше использовал MzScheme, но я помню, что поддержка была отброшена. Конечно, некоторые из реализаций Common LISP делают это хорошо. Если Embeddable Common Lisp (ECL) работает, он может работать для вас. Я не использую его, поэтому не уверен, в каком состоянии находится поддержка потоков, и это, конечно, может зависеть от платформы.

Обновление Кроме того, если я правильно помню, GHC Haskell не выполняет то, о чем вы просите, но может эффективно делать то, что вы хотите, поскольку, опять же, насколько я помню, он будет вращаться нативно. поток на ядро ​​или около того, а затем запустить свои потоки через эти ....

4 голосов
/ 16 июня 2009

Вы можете свободно использовать несколько потоков с языком Python в таких реализациях, как Jython (в JVM, как @Reginaldo упоминает Groovy), и IronPython (в .NET). Для классической реализации языка Python на CPython, как упоминает комментарий @ Dan, multiprocessing (а не threading) - это способ свободно использовать столько ядер, сколько у вас имеется

3 голосов
/ 16 июня 2009

Синтаксис потока может быть статическим, но реализация в операционных системах и виртуальных машинах может измениться

Ваш язык сценариев может использовать настоящие потоки в одной ОС и поддельные потоки в другой.

Если у вас есть требования к производительности, возможно, стоит позаботиться о том, чтобы скриптовые потоки перешли на самый полезный уровень в ОС. Потоки в пользовательском пространстве будут работать быстрее, но для большей блокировки потоков будут лучше работать потоки ядра.

3 голосов
/ 16 июня 2009

Поскольку Groovy основан на виртуальной машине Java, вы получаете поддержку истинных потоков.

2 голосов
/ 19 июня 2016

Ответ на этот вопрос уже принят, но только для того, чтобы добавить, что кроме tcl, единственным известным мне интерпретируемым языком сценариев, который поддерживает многопоточность и поточно-ориентированное программирование, является Qore .

Qore был разработан снизу вверх для поддержки многопоточности; каждый аспект языка является потокобезопасным; язык был разработан для поддержки масштабируемости SMP и многопоточности. Например, вы можете использовать оператор background для запуска нового потока или класс ThreadPool для управления пулом потоков. Qore также будет генерировать исключения с общими ошибками потоков, так что ошибки потоков (такие как потенциальные взаимоблокировки или ошибки с API потоков, такие как попытка получить блокировку, которая уже удерживается текущим потоком) будут немедленно видны программисту.

Qore дополнительно поддерживает и ресурсы потоков; например, распределение DatasourcePool обрабатывается как локальный ресурс потока; Если вы забудете зафиксировать или откатить транзакцию до завершения потока, обработка ресурсов потока для класса DatasourcePool автоматически откатит транзакцию и выдаст исключение с удобной информацией о проблеме и о том, как она была решена.

Может быть, это может быть полезно для вас - обзор возможностей Qore здесь: Зачем использовать Qore? .

2 голосов
/ 11 августа 2010

F # в .NET 4 имеет отличную поддержку параллельного программирования и чрезвычайно хорошую производительность, а также поддержку файлов .fsx, специально разработанных для сценариев. Я делаю все свои сценарии, используя F #.

1 голос
/ 16 июня 2009

CSScript в сочетании с Параллельные расширения не должны быть плохим вариантом. Вы пишете свой код на чистом C #, а затем запускаете его как скрипт.

0 голосов
/ 22 июня 2017

Guile поддерживает потоки POSIX, которые я считаю аппаратными.

0 голосов
/ 09 апреля 2015

Это не связано с механизмом резьбы. Проблема в том, что (например, в python) вам нужно получить экземпляр интерпретатора для запуска скрипта. Чтобы получить интерпретатор, вы должны заблокировать его, так как он будет вести подсчет ссылок и т. Д., И избегать одновременного доступа к этим объектам. Python использует pthread, и они являются реальными потоками, но когда вы работаете с объектами python, только один поток выполняет другой, ожидающий. Они называют это GIL (Global Interpreter Lock), и это главная проблема, которая делает невозможным настоящий параллелизм внутри процесса.

https://wiki.python.org/moin/GlobalInterpreterLock

Другие языки сценариев могут иметь такую ​​же проблему.

...