HispaMSX

RE:_Disertación_sobre_lenguajes_de_alto_nivel,_consumismo,_etc...

2004-05-12 21:30:23
No, la mala leche viene de esos prejuicios estupidos...

Bueno... pues como sigo sin saber de qué c..o hablas, vamos a 
desglosar lo que te ha hecho enfadar, para ver si realmente son 
prejuicios y si son estupidos... 
Como foro que es esto, creo que está bien discutir puntos de vista... 
aunque en este caso no sean de MSX. Sí me gustaría saber tus puntos 
de vista sobre el tema, ya que supongo que si tienes una postura tan 
firme, es por que supongo que sabrás de lo que hablas, no?

Esto es lo que yo escribí...

Teneis parte de razón, pero yo creo que si ahora se programa en 
lenguajes como Java, o en C++ con esas mierda librerías ultra-
portables y ultra-lentas (Qt, GTK),

Bueno, quizá lo de "mierda" es una palabrota que se me he escapao y 
que no venía a cuento, pero es verdad que Java es muuy lento, y que 
Qt y GTK, aunque mucho más rapidas que Java+Swing, son bastante 
lentas si las comparamos con la API de Micro$oft, básicamente por que 
son mas portables y tienen más capas de SW de por medio.

es más bien por economía mas que 
por comodidad. Y lo digo por experiencia, que trabajo como 
programador de Java y realmente se nota la velocidad a la hora de 
programar. Si a una empresa cada hora de desarrollo le puede costar 
entre 40 o 60 euros, echad cuentas en que sale más barato comprarse 
un pentium 7 que en dedicarse a optimizar para nuestros obsoletos PC
(suena irónico jeje)... ya por no hablar si hubiera que hacer ports 
a 
multiples sistemas operativos (cosa que con java no pasa)

Esto no hay que argumentarlo, por que es un argumento. Nadie puede 
negar que, el tiempo de desarrollo para proyectos medianamente 
grandes sigue este esquema:

Ensamblador > C > C++ > Java y otros

O es que pensais que conceptos como gestión de excepciones, 
orientación a objetos, o gestión automática de la memoria salieron 
por que sí?
Y el que niegue esto y diga que son prejuicios es que nunca ha 
participado en proyectos informáticos complejos.

Aunque ese no es el caso del usuario doméstico, porque CÓMO ME JODE 
no poder usar a una velocidad mínimamente decente determinados 
programas por que los cabrones de sus programadores los han 
programado en Java (JBuilder, Idea, Netbeans...)

Para argumentar esto, sólo tienes que venir a mi casa y ver a qué 
velocidad miserable se ejecutan en mi PC. Aunque supongo que estás de 
acuerdo conmigo.

De este verano no pasa que me compro un pentium 9 a 400 
Gigahertzios .... ETC ETC ETC

Esto sí lo acepto como "gilipolleces" :p

Y ahora vamos a hablar sobre lo que yo sí considero un PREJUICIO 
ESTÚPIDO: "Pues a mí me gusta programar en ensamblador mi PC (que no 
MSX) por que así los programas están más optimizados y van mas 
rápidos". Este prejuicio lo haremos extensible a cualquier máquina un 
poco moderna (no hace falta que lo sea mucho) y explicaré por que es 
INFUNDADO (suena mejor que estúpido, no?).

1 - REPERTORIO DE INSTRUCCIONES: alguien conoce de memoria todas las 
instrucciones de un procesador moderno? Hay cientos! Debido a las 
necesidades en las aplicaciones actuales (sobretodo multimedia), hoy 
día incluso los procesadores RISC tienen instrucciones muy complejas, 
sobretodo para el proceso digital de señales multimedia (p. ej: MMX o 
3D-Now), aparte de varios tipos de sumas, divisiones, 
multiplicaciones, correcciones de nosequé.... en fín, que uno puede 
tener en mente todas las instrucciones del z80, pero tener en mente 
400 o 500 instrucciones y saber elegir siempre entre la más adecuada, 
al menos para mi mundana mente es tarea de locos. Aún así para mí 
este es el menor impedimento que hay para programar ensamblador y 
seguro que hay gente tan crack que es capaz de dominar perfectamente 
todo el repertorio.

