Andrés Ambrois <andresambr...@gmail.com> writes: > Es fácil demostrar que en algunos ejemplos, un buen JIT le gana al mismo > código en C[0]. Y ni hablar en el caso del compilador y JIT de Java, que > pueden hacer muchísimas más optimizaciones que PyPy.
No es comparable, "el mismo código", el mismo código es una implementación
naive generalmente, y por eso anda peor. Lo que se necesita es código
equivalente, que es muy distinto.
Si vamos a hablar de ventajas, bien: estas VM es que hacen profiling en run
time, por lo cual pueden aprovechar mejor el tiempo que dedican a las
optimizaciones y elegir mejor que tipo aplicar.
Pero aún si no se hace profiling del código en C, GCC 4.5 optimiza bastante
inteligentemente, y siempre se pueden usar hints. Claro, por otra parte es
un compilador pesado.
Además, para quien sabe como se comporta el compilador, es fácil escribir
código que optimiza bien.
> Y me quedo con esta cita de los comentarios del post:
>
> Greg said...>
> Everyone knows Python runs faster than C...
¿Qué relevancia puede tener un comentario como ese?
Además, no veo en tus fuentes ningún análisis del resultado de la
optimización para ninguna de las dos partes.
Para el caso particular, admite que el problema es el inlining entre
archivos (cosa que mejoró mucho con GCC 4.5 por cierto).
Lo único cuestionable son las bibliotecas compartidas, sin embargo, todo el
mundo sabe que son algo maligno. En el caso de Python, equivale a tener todo
estático, y en ese caso GCC puede optimizar.
Creo que es totalmente irrelevante esa referencia.
>> Por otra parte, lenguajes como Python están muy lejos de ser sofisticados en
>> cuanto a optimización, dado que se hace en run-time. No es comparable con lo
>> que aplica GCC por ejemplo. La ventaja está del lado del código escrito en
> C.
>
> {{Citation needed}}
>
> No sé de donde sacaste que la optimización de compilación es más sofisticada
> que la optimización en run time. Aún así, tanto Java como Python son
> compilados a bytecode, por lo que una gran parte de las técnicas de
> optimización disponibles para compiladores de C, también lo están para ellos.
¡Java está en otra categoría!, compila en dos etapas, y sí aplica varias
optimizaciones importantes.
Por cuestiones de economía no se puede aplicar optimizaciones profundas en
run-time. Incluso si mirás GCC, muchas de las optimizaciones hay que
activarlas a mano, porque al ser muy pesadas no se aplican por omisión.
De todos modos, lo que digo es simplemente que: es una falacia decir que
cualquiera de esos lenguajes está a la altura de código *bien escrito* en
C.
Lo que funciona realmente bien en estos lenguajes es delegar el proceso
pesado a las extensiones y primitivas escritas en C.
Estoy de acuerdo sí, en que para muchas cosas es difícil una mejora
substancial respecto a Python, porque esas partes son código C bien
optimizado, sin embargo, es imposible hacerlo peor por la misma razón.
Ninguna de esas comparaciones es objetiva. Hay que analizar el resultado en
detalle, y ver qué código máquina se ejecuta durante la vida del proceso, lo
que nos daría una idea del costo computacional de ambas soluciones.
Ahí es donde salta a la vista de manera muy clara que las soluciones que
proponen en C no son equivalentes.
No cuestiono Python como medio de obtener resultados decentes rápido, pero
no es mágico, y no es posible que le gane a C.
Sí creo que es posible diseñar lenguajes mejores que C, en su misma
categoría, pero ya eso es otra cosa.
pgp053xy0Xp1G.pgp
Description: PGP signature
_______________________________________________ General mailing list General@lists.montevideolibre.org http://lists.montevideolibre.org/listinfo.cgi/general-montevideolibre.org
