[pyar] PHP vs Python

Charly Román chack14rock en gmail.com
Lun Mayo 26 15:50:59 ART 2014


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


More information about the pyar mailing list