Prescott 3.2 vs Northwood 3.2 (resultados deducibles…)
-
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. -
Publicado originalmente por larcos
**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:**
Ahora me tengo que ir a estudiar toda la noche, a ver si alguien puede compilarse el binario para windows y así lo probais todos.
Si nadie puede, a ver si mañana lo hago yo, pero ahora no puedo. -
Un amigo mio me dijo una vez que era perfectamente posible hacer un programa como el que comentáis, que sea intensivo de coma flotante, y que putee el largo pipeline del P4 (haciendo fallos en las predicciones etc), y que favoreciera en cierto modo la arquitectura del Athlon. El resultado sería que en un XP 1700+ se ejecutaría de 5 a 10 veces más rapido que en un P4 3,2 ghz.
Todo esto, claro, sin ir a muerte a por el pentium 4, simplemente un programa con ciertas características, y que al programarlo no tengamos en cuenta las peculiaridades de la arquitectura del P4.
Si nos ponemos a joder a posta el pentium 4, ese 5-10 se convertiría en 20-100, pero claro, eso ya sería trampa, jeje
-
El problema es que las SSE son un invento de intel y normalmente van mas rapido en sus micros.
Lo de hacer un programa que hiciese eso no tiene porque ser muy complicado, al menos a alto nivel, el problema es que a alto nivel no notariamos demasiada mejora.
El problema esta en que si tu haces un programa muy optimizado pero el compilador te crea codigo generico no ganas nada. Si lo haces al contrario y creas un algoritmo generico y usas un compilador optimizado todo el rendimiento dependera de este. Lo ideal es utilizar un programa especificamente diseñado para una plataforma y compilarlo con un compilador especifico para la misma.
Sobre los test o se optimizan los dos o no se optimiza ninguno, en casos diferentes los rendimientos no serviran de nada.
-
hace poco tuve q hacer un programa q calculaba unas rotaciones de coordenadas, lo hice en C, en ensamblador y en MMX.
no eran más q unas sumas y multiplicaciones
El código se compilaba con builder, pero sin ningún tipo de optimización.
pues nada más decir, q la ejecución en un P4 era pa-te-ti-ca
-
Publicado originalmente por josefu
**Alguien se anima ha probar con un p4???
**
No se que GCC bajarme.. Si me pudieseis poner un link os lo agradeceria
Un saludo
