[pyar] PHP vs Python

[Luis Masuelli]

Lo de "sin librerias externas" fue un extremo hipotetico - como mínimo la extensión de MySQL hay que compilarla y la de Pillow tambien. Pero bueno gracias x tirarme una luz en el tema este xq la verdad q me sacaba el sueño en parte (y a mi experiencia propia: Python siempre se me hizo más rápido pero no me es muy común pensar en código que haya hecho para ambos casos, y el hecho de haber usado un framework muy pija para PHP que por suerte ya se esta muriendo - RadPHP XE - tambien contamina un poco la comparacion).
Lo que es IRREFUTABLE - o al menos no encuentro por el momento forma alguna en que me lo puedan refutar - es que Python es el lenguaje mas "rapido" que conozco, juzgado ahora como LENGUAJE -es decir leerlo y escribirlo- y como CULTURA -es decir: la tendencia a facilitar todo el desarrollo-, e igualado por Ruby/Groovy (nunca usé ruby asi nomas, sino que tuve algo de contacto con groovy). Programar en PHP se me hace eterno y horrible - pienso que los que mantienen los frameworks vigentes hoy son masoquistas o no conocen otro mundo que no sea PHP.

> Date: Mon, 26 May 2014 14:55:06 -0300
> From: klaussfreire en gmail.com
> To: pyar en python.org.ar
> Subject: Re: [pyar] PHP vs Python
> 
> 2014-05-26 14:03 GMT-03:00 Luis Masuelli <luismasuelli en hotmail.com>:
> > Bajo qué condiciones es más rápido un código en PHP (estándar, calculo, los
> > que te vienen en el LAMP o WAMP o XAMP) que un código en Python (CPython)?
> >
> > Páginas como estas: http://benchmarksgame.alioth.debian.org/u64q/php.php
> >
> > Otros comentarios que encontré es que Python es más rápido en sistemas onda
> > web (en parte me gusta atribuir eso al hecho de que las clases son cargadas
> > solo una vez, mientras que en PHP una clase es resuelta y cargada en cada
> > request en que se la necesita - asumiendo que usan autoloads), pero mi
> > pregunta en realidad no va a estos sistemas (no va al hecho de comparar
> > Django con Laravel, por ejemplo) sino a benchmarks simples de scripts
> > (ejemplo: supongamos q necesito 3 demonios en mi vps que hagan algo
> > intensivo o batch y que sean de puro código python y no de librerias
> > externas como ffmpeg porque ahi no me haria mucho sentido comparar).
> 
> <flame>
> 
> "sin librerías externas" es como ponerte un grillete.
> 
> Los benchmarks me llamaron la atención, porque mi experiencia es, con
> o sin librerías externas, Python es *siempre* más rápido. Pero los
> benchmarks decían lo contrario, así que me fijé.
> 
> Esos benchmarks están todos mal medidos.
> 
> Cuentan "CPU secs", que no incluye "system time" - o sea, lo que
> consume el kernel, ni cuentan el tiempo real (o sea que si usa un core
> más para tardar menos, lo cuentan como que tardó más, porque cuentan
> el tiempo doblemente).
> 
> Se evidencia eso en el CPU usage de las versiones de php - que están
> inestablamente entre 100 y 0, lo cual llama mucho la atención para un
> benchmark CPU-bound.
> 
> Uno diría, bue, si usa menos CPU es que es más rápido. Que pueda usar
> los 4 CPUs es sólo incidental, todos los lenguajes pueden. Uno diría
> bue, si el kernel consume más CPU, por qué tendría que usarse eso en
> contra del lenguaje?
> 
> Lo cierto es que la implementación del lenguaje afecta mucho al
> consumo de ciclos en kernel-mode. Por ejemplo, pasa con Python que
> cuando tenés muchos threads, eso hace trabajar mucho al kernel por el
> GIL (y otros semáforos que podés tener por ahí). Eso cuenta. Con php,
> hay algo mucho más malévolo: usan sysv queues, aparentemente
> abusándolas, no están diseñadas para altos volumenes de mensajes, y
> por eso el CPU se queda en 0: porque el kernel come el resto.
> 
> En síntesis: no le des ni un poquito de bola a esa página, que tiene
> más error que resultados.
> 
> </flame>
> 
> A lo cierto: la performance depende fuertemente de la tarea. Por más
> que mis tareas fueron siempre más rápido y consumiendo menos memoria
> en Python, para vos puede ser diferente. Probalo. Codeá en ambos y
> fijate cuál anda mejor. De paso vas a ver en carne propia cuál te
> parece más ágil en desarrollo, que es algo que nadie puede superar de
> python. Especialmente si pensás hacer todo "sin librerías externas",
> frase que es de fakir - voy a dormir, pero no en el piso ni en un
> colchón, sobre clavos de punta. Porque me la banco.
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
> 
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
> 
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina - http://www.usla.org.ar
 		 	   		  
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140526/7a300e04/attachment.html>