Escaso apoyo a la arquitectura de 64 bits

[Jose Luis Alarcon Sanchez-2]

Hola Amigos.

Tengo un flamante AMD64 X2 desde hace poco mas de tres semanas, y la verdad es que es un cacharro magnifico... pero ¡que odisea la de los sistemas libres compilados para 64 bits!. Se echan de menos muchisimas aplicaciones las cuales su instalacion-uso es trivial en los sistemas de 32 bits. ¿Ha conseguido alguien navegar usando algun plugin para Java?.

Solucion "chapucera": como el disco duro es muy grande, dividirlo en particiones y usar de forma paralela dos sistemas, el de 64 bits y el de 32 bits. Por desgracia y en contra de lo que me habia pensado en un principio, entro mas veces y uso durante mas tiempo el sistema compilado para 32 bits, con lo cual, y sin ninguna duda, estoy desperdiciando capacidades de mi nueva maquina.

En este caso esta muy por delante el hardware sobre el software. Ya es hora de que los responsables de las distros se pongan las pilas y den prioridad ABSOLUTA a los sistemas de 64 bits como la "arquitectura normal y mas comunmente usada" y dejen a los sistemas de 32 bits como algo "legacy". Una arquitectura heredada a la que de forma secundaria solo mantienen por cuestiones de compatibilidad con las nuevas releases.

Mientras no suceda esto que solicito, vamos a seguir siendo una especie de "ciudadanos de segunda". ¿Tengo razon o no?.

Saludos.

Jose.

--
http://www.lordofunix.org/ 

Usuario GNU/Hurd no registrado.
Usuario BSD registrado 51101.
Usuario Linux registrado #213309.
Una vez más cabalgaré con mis caballeros,
para defender lo que fue.....
y el sueño de lo que pudo ser.

[Félix Martos Trenado]

El Mar, 7 de Agosto de 2007, 2:15 pm, Jose Luis Alarcon Sanchez escribió:

> Hola Amigos.
>
> Tengo un flamante AMD64 X2 desde hace poco mas de tres semanas, y la
> verdad es que es un cacharro magnifico... pero ¡que odisea la de los
> sistemas libres compilados para 64 bits!. Se echan de menos muchisimas
> aplicaciones las cuales su instalacion-uso es trivial en los sistemas de
> 32 bits. ¿Ha conseguido alguien navegar usando algun plugin para Java?.
>
> Solucion "chapucera": como el disco duro es muy grande, dividirlo en
> particiones y usar de forma paralela dos sistemas, el de 64 bits y el de
> 32 bits. Por desgracia y en contra de lo que me habia pensado en un
> principio, entro mas veces y uso durante mas tiempo el sistema compilado
> para 32 bits, con lo cual, y sin ninguna duda, estoy desperdiciando
> capacidades de mi nueva maquina.
>
> En este caso esta muy por delante el hardware sobre el software. Ya es
> hora de que los responsables de las distros se pongan las pilas y den
> prioridad ABSOLUTA a los sistemas de 64 bits como la "arquitectura normal
> y mas comunmente usada" y dejen a los sistemas de 32 bits como algo
> "legacy". Una arquitectura heredada a la que de forma secundaria solo
> mantienen por cuestiones de compatibilidad con las nuevas releases.
>
> Mientras no suceda esto que solicito, vamos a seguir siendo una especie de
> "ciudadanos de segunda". ¿Tengo razon o no?.

En parte... quizás sea cierto que los responsables de las distros no ponen
de su parte, pero yo no lo creo así. Se ha hecho mucho en muchas distros,
especialmente en Mandriva, para solventar los problemas que (seguro) te
has encontrado.

En concreto el problema del que hablas, el plugin de Java y otro que
habrás tenido, el de Flash, son responsabilidad completa y absoluta de los
que no proveen de versiones funcionales de estos para arquitecturas de 64
bits, porque se trata de elementos cerrados, como son Macromedia y Sun. En
el caso de Java es posible que seas capaz de echarlo a andar con la ultima
versión y utilizando la versión x86-64 que provee Sun, pero no lo tengo
muy claro. En el de Macromedia Flash la cosa está más difícil y la
comunidad, según leí hace no mucho, está desarrollando un wrapper para que
marche, aunque lo que sí funciona son los clones libres.

