[pyar] PHP vs Python

[Luis Masuelli]

Flashie por el parecido de la sintaxis en los patrones builder y esas cosas, y los pibes me dijeron q estaba basado en ruby ._.

> Date: Mon, 26 May 2014 13:50:59 -0500
> From: chack14rock en gmail.com
> To: pyar en python.org.ar
> Subject: Re: [pyar] PHP vs Python
> 
> Ruby no tiene nada que ver con Groovy .__.
> 
> El día 26 de mayo de 2014, 13:48, Luis Masuelli
> <luismasuelli en hotmail.com> escribió:
> > 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
> >
> > _______________________________________________
> > 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
> _______________________________________________
> 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/a8e8e321/attachment.html>