2010-10-24 46 views
27

He visto este argumento en algunos lugares, y ahora, recientemente lo volví a ver en una publicación de reddit. Esto de ninguna manera es una llama en contra de ninguno de estos dos idiomas. Simplemente estoy desconcertado por qué esta mala reputación sobre Python no es escalable.
Soy un chico pitón y ahora estoy comenzando con Java y solo quiero entender qué hace que Java sea tan escalable y si la configuración de python que tengo en mente es una buena forma de escalar grandes aplicaciones de Python.¿Por qué la gente dice que Java es más escalable que Python?

Ahora vuelvo a mi idea de escalar una aplicación de Python. Digamos que lo codificas usando Django. Django ejecuta sus aplicaciones en modo fastcgi. Entonces, ¿qué pasa si tiene un servidor Nginx frontal y detrás de él tantos otros servidores como sea necesario que cada uno ejecute su aplicación Django en modo fastcgi. El servidor Nginx frontal luego cargará el equilibrio entre los servidores en ejecución back-end Django fastcgi. Django también es compatible con múltiples bases de datos para que pueda escribir en un DB maestro y luego leer de muchos esclavos, una vez más para el equilibrio de carga. Lanza un servidor memcached a esta mezcla y allí tienes escalabilidad. ¿No es así?

¿Es esta una configuración viable? ¿Qué hace Java mejor? ¿Cómo escalas una aplicación Java?

+0

Esto probablemente se cerrará porque cada vez que discute problemas potenciales con lenguajes dinámicos, los sentimientos se lastiman muy rápido. Sin embargo, tenga en cuenta que su idea sobre escalar python puede estar bien, pero eso no dice nada sobre si Java es más escalable o no. Además, otra cosa a considerar, si una plataforma puede escalar "similarmente bien" a otra, pero requiere una configuración mucho más compleja, ¿es realmente más escalable? – BobbyShaftoe

+4

"los sentimientos se lastiman muy rápido". Creo que algunas personas deberían dejar de tomar demasiado café y concentrarse en las cosas más importantes de la vida. Es solo un maldito lenguaje ... –

+4

Escalable puede significar muchas cosas. Si dices que algo no se escala, debes decir de qué manera y también decir por qué es importante. C++ puede escalar a un hilo de 100K y Java puede escalar a hilos de 10K, pero si solo necesitas 10s de hilos, ¿es importante? –

Respuesta

21

La escalabilidad es un término muy sobrecargado en estos días. Los comentarios probablemente se refieren a la escalabilidad vertical en proceso.

Python tiene un bloqueo de intérprete global (GIL) que limita severamente su capacidad de escalar hasta muchos hilos. Lo libera cuando llama al código nativo (readquiriéndolo cuando el nativo regresa), pero esto aún requiere un diseño cuidadoso al intentar escribir software escalable en Python.

+8

Dicho esto, algunas implementaciones como Stackless son mejores en el aspecto de subprocesamiento, mucho mejor. Por ejemplo, Stackless Python es empleado por MMORPG Eve Online. –

+4

Pero debe tenerse en cuenta que Stackless Python no elimina el GIL. Puede facilitar la programación simultánea pero no permite la ejecución paralela. PyPy y Unladen Swallow tienen la eliminación del GIL como uno de sus objetivos, pero ninguno (como recuerdo) todavía está allí. IronPython y Jython son los únicos competidores serios, actualmente sin GIL, que yo sepa. –

+1

@Tim: Stackless tiene un solo subproceso. Simula hilos para permitir un comportamiento altamente concurrente, siempre que todo esté vinculado a E/S. Pero si ejecuta una carga de trabajo vinculada a la CPU a través de Stackless en un sistema de 8 núcleos, no verá más de aproximadamente el 12% de utilización. –

3

Sin entrar en una guerra de llamas, ¿considera cómo maneja Python las aplicaciones de subprocesos múltiples en comparación con Java? Por ejemplo, ¿qué bloqueos globales existen en ambos idiomas que dañan la concurrencia (sugerencia, GIL de Python - Bloqueo de intérprete global)?

12