> Saludos.
>
> Jose.
>
> --
> http://www.lordofunix.org/
>
> Usuario GNU/Hurd no registrado.
> Usuario BSD registrado 51101.
> Usuario Linux registrado #213309.
> Una vez más cabalgaré con mis caballeros,
> para defender lo que fue.....
> y el sueño de lo que pudo ser.
>
>

--
     Félix Martos
http://asinkecualo.org

[Eduardo Mestre Sáez-3]

El mar, 07-08-2007 a las 14:15 +0200, Jose Luis Alarcon Sanchez
escribió:
> Hola Amigos.

Hola

> Tengo un flamante AMD64 X2 desde hace poco mas de tres semanas, y la
> verdad es que es un cacharro magnifico... pero ¡que odisea la de los
> sistemas libres compilados para 64 bits!. Se echan de menos muchisimas
> aplicaciones las cuales su instalacion-uso es trivial en los sistemas
> de 32 bits. ¿Ha conseguido alguien navegar usando algun plugin para
> Java?.

Como ya sabes, no tengo un procesador de 64 bits, pero de todas
formas... ¿has mirado en blogdrake? Haciendo una pequeña búsqueda sobre
nspluginwrapper:

http://blogdrake.net/node/7509?cx=011388937768003152519%
3A9t9odw-zehe&cof=FORID%3A11&as_q=nspluginwrapper&sa=BuscaDRAKE+2#1010

Hasta 73 resultados.

La información sobre el paquete:

Name : nspluginwrapper
Version : 0.9.90.3 Vendor : Mandriva
Release : 1mdv2007.0 Date : 2006-09-19 16:12:28
Group : Networking/WWW Source RPM : nspluginwrapper-0.9.90.3-1mdv2007.0.src.rpm
Size : 121833         Packager : Gwenole Beauchesne < gbeauchesne_mandriva_com>
Summary : A compatibility layer for Netscape 4 plugins
Description :
nspluginwrapper makes it possible to use Netscape 4 compatible plugins
compiled for i386 into Mozilla for another architecture, e.g. x86_64.

This package consists in:
* npviewer: the plugin viewer
* npwrapper.so: the browser-side plugin
* nspluginwrapper: a tool to manage plugins installation and update

Traducido: se trata de un paquete que te permite instalar los plugins de
32 bits en el Mozilla de 64 bits ¿a que mola?

> Solucion "chapucera": como el disco duro es muy grande, dividirlo en
> particiones y usar de forma paralela dos sistemas, el de 64 bits y el
> de 32 bits. Por desgracia y en contra de lo que me habia pensado en un
> principio, entro mas veces y uso durante mas tiempo el sistema
> compilado para 32 bits, con lo cual, y sin ninguna duda, estoy
> desperdiciando capacidades de mi nueva maquina.

En absoluto muchacho. Afortunadamente el diseño de la arquitectura
x86-64 te permite ejecutar en un sistema de 64 bits correr aplicaciones
de 32 bits.

En Windows lo resuelven con lo que ellos llaman wow64 (Windows over
Windows 64), que es un servicio que traduce las llamadas de 32 a
llamadas de 64 bits y viceversa, ya que por coherencia de las
estructuras de datos, Windows requiere que las llamadas de 64 bits
también actualicen las estructuras de datos de 32 bits, que no pueden
ser compartidas.

En Linux simplemente tienes que tener instaladas las librerías de 32
bits que requieran las aplicaciones de 32 bits para ejecutarse. Es
decir, que al final tienes dos versiones de las librerías, la de 64 bits
y la de 32 bits (sólo si tienes aplicaciones de 32 bits y además sólo
las justas imprescindibles)

