-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Menos mal que aclaraste que piensas eso, pero la realidad indica algo muy distinto, mientras un P4 necesita 20 ciclos de reloj para un determinado proceso, los AMD64 necesitan 12 ciclos de reloj para el mismo proceso (los Athlon 32 entre 10 y 15), siempre hablando de procesos de 32 bits, porque si hablamos de procesos en 64 bits, la diferencia es mayor, ya que el unico P4 o Xeon es el EMT64, que puede competir, emula los 64 bits. A intel, no le queda mas que recurrir a trampas de mercadeo sucio, para poder seguir en el mercado: http://www.eetimes.com/showArticle.jhtml?articleID=164904088 jteraman@gmail.com wrote:
Al hilo de la noticia, pienso que ambos micros son parecidos en cuanto a funcionalidaad se refier, he funcionado con los 2 y me decanto por AMD por los 64bits(capricho, yo no los uso pero ni con mucho al 50%). Ahora la tecnologia x86 de ambas empresas ha salido para adelante por la cantidad de dinero que ambas empresas han metido para hacerlos buenos. Pero los dos se deberian mejorar bastante. Ya que bugs hay de ambas partes. Simplemente es una cuestion de empresas, y juegan con los usuarios, para que les compremos a unos a otros. Si preguntasemos a un téncio de intel o de amd seguro que ambos dirian que deben mejorar muchas cosas. El marketing esta reñido con la tecnologia. Pero bueno, te decantes por uno o por otro, llegado el caso, a disfrutar.
Saludos
kepa
El Viernes, 24 de Junio de 2005 01:30, Juan Erbes escribió:
Ya que no encontraste las recomendaciones de Oracle, te las paso: "Oracle Support reports that most systems perform *better* *without* hyperthreading anyway." http://www.dba-oracle.com/oracle_tips_cpu_count_wrong.htm http://dba.5341.com/msg/17680.html
Y el otro bug considerado critico del hyperthreading: http://www.linuxsecurity.com/content/view/119124/65/
Para aquellos que les gusta escuchar los mp3 en la compu, tambien deben desactivar el HT: http://bugs.xmms.org/show_bug.cgi?id=2016
Durante mucho tiempo se habló del duopolio wintel. Para mi hay muchas cosas en comun entre microsoft e intel, empezando con el FUD, continuando con el vaporware, y terminando en la producción de productos basados en patentes robadas, y en ambos casos a Digital (entre otras), en el caso de microsoft, partes del NT, que provenian del VAX VMS, y en el caso de intel allá por los 90, que le iva a comprar las patentes a Digital de los micros Alpha, y cuando obtuvo toda la información, no las compró, aunque años mas tarde tubo que pagar las multas a causa del juicio por este robo. El hyperthreading bug, pasa a formar parte de la historia de bugs de intel, que se suman al famoso "Comma bug", al "F00F bug", y otros tantos. Como tu dices, alguna solución debe tener, pero mientras tanto, todos los micros con el bug HT, a alguien se los deben meter, por eso, acá están gastando un dineral en publicidad, para tratar de que los padres se los compren en las computadoras a sus hijos para el colegio. Intel, no se va a comer esos micros. Otra vez, vendiendo mentiras.
Eduardo J. Vega A wrote:
¿Tu crees que el compilador de intel sirve para los AMD? No veo pq Intel deberia de hacer que su compilador sirvieda excepcionalmente bien para los Productos de AMD...
O es otra herramienta para hacer aplicaciones que corran bien en micros intel y mal en micros AMD? es una herramienta de desarrollo optimizada por su fabricante, para que, en las plataformas que el mismo fabrica, corran mucho mejor las aplicaciones punto...
no veo como mencione pq Intel deberia de optimizar sus compiladores para HW de terceros... es acaso que estos terceros no pueden hacer lo propio en investigacion y desarrollo para tener su propio compilador que optimize el SW para que corra en su plataforma?
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, Si tan enamorado estuviese Torvalds de AMD, me pregunto... pq no participo activamente en el desarrollo de algo similar a Transmeta en AMD ? ya que segun mencionas, el apego supremo es por esta plataforma?
mientras esta le suministraba los emuladores de desarrollo para el AMD64. Si asi fuera, no veo por que AMD en un afan de apoyar de una u otra forma el ecosistema de SW no desarrolla un compilador para optimizar el desarrollo de SW bajo su plataforma...
mas aun, si es cierto que son tan buenos partners de negocio con SuSE (Novell) y son un Mayor Sponsor de desarrollo del Kernel...
Por su parte, hasta donde se Intel tiene particupacion efectiva y real con Red Hat, SuSE, y tambien otra Disti China (no recuerdo el nombre) no solo apoyando con fondos (y una buena cantida de $$) sino con soporte para sus plataformas tanto de servidores, estaciones de trabajo, PC's de escritorio, y Laptops tanto a nivel de Drivers como de soporte por parte de su infraestructura de soporte sea en forma directa a usuarios finales, como a travez de su canal de ventas.
Por acá, intel está haciendo una campaña publicitaria desesperada, para sacarse de encima los P4 HT. de hecho, la tecnologia de HT es algo que va a seguir, y que incluso el mismo Torvalds ha visto con beneplacito... (basta leer el link enviado anteiormente por otro amigo de la lista)...
el soporte para HT sigue en las lineas P4 5xx, P4 6xx, y en los modelos de Extreme Edition Dual Core... (idem para Tecnologia Xeon).
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 en ninguna parte de Oracle dice oficialmente que esto sea asi... si se dan recomendaciones de posibles errores en la configuracion de los parametros internos de funcionamiento de la instancia de la BD que pudieran ser afectados (y mencionan tambien como ajustarlos correctamente) para que trabajen con soporte para Tecnologia HT
Para muestra un boton.. si buscamos hyperthreading bug+oracle en Google da un flamante resultado de
Results 1 - 10 of about 8,860 for hyperthreading <http://www.google.com//url?sa=X&oi=dict&q=http://www.answers.com/bug%26r
%3D67>bug+<http://www.google.com//url?sa=X&oi=dict&q=http://www.answers.co
m/oracle%26r%3D67>oracle
en donde 0 son links de Oracle directamente...
luego... si buscamos en Oracle directamente...
NO encontramos ningun link que indique que Oracle NO soporta la tecnologia HT de los procs Intel... y que NO recomienda el desabilitarlo para el uso de NINGUNO de sus productos en NINGUNO de los OS's soportados...
Cito textualmente de Oracle:
Ok -- before I start with an answer, I'll ask everyone "please be polite in all followups". Stick to technical issues only. thanks
No bug there -- not at all. In fact, it would be a bug if CPU_COUNT was set differently than what the OS told us to set it to. I suggest taking a look at metalink Note 205089.1, this explains how Oracle takes full advantage of the logical CPUs
Hyper threading (which you can briefly read about here:
http://www.intel.com/technology/hyperthread/http://www.intel.com/techno logy/hyperthread/
http://arstechnica.com/articles/paedia/cpu/hyperthreading.ars/1
) was designed to do exactly what is happening here -- the illusion of multiple CPU's.
So, no -- no bug. But the rest of the article has some issues too.
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:367983 53051561
(sin errores y a mayor velocidad), y 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. amigo.. si gustos no hubieran tu no tendiras un AMD y otra gente un Intel y otra gente Sparcs o PC's basadas en procs de terceros... por suerte hay variedad de gustos, variedad de posibles soluciones y mas importante aun.. que cada quien, tenga la libertad de escoger lo que mas le convenga...
Basta con buscar en el Google, con las palabras "hypetrheading bug", y ya aparece abundante información. si claro.. como el papel... aguanta lo que le pongan...
si se revisa seriamente y en detalle los links si hay algunos bugs de aplicaciones asociadas con librerias que tienen problemas actualmente... me pregunto, si esto sera un problema infranqueable o si efectivamente existe la posibilidad como ya ha pasado cuando hay pulgas, de que se corrijan los errores... como siempre pasa ??? hummmm...
no creo que sea muy dificil de suponer...
Igual es muy interesante hacer otras consultas en google por ej.
Results 1 - 10 of about 68,500 for opteron 64+<http://www.google.com//url?sa=X&oi=dict&q=http://www.answers.com/bugs %26r%3D67>bugs
Results 1 - 10 of about 379,000 for athlon 64+<http://www.google.com//url?sa=X&oi=dict&q=http://www.answers.com/bugs %26r%3D67>bugs
Results 1 - 10 of about 604,000 for amd+<http://www.google.com//url?sa=X&oi=dict&q=http://www.answers.com/bug s%26r%3D67>bugs
Results 1 - 10 of about 63,400 for hyperthreading <http://www.google.com//url?sa=X&oi=dict&q=http://www.answers.com/bug%26r %3D67>bug
Ups... 63,400 Contra 68,500 como la simple cantidad de resultados de una busqueda no es suficiente para demostrar los pro's y contras... sino para informarse de algo...
Saludos, Juan
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCyDVnNwzM1CV+oH4RAnFjAJ484lZjymTPIOla27FDhWC7cWeFCgCfXJx0 yYaOUl8/fgYri0KelPYOE4U= =cwL+ -----END PGP SIGNATURE-----