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
