Prescott 3.2 vs Northwood 3.2 (resultados deducibles…)
-
Volvemos a lo de siempre, aqui al final lo que importa es el precio.
Vaya bien, mal, regular o como sea todo va a depender del precio que tanga.
Es igual que lo de amd-intel, si el XP rinde lo mismo a menos velocidad, pero la realidad es que para obtener el mismo rendimiento tienes que gastarte aproximadamente lo mismo (en cpu), uno sera un P14 a 8 Ghz y el otro un AMD128 intercooler 9200+ corriendo a 200Mhz, pero lo que importa es que los dos te dan 5000 puntos en no se que test y cuentan 200$.
P.D.: Lo del calor no es ningun problema porque Intel ha firmado un acuerdo con nVidia para vender en un mismo paquete micros de 120W y 5800 para que tiren el aire calietne fuera. Una compañia de viajes en globo ya ha ocmprado varios para inflar sus aparatitos:D
-
Conocía ese post, Tassadar, pero es que la arquitectura del Pentium M en sobremesa es, por ahora, una quimera. Además de que posiblemente, como bien dice Pakohuelva, no tengan demasiadas posibilidades de llegar a velocidades suficientemente altas. Puede que para el futuro se consiga pasar la arquitectura del Pentium M a un modelo más actual, para así conseguir llegar a velocidades superiores a 3Ghz y se planteen ponerlo en un pc de sobremesa, pero por ahora no existe. Y mientras tanto tenemos que seguir con nuestros equipos, la mayoría con AMD, los que tengan suficiente dinero con un P4 a 3.2 (que aunque sea menos eficiente, es más rápido, la cuestión es cuanto más rápido, en mi opinión, no lo suficiente).
Quiero pensar que Intel conseguirá enderezar el rumbo, que bajará el calor emitido por ese Prescott, que le pondrá 2 pipelines más cortitos, que lo afinará para que rinda más que el P4. Si no es así, seguiré con mi Athlon hasta que bien entrado el 2005 los AMD64 estén firmes, con su socket 939, con su DDR2, con su BTX, con su SO de 64bits, y con las mejoras que habrá para entonces.
Pero todos sabemos que a Intel todavía le queda un colchón enorme hasta haber perdido suficientes ventas como para que AMD suponga un problema real. Ya veremos que pasa con el tiempo, esperemos que AMD haga las cosas bien y que Intel enderece el rumbo, o por lo menos baje los precios.
-
Tampoco podemos pensar que el problema de Intel es tecnologico y que lanza los micros asi porque no puede de otra forma, los lanza asi porque es el camino que ha decidido apareciendole ahora un pequeño problema de marketing, si dijo que lo del PR de AMD era un "timo" no es plan que lo hagan ellos, pues solo les queda correr.
-
Como bien dicen en overclockers.com (abajo está el link, de recomendada lectura) lo de las 32 etapas no es ni bueno ni malo en sí, es simplemente un principio de diseño tan válido como cualquier otro. El problema es que, al parecer, Intel se ha visto obligada a hacerlo prácticamente a última hora (no iban a ser tantas etapas) porque no ha conseguido el incremento de velocidad (MHz) esperado con el Prescott por el paso a los 9 nm. Así que han intentado recuperar los MHz que se les han quedado por el camino por la vía rápida, es decir, reduciendo el rendimiento MHz a MHz de la CPU. Algo no les ha salido muy bien cuando una reducción en el proceso de fabricación produce un micro que a igual velocidad y menos voltaje disipa mucho más calor que uno equivalente en 0,13 micras.
http://www.overclockers.com/articles940/
Ya se encargarán luego de camuflar la pérdida de rendimiento con nuevas optimizaciones SSE (ya es vergonzoso) y la mayor capacidad de cache L2, lo cual combinado con una de sus eficientes campañas de marketing y publicidad harán del Prescott un superventas como todos sus antecesores… Y no es que sea un mal procesador, pero no va a resultar ser la maravilla que muchos esperaban y que nos intentarán vender.
Y por otro lado, Intel ha decidido ya el abandono y muerte ¿anticipada? del socket 478 sin que se tenga muy claro cual es el motivo... Tanta polémica sobre si los 865 y 875 soportaban o no el Prescott, los fabricantes que se lanzan a revisar sus diseños para hacerlos "Prescott ready" y resulta que lo más potente que va a existir para socket 478 va a seguir siendo el Northwood ya que el Prescott se quedará en 3,4 GHz ¿la vieja jugada para vender más chipsets y placas? Ya sabéis, el que quiera Prescott de verdad, socket LGA775 al canto que de paso necesitará nuevos conectores de las fuentes de alimentación y veremos a ver si DDR2...
http://www.xbitlabs.com/news/cpu/display/20040123103754.html
Salu2
-
Yo no os entiendo algunas veces… vamos a ver, osea que os parece normal o no tan malo que saquen un nuevo micro y sea (si se confirma) un 10% más lento que el anterior??? ¿estais diciendo eso????????????????
Me parece perfectamente normal, ¿porque?, pues porque es Intel, tio, e intel nos tiene acostumbrados a esto y a otras muchas 'lindeces'.
Es normal, y seguro que como te dicen, Intel venderá muchisimos Prescott (más de los Athlon 64 que venderá AMD), aunque por supuesto, yo no seré uno de esos compradores, ni por supuesto también, nadie que se deje llevar por mi consejo.
Un saludo.
-
Vamos a darle un tiempo a Intel. Al principio el p4 no rendia como debiera, pero ahora rinde bastante bien, optimizaciones incluidas. Sacaron el EE para luchar contra el AMD 64. Una cagada porque no se pueden comparar ni en broma. Y segun tambien he leido, las 32 etapas no se les vera el autentico rendimiento hasta que el precott no alcance velocidades por encima de 4Ghz. Vamos a esperar a ver que pasa.
Pero en el temas de las perras, por ahora me decanto por AMD XP o 64, porque Intel sigue siendo mas cara y el rendimiento muy parecido.
-
Y segun tambien he leido, las 32 etapas no se les vera el autentico rendimiento hasta que el precott no alcance velocidades por encima de 4Ghz
El autentico rendimiento? Lo que pasa es que al tener 32 etapas hasta que no alcance 4Ghz no valdra una mierda, esto es lo que pasa… y claro que no se le vera el rendimiento a partir de los 4Ghz, a caso no es lo que ha hecho siempre intel? Tirar de Mhz.... ya que su tecnologia no aprovecha los ciclos, esto es a lo que se deberian centrar y no en Ghz y más Ghz.. claro que las cifras entran muy bien por los ojos a la hora de comprar cuando no entiende :rolleyes:
Habra que ver su rendimiento con DDR2 montada... todo se vera... -
jeje… lo más gracioso de esto útlimo que comentais es que el Prescott solo está previsto que llegue a 4.2ghz XDDDDDDDDDDDDDDDDDDD para ser sustituido por el Tejas XDDDD
-
Dos cosillas:
Primera, ¿no os parece curioso que su rendimiento sea menor solo cuando interviene la grafica?
Segunda, lo de las 32 etapas puede arreglarse atraves de un compilador diseñado especificamente para esto, al menos no penalizaria tanto el trabajar a baja velocidad.
-
Pako, es inferior tambien en la prueba de render del Cinebench donde la gráfica ni pincha ni corta, algo así como un 12% más lento que el Northwood a misma frecuencia
-
No habras un debate de renders con packohuelva :susto: :susto::D
-
A venga vale, que esta en segundo, yo habia seguido viendolo como el mas alto.
De todas formas no queria insinuar que el problema fuera de la grafica si no de los calculos que se hacen cuando juegas y que supongo que seran de FPU basicamente, es decir, que si tiene una FPU todavia peor que la del P4 actual tendremos que tirar de SSE24
-
sacto la de Cinenbench está en segundos, menos es mejor
-
Segunda, lo de las 32 etapas puede arreglarse atraves de un compilador diseñado especificamente para esto, al menos no penalizaria tanto el trabajar a baja velocidad.
Estamos en lo de siempre, hay que programar específicamente para este micro, centrándose en él y como trabaja…...... si no optimizas para Intel, no vale una mierda.
Lo he dicho trillones de veces, si se optimizara para AMD con la mitad del empeño que se optimiza para Intel, las cosas serían muuuuuuuy diferentes.
-
Ya ves, yo me conformaria con que amd pudiera correr los programas sin optimizaciones para intel, con eso ya aumentarian su rendimiento.
-
No hay ningun programador "pofesioná" en este foro? xD Que nos haga un benchmark tipo super pi pero optimizado para AMD y luego lo hacemos correr en ambas plataformas…
-
Hombre, conociendo bien bien la arquitectura interna de los XP… a alguien con un buen nivel de ensamblador no le debería resultar demasiado difícil. Un bucle de una dimensión bastante considerable que basicamente haga operaciones a chapa de la manera más fqavorecedora posible para la plataforma de AMD, quizá haciendo multitud de cálculos de coma flotante y saltos condicionales dificilmente predecibles para la BPU de Intel... bueno, me callo, qune aun meteré la gamba (es que me ha gustado mucho el árticulo de X-bit labs que ha puesto pakohuelva en la rama esa de "Apple miente más que habla":rolleyes: )
1 saludo
-
Lo de programar en ensablador a estas alturas es bastante complicado y si ya hablamos de los Opteron y familia ni os cuento.
No vayais a pensar que los programadores se lo curran para Intel, ni mucho menos, lo que pasa es que los compiladores generan codigo optimizado para estos micros. En casi todos los compiladores viene informacion sobre las optimizaciones para MMX/SSE pero encontrar para 3dnow es francamente complicado y a nivel de procesador, no de instrucciones, la ultima vez que mire no habua ninguno, ni siquiera el gcc que se caracteriza precisamente por generar codigo eficiente.
-
En casi todos los compiladores viene informacion sobre las optimizaciones para MMX/SSE pero encontrar para 3dnow es francamente complicado
Pero tendran alguna mas que esa no? Porque el XP tambien tiene MMX y SSE no?
-
Yo me he bajado el código fuente de un programa tipo superpi llamado pi_css5 y he hecho las siguientes pruebas:
Lo he compilado con las opciones -march=athlon -O3, le he dicho que me calculase 2e6 nº:
josefu@caligula:~/tmp/pi/pi_css5_src$ ./pi_css5 Calculation of PI using FFT and AGM, ver. LG1.1.2-MP1.5.2a.memsave Number of digits of pi to calculate? 2000000 initializing... nfft= 524288 radix= 10000 error_margin= 0.00849935 calculating 2097152 digits of PI... AGM iteration precision= 48: 2.74 sec precision= 80: 2.74 sec precision= 176: 2.75 sec precision= 352: 2.73 sec precision= 688: 2.74 sec precision= 1392: 2.75 sec precision= 2784: 2.74 sec precision= 5584: 2.73 sec precision= 11168: 2.73 sec precision= 22336: 2.72 sec precision= 44688: 2.78 sec precision= 89408: 2.90 sec precision= 178816: 2.73 sec precision= 357648: 2.72 sec precision= 715312: 2.73 sec precision= 1430640: 2.74 sec precision= 2861280: 2.75 sec writing pi2097152.txt... 54.05 sec. (real time) ```Luego lo he vuelto a compilar con _-march=athlon -O2_ y ha hecho esto:josefu@caligula:~/tmp/pi/pi_css5_src$ ./pi_css5_o2
Calculation of PI using FFT and AGM, ver. LG1.1.2-MP1.5.2a.memsave
Number of digits of pi to calculate?
2000000
initializing...
nfft= 524288
radix= 10000
error_margin= 0.00849935
calculating 2097152 digits of PI...
AGM iteration
precision= 48: 2.75 sec
precision= 80: 2.73 sec
precision= 176: 2.74 sec
precision= 352: 2.73 sec
precision= 688: 2.73 sec
precision= 1392: 2.73 sec
precision= 2784: 2.73 sec
precision= 5584: 2.74 sec
precision= 11168: 2.72 sec
precision= 22336: 2.74 sec
precision= 44688: 2.74 sec
precision= 89408: 2.72 sec
precision= 178816: 2.74 sec
precision= 357648: 2.73 sec
precision= 715312: 2.74 sec
precision= 1430640: 2.73 sec
precision= 2861280: 2.75 sec
writing pi2097152.txt...
53.84 sec. (real time)Esto en un t-bred 1700+ sin oc Versión de gcc: 3.3.3 Alguien se anima ha probar con un p4??? Si quereis os subo los binarios, pero es bastante fácil de compilar. Los que tengan windows podreis bajaros el [gcc](http://www.gnu.org/software/gcc/) para compilarlo con las opciones pertinentes para vuestro micro. Lo pongo en la rama de bench superpi xq esto es un poco ot en esta rama?? PD: Alguno de gentoo que controle más esto de las optimizaciones?? yo he puesto lo he visto más o menos (la página man del gcc es demasiado larga…) [editado] Lo he vuelto ha hacer (con el binario compilado con -O2) como root, con la máxima prioridad (nice -20) y con casi todos los servicios detenidos (se me ha quedado el ssh por ahí…) y ha tardado esto:Calculation of PI using FFT and AGM, ver. LG1.1.2-MP1.5.2a.memsave
Number of digits of pi to calculate?
2000000
initializing...
nfft= 524288
radix= 10000
error_margin= 0.00849935
calculating 2097152 digits of PI...
AGM iteration
precision= 48: 2.57 sec
precision= 80: 2.58 sec
precision= 176: 2.57 sec
precision= 352: 2.57 sec
precision= 688: 2.58 sec
precision= 1392: 2.57 sec
precision= 2784: 2.57 sec
precision= 5584: 2.57 sec
precision= 11168: 2.58 sec
precision= 22336: 2.57 sec
precision= 44688: 2.57 sec
precision= 89408: 2.57 sec
precision= 178816: 2.58 sec
precision= 357648: 2.57 sec
precision= 715312: 2.58 sec
precision= 1430640: 2.57 sec
precision= 2861280: 2.58 sec
writing pi2097152.txt...
50.69 sec. (real time)