> En este caso esta muy por delante el hardware sobre el software. Ya es

En este caso es normal, el software no se ha podido desarrollar hasta no
haber tenido el hardware, por mucho que AMD ofreciese emuladores a los
desarrolladores... de hecho el emulador resultó útil casi exclusivamente
para el desarrollo del compilador.

>  hora de que los responsables de las distros se pongan las pilas y den
> prioridad ABSOLUTA a los sistemas de 64 bits como la "arquitectura
> normal y mas comunmente usada" y dejen a los sistemas de 32 bits como
> algo "legacy". Una arquitectura heredada a la que de forma secundaria
> solo mantienen por cuestiones de compatibilidad con las nuevas
> releases.

La verdad es que no puedo estar, de momento, de acuerdo contigo. Primero
hay que ver si la "promesa" de AMD se cumple, y realmente supone un
beneficio el uso de los 64 bits en la mayoría de los casos. A priori en
realidad los 64 bits de per se les son útiles a muy poca gente, sólo
aquellos que tratan con volúmenes de datos que superen ampliamente los
4GB y que requieran espacios de memoria que superen esta limitación.
También les podría ser interesante a los de cálculo numérico, pero lo
cierto es que me temo que la mayoría harían uso del coprocesador
matemático, que ya dispone desde siempre de registros de 64 bits, están
optimizados para las operaciones matemáticas en gran escala y además
vienen "de serie" desde el i80486 y muy mejorados gracias a su
funcionalidad SIMD desde los Pentium MMX.

Las promesas de rendimiento de AMD en realidad no se fundamentan tanto
en los 64 bits, sino en el rediseño de la arquitectura, ya que se ha
pasado de un híbrido CISC-RISC como era ya actualmente la x86-32 en una
arquitectura más puramente RISC, en la que el compilador tiene más
facilidades para permitir el paralelismo y por tanto permitir a la CPU
ejecutar más instrucciones por ciclo. El problema es que al pasarse a 64
bits, entre otras cosas, se penalizan los accesos a memoria (que siempre
son varios ordenes de magnitud más lentos que la CPU).

Es decir, a pesar de las grandes mejoras teóricas que supone la
arquitectura x86-64 respecto a la tradicional x86-32, todavía esta por
demostrar que realmente el "usuario normal" tenga mejora respecto a los
32 bits. De hecho las primeras versiones de 64 bits frustraron un poco
las expectativas, debido al código de mala calidad de las primeras
versiones de los compiladores (los compiladores de 32 bits son muy
maduros y generan un código muy bueno a pesar de las limitaciones de la
arquitectura x86-32).

Además algunos procesadores (principalmente los primeros Intel x86 con
soporte de 64 bits, los Pentium D y los últimos Pentium 4) dan un pésimo
rendimiento en 64 bits. Además los Core1 (tanto los Solo como los Duo)
no tienen soporte de 64 bits (los Core2 si que lo tienen).

Otro importante problema de la arquitectura x86-64 es que es de AMD, y
al principio Intel no la apoyó porque pensaba que iba en decremento de
su propia arquitectura IA64 (que nada tiene que ver con el x86 y en
principio es mucho más avanzada y radical, aunque mucho más problemática
para el compilador y el desarrollador). Al final a Intel no le ha
quedado más remedio que aceptar, pero lo ha hecho de mala manera, ya que
en lugar de unirse a x86-64.org (una organización supuestamente
independiente promovida por AMD para el desarrollo de la arquitectura de
64 bits en la que cualquiera puede colaborar y que de hecho colaboran
algunos otros fabricantes de CPU compatibles x86) ha desarrollado su
propio dialecto, el EM64T, que aunque es básicamente compatible con la
x86-64, tiene algunas diferencias importantes. Esto hace que en realidad
se compile usando el subconjunto intersección entre x86-64 y EM64T y se
pierdan muchas opciones de optimización (esto evidentemente no sucede en
aquellas distribuciones que se compilan en tiempo de instalación, pero
Mandriva no es el caso).

