RE: [suse-linux-s] SUSE y AMD 64
Hola :)
-----Original Message-----
Subject: Re: [suse-linux-s] SUSE y AMD 64
Volvemos al problema que se discutía antes: los binarios NO son compatibles, al igual que uno para Mac NO es compatible con x86, o uno RISC NO es compatible x86, son 2 arquitecturas diferentes. Habría que cambiar instrucciones específicas y recompilar. Por ejemplo, el Oracle para x86 NO se debe llevar a x86_64.
Digo "no se debe llevar" porque por poder se puede, pero es igual que andar con un Ferrari por la montaña, poder se puede ... pero no se debe ;)
Creo que no me entendiste bien: yo partia de la base, de que partiendo de los mismos fuentes, se pueda compilar para distintas arquitecturas, como por ejemplo el kernel linux.
Eso está claro, pero hay que pensar si esas fuentes están optimizadas para todas las arquitecturas que soporta. Puede darse el caso que NO esté optimizada por la sencilla razón de que una arquitectura no ofrece toda la documentación o información, como es el caso de los zSeries de IBM. La comunidad Linuxera tiene cierta información sobre los zSeries, pero no toda por lo que hay cosas que no están optimizadas, hay cosas que no se pueden portar, hay drivers que SÓLO los hace IBM, ... Luego hay que tener en cuenta el compilador que puede que NO esté optimizado para esa otra arquitectura, o las librerías, ...
En cuanto a Oracle, tiene una version optimizada para AMD64:
Por eso mismo digo que no se debe correr Oracle x86 sobre un x86_64. Existe una versión específica de Oracle para cada arquitectura. Lo mismo ocurre con otro SW. Cuando escribes:
No dice que rendimiento tendrian esas aplicaciones en otro hardware de igual costo, equipado con micros Opteron?
Esas aplicaciones han sido portadas a IA64 y han sido optimizadas para IA64 por lo que no la (puedes) debes correr en x86_64, necesitarías un desarrollo específico para x86_64. Algunas de ellas sí se han portado, como por ejemplo Oracle, pero otras posiblemente no. La cuestión sería si el rendimiento de Oracle para IA64 y sobre x86_64 es igual, mejor o peor. Eso sí, tienen que ser condiciones idénticas. En otro correo anterior tuyo comentas:
Ok, lo correcto, sería probar y ver que sucede, sobre una base de datos Oracle, con y sin HT. Yo no tengo ningun servidor con Oracle, y P4 HT para probarlo, y tampoco compraria intel. Está probado, que en ciertas aplicaciones, no siempre mejora el rendimiento, sino que al contrario, baja el rendimiento, e introduce errores.
Esto es lo que llevo diciendo durante todo este thread: - depende de para qué se vaya a usar - depende de opciones de compilación - depende del compilador - depende de las librerías - ... No es tan sencillo como decir: uno es mejor que otro. Igualmente podríamos estar discutiendo si es mejor un sistema SMP o uno no-SMP. Depende de para qué, depende de si la aplicación está optimizada para SMP o no. Otra posible discusión es si es mejor un sistema SMP o un cluster ... depende de lo que se esté haciendo. No es una cuestión tan sencilla, depende del caso en el que nos encontremos. En otro correo copias de Inet:
So back to the question, should you enable disable hyperthread? A) What are you trying to do? If you are running two high demand multi-tasking operations, or one critical timing operation (like burning a CD) and still doing other things... you want hyperthread on. But each task runs slower only allowed half the CPU total processing capability. If you want one really fast task able to stomp the other tasks into the ground and leave them a pile of mush in your wake, you want hyperthread off.
Volvemos a lo mismo: depende de lo que se esté haciendo. Los que estamos de cara al cliente (comerciales, preventa, ...) tenemos que tener mucho cuidado con decir "esto es mejor", hay que conocer al cliente y los problemas que tiene, hay que analaizar su situacióon y ver qué quiere, de cuánto dinero dispone, conocimientos, gente, qué pretende resolver, ... y en función de todo eso decirle "según lo que me has contado y lo que he podido entender, creo que lo que mejor te viene para este caso es esto porque bla, bla, bla, ..." Saludos :) Rafa -- Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia , 120 - Planta Baja 28003 Madrid, Spain Tel: +34 91 3984200 Fax: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com
participants (1)
-
Rafael Griman