[Usuarios] Arquitecturas X86 - 64

Jimmy Latouche jimmy.lc en gmail.com
Lun Sep 14 11:26:16 CDT 2009


Me van a disculpar por cambiar el Topic, pero a esta discusión se le
puede sacar mucho el jugo si se encamina correctamente.

Esteban Monge wrote:
> Con respecto a este comentario:
> 
> Es una pena que por la inercia del mercado — gracias a gente como vos — AMD
> tenga que continuar desperdiciando una cantidad significativa de espacio en
> el silicón solo para mantener compatibilidad con una cosa literalmente del
> siglo pasado.
> 
> No me gusta calificar de porquería nada, pero, no es cierto que el software
> libre precisamente garantiza que los datos se mantengan intactos a pesar de
> que sean del siglo pasado?

No no, es diferente, la compatibilidad de datos (hojas de calculo,
archivos multimedia, etc) tiene poco o nada que ver con la forma en la
que se corren las instrucciones de un procesador, un claro ejemplo de
ello es el caso de OSX darwin corriendo sobre un procesador Power PC G3,
es muy diferente a la forma en que trabaja Intel pero aún así hay
software que permite abrir los archivos.

Recuerdo que por ejemplo los procesadores G3 de 400Mhz eran equiparados
en desempeño a un Pentium III corriendo a 700Mhz, gran parte del "por
qué" radicaba en el uso correcto del set de instrucciones y de eso es lo
que Marcelo ha estado hablando.

> Uno de los objetivos que se cumplen al lanzar una biblioteca nueva es que
> sea 100% compatible con una anterior, entonces, eso es basura y porquería
> también?

Es correcto, en teoría debería haber compatibilidad hacia atrás, pero en
algunas ocasiones se viene arrastrando desde hace tiempo cosas que
solamente reducen el desempeño general y producen dolores de cabeza, voy
a citar un ejemplo que no me gusta pero ahí va:

La razón por la que mucho software que funcionaba en XP no corre en
Vista es porque MS se dió cuenta que mantener la compatibilidad hacia
atrás en sus API y otras partes solamente estaba provocando malas
prácticas de programación y complicaciones, con la aparición de Vista se
amarraron los pantalones y dijeron "Hasta aquí" si.. no sirvió, Vista
fue un fracaso ¿Y qué? igual la gente que tiene que usar Windows por una
razón u otra eventualmente va a tener que migrar a una nueva encarnación
del OS donde los métodos antiguos ya no funcionan.

La cosa es: ¿Rompió la compatibilidad con la apertura de archivos hecho
en la era de DOS? ¡NO! definitivamente si lo hizo con los ejecutables
pero los datos ahí están.

De la misma forma pregúntale a un programador de 80286, 8086 si está
interesado en volver a programar de la forma en que lo hacía en su
época, una de las cosas que mas agradecen esos programadores fue la
aparición de instrucciones que facilitaban el manejo de memoria, fue
acogido por todos, el modelo anterior fue desechado y nadie se quejó. De
nuevo, lo que dice Marcelo es mas o menos similar: de que sirve tener un
set de instrucciones que ofrecen un sin número de características
avanzadas si seguimos arrastrando un montón de cosas que ya de por sí se
van a morir.


> Yo la verdad veo muy lógico eso que dice Marcelo, pero para muchas empresas
> y personas es vital que su software y hardware sea compatible con
> tecnologías antiguas, para mi la verdad es frustrante tener que compilar
> Doom con librerías nuevas (no Doom precisamente si no el motor) y ver que
> corre lento en un procesador de 400Mhz, mientras que antes corría super bien
> en una máquina con 100Mhz. Claro esta observación es totalmente objetiva, ya
> que podríamos aducir que no es lo mismo correr en DOS Doom que en un Debian
> actual, pero constantemente los softwares se hacen grandes pelotas de código
> que guardan compatibilidad con otros.

