Prescott 3.2 vs Northwood 3.2 (resultados deducibles…)
-
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) -
A ver esos Pentiummms que sacan
Qué diferencia hay entre -O3 y -02? -
pa no marear la perdiz, y si lo pones en otro post tipo SUPER_PI como el de krampak?
PD: krampak, cada vez q recuerdo la peli d dnd viene eso… jajaja:risitas: :risitas: :risitas:
-
Publicado originalmente por krampak
Aqui ya esta bien… estamos hablando de rendimiento de microprocesadores. A ver esos Pentiummms que sacan
Qué diferencia hay entre -O3 y -02?Según la página man de gcc:
-O2 Optimize even more. GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff. The compiler does not perform loop unrolling or function inlin- ing when you specify -O2\. As compared to -O, this option increases both compilation time and the performance of the generated code. -O2 turns on all optimization flags specified by -O. It also turns on the following optimization flags: -fforce-mem -foptimize-sibling-calls -fstrength-reduce -fcse-fol- low-jumps -fcse-skip-blocks -frerun-cse-after-loop -frerun-loop-opt -fgcse -fgcse-lm -fgcse-sm -fdelete-null-pointer-checks -fexpensive-optimizations -fregmove -fsched- ule-insns -fschedule-insns2 -fsched-interblock -fsched-spec -fcaller-saves -fpeephole2 -freorder-blocks -freorder-functions -fstrict-aliasing -falign-functions -falign-jumps -falign-loops -falign-labels Please note the warning under -fgcse about invoking -O2 on programs that use computed gotos. -O3 Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions and -frename-registers options. ```Según parece, en teoría, O3 optimiza más de que O2, pero en la práctica no es así. Los de gentoo, hablad, que yo soy un pobre debianero con los paquetes precompilados y no tengo ni idea.