2 - ARQUITECTURA DEL PROCESADOR: ummmm.... cierto compañero mío de la 
universidad, asiduo a esta lista, ha sufrido conmigo esto ;) El 
procesador z80 tiene una arquitectura bastante sencilla, y realmente 
no hace falta conocerla a fondo para programarlo eficientemente. Pero 
en los procesadores modernos esto hay que tenerlo MUY en cuenta para 
que los programas vayan eficientemente. Como seguramente alguno no 
sepa de qué hablo, explico brevemente dos de los conceptos básicos:
2.1 - Pipeline
En los procesadores antiguos (z80, 68000), se ejecutaba una 
instrucción, y cuando esta acababa, se ejecutaba otra. La ejecución 
de una instrucción código máquina se puede dividir en etapas, en las 
cuales se usa sólo una parte del procesador. Entonces los ingenieros 
se plantearon hacer que, por ejemplo, mientras el procesador 
ejecutaba una instrucción (etapa de ejecución), aprovechara para ir 
buscando en memoria la siguiente (etapa de búsqueda). Por tanto, en 
este pipeline de "2" etapas podían ejecutarse a la vez 2 
instrucciones. Considerad un pipeline como una carretera por donde 
van las instrucciones en fila india.
Sólo he de decir que el último modelo de Pentium IV tiene 33 etapas 
de pipeline, y estos pipelines tienen diferentes caminos, y unas 
instrucciones pueden adelantar a otras, y una parafernalia del 
copón... Como no todas las instrucciones son iguales (no duran lo 
mismo, no ocupan los mismos recursos del procesador, no van por los 
mismos caminos...) a la hora de programar el código máquina hay que 
insertarlas en un determinado orden para intentar que, aunque nunca 
se puedan ejecutar 33 instrucciones a la vez (en el caso del P4) sí 
se puedan ejecutar las máximas posibles. Para ello es necesario saber 
todas las características de cada una de las instrucciones (tiempo de 
ejecución, caminos, recursos utilizados...) y las características del 
pipeline.
2.2 - Superescalar, VLIW
Son conceptos parecidos, y estos se basan en que si, por ejemplo, una 
división tarda 4 ciclos de reloj, a la que vengan 4 divisiones 
seguidas tardaremos 16 ciclos de reloj para sólo 4 instrucciones. 
Para optimizar esto se meten en el procesador 4 divisores (por 
ejemplo), de manera que las 4 divisiones se puedan ejecutar a la vez, 
y tengamos 4 divisiones ejecutadas en 4 ciclos de reloj. Esto es 
Superescalar.
El VLIW (Very Long Instruction Word), que usan los procesadores de 
256 bits, es parecido. solo que las 4 divisiones se meten a la vez en 
el procesador (digamos que una instrucción ensamblador realmente está 
dividida en varias instrucciones).
Como un procesador no tiene sumadores, divisores o multiplicadores 
infinitos, es necesario ordenar las instrucciones en un orden 
correcto para que no tengan que esperar a que los recursos estén 
desocupados. Para ello hay que conocer bien los tiempos de ejecución 
y los recursos utilizados por las instrucciones, y también hay que 
conocer los recursos de que dispone el procesador, los cuales pueden 
cambiar de un modelo a otro.

Esto que explico no es nuevo, muchas de estas cosas ya existían en 
los años 80-90, aunque es algo más reciente verlo en procesadores más 
domésticos.
Esto que expliqué es una simplificación, pues hay problemas de 
dependencias entre instrucciones que también hay que resolver. Además 
los procesadores actuales son bastante más complicados, por que 
tienen todavía más pijadas (como varios niveles de memoria caché, 
etc...). Si queremos programar óptimamente en ensamblador, no sólo 
necesitaremos un huevo de tiempo en documentarnos a fondo sobre el 
procesador, sino que para escribir 10 instrucciones estaremos 30 
minutos calculando, simulando, imaginando... Por que en un procesador 
moderno no es lo mismo hacer:
                        load a,3
                        load b,4
                        load c,5
                        load d,6
                        mul e,a,b
                        mul f,c,d
que hacer:
                        load a,3
                        load b,4
                        mul e,a,b
                        load c,5
                        load d,6
                        mul f,c,d
ya que ahora el orden de las instrucciones, aunque no afecte al 
resultado de la operación, dependiendo del contexto sí puede afectar 
de manera seria el rendimiento del programa.
Y ya por no hablar de sistemas multiprocesador, etc...

3 - COMPILADORES INTELIGENTES: hoy en día los compiladores no sólo 
hacen los cálculos y especulaciones necesarias para optimizar para 
una arquitectura en concreto. También llevan sus optimizadores la mar 
de majos que, una vez generado un código pseudoensamblador, lo 
repasan varias veces para eliminar esas partes de código 
innecesarias, o para redistribuir el código de manera que corra más, 
o modificarlo para que ocupe menos memoria, y un larguisimo 
etcetera...

Si a todo esto le añadimos los conceptos sobre economía, y que 
programar una aplicación WEB o manejar Bases de Datos en ensamblador 
sería de "flipao de la vida", me veo con argumentos suficientes para 
decir que hoy en día, en las grandes aplicaciones el ENSAMBLADOR ESTÁ 
MUERTO.

OJO! En esto no incluyo el manejo de aplicaciones con 
microcontroladores, donde se empieza a abandonar, pero se sigue 
utilizando.
También creo que en determinadas aplicaciones de cálculos muy  
intensos, como podría ser una aplicación multimedia actual, se podría 
optimizar a mano algún pequeño bucle que se repita muchas veces, con 
tal de mejorar su velocidad. Pero eso sí, habría que conocer muy a 
fondo lo que se está haciendo (procesador, compilador, etc...)

Joé nennn que jartá de escribir me he pegao... Espero me perdoneis si 
se me ha colao alguna falta de ortografía eh?

Por cierto, por mi parte se acabó este hilo, por que ya he expuesto 
mis argumentos y por que no quiero continuar alejandolo de la 
temática MSX. Eso sí, leeré gustoso todas vuestras 
réplicas/insultos/vetatomarporculos.

Saludos a todos,
Mario Macías Lloret


<Anterior en la conversación] Conversación actual [Siguiente en la conversación>