Какие языки сценариев поддерживают многоядерное программирование?

Question

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

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

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

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

ЗАКАНЧИВАЙТЕ

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

Как Заводной основан на виртуальной машине Java, вы получаете поддержку true threads.

Answer 5

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

Answer 6

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

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

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

Возможно, это могло бы быть полезно для вас - обзор функций Qore находится здесь: Зачем использовать Qore?.

Answer 7

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

Answer 8

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

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

У других скриптовых языков может быть примерно такая же проблема.

Answer 9

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