Como ves, en realidad el problema es que la arquitectura de 64 bits es
de por si problemática, y con los procesadores actuales y las
necesidades actuales, en realidad la mayoría de la gente tiene
suficiente todavía con los 32 bits y por eso todavía no han madurado lo
suficiente las distribuciones de 64 bits.

> Mientras no suceda esto que solicito, vamos a seguir siendo una
> especie de "ciudadanos de segunda". ¿Tengo razon o no?.

Todos los usuarios de arquitecturas minoritarias son siempre usuarios de
segunda, ya que al ser minoritarias, las usan menos gente y por tanto
las cosas están siempre menos probadas. Eso, como linuxero, deberías
saberlo ya.

> Saludos.
>
> Jose.
>
--
Signate:      Powered by Linux !!!! Registered User #98037
  ____________    __________
 I  ______    \  /    ______I emestre@...
 I  I___  I    \/    I______  Eduardo.Mestre@...
 I  ____I I  I\  /I  _____  I
 I  I_____I  I \/ I  _____I I
 I___________I    I_________I

We salute you!!! (AC-DC dixit)
Si vienes a Tarragona, tomate una birra en el Helvete Metal Bar:
http://helvete.servebeer.com
Escucha a mi grupo Speedball en http://speedball.servemp3.com

[Jose Luis Alarcon Sanchez-2]

On Tue, 07 Aug 2007 22:08:23 +0200
Eduardo Mestre Sáez <Eduardo.Mestre@...> wrote:

> El mar, 07-08-2007 a las 14:15 +0200, Jose Luis Alarcon Sanchez
> escribió:
> > Hola Amigos.
>
> Hola

Hola Eduardo. :)

>
> > Solucion "chapucera": como el disco duro es muy grande, dividirlo en
> > particiones y usar de forma paralela dos sistemas, el de 64 bits y el
> > de 32 bits. Por desgracia y en contra de lo que me habia pensado en un
> > principio, entro mas veces y uso durante mas tiempo el sistema
> > compilado para 32 bits, con lo cual, y sin ninguna duda, estoy
> > desperdiciando capacidades de mi nueva maquina.
>
> En absoluto muchacho. Afortunadamente el diseño de la arquitectura
> x86-64 te permite ejecutar en un sistema de 64 bits correr aplicaciones
> de 32 bits.
>

Ahí podría residir precisamente uno de los principales "defectos" de
estos cacharros: ¿Por qué hacerlos compatibles "hacia atrás" con los
sistemas operativos compilados para 32 bits?. Ya puestos, que los
hagan también capaces de correr sistemas de 16 bits. Total, para no
perder la compatibilidad...

Si estas máquinas no pudiesen correr sistemas de 32 bits, los hacedores
de software se pondrían bien las pilas en empezar a preparar buenas
aplicaciones-sistemas de 64 bits. Pero al existir la compatibilidad,
en el mundo real parece que se les ha quitado la prisa por hacer emerger
la computación a 64 bits como la primaria y dominante a partir de algún
momento determinado. Y nada, así en el mundo del software el desarrollo
a 64 bits se asienta como algo paralelo o alternativo, pero no llega el
instante (que me temo que si llegó cuando se pasó de 16 a 32 bits) en
que se diga "bueno, los 32 bits son el pasado y a partir de ahora la
computación preponderante o dominante será la basada en 64 bits".

