Hace unos días, la cuenta oficial en Twitter de PyPI (Python Package Index), el repositorio de software vinculado al lenguaje Python, publicaba la siguiente imagen, mostrando el nivel de consumo de CPU resultante de la ejecución de Gunicorn (un servidor web basado en Python), justo antes y después de ser actualizado a la nueva versión de Python, la 3.11.
|
etiquetas: python , consumo cpu , lenguaje
Edit. Parece que ya van por la 3.10 pero dudo que esa sea la situación con Ubuntu y Debian que son los sistemas usados en Google Colabs.
Precisamente, el release manager de la 3.11, y miembro de Faster CPython, es español y hace unos meses que dio una charla al respecto en la PyConEs sobre este tema: youtu.be/94jLt3CX5Dc
En cualquier caso Python es un lenguaje interpretado a través de un lenguaje intermedio, al estilo de los bytecodes de Java. Cualquier lenguaje compilado medianamente correcto será mucho más eficaz.
Si en vez de desarrollar en 100 horas tardas 20 para un programa que va a estar 10 años en cloud consumiendo cpu, dime donde está el ahorro.
Ahora, que si, que el programador se siente superbien porque ha hecho nosequé superápido.
Además, que estás suponiendo que el coste de cpu va a ser bajo forever
(Y antes de que me digáis "pues python se usa para inteligencia artificial", responderé que sí, pero el "backend" de todas esas librerías es C/C++).
Se utiliza el término en inglés porque es una posición dentro de un equipo o empresa que se inventó en algún país de habla inglesa.
La documentación y los libros que se escribe sobre ello generalmente también es en inglés, por lo que traducirlo al español haría que la gente no se entendiera entre ella.
* Despliegan en producción 1 vez cada 10 años (deploy early and often? )
* De lo anterior se intuye que nunca aplican actualizaciones de software, ni siquiera las de seguridad.
* Escribir bugs y desplegar parches para los mismos es de débiles.
* Si código es escrito directamente en binario.
* Lo más cerca que han estado de cualquier lenguaje de alto nivel, son los artículos de magnet.xataka.com y genbeta.
Y así nos va. Vaya nivel...
Por curiosidad, ¿puedes explicar esto? Gracias
Punto uno: no me jodáis la coña
Y punto dos: Java usa una máquina virtual al igual que Python, no es compilado.
Una característica de Python es su capacidad de invocar código que está escrito en C. Eso es algo que también tienen Java, Rust, Go...
Cuando tú programas en Python e invocas una biblioteca intensiva en cálculo, por ejemplo Tensorflow para redes neuronales o Numpy para cálculo numérico, estas bibliotecas proveen una interfaz en Python para que puedas programar con ellas en Python, pero el núcleo (lo que hace los cálculos) está escrito en C/C++. De esta manera, por una parte ganas la comodidad de programar en Python (si es que te gusta ese tipo de lenguajes) y por otra parte consigues un uso eficiente de tus recursos y una velocidad de ejecución aceptable.
Por ejemplo, código NumPy que está escrito en C++: github.com/numpy/numpy/blob/main/numpy/core/src/npymath/ieee754.cpp
O código del núcleo de Tensorflow, también escrito en C++: github.com/tensorflow/tensorflow/blob/master/tensorflow/core/ops/batch
C.c #30
El duelo final es entre Python y JavaScript
Los proyectos nunca se acaban. Siempre hay errores o nuevas funcionalidades que aparecen.
Y sí, generalmente es más barato echar más hardware al problema que pagar más programadores. Que igualmente no es cierto porque la diferencia real de programar una aplicación web en Python o en C++ es nula.
A mí lo que me sorprende esque #_18 tenga tantos votos positivos teniendo en cuenta que no tiene ni idea de desarrollo software.
Cosa que por otro lado todos ya sabíamos.
Optimizaciones que fueron saliendo con el tiempo
Y, de hecho, java consume mucho menos que .net (del orden de la mitad, ojo!).
Habia unas graficas por ahi que vi en internet hace uno o dos meses y, de las cuales, me llamo MUCHO la atencion eso: que java consumia poquisima energia (y sin graalVM ni nada)
un saludo.
Debo confesar que se me has sacado una carcajada. El desarrollo de cualquier software es como un cáncer que se extiende durante toda su vida.
#13 ahora bien, así como le digo eso al compañero eso, a ti te digo que en Python hay cosas que se pueden programar muy rápidamente pero también es verdad que por la idiosincrasia del ecosistema Python, donde no se usa el tipado correspondiente ni de casualidad, hace que cualquier error sea una odisea encontrarlo y corregirlo. Eso hace que el tiempo que ahorras por un lado, lo pierdas por el otro con creces. Para mí, los únicos lenguajes que deberían usarse para aplicaciones que van a estar en producción, son aquellos que poseen un fuerte y estático tipado, y que además es obligatorio su uso. Eso es lo que más tiempo ahorra a un programador.
Python está muy bien para prototipado.
Python 3.9.2
debian stable.
Muy recomendable la librería Numba para ciertos cálculos científicos, sobre todo cuando se tengan que hacer muchas veces.
Vamos a comparar con Ruby, con PHP... no sé.
De el siguiente artículo - zathiro.wordpress.com/2010/08/21/python-lenguaje-semi-interpretado/
"Python tiene, no obstante, muchas de las características de los lenguajes compilados, por lo que se podría decir que es semi interpretado. En Python, como en Java y muchos otros lenguajes, el código fuente se traduce a un pseudo código máquina intermedio llamado bytecode la primera vez que se ejecuta, generando archivos .pyc o .pyo (bytecode optimizado), que son los que se ejecutarán en sucesivas ocasiones."
Supongo que se refiere a eso. No es una compilación al estilo C, pero sí hay un compilador.
benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharp.htm
Bibliotecas
Pero en general, la "compilación" de Python sucede de forma automática, que no quiere decir que no haya un compilador.
Pero vamos que la comparación no es idea mía, esta en el artículo donde se comparan unos 20 lenguajes. Además que la comparación se basa en una métrica bien concreta consumo de cpu.
Personalmente por experiencia se que la decisión de que lenguaje usar es algo que obedece a muchos factores, y muchas veces el rendimiento del lenguaje está al final de la lista. Por ejemplo si tu empresa solo hay programadores x, y legacy en x buscarán programarlo en x y si en algún momento cambian a y será por que no encuentran programadores x.
La industria está transformándose hacia modelos de CI/CD para poder competir (eso en España, en otros sitios y en algunos sectores ya están 100% en ese modelo). El desarrollo es el mayor coste de cualquier producto de software, y con cosas como esta que reducen y optimizan el resto de costes, cada vez será un % mayor.
Y aun diría más, en cuanto las IAs que programen estén más afinadas y sirvan para un uso industrial, en lugar de reducir el número de programadores hará que se pase al siguiente nivel, donde desarrollos de años se hagan en meses y la demanda de software cada más complejo se dispare. Eso acabará haciendo que se necesiten incluso más programadores, ya que con una IA una pequeña empresa va a poder plantearse tener lonque ahora solo tienen las grandes empresas (y estas pasarán al siguiente escalón)
Más fea es la sintaxis de Javascript o los derivados de C.
Las tabulaciones son malas? Hacen que el código sea mucho más legible. Dios, como odio programas que no tabulan los bloques y se hacen dificiles de saber donde empieza y termina un bloque. Con las tabulaciones ves visualmente e inmediatamente lo que corresponde a un bloque.
Yo también soy un talibán de las tabulaciones pero eso no tiene nada que ver con que el sistema de llaves me parezca más cómodo y visual. Además las llaves permiten en lenguajes más modernos hacer closures , pasar comportamientos como argumento, etc que no creo que pudieran ser implementados sin llaves o algún otro símbolo que marque el inicio y fin de cada bloque. Al decir que no me gusta nada Python no quiero decir que JavaScript u otros lenguajes más veteranos sean más "bonitos", pero para ser Python un lenguaje relativamente reciente me parece bastante obsoleto estéticamente y encima con pobre rendimiento y limitaciones técnicas de despliegue. Si echas un vistazo a Swift o Kotlin, o incluso las últimas versiones de java, dices, joder qué cómodo e intuitivo todo.
Según tengo entendido, para encontrar C, C++, Rust, y similares en el backend de un servidor tiene que ser algo que maneje flujos de datos enormes, como puedan ser los servidores de YouTube, Netflix y demás
Puedes comparar el número de penalties que un portero y un delantero paran, sí. Puedes comparar el número de goles que marcan, sí.
Puedes hacer desarrollo backend web con C, sí. Sería una locura, sí.
Puedes hacer programación de bajo nivel con Python, sí. Sería una locura, sí.
Python es mucho más accesible que C y eso lo hace más lento que C. El cometido de los 2 es muy distinto.
Luego ya... compilado vs interpretado, tipado dinámico vs estático...
En Python puedes hacer "closures" sin ningún problema. Son bastante habituales. Por ejemplo todos los decoradores vendrían de un "closure".
En strings modernos, lo del % no lo usas para nada. Yo nunca he necesitado esa sintaxis. Escribes algo así: f'mi nombre es: {nombre}' Y tira millas.