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

Я написал небольшое приложение python, и здесь вы можете увидеть, как выглядит Диспетчер задач во время обычного запуска. http://weinzierl.name/temp/multicore-hires.png

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

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

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

ЗАВЕРНУТЬ

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

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

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

9 ответов


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

ваш язык сценариев может использовать true threading на одной ОС и fake-threads на другой.

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


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

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

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

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


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


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


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


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

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

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

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


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


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

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

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


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