> En Windows lo resuelven con lo que ellos llaman wow64 (Windows over
> Windows 64), que es un servicio que traduce las llamadas de 32 a
> llamadas de 64 bits y viceversa, ya que por coherencia de las
> estructuras de datos, Windows requiere que las llamadas de 64 bits
> también actualicen las estructuras de datos de 32 bits, que no pueden
> ser compartidas.
>
> En Linux simplemente tienes que tener instaladas las librerías de 32
> bits que requieran las aplicaciones de 32 bits para ejecutarse. Es
> decir, que al final tienes dos versiones de las librerías, la de 64 bits
> y la de 32 bits (sólo si tienes aplicaciones de 32 bits y además sólo
> las justas imprescindibles)
>
> > En este caso esta muy por delante el hardware sobre el software. Ya es
>
> En este caso es normal, el software no se ha podido desarrollar hasta no
> haber tenido el hardware, por mucho que AMD ofreciese emuladores a los
> desarrolladores... de hecho el emulador resultó útil casi exclusivamente
> para el desarrollo del compilador.
>
> >  hora de que los responsables de las distros se pongan las pilas y den
> > prioridad ABSOLUTA a los sistemas de 64 bits como la "arquitectura
> > normal y mas comunmente usada" y dejen a los sistemas de 32 bits como
> > algo "legacy". Una arquitectura heredada a la que de forma secundaria
> > solo mantienen por cuestiones de compatibilidad con las nuevas
> > releases.
>
> La verdad es que no puedo estar, de momento, de acuerdo contigo. Primero
> hay que ver si la "promesa" de AMD se cumple, y realmente supone un
> beneficio el uso de los 64 bits en la mayoría de los casos. A priori en
> realidad los 64 bits de per se les son útiles a muy poca gente, sólo
> aquellos que tratan con volúmenes de datos que superen ampliamente los
> 4GB y que requieran espacios de memoria que superen esta limitación.
> También les podría ser interesante a los de cálculo numérico, pero lo
> cierto es que me temo que la mayoría harían uso del coprocesador
> matemático, que ya dispone desde siempre de registros de 64 bits, están
> optimizados para las operaciones matemáticas en gran escala y además
> vienen "de serie" desde el i80486 y muy mejorados gracias a su
> funcionalidad SIMD desde los Pentium MMX.
>
> Las promesas de rendimiento de AMD en realidad no se fundamentan tanto
> en los 64 bits, sino en el rediseño de la arquitectura, ya que se ha
> pasado de un híbrido CISC-RISC como era ya actualmente la x86-32 en una
> arquitectura más puramente RISC, en la que el compilador tiene más
> facilidades para permitir el paralelismo y por tanto permitir a la CPU
> ejecutar más instrucciones por ciclo. El problema es que al pasarse a 64
> bits, entre otras cosas, se penalizan los accesos a memoria (que siempre
> son varios ordenes de magnitud más lentos que la CPU).
>
> Es decir, a pesar de las grandes mejoras teóricas que supone la
> arquitectura x86-64 respecto a la tradicional x86-32, todavía esta por
> demostrar que realmente el "usuario normal" tenga mejora respecto a los
> 32 bits. De hecho las primeras versiones de 64 bits frustraron un poco
> las expectativas, debido al código de mala calidad de las primeras
> versiones de los compiladores (los compiladores de 32 bits son muy
> maduros y generan un código muy bueno a pesar de las limitaciones de la
> arquitectura x86-32).
>
> Además algunos procesadores (principalmente los primeros Intel x86 con
> soporte de 64 bits, los Pentium D y los últimos Pentium 4) dan un pésimo
> rendimiento en 64 bits. Además los Core1 (tanto los Solo como los Duo)
> no tienen soporte de 64 bits (los Core2 si que lo tienen).
>
> Otro importante problema de la arquitectura x86-64 es que es de AMD, y
> al principio Intel no la apoyó porque pensaba que iba en decremento de
> su propia arquitectura IA64 (que nada tiene que ver con el x86 y en
> principio es mucho más avanzada y radical, aunque mucho más problemática
> para el compilador y el desarrollador). Al final a Intel no le ha
> quedado más remedio que aceptar, pero lo ha hecho de mala manera, ya que
> en lugar de unirse a x86-64.org (una organización supuestamente
> independiente promovida por AMD para el desarrollo de la arquitectura de
> 64 bits en la que cualquiera puede colaborar y que de hecho colaboran
> algunos otros fabricantes de CPU compatibles x86) ha desarrollado su
> propio dialecto, el EM64T, que aunque es básicamente compatible con la
> x86-64, tiene algunas diferencias importantes. Esto hace que en realidad
> se compile usando el subconjunto intersección entre x86-64 y EM64T y se
> pierdan muchas opciones de optimización (esto evidentemente no sucede en
> aquellas distribuciones que se compilan en tiempo de instalación, pero
> Mandriva no es el caso).
>
> Como ves, en realidad el problema es que la arquitectura de 64 bits es
> de por si problemática, y con los procesadores actuales y las
> necesidades actuales, en realidad la mayoría de la gente tiene
> suficiente todavía con los 32 bits y por eso todavía no han madurado lo
> suficiente las distribuciones de 64 bits.
>

