Pregunta

He escrito una pequeña aplicación de Python y aquí puedes ver cómo se ve el Administrador de tareas durante una ejecución típica.
(fuente: weinzierl.name )

Si bien la aplicación es perfectamente multiproceso, como era de esperar, solo utiliza un núcleo de CPU. Independientemente del hecho de que la mayoría de los lenguajes de script modernos admiten subprocesos múltiples, los scripts solo pueden ejecutarse en un núcleo de CPU .

Ruby, Python, Lua, PHP solo pueden ejecutarse en un solo núcleo. Incluso Erlang, que se dice que es especialmente bueno para la programación concurrente, se ve afectado.

¿Existe un lenguaje de scripting que se haya incorporado ¿Compatibilidad con subprocesos que no se limitan a un solo núcleo?

WRAP UP

Las respuestas no fueron exactamente lo que esperaba, pero the < El código> TCL answer se acerca. Me gustaría agregar perl , que (al igual que TCL ) tiene subprocesos basados ??en intérpretes.

Jython, IronPython y Groovy caen bajo el paraguas de combinar un idioma probado con el probado Máquina virtual de otro idioma. Gracias por sus sugerencias en este dirección.

Elegí La respuesta de Aiden Bell como < em> Respuesta aceptada . Él no sugiere un lenguaje en particular, pero su comentario fue muy perspicaz para mí.

¿Fue útil?

Solución

La sintaxis de subprocesos puede ser estática, pero la implementación en los sistemas operativos y las máquinas virtuales puede cambiar

Tu lenguaje de scripting puede usar subprocesos verdaderos en un sistema operativo y subprocesos falsos en otro.

Si tiene requisitos de rendimiento, puede valer la pena mirar para asegurarse de que los subprocesos con guión se encuentren en la capa más beneficiosa del sistema operativo. Los subprocesos del espacio de usuario serán más rápidos, pero para bloquear en gran medida la actividad del subproceso, los subprocesos del kernel serán mejores.

Otros consejos

Parece que utilizas una definición de " lenguaje de scripting " eso puede provocar algunas cejas, y no sé lo que eso implica acerca de sus otros requisitos.

De todos modos, ¿has considerado TCL? Hará lo que quieras, creo.

Ya que está incluyendo en su lista lenguajes de propósito bastante general, no sé qué tan grande es una implementación aceptable para usted. Me sorprendería si una de las implementaciones de zillion Scheme no se ajustara a los subprocesos nativos, pero desde lo alto de mi cabeza, solo puedo recordar el MzScheme que solía, pero me parece recordar que el soporte se abandonó. Ciertamente, algunas de las implementaciones de LISP comunes hacen esto bien. Si Embeddable Common Lisp (ECL) lo hace, podría funcionar para usted. Sin embargo, no lo uso, por lo que no estoy seguro de cuál es el estado del soporte de subprocesos y, por supuesto, esto puede depender de la plataforma.

Actualizar Además, si recuerdo correctamente, GHC Haskell no hace lo que está pidiendo, pero puede hacer lo que quiera, ya que, una vez más, según recuerdo, dará un vuelco subproceso nativo por núcleo o algo así y luego ejecute sus subprocesos a través de esos ...

Puede realizar múltiples subprocesos libremente con el lenguaje de Python en implementaciones como Jython (en JVM, como @Reginaldo menciona Groovy) y IronPython (en .NET). Para la implementación CPython clásica del lenguaje Python, como se menciona en el comentario de @ Dan, multiprocessing (en lugar de threading ) es la manera de utilizar libremente tantos núcleos como tenga disponibles

Como Groovy se basa en la máquina virtual de Java, obtienes soporte para verdaderos hilos.

F # en .NET 4 tiene un excelente soporte para la programación en paralelo y un rendimiento extremadamente bueno, así como soporte para archivos .fsx que están diseñados específicamente para secuencias de comandos. Hago todos mis scripts usando F #.

Ya se ha aceptado una respuesta para esta pregunta, pero solo para agregar que además de tcl, el único otro lenguaje de script interpretado que conozco que admite la programación multihebra y segura para subprocesos es Qore .

Qore se diseñó de abajo hacia arriba para admitir multihilo; cada aspecto del lenguaje es seguro para subprocesos; el lenguaje fue diseñado para soportar la escalabilidad SMP y el subprocesamiento múltiple de forma nativa. Por ejemplo, puede usar el operador background para iniciar un nuevo hilo o la clase ThreadPool para administrar un grupo de hilos. Qore también lanzará excepciones con errores comunes de subprocesos para que los errores de subprocesos (como posibles interbloqueos o errores con las API de subprocesos, como intentar agarrar un bloqueo que ya está retenido por el subproceso actual) sean inmediatamente visibles para el programador.

Qore además admite y subprocesos recursos; por ejemplo, una asignación de DatasourcePool se trata como un recurso de subproceso local; Si olvida confirmar o revertir una transacción antes de finalizar su hilo, el manejo de recursos de hilo para la clase DatasourcePool revertirá la transacción automáticamente y generará una excepción con información fácil de usar sobre el problema y Cómo se resolvió.

Tal vez podría ser útil para usted: aquí encontrará una descripción general de las características de Qore: ¿Por qué usar Qore? .

CSScript en combinación con Parallel Extensions no debería ser una mala opción. Usted escribe su código en C puro y luego lo ejecuta como una secuencia de comandos.

No está relacionado con el mecanismo de subprocesamiento. El problema es que (por ejemplo, en Python) tiene que obtener una instancia de intérprete para ejecutar el script. Para adquirir el intérprete, debe bloquearlo, ya que mantendrá el recuento de referencias, etc., y deberá evitar el acceso simultáneo a estos objetos. Python usa pthread y son hilos reales, pero cuando trabajas con objetos de python, solo un hilo está ejecutando otro que espera. Llaman a esto GIL (Global Intérprete Lock) y es el problema principal que hace que el paralelismo real sea imposible dentro de un proceso.

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

Los otros lenguajes de scripting pueden tener el mismo problema.

Guile admite subprocesos POSIX que creo que son subprocesos de hardware.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top