Aunque no estoy de acuerdo con la afirmación, supongo que piensan que Java es más escalable porque ejecuta lote más rápido. La JVM es muy eficiente (excepto tal vez en el uso de la memoria). Además, el GIL de Python (Global Interpreter Lock) no permite el enhebrado "real", mientras que Java no tiene un GIL y tiene verdadero multihilo.

+0

¿Qué quiere decir con "JVM"? Es solo una especificación que podría implementarse de maneras muy diferentes, lo que lleva a resultados de rendimiento muy diferentes. No tratando de ser un imbécil, realmente solo curiosidad. –

+3

HotSpot, que es lo que usa la mayoría de la gente. –

+4

Pero Python se ejecuta en la JVM y, como consecuencia, obviamente también en HotSpot, así que si la escalabilidad se trata de HotSpot y ambos idiomas se ejecutan en HotSpot, ¿por qué exactamente uno es "más escalable" que el otro? –

1

Hmmm: escalable podría significar muchas cosas: escalable según la arquitectura distribuida, escalable según la velocidad.

En la escalabilidad por velocidad, Java generalmente puede procesar instrucciones más rápido que python: para el tipo correcto de problema, mucho más rápido (supongo que la razón principal es que Java está compilado mientras que Python es interpretado). Desde ese punto de vista, Java generalmente puede hacer más con menos y, por lo tanto, es más escalable.

Me refiero a mi fuente de información experimental de nuevo a dos fuentes; http://mrpointy.wordpress.com/2007/11/06/java-vs-python-performance/ y http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/

+2

En el frente de crujido de números, usted es técnicamente correcto. Excepto que cualquier crunch serio de números en Python se hace usando la biblioteca [numpy] (http://numpy.scipy.org/), que está basada en C/Fortran y generalmente tiene un mejor rendimiento que las bibliotecas de Java. –

+0

Lo siento, cuando digo números crujidos, no me refiero específicamente al álgebra lineal y similares. Voy a reformular. – Brabster

+1

1) Python no se interpreta, se compila. De eso se trata la votación negativa. 2) la mayoría de los crujidos de números se reduce al álgebra lineal "y similares". – aaronasterling

3

Creo que este artículo resume muchos de los argumentos del cambio de escala y los lenguajes dinámicos:

http://blogs.tedneward.com/2008/01/24/Can+Dynamic+Languages+Scale.aspx

Vale la pena señalar sus dos definición para escalar ...

  1. Tamaño del proyecto, como en líneas-de-código (LOC)
  2. capacidad de manejo, como en "que necesita para escalar hasta 100.000 solicitudes por segundo"

Un argumento frecuentemente utilizado sobre cualquier escalado de idioma dinámico es que a medida que crece la base de código, se hace más difícil refactorizarlo sin compatibilidad con IDE. Debido a la falta de información de tipo en tiempo de compilación, este soporte es a menudo imposible de implementar en lenguajes dinámicos.

+0

Estoy llamando mierda en esto. Los IDE de refactorización automática * se inventaron * en lenguajes dinámicos y el soporte de refactorización en IDE de lenguaje dinámico como VisualWorks y co. todavía está muy por delante de todo lo que he visto para los lenguajes estáticos. –

+0

¡No hay necesidad de maldecir! - Soy un gran admirador de los lenguajes dinámicos, pero es un hecho que muchos tipos de refactorización son mucho más difíciles de implementar en lenguajes dinámicos. http://beust.com/weblog/2006/10/01/dynamic-language-refactoring-ide-pick-one/ – Pablojim

0

Me enojo cuando veo argumentos como este. No porque tenga todo menos que ver con los enemigos que hieren mi melodía de Python, sino porque, en mi opinión, decir "X no escala" no tiene sentido. Es necesario especificar una dimensión, como mínimo.

Las personas son reacias a hacer esto, ya que a menudo revela el hecho de que no tienen un buen manejo del problema con el que están hablando con confianza. El bloqueo de intérprete global es una buena piedra de toque aquí: los hilos no son la única forma de realizar operaciones concurrentes.

Cuestiones relacionadas