RE: [suse-linux-s] SUSE y AMD 64
Hola :)
-----Original Message-----
Subject: Re: [suse-linux-s] SUSE y AMD 64
"We were told by HP in December 2004 that Itanium chip had 2,900 applications ported to it and that HP hoped to hit 4,500 applications by the end of 2005. Having pulled in 1,100 new applications in less than six months already, if this rate can be sustained, Itanium could have more than 5,000 applications by the end of the year -- well ahead of HP's projections from six months ago."
No dice que rendimiento tendrian esas aplicaciones en otro hardware de igual costo, equipado con micros Opteron?
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 ;)
Por cierto ... nadie ha mencionado los Power ;)
¿Y lo de Apple pasando a Intel? ... Da que pensar ...
Yo creo que intel, está buscando otros caminos, por el territorio que está perdiendo frente a AMD.
Yo no sé qué pensar ... los PowerPC son procesadores MUY buenos. A lo mejor no es Intel el que busca refugio y cobijo sino que es Apple quien lo busca porque NO hay SW para PowerPC, sólo el que hace Mac/Apple, las dos cosas que hace MS (para que no le acusen de monopolio, tampoco debe comprar a Mac porque entonces vuelven a acusarle de monopolio) y las otras dos cosas que hace IBM y alguna empresa más (Macromedia y Adobe, por ejemplo).
Nos queda por debatir si influye usar el compilador de Intel o el gcc, parámetros de optimización, ...
¿Tu crees que el compilador de intel sirve para los AMD?
No, pero AMD NO saca uno suyo ni colabora como debería con gcc para hacerle frente a icc. Pero, sí podemos compara el icc y el gcc frente a frente en el mismo procesador y veremos que uno da mejores rendimientos en una cosa y peores en otra. Por ejemplo: si alguien compila el kernel de Linux con icc ... le deseo mucha suerte.
O es otra herramienta para hacer aplicaciones que corran bien en micros intel y mal en micros AMD?
Puede ser, puede que no: ver ejemplo del kernel que comento arriba.
Claro que AMD, pudiera hacer su compilador, y mas despues de haber trabajado estrechamente con la gente de Suse en el desarrollo del kernel, y Torvalds que estaba en Transmeta, mientras esta le suministraba los emuladores de desarrollo para el AMD64.
No creo que deba sacar su propio compilador ya que tiene el gcc, lo que debería hacer es colaborar más con gcc para conseguir mejoras para sus procesadores. También colaborar con gdb, glibc, valgrind y demás utilidades de muy bajo nivel. Otra pregunta que me ronda la cabeza es: - ¿qué peso tienen las diferentes cachés de L1, L2 y L3? - ¿qué peso tienen los anchos de banda? Todo esto que puede parecer irrelevante, pero no es tan irrelevante y ya no depende del procesador sino de fabricantes de memorias, placas base, ...
Por acá, intel está haciendo una campaña publicitaria desesperada, para sacarse de encima los P4 HT. Yo vuelvo a sostener lo mismo: si para una aplicación seria como una base de datos Oracle, funcionan mas eficientemente con el HT desactivado (sin errores y a mayor velocidad), y
Copio un trozo de un correo de un DBA MUY activo en las listas de SUSE (Oracle y SLES), es un tío MUY cañero que tiene montado un arsenal de Oracles de impresión: "I tested Oracle with and without HT, on DELL 2850. (1) Performance is almost the same. (2) With HT, performance floats more than withot HT (5 - 10%). (3) Without HT, system was niot stable (I do not know why, but it died in 2 hours of heavy testings). I believe, no one really debug this Linuxes with HT turned off, so it is safer to keep it turned on as by default." Traduzco el punto 3: "Sin HT, el sistema no era estable (no sé por qué, pero murió a las 2 horas de pruebas duras)" Vuelvo a repetir, NO ESTOY DEFENDIENDO HT NI A INTEL. Lo que digo es que hay que ver para qué se está utilizando cada cosa, qué versiones, qué sistema operativo, qué opciones de compilación, placas base, compiladores usados, ... NO es tan sencillo afirmar este o aquel procesador es mejor. Yo soy nuevo en SGI y estoy viendo que vivía en la inopia absoluta. Hablando con clientes que demandan MUCHA potencia, con técnicos de aquí, desarrolladores, ... me estoy dando cuenta de lo ignorante que soy en cuanto a procesadores, compiladores, ... 0:) Y eso que llevo 10 años con Linux !!!
hasta en aplicaciones triviales, como la reproducción de un mp3, el HT introduce distorsión, no me importa que en una aplicación x, sea mas rapido, a no ser que me lo regalen, y solamente lo use para correr esa aplicación x, donde sea eficiente y no introduzca errores.
Esa es la cuestión, a TI no te importa que una aplicación x sea más rápida, pero hay clientes que SÍ les importa porque esa aplicación les mueve MILLONES de dólares/euros que pueden ser pérdidas o ganancias. Puede suponer tardar un día menos en obtener respuesta a un problema. Y NO, NO estoy sólo hablando de dinero, también hago referencia a casos clínicos en los que el tiempo de respuesta, potencia de cálculo, ... son de vital importancia porque NO se traducen sólo a dólares/euros.
Basta con buscar en el Google, con las palabras "hypetrheading bug", y ya aparece abundante información.
Esto es como buscar Windows frente a Linux o Linux frente a Windows, te van a aparecer el mismo número de links. Habrá estudios serios de cada bando y los habrá menos serios ;) Esto NO quiere decir que esté quitando importancia a AMD y que favorezco a Intel. Lo que digo es que depende de para qué lo quieres usar, de la aplicación, el compilador, ... Esto me recuerda a otro debate de si KDE consumía más o menos recursos que Gnome, si era o no más rápido. El problema no era Gnome frente a KDE, el problema era que gcc NO tenía buen soporte para C++ por lo que el problema se extendía a todas las aplicaciones escritas en C++. Poco después se mejoró el soporte de C++ para gcc y KDE resultaba ser más rápido que Gnome ... La gente estaba discutiendo si KDE era mejor o no que Gnome, cuando lo que había que discutir era si el soporte de gcc para c++ era el correcto o no. Lo que quiero hacer ver es que no es tan sencillo decir que esto o aquello es mejor. ¿Es mejor un Ferrari o un Peugeot? Depende de para qué los vas a usar, de las ruedas, de la carretera, del combustible, ... A pasarlo bien !!! :) Rafa
Rafael Griman wrote:
Hola :)
-----Original Message-----
Subject: Re: [suse-linux-s] SUSE y AMD 64
"We were told by HP in December 2004 that Itanium chip had 2,900 applications ported to it and that HP hoped to hit 4,500 applications by the end of 2005. Having pulled in 1,100 new applications in less than six months already, if this rate can be sustained, Itanium could have more than 5,000 applications by the end of the year -- well ahead of HP's projections from six months ago."
No dice que rendimiento tendrian esas aplicaciones en otro hardware de igual costo, equipado con micros Opteron?
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. En cuanto a Oracle, tiene una version optimizada para AMD64: http://www.linuxelectrons.com/article.php/20040525063205874 Segun he posteado en otro mensaje, el HT, no serviría, en un Powerpc, ni en un AMD K6 en adelante, ya que en realidad, el HT es un parche al defecto de los micros intel, de que necesitan 20 etapas o ciclos de reloj, para realizar una operación completa, contra 12 etapas que necesita un AMD para la misma operación. Entonces, el recurso del HT, lo que hace, es intercalar otros procesos, para sacarle el jugo a las etapas vacantes y reducir la latencia, cosa que no ocurre en los AMD, ya que muchos procesos se hacen en paralelo, y no en serie como en los Pentium, razon por la cual, los AMD tienen mayor potencia de procesamiento por cada ciclo de reloj. Saludos, Juan
participants (2)
-
Juan Erbes
-
Rafael Griman