Eso es un problema inevitable hasta cierto punto sabes, si realmente
nuestra sociedad estuviera basada en esa linea de pensamiento entonces
todavía sería posible conseguir lectores de tarjetas perforadas en las
tiendas de cómputo, reproductores de acetato en todos los comercios,
Betamax en todas partes, etc.

No hay una respuesta definitiva a ese dilema que pones e incluso en
Slashdot aparece el tema al menos unas 10 veces al año, la mejor
práctica es migrar los datos importantes de un formato a otro en cada
transición tecnológica, por ejemplo de cinta a disco magnético, de disco
magnético a disco óptico, de disco óptico a lo que venga.

Con respecto a los formatos duraderos y perdurables, pues
lamentablemente aún estamos en pañales, a penas empezamos a generar
conciencia del problema a nivel mundial, por lo que te puedo asegurar
que el problema de las librerías es el menor de ellos.

Aún así, un buen truco que he visto es la emulación de plataformas, eso
es una muy buena idea para correr cosas muy viejas en arquitecturas
modernas sin tener que recompilar nada.

> Yo se que suena algo ilógico y diferente que se comparen software y
> hardware, pero habrá alguien por ahí que todavía utilice instrucciones de
> 386 para crear procesadores, como los Via C3 o C7, es mas la mayoria de la
> gente usa GNU/Linux para 386...

¡AH! si, pero eso es diferente, esos procesadores por lo general se
crean para aplicaciones embeded o de bajo impacto y muy específicas, en
esos casos se prefiere mantener las cosas de ese tamaño por muchas
razones como lo son el consumo eléctrico, calentamiento, tolerancia a
fallos, etc.

Si... es cierto... esos procesadores pueden servir para escritorio, pero
si lo ves de esa forma tan cuadrada entonces uno también puede hacer una
PC de escritorio a punta de chips PIC, preguntale a Steve Wozniak acerca
de eso, ¿Es funcional? errrmmm... me quedo con un Athlon 64 o mas,
muchas gracias.

> Otra cosa, yo tengo también todo en 64bits, y con un mísero GB de RAM (menos
> como 64MB de vídeo) y si noté diferencias de rapidez, también anoto que yo
> no uso KDE o GNOME, uso enlightenment y en su versión 0.16... lo cual me da
> argumentos para decir que gracias a cambios en el proyecto enlightenment mi
> escritorio quedó defastado, nada de E17 es compatible con E16, se pueden
> compilar cosas como el dock, pero igual tengo que compilar todas las
> librerías necesarias para E17, hubiera sido importante que se mantiviera la
> compatiblidad...

Pero eso no es culpa tuya, eso simple y sencillamente se trata de que en
el proyecto no han portado los paquetes de una versión a otra, la
pregunta es ¿Por qué no lo han hecho?

Por favor toma nota que E17 NO es estable oficialmente, si estas usando
algo que está en etapa de desarrollo entonces no empieces a quejarte de
compatibilidades. Si aún después de que hagan el release oficial de E17
no tienes compatibilidad con E16 entonces habría que analizar las causas
del por qué, me inclino a pensar que (ésta me encanta) los programadores
decidieron no seguir arrastrando la forma en que se hacían las cosas
porque hay una mejor forma de hacerlo ahora, ¿alguien nota una paradoja?

> No me quejo, yo veo todas las recomendaciones válidas, no veo motivos para
> brincar y decir que algo es porquería...

Yo creo que el comentario depende mucho del punto de vista, el grueso de
los usuarios estamos en una estación de trabajo o menos, imagino que
para las personas que desarrollan en serio si debe representar un
problema tener toda esa jugosa arquitectura esperando a ser explotada y
estar atado de manos por arrastrar cuestiones arcaicas.



_______________________________________________
Lista de correo "usuarios", usuarios en softwarelibrecr.org

Para modificar las preferencias o anular la suscripción visite:
http://lists.softwarelibrecr.org/mailman/listinfo/usuarios

Para obtener instrucciones para organizar automáticamente los correos que vienen de esta lista visite:
http://www.softwarelibrecr.org/documentacion/software_libre/thunderbird/filtrar_listas



Más información sobre la lista de distribución Usuarios