No me importa en absoluto que discrepes de mis opiniones. Todo lo contrario,
encantado de aprender mogollón de tus bien argumentados razonamientos.

> > Mientras no suceda esto que solicito, vamos a seguir siendo una
> > especie de "ciudadanos de segunda". ¿Tengo razon o no?.
>
> Todos los usuarios de arquitecturas minoritarias son siempre usuarios de
> segunda, ya que al ser minoritarias, las usan menos gente y por tanto
> las cosas están siempre menos probadas. Eso, como linuxero, deberías
> saberlo ya.
>

¡Ahí me has dao un palo fuerte! 8P. Tocado... y hundido. :D

Salut!

Jose.

--
http://www.lordofunix.org/

Usuario GNU/Hurd no registrado.
Usuario BSD registrado 51101.
Usuario Linux registrado #213309.
Una vez más cabalgaré con mis caballeros,
para defender lo que fue.....
y el sueño de lo que pudo ser.

[Eduardo Mestre Sáez-3]

El mar, 07-08-2007 a las 23:39 +0200, Jose Luis Alarcon Sanchez
escribió:

> On Tue, 07 Aug 2007 22:08:23 +0200
> Eduardo Mestre Sáez <Eduardo.Mestre@...> wrote:
>
> > El mar, 07-08-2007 a las 14:15 +0200, Jose Luis Alarcon Sanchez
> > escribió:
> > > Hola Amigos.
> >
> > Hola
>
> Hola Eduardo. :)
>
> >
> > > Solucion "chapucera": como el disco duro es muy grande, dividirlo en
> > > particiones y usar de forma paralela dos sistemas, el de 64 bits y el
> > > de 32 bits. Por desgracia y en contra de lo que me habia pensado en un
> > > principio, entro mas veces y uso durante mas tiempo el sistema
> > > compilado para 32 bits, con lo cual, y sin ninguna duda, estoy
> > > desperdiciando capacidades de mi nueva maquina.
> >
> > En absoluto muchacho. Afortunadamente el diseño de la arquitectura
> > x86-64 te permite ejecutar en un sistema de 64 bits correr aplicaciones
> > de 32 bits.
> >
>
> Ahí podría residir precisamente uno de los principales "defectos" de
> estos cacharros: ¿Por qué hacerlos compatibles "hacia atrás" con los
> sistemas operativos compilados para 32 bits?. Ya puestos, que los
> hagan también capaces de correr sistemas de 16 bits. Total, para no
> perder la compatibilidad...

Pueden, sin duda. Como no existe Linux de 16 bits debido a que surgió
directamente para 32 bits, no hay librerías de 16 bits, pero
técnicamente nada impediría que las hubiese. De todas formas, la mejor
prueba la tienes con dosbox o con dosemu: puedes correr aplicaciones de
16 bits en Linux x86-64 sin problemas sin necesidad de usar un emulador
del procesador ni las novísimas técnicas de virtualización.

> Si estas máquinas no pudiesen correr sistemas de 32 bits, los hacedores
> de software se pondrían bien las pilas en empezar a preparar buenas
> aplicaciones-sistemas de 64 bits. Pero al existir la compatibilidad,
> en el mundo real parece que se les ha quitado la prisa por hacer emerger
> la computación a 64 bits como la primaria y dominante a partir de algún
> momento determinado. Y nada, así en el mundo del software el desarrollo

