¿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.com/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/technology/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:367983530...
(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/bugs%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
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.com/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/technology/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:367983530...
(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/bugs%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
Hola Amigo.... nuevamente... ese link No es oficial de Oracle... y en el Site tanto de Oracle como de Metalink NO tienen referencias oficiales al respecto... por lo que sites de 3eros NO pueden, NI son voceros oficiales de Oracle... Si revisas el Link de Ask Tom que SI es de Oracle Corp. Dice... 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 Nuevamente aca esta el Link de ORACLE http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:367983530... Por lo que es una referencia VALIDA de un punto de Vista de Oracle,,, NO de terceros que dicen, que Oracle dice...
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
estos NO son Links de Oracle,,, No son opiniones oficiales de Oracle, por lo que NO pueden ser tomadas como referencias de Oracle en lo absoluto, si fueran de Oracle, estarian en el Site de Oracle y MUY claro diria Oracle, NO soportamos el Feature de HT en bla bla bla... y esto NO esta expuesto NI expresado NI en Oracle, NI en Metalink...
Y el otro bug considerado critico del hyperthreading: http://www.linuxsecurity.com/content/view/119124/65/
No. Although the specific exploit developed by Mr. Percival is specific to HT, we believe that these types of attacks can be demonstrated across most all processors whose established, high-level, processor architectures date back to the mainframe days. As such Intel is working with the software industry, including Microsoft, RSA, OpenSSL, Red Hat and SuSE, to define and refine enhancements to the cryptographic software implementations that we believe will mitigate this, and many other potential software timing vulnerabilities. We expect that the software industry will evaluate and address this within their normal, well established, processes and timelines
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.
seria cierto de ser el caso de que Intel fuera una plataforma cerrada, pero no lo ha sido, no lo es, y no lo sera... Puedes correr Linux, FreeBSD, Novell, OS2, y otro chorro de OS's... Asi que es una plataforma 100% abierta... Si ves en las politicas de Intel, NO se comprara hablando mal de los productos de 3eros, aunque podria hacerlo, no ha utilizado el musculo financiero tampoco para terminar en forma absoluta la competencia... todo lo contrario, si preguntas a algun funcionario oficial de Intel NO te va a hablar mal de productos de 3eros... lo que te van a hacer es hablar de las bondades y beneficios del producto propio... y si aun asi, no te parece, pues genial... Intel no recurre a artificios mercadotecnicos para la venta.. no lo necesita...
Para mi hay muchas cosas en comun entre microsoft e intel, empezando con el FUD,
Puntos de vista, no los comparto... solo los respeto...
continuando con el vaporware,
esto seria como decir hey... tengo un ATHLON64 y es 100% a 64 Bits y no solo registros de memoria a 64 bits... je j eje aca es muy curioso.. ya que NUNCA he visto un solo link o informacion proveniente de Intel hablando mal del producto de alquien mas... incluso, aunque asi pudiera hacerlo... igual que con lo de los links de infor del robo de demandas, si tienes links que en el Site de Intel, te hablen mal de producto de Terceros, porfavor, compartelos... Si en el WWW hay muuucha gente que ponen y se especializan en decir cosas en nombre de terceros... pero, si son serios, creo que harian referencia a pruebas REALES, y no chismes de correo... chismes de pasillo... leyendas urbanas....
y terminando en la producción de productos basados en patentes robadas, y en ambos casos a Digital (entre otras),
No veo que ni en Digital ni en otros esten en procesos Legales de demandas por Robo de Patentes como lo dices... si tienes los links ESO SI, de las fuentes oficiales y no de terceros que dicen algo en representacion de.... me encantaria desencantarme de por lo que porfa.. compartelas... Si de hecho buscas en Google NO encuentras referencias oficiales al respecto... si las tienes porfavor, compartelas para que asi todos leamos de fuentes oficiales, y no de "Mitos urbanos" informacion al respecto de algo tan serio.
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.
Creo que aca estamos como en el Caso de SCO que pega gritos al clielo de que IBM le ha robado codigo y pues... hasta donde recuerdo... eso sigue en nada... Creo que si hay una documentacion clara de Robo de Patentes o de Espionaje Industrial, especialmente en Gringolandia, NO esperaria ninguna compannia de hecho lo que encontre fue: Noticia : El socio de Intel demanda a Intel (y a AMD) Esta semana se ha acusado a Intel y AMD de incumplimiento de patente, uniéndose así a VIA en la lista de fabricantes de chips que han utilizado tecnología de Acacia Research. El papel de Intel es particularmente interesante: ya ha sido demandado por una filial de Acacia y trabaja con otra filial fabricando chips. La filial que acaba de demandar a Intel lo hace por un tema de patentes de técnicas de coherencia de caché, que pertenecen a la empresa Computer Cache Coherence Corp. Acacia demandó a VIA en diciembre de 2004, y este mes ha introducido a Intel y AMD en la lista de esa misma demanda. Las tres empresas venden componentes que incorporan tecnología que pertenece a Acacia, dice ésta. Sincronizando la memoria principal y la caché, la tecnología permite que las diferentes memorias se comuniquen y sincronicen entre ellas, permitiendo a los periféricos trabajar más rápidamente, aduce Acacia; a lo que Intel responde que la demanda no ha lugar. Fuente: <http://www.theregister.co.uk/2005/05/05/intel_amd_sued/>theregister O sea.. la demanda fue tanto para uno como para otro.... sera que no hay blancos corderitos en la industria....
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.
si muy cierto lo del bug del Pentium al inicio aca esta la repuesta de Intel.. trabajar en solucionar el problema... no ocultarlo, ni tratar de engannarlo mediante publicidad engannosa... http://support.intel.com/support/processors/pentium/ppiie/
Como tu dices, alguna solución debe tener, pero mientras tanto, todos los micros con el bug HT, a alguien se los deben meter,
no creo.. hay gente que saben ver las ventajas que ofrece esta entre cualquiera de las otras tecnologias adicionales que ofrece Intel EM64T, SSE3, XD y asi muchas otras mas... Es facil ver el indice de RMA que hay por fabricante entre los integradores... y darse cuenta, cual es el producto que mas devuelven y cual no...
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.
Si sabes en USA y el Europa la falsa publicidad es seriamente Penada por ley... y sin embargo, no veo a nadie haciendose millonario a costa de las mentiras que dice Intel de sus productos... y por la falsa publicidad o publicidad engannosa de poner nombres de modelos para confundir al comprador incauto y falto de conocimiento que asuma que por el nombre del procesador, sea la velocidad del mismo... o que EM64T sean 64 Bits en el 100% de la arquitectura como otros fabricantes si quieren dar a entender, Creo que es sano que exista algun grado de competencia para Intel, como lo podria ser para algunos AMD, Transmeta, Motorola, etc... ya que la competencia genera evolucion o extincion del mas debil... Asi que viva la competencia, lastima que no es mas fuerte aun, como para que todos nos veamos beneficiados... Un saludo cordial... Y en serio... que dicha que existe la discusion sana de algo... ya que asi, todos aprendemos mas los unos de los otros, Puede que no este de acuerdo con lo que dices, pero luchare hasta la muerte para que tengas el derecho de decirlo. -------------------------------------------------------------------------- Voltaire (si no me equivoco).
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. En cuanto al juicio de Digital contra intel por el robo de patentes, aquí van los links (no me vengas conque no son del sitio oficial de Digital, o el ministerio de justicia de USA): http://www.courttv.com/archive/legaldocs/cyberlaw/digital.html http://earthlink.com.com/2100-1023_3-279719.html http://www.tcd.ie/Economics/staff/mariuzzf/Homepage/IndustrialEconomics/Grou... http://www.courttv.com/archive/legaldocs/cyberlaw/intel.html http://www.windowsitpro.com/Article/ArticleID/17416/17416.html?Ad=1 http://www.ipww.com/texts/0405/intergraph.html Un link interesante, donde explica porque AMD y los Power PC no necesitan HT (Why hyperthread? Why never hyperthread?): http://www.1src.com/forums/archive/index.php/t-84234.html Hyperthread was a theory test, can a dual processor share the same process queue and work efficiently, work efficiently being the proper cornerstone. It is the entire design behind dual core coming later this year. AMD didn't bother with hyperthread, Intel proved it works so AMD didn't need to. This is also why you won't find Hyperthread Macs. It also solves an Intel only problem. Intel in its "infinite wisdom" builders larger and larger process queues, but this looses effiency when the processor multi-tasks. You will find Intel designs talking about Hyperthread achieving 10-15% higher performance. Well, then a hyperthread G4 or G5 or Athlon would get 10-15% performance increase too? nope. With the smaller process queues of the Athlon it is able to switch processes faster than the Intel, it is that difference between the Athlon and the Intel chips that hyperthread makes up for.... but only if you are running two high performance tasks! ooooo cue the dramatic music. A power-pc design being RISC would gain almost nothing in hyperthread, but the microcode to handle logical processor splits would most assuredly slow it down. So no hyperthread Macs. AMD FX and Opteron lines finally get up to the processor queues that might gain something from hyperthread, but they are trying desperately to beat Intel to the dual core and skip hyperthread all-together. Thus no hyperthread on AMD. 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. Eduardo J. Vega A wrote:
Hola Amigo.... nuevamente... ese link No es oficial de Oracle... y
en el Site tanto de Oracle como de Metalink NO tienen referencias oficiales al respecto... por lo que sites de 3eros NO pueden, NI son voceros oficiales de Oracle...
Si revisas el Link de Ask Tom que SI es de Oracle Corp. Dice...
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
Nuevamente aca esta el Link de ORACLE http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:367983530...
Por lo que es una referencia VALIDA de un punto de Vista de Oracle,,, NO de terceros que dicen, que Oracle dice...
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
estos NO son Links de Oracle,,, No son opiniones oficiales de Oracle, por lo que NO pueden ser tomadas como referencias de Oracle en lo absoluto, si fueran de Oracle, estarian en el Site de Oracle y MUY claro diria Oracle, NO soportamos el Feature de HT en bla bla bla...
y esto NO esta expuesto NI expresado NI en Oracle, NI en Metalink...
Y el otro bug considerado critico del hyperthreading: http://www.linuxsecurity.com/content/view/119124/65/
No. Although the specific exploit developed by Mr. Percival is specific to HT, we believe that these types of attacks can be demonstrated across most all processors whose established, high-level, processor architectures date back to the mainframe days. As such Intel is working with the software industry, including Microsoft, RSA, OpenSSL, Red Hat and SuSE, to define and refine enhancements to the cryptographic software implementations that we believe will mitigate this, and many other potential software timing vulnerabilities. We expect that the software industry will evaluate and address this within their normal, well established, processes and timelines
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.
seria cierto de ser el caso de que Intel fuera una plataforma cerrada, pero no lo ha sido, no lo es, y no lo sera...
Puedes correr Linux, FreeBSD, Novell, OS2, y otro chorro de OS's...
Asi que es una plataforma 100% abierta...
Si ves en las politicas de Intel, NO se comprara hablando mal de los productos de 3eros, aunque podria hacerlo, no ha utilizado el musculo financiero tampoco para terminar en forma absoluta la competencia...
todo lo contrario, si preguntas a algun funcionario oficial de Intel NO te va a hablar mal de productos de 3eros... lo que te van a hacer es hablar de las bondades y beneficios del producto propio... y si aun asi, no te parece, pues genial...
Intel no recurre a artificios mercadotecnicos para la venta.. no lo necesita...
Para mi hay muchas cosas en comun entre microsoft e intel, empezando con el FUD,
Puntos de vista, no los comparto... solo los respeto...
continuando con el vaporware,
esto seria como decir hey... tengo un ATHLON64 y es 100% a 64 Bits y no solo registros de memoria a 64 bits... je j eje
aca es muy curioso.. ya que NUNCA he visto un solo link o informacion proveniente de Intel hablando mal del producto de alquien mas... incluso, aunque asi pudiera hacerlo...
igual que con lo de los links de infor del robo de demandas, si tienes links que en el Site de Intel, te hablen mal de producto de Terceros, porfavor, compartelos...
Si en el WWW hay muuucha gente que ponen y se especializan en decir cosas en nombre de terceros...
pero, si son serios, creo que harian referencia a pruebas REALES, y no chismes de correo... chismes de pasillo... leyendas urbanas....
y terminando en la producción de productos basados en patentes robadas, y en ambos casos a Digital (entre otras),
No veo que ni en Digital ni en otros esten en procesos Legales de demandas por Robo de Patentes como lo dices...
si tienes los links ESO SI, de las fuentes oficiales y no de terceros que dicen algo en representacion de....
me encantaria desencantarme de por lo que porfa.. compartelas...
Si de hecho buscas en Google NO encuentras referencias oficiales al respecto... si las tienes porfavor, compartelas para que asi todos leamos de fuentes oficiales, y no de "Mitos urbanos" informacion al respecto de algo tan serio.
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.
Creo que aca estamos como en el Caso de SCO que pega gritos al clielo de que IBM le ha robado codigo y pues... hasta donde recuerdo... eso sigue en nada...
Creo que si hay una documentacion clara de Robo de Patentes o de Espionaje Industrial, especialmente en Gringolandia, NO esperaria ninguna compannia
de hecho lo que encontre fue:
Noticia : El socio de Intel demanda a Intel (y a AMD) Esta semana se ha acusado a Intel y AMD de incumplimiento de patente, uniéndose así a VIA en la lista de fabricantes de chips que han utilizado tecnología de Acacia Research. El papel de Intel es particularmente interesante: ya ha sido demandado por una filial de Acacia y trabaja con otra filial fabricando chips. La filial que acaba de demandar a Intel lo hace por un tema de patentes de técnicas de coherencia de caché, que pertenecen a la empresa Computer Cache Coherence Corp. Acacia demandó a VIA en diciembre de 2004, y este mes ha introducido a Intel y AMD en la lista de esa misma demanda. Las tres empresas venden componentes que incorporan tecnología que pertenece a Acacia, dice ésta. “Sincronizando la memoria principal y la caché, la tecnología permite que las diferentes memorias se comuniquen y sincronicen entre ellas, permitiendo a los periféricos trabajar más rápidamente”, aduce Acacia; a lo que Intel responde que la demanda no ha lugar. Fuente: <http://www.theregister.co.uk/2005/05/05/intel_amd_sued/>theregister
O sea.. la demanda fue tanto para uno como para otro.... sera que no hay blancos corderitos en la industria....
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.
si muy cierto lo del bug del Pentium al inicio
aca esta la repuesta de Intel.. trabajar en solucionar el problema... no ocultarlo, ni tratar de engannarlo mediante publicidad engannosa...
http://support.intel.com/support/processors/pentium/ppiie/
Como tu dices, alguna solución debe tener, pero mientras tanto, todos los micros con el bug HT, a alguien se los deben meter,
no creo.. hay gente que saben ver las ventajas que ofrece esta entre cualquiera de las otras tecnologias adicionales que ofrece Intel EM64T, SSE3, XD y asi muchas otras mas...
Es facil ver el indice de RMA que hay por fabricante entre los integradores... y darse cuenta, cual es el producto que mas devuelven y cual no...
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.
Si sabes en USA y el Europa la falsa publicidad es seriamente Penada por ley... y sin embargo, no veo a nadie haciendose millonario a costa de las mentiras que dice Intel de sus productos... y por la falsa publicidad o publicidad engannosa de poner nombres de modelos para confundir al comprador incauto y falto de conocimiento que asuma que por el nombre del procesador, sea la velocidad del mismo...
o que EM64T sean 64 Bits en el 100% de la arquitectura como otros fabricantes si quieren dar a entender,
Creo que es sano que exista algun grado de competencia para Intel, como lo podria ser para algunos AMD, Transmeta, Motorola, etc... ya que la competencia genera evolucion o extincion del mas debil...
Asi que viva la competencia, lastima que no es mas fuerte aun, como para que todos nos veamos beneficiados...
Un saludo cordial...
Y en serio... que dicha que existe la discusion sana de algo... ya que asi, todos aprendemos mas los unos de los otros,
Puede que no este de acuerdo con lo que dices, pero luchare hasta la muerte para que tengas el derecho de decirlo. --------------------------------------------------------------------------
Voltaire (si no me equivoco).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-06-23 a las 23:26 -0300, Juan Erbes escribió:
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.
Er... la "discusión" (en el sentido británico del término) es muy interesante, pero os agradecería que al contestar recortáseis el texto del contertulio a quien contestais. Tu correo anterior, Juan, tiene 16 kilobites, y la mitad más o menos corresponden a texto quoteado al continuación del tuyo, redundante, ya que lo hemos recibido todos anteriormente. Para eso sirve el soporte de hilado en los editores de correo ;-) ¿Ok? :-) - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCu/CAtTMYHG2NR9URAigTAJ9L4UeGhujYZ38oBq5tktWTcPzx7ACgk5h7 NEXTXdKL8w13H4oaZCpO8DE= =gLe+ -----END PGP SIGNATURE-----
El Viernes, 24 de Junio de 2005 01:30, Juan Erbes escribió: 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
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
-- "Hay dos productos que han salido de Berkeley: el LSD y el UNIX. No creemos que sea una coincidencia." Jeremy S. Anderson "Solo se que no se nada" Socrates.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-06-24 a las 08:01 +0200, jteraman@gmail.com escribió: Otro. Lo mismo, recorta el texto quoteado del correo anterior, porfa: tu emilio tiene 13 kilobytes, de los que 2 son tuyos, y unos 11 de Juan, que ya tenemos todos. Es repetir información redundante, y larga. Recuerda que muchos seguimos trabajando con modems. Y yo al menos, no soy accionista de telefónica. :-P
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%).
Yo reconozco que el AMD está muy bien, pero no me gusta porque se calienta mucho. No se si pasa con los actuales, pero hace un par de años se quemaban si no había disipador o no estaba a la altura, dependían del sistema operativo para pararse. Eso al intel no le pasaba. Y no hace falta que me lo diga nadie, yo he tenido mi P-IV con el ventilador parado por error... No tengo más que mirar los PCs de mis amigos con los turboventiladores (plural) en la caja :-P No se si eso sigue siendo el caso, pero esa mala impresión sigo teniendola, y no me gusta, no me fio. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCu/MDtTMYHG2NR9URAim5AJ4peF1a1vAWfEDl8kFqdTTheEBj/wCdF8u7 m6poHQ1plqKjKBVGi3MrTjs= =SPTm -----END PGP SIGNATURE-----
Carlos E. R. escribió:
No tengo más que mirar los PCs de mis amigos con los turboventiladores (plural) en la caja :-P No se si eso sigue siendo el caso, pero esa mala impresión sigo teniendola, y no me gusta, no me fio.
A ver. Yo tengo los siguientes cacharros: AMD Athlon 3200 XP FSB 400 PIV 2.66 FSB 533 AMD Athlon 2000 XP Mobile -un portátil- AMD Athlon 2800 XP AMD K6/2 500 Y recientemente he armado un PIV 3.0 Ghz Presscott -creo- de estos con hypertrheading. Bien, te comentaré Que los antigus pentium como el que yo tengo... son fríos fríos, en comparación con los athlon -bueno el mobile raramente se pone a más de 55ºC. Pero los nuevos Pentium IV que hay que son más calientes todavía -y parecía imposible que los Athlon XP- y hay que ponerles turboreactores como a los athlon. Personalmente si yo pudiera comprar ahora uno de los antiguos Pentium como el que tengo lo preferiría sobre uno de los nuevos o sobre un athlon... pero viendo que todavía tienen más problemas de calor los últimos pentium y teniendo en cuenta que se dice que tienen problemas con el hyperthreading con determinadas aplicaciones sigo prefiriendo un Athlon XP. De cualquier forma ahora están los Sempron que si se mira la tabla de disipación de calor son más fresquitos que los Athlon -en concreto el Sempron 3000 FSB333 está bien. De los AMD64 no probé ninguno... pero dicen que también se achicharran fácil de todas formas la mejor manera de comprobarlo es mirando la potencia disipada en las especificaciones técnicas.
Y recientemente he armado un PIV 3.0 Ghz Presscott -creo- de estos con hypertrheading.
Bien, te comentaré
Que los antigus pentium como el que yo tengo... son fríos fríos, en comparación con los athlon -bueno el mobile raramente se pone a más de 55ºC.
Pero los nuevos Pentium IV que hay que son más calientes todavía -y parecía imposible que los Athlon XP- y hay que ponerles turboreactores como a los athlon.
aca seria muy interesante preguntarte si estas o no usando un Chassis TAC 1.1, ya que, con solo usar este chassis (que es el que Intel mismo te recomienda) NO tienens necesidad de estar incluyendo ventiladores adicionales, que podrian eventualmente estar provocando presurizacion interna y reflujos de aire caliente en el Chassis. www.intel.com/gp/chassis ahi hay listas de algunos de los chassis Validados TAC 1.1 por Intel, y veras, que Intel mismo te indica, que el Chassis TAC 1.1 es requisito para Procesadores P4 sea serie 5xx o de los P4 viejitos (basados en frecuencia) ya con velocidades de 3 o > Ghz...
Personalmente si yo pudiera comprar ahora uno de los antiguos Pentium como el que tengo lo preferiría sobre uno de los nuevos
creo que si tuvieras un chassis adecuado ,sacarias mas ventaja con el cambio del FSB de 533 a 800 Mhz, con el 1 MB de Cache en L2, en vez de 512 Kb de Cache en L2, con las instrucciones SSE3 y mejoramiento en el Sync de Los Trheads eso entre otras cosas tales como soporte para Memoria DDR2, SATA Ver 1, u otras mas que pudieran estar disponibles dependiendo del modelo de tarjeta madre que uses... y como te dije... si tienes problemas de sobrecalentamiento, Usa el Chassis Adecuado (www.intel.com y la referencia Standard de la industria www.formfactor.org) ahi encuentras que es lo que tienes que buscar para que evites problemas de sobrecalentamiento (al menos en el lado de Intel) desconozco que han hecho los amigos de AMD para evitar el achicharramiento que tenian antes los procs pero... hasta donde tengo entendido eso es ya asunto del pasado, ya no hechan humo tan pateticamente como se mostraba incluso en un video de Toms Hardware que estaba disponible hace algun buen tiempo en ese mismo site.
o sobre un athlon... pero viendo que todavía tienen más problemas de calor los últimos pentium y teniendo en cuenta que se dice que tienen problemas con el hyperthreading con determinadas aplicaciones sigo prefiriendo un Athlon XP.
--ed He who fights with monsters might take care lest he thereby become a monster. And if you gaze for long into an abyss, the abyss gazes also into you .Friedrich Nietzsche, Beyond Good and Evil, Aphorism 146
Hola
Yo reconozco que el AMD está muy bien, pero no me gusta porque se calienta mucho. No se si pasa con los actuales, pero hace un par de años se quemaban si no había disipador o no estaba a la altura, dependían del sistema operativo para pararse. Eso al intel no le pasaba.
Hace unas 2 semana me trajeron para repar una pc con un Duron de 1GHz, no le funcionaba con XP la grabadora. Luego de intentar un par de cosas desarmo la caja para controlar los cables y oh sorpresa el ventilador estaba parado y sus etiquetas negras, quemadas por el calor. No se cuanto estuvo funcionando así pero por lo trabado que estaba supongo que muchos días. Un poco de aceite lo solucionó, almenos por el momento. Yo creia que tendría que haberse quemado, pero no paso. Como castigo le instale Linux y ahora hay 3 nuevos usuarios.
Y no hace falta que me lo diga nadie, yo he tenido mi P-IV con el ventilador parado por error...
No tengo más que mirar los PCs de mis amigos con los turboventiladores (plural) en la caja :-P No se si eso sigue siendo el caso, pero esa mala impresión sigo teniendola, y no me gusta, no me fio.
Por cierto no yo tengo un Athlon y no lo dejaría funcionar sin su ventilador. Espero que pronto se pongan las pilas los desarrolladores y bajen el consumo de energía de los PC. Alfredo
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-06-26 a las 21:51 -0300, Alfredo Jesús Delaiti Iannelli escribió:
Luego de intentar un par de cosas desarmo la caja para controlar los cables y oh sorpresa el ventilador estaba parado y sus etiquetas negras, quemadas por el calor.
Duro el durón, ¿eh? :-p Tendrían que tener alarma de ventilador estas cosas... si es que además son sencillas, es por ahorrar unos centimos.
Por cierto no yo tengo un Athlon y no lo dejaría funcionar sin su ventilador. Espero que pronto se pongan las pilas los desarrolladores y bajen el consumo de energía de los PC.
Dudoso. Aumentar la frecuencia de reloj trae consigo disparar el consumo, eso es impepinable. Y como se supone que el mercado demanda más potencia de calculo, pues la inmediata es aumentar la frecuencia. Lo que si que pueden hacer es ajustar dinámicamente la frecuencia de la cpu, según necesidades del sistema, y eso en un equipo de sobremesa hace mucho. La CPU en mi equipo está la mayor parte del tiempo al 5%... Si no me equivoco, el transmeta de la empresa en la que trabajó Linus T. hace eso. Una alternativa más seria sería los procesadores divididos, cuatro CPU en un mismo encapsulado, trabajando en paralelo. Si el sistema esta al ralentí, podría parar 3 cpus y bajar la frecuencia. Se supone que con más procesadores, es innecesaria tanta velocidad de reloj. Otra alternativa de aumento de velocidad efectiva es aumentar la velocidad de la memoria, no de la cpu. En el mio, el bus de memoria va a 100Mhz, la cpu a 1800... la cpu podría hacer nosecuantos ciclos por cada lectura/escritura. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCv+XjtTMYHG2NR9URAr0XAJ9iaXYYOyvRXiGDjMJORagHuz6/mgCdGkSL CVzYE881FrZDzwjuxpvYzh8= =ATZ7 -----END PGP SIGNATURE-----
-----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-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-07-03 a las 15:58 -0300, Juan Erbes escribió:
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
Juan, por favor, tu correo tiene 14 kilobytes, de los que 13 corresponden a la copia integra del correo de jteraman. Tienes que preocuparte de cortar esas copias inutiles y más en correos tan largos. Piensa que no todo el mundo tiene banda ancha. :-( Los que quieran ver a que estás respondiendo, no tienen más que ver el correo original, que todos tenemos archivado y podemos leer con una tecla o dos: para algo sirven los hilos. Y los que no lo tengan, es que el hilo no les interesa. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCzIZYtTMYHG2NR9URAoF9AJwJw+4ZN+aDPQAvg8dNVXWJnqJFOwCffC4D 6eG84DgCrwn9t9kupx10mno= =T9w5 -----END PGP SIGNATURE-----
participants (6)
-
Alfredo Jesús Delaiti Iannelli -
Carlos E. R. -
csalinux -
Eduardo J. Vega A -
jteraman＠gmail.com -
Juan Erbes