[...] Guido van Rossum, creador de Python, que desde hace tiempo es el lenguaje de programación más popular según distintas métricas, afirma que quieren hacer que su creación sea el doble de rápida. Pese a su popularidad, no es aun asunto menor, pues esa "lentitud" está haciendo que surjan implementaciones como Pyston, o no ser alternativa en muchos casos a C++ por necesidades de velocidad.
@admin Hay aquí hay un usuario haciendo un uso indebido del nick
#10:
#4#7 Nunca un lenguaje interpretado será tan rápido como un lenguaje compilado. El problema de Python no es la velocidad comparado con C o Rust. Nunca será tan rápido salvo que transformen el intérprete en un compilador y ejecutes código nativo.
De hecho, debería dar igual que un lenguaje sea más lento o rápido que otro ya que los lenguajes son creados para lo que son. Lo suyo es hacer lenguajes fácilmente interoperables.
Hacer un programa de computación intensiva en python no tiene sentido. Hacer la interfaz para manejar unos algoritmos a bajo nivel que hagan la computación intensiva en python tiene muchísimo más sentido que hacerlo en C. Por eso en IA se usa Python para la lógica, y C o C++ para el computo.
#4#7 Nunca un lenguaje interpretado será tan rápido como un lenguaje compilado. El problema de Python no es la velocidad comparado con C o Rust. Nunca será tan rápido salvo que transformen el intérprete en un compilador y ejecutes código nativo.
De hecho, debería dar igual que un lenguaje sea más lento o rápido que otro ya que los lenguajes son creados para lo que son. Lo suyo es hacer lenguajes fácilmente interoperables.
Hacer un programa de computación intensiva en python no tiene sentido. Hacer la interfaz para manejar unos algoritmos a bajo nivel que hagan la computación intensiva en python tiene muchísimo más sentido que hacerlo en C. Por eso en IA se usa Python para la lógica, y C o C++ para el computo.
#10 Realmente la definción de un lenguaje como compilado o interpretado es bastante difusa. Existen intérpretes para C y compiladores para Python.
La causa de que prácticamente cualquier algoritmo sea más lento en Python que en C, independientemente de que se ejecute compilado o interpretado, tiene más que ver con la gestión de memoria (GC) y de hilos (GIL).
Por eso en IA se usa Python para la lógica, y C o C++ para el computo.
Para análisis numérico también se usan librerías de Fortran, pero todo eso suele ser transparente para el usuario. No hay muchos data scientists que breguen con C/C++, ni muchos programadores de C++ que programen en ensamblador.
Como bien dices, cada lenguaje tiene su objetivo. El de Python es aumentar la legibilidad y la productividad, a costa de las prestaciones, y el de C/C++ es aumentar las prestaciones... a costa de la seguridad Por suerte ahora existen lenguajes como Rust o D que alcanzan las mismas prestaciones garantizando la memory safety.
Pese a su popularidad, no es aun asunto menor, pues esa "lentitud" está haciendo que surjan implementaciones como Pyston
Sí, es un problemón para cualquier lenguaje que "surjan" implementaciones optimizadas para actividades concretas
o no ser alternativa en muchos casos a C++ por necesidades de velocidad.
Comparar a C++ con Python es como comparar un tractor con una autocaravana. Además CPython está implementado en C y sólo con añadir la cabecera Python.h tienes una interfaz completa al lenguaje y puedes desarrollar extensiones nativas en C/C++. Vamos, otro problemón...
Actualmente, van Rossum se encuentra trabajando en Python, pero desde el seno de Microsoft, a donde llegó tras "aburrirse" de su jubilación. Esto generó algunas polémicas
Para polémicas las que lo llevaron a jubilarse, como la del operador walrus; pero yo no he visto nunca una polémica sobre quién paga el sueldo de los core developers. Porque los usuarios ya te digo que no, y la Python Software Foundation... miña pobre.
Siempre es de agradecer que quieran mejorar la velocidad siempre que no afecte a la compatiblidad, porque Pypy con ciertas librerías no se lleva bien, pero al final si quieres máximo rendimiento con código portable sólo queda C, si quieres seguridad renunciando a un poco de rendimiento se puede recurrir a Rust. En Python además puedes hacer uso de ctypes para usar funciones escritas en C.
Comentarios
Dos veces 0 es 0!.
#1 Pues no.
2x0 = 0
0! = 1
@admin Hay aquí hay un usuario haciendo un uso indebido del nick
#2 No puede ser, los meneantes eran de letras y ahora salen con factoriales. Espero que el letrado admin te de tu merecido.
#3 Creo que no va a aparecer, debió de creer que la arroba era para multiplicar matrices... A ver si así... Ⓐadmin !
De todos los problemas que tiene Python del último que me preocuparía sería su velocidad
#8 pero mucha gente lo usa para machine b learning. Eso tarda mucho y requiere mucha capacidad.
#4 #7 Nunca un lenguaje interpretado será tan rápido como un lenguaje compilado. El problema de Python no es la velocidad comparado con C o Rust. Nunca será tan rápido salvo que transformen el intérprete en un compilador y ejecutes código nativo.
De hecho, debería dar igual que un lenguaje sea más lento o rápido que otro ya que los lenguajes son creados para lo que son. Lo suyo es hacer lenguajes fácilmente interoperables.
Hacer un programa de computación intensiva en python no tiene sentido. Hacer la interfaz para manejar unos algoritmos a bajo nivel que hagan la computación intensiva en python tiene muchísimo más sentido que hacerlo en C. Por eso en IA se usa Python para la lógica, y C o C++ para el computo.
cc #9
#10 Realmente la definción de un lenguaje como compilado o interpretado es bastante difusa. Existen intérpretes para C y compiladores para Python.
Por suerte ahora existen lenguajes como Rust o D que alcanzan las mismas prestaciones garantizando la memory safety.
La causa de que prácticamente cualquier algoritmo sea más lento en Python que en C, independientemente de que se ejecute compilado o interpretado, tiene más que ver con la gestión de memoria (GC) y de hilos (GIL).
Por eso en IA se usa Python para la lógica, y C o C++ para el computo.
Para análisis numérico también se usan librerías de Fortran, pero todo eso suele ser transparente para el usuario. No hay muchos data scientists que breguen con C/C++, ni muchos programadores de C++ que programen en ensamblador.
Como bien dices, cada lenguaje tiene su objetivo. El de Python es aumentar la legibilidad y la productividad, a costa de las prestaciones, y el de C/C++ es aumentar las prestaciones... a costa de la seguridad
#9 La computación final usa librerías nativas.
Pese a su popularidad, no es aun asunto menor, pues esa "lentitud" está haciendo que surjan implementaciones como Pyston
Sí, es un problemón para cualquier lenguaje que "surjan" implementaciones optimizadas para actividades concretas
o no ser alternativa en muchos casos a C++ por necesidades de velocidad.
Comparar a C++ con Python es como comparar un tractor con una autocaravana. Además CPython está implementado en C y sólo con añadir la cabecera Python.h tienes una interfaz completa al lenguaje y puedes desarrollar extensiones nativas en C/C++. Vamos, otro problemón...
Actualmente, van Rossum se encuentra trabajando en Python, pero desde el seno de Microsoft, a donde llegó tras "aburrirse" de su jubilación. Esto generó algunas polémicas
Para polémicas las que lo llevaron a jubilarse, como la del operador walrus; pero yo no he visto nunca una polémica sobre quién paga el sueldo de los core developers. Porque los usuarios ya te digo que no, y la Python Software Foundation... miña pobre.
#0 No me había dado cuenta y he estado apunto de publicarla; aquí una de las fuentes originales, donde viene la información más extendida
https://www.zdnet.com/article/python-programming-we-want-to-make-the-language-twice-as-fast-says-its-creator/
meneada igualmente.
Siempre es de agradecer que quieran mejorar la velocidad siempre que no afecte a la compatiblidad, porque Pypy con ciertas librerías no se lleva bien, pero al final si quieres máximo rendimiento con código portable sólo queda C, si quieres seguridad renunciando a un poco de rendimiento se puede recurrir a Rust. En Python además puedes hacer uso de ctypes para usar funciones escritas en C.
#6 Rust no tiene peor rendimiento que C.