Al contrario, si el sistema operativo de 64 bits no pudiese correr las
aplicaciones actuales de 32 bits, no habrían tenido el más mínimo
futuro, por lo menos a nivel comercial. Ya ha sucedido, por ejemplo en
el caso del OS/2. El OS/2 se desarrolló como sistema operativo
multitarea para el entonces novedoso i80286. Dicho procesador es el
primero de Intel que incluye un modo de memoria protegida con
segmentación y paginación, pero a diferencia del i80386 y posteriores,
no incluye ni un modo virtual x86 ni una instrucción para retornar del
modo protegido al modo real sin reiniciar el procesador ya que Intel
consideró inútil ¿quién quería poder volver al modo real en el que la
aplicación se apodera de todo el sistema estando en un sistema
protegido?. Pues resulta que todo el mundo quería eso, ya que todos se
habían gastado una buena cantidad de dinero en su software para
Ms/PC-DOS y deseaban que el nuevo sistema operativo que substituyese al
DOS (para eso desarrollaron el OS/2, no lo olvidemos) pudiese ejecutar
todo ese caro software (dinero invertido que había que amortizar y que
no se iba a tirar por la ventana así como así). Al final IBM logró
incorporar un procedimiento, altamente ineficiente, para que OS/2
pudiese correr aplicaciones DOS, pero si la aplicación DOS se colgaba,
igual que en DOS, todo el sistema se colgaba, y como era ineficiente,
era más lento que usar la aplicación directamente en Ms/PC-DOS. Es
cierto que permitía ejecutar más de una aplicación a la vez, pero lo que
llamó la atención era que las aplicaciones eran más lentas, era tan
inestable o más que Ms/PC-DOS y no era 100% compatible. Consecuencia:
fracaso comercial, del que nunca OS/2 logró salir a pesar de corregir
todos estos problemas en versiones posteriores y ser muy superior a su
competencia.

Microsoft aprendió mucho de esto, y por eso siempre ha tratado de
mantener toda la posible compatibilidad hacia atrás posible. Intel ya
sabía lo importante que era la compatibilidad hacia atrás, pero pareció
olvidarlo con su IA64 y los Itanium, que son los procesadores de 64 bits
que Intel sacó originalmente. Los Itanium tienen un diseño
"revolucionario" (son una mezcla entre RISC y VLIW) y rompedor, que por
diseño no son compatibles con x86, pero que incluyen un
emulador/traductor/compilador-just-in-time (no me aclaro del todo sobre
lo que realmente es) que lo hace compatible con el software de PC...
pero mucho más lento. Aunque usando Linux, HP-UX o Windows para Itanium
puede llegar a ser muy rápido, usando código de x86 se arrastra, y por
tanto el carísimo Office, el SQL-Server, Oracle o Lotus Domino van más
lentos que en un relativamente más barato Xeon. Consecuencia: el que
haya visto un Itanium que levante la mano.

De hecho el x86-64 surgió a consecuencia del fracaso del Itanium.

> a 64 bits se asienta como algo paralelo o alternativo, pero no llega el
> instante (que me temo que si llegó cuando se pasó de 16 a 32 bits) en
> que se diga "bueno, los 32 bits son el pasado y a partir de ahora la
> computación preponderante o dominante será la basada en 64 bits".

Es que no es equiparable el pasar de 16 a 32 bits que pasar de 32 a 64
bits, y aún así, recuerda que el primer procesador para PC de 32 bits
fue el i80386 (del año 1986), el primer sistema operativo popular en PC
mayoritariamente de 32 bits fue el Windows 95 (1995), y el realmente
popular sistema operativo totalmente de 32 bits es el Windows XP (año
2001). Todos ellos mantienen cierto grado de compatibilidad con
aplicaciones de 16 bits.

Cuando Apple sacó el Macintosh, usando un Motorola 68000 totalmente de
32 bits, competía con los PC que usaban i8086 y i80286 que son
totalmente de 16 bits, y nadie hablaba de la ventaja de tener 32 bits.

La ventaja de usar 32 bits respecto a usar 16 se reduce a que en 16 bits
sólo puedes usar bloques de datos de hasta 64KB, mientras que en 32 bits
puedes usar bloques de hasta 4GB. Es evidente que tratar la información
en bloques de 64KB, aunque posible, es ineficiente y un auténtico coñazo
para el programador. De momento los 4GB siguen siendo un límite
aceptable.

El hecho es que además de los 32 bits el i386 incluía muchas más
características interesantes, incluso más interesantes que los propios
32 bits, pero no se si Intel o Microsoft logró asociar todas esas
ventajas a los "mágicos" 32 bits. AMD se ha subido al carro, y ha dicho
¿recodáis lo sorprendente que ha sido pasar de 16 a 32 bits (Windows 3.x
vs XP)? pues ¡¡imagínate lo que es pasar de 32 a 64!!!

Los 64 bits no son mágicos, es principalmente propaganda. Si, pasas de
poder usar 4GB a poder usar 256TB de espacio de direccionamiento (aunque
difícilmente encontraras placa madre que acepte más RAM de los 64GB
teóricos que acepta la arquitectura de 32 bits actual, de hecho, las que
he mirado "sólo" llegan hasta los 8GB).

> >
> > Como ves, en realidad el problema es que la arquitectura de 64 bits es
> > de por si problemática, y con los procesadores actuales y las
> > necesidades actuales, en realidad la mayoría de la gente tiene
> > suficiente todavía con los 32 bits y por eso todavía no han madurado lo
> > suficiente las distribuciones de 64 bits.
> >
>
> No me importa en absoluto que discrepes de mis opiniones. Todo lo contrario,
> encantado de aprender mogollón de tus bien argumentados razonamientos.

Cuando AMD sacó sus procesadores de 64 bits, que eran los x86 más
rápidos del mercado, prometió que usando código puramente 64 bits
incluso se aumentaba hasta un 30% el rendimiento. De ahí que todos como
locos a sacar versiones de 64 bits de Linux.

Efectivamente se observó que se podía sacar "hasta" un 30% más de
rendimiento, se habían olvidado de hablar del "desde", y el "desde"
parece ser un -15%, es decir, que podía ir más lento en 64 bits que en
32 bits, aunque, como ya he dicho, podría deberse al bajo rendimiento de
los primeros compiladores.

> > > Mientras no suceda esto que solicito, vamos a seguir siendo una
> > > especie de "ciudadanos de segunda". ¿Tengo razon o no?.
> >
> > Todos los usuarios de arquitecturas minoritarias son siempre usuarios de
> > segunda, ya que al ser minoritarias, las usan menos gente y por tanto
> > las cosas están siempre menos probadas. Eso, como linuxero, deberías
> > saberlo ya.
> >
>
> ¡Ahí me has dao un palo fuerte! 8P. Tocado... y hundido. :D

No, hundido no, nunca.

> Salut!
>
> Jose.
>
> --
> http://www.lordofunix.org/
>
> Usuario GNU/Hurd no registrado.
> Usuario BSD registrado 51101.
> Usuario Linux registrado #213309.
> Una vez más cabalgaré con mis caballeros,
> para defender lo que fue.....
> y el sueño de lo que pudo ser.

--

Signate:      Powered by Linux !!!! Registered User #98037
  ____________    __________
 I  ______    \  /    ______I emestre@...
 I  I___  I    \/    I______  Eduardo.Mestre@...
 I  ____I I  I\  /I  _____  I
 I  I_____I  I \/ I  _____I I
 I___________I    I_________I

We salute you!!! (AC-DC dixit)
Si vienes a Tarragona, tomate una birra en el Helvete Metal Bar:
http://helvete.servebeer.com
Escucha a mi grupo Speedball en http://speedball.servemp3.com