AMD Clawhammer Vs Intel Pentium 4 XEon e Itanium
-
Vamos a ver. Pakohuelva, yo no digo que tu te inventes las cosas, pero yo tampoco me invento nada, todo mi anterior post giraba en torno al tema de que el rendimiento del P4 en fpu pura es simplemente patético, y eso es lo que intentaba demostrar, otra cosa es que en las aplicaciones del dia a dia la cosa sea así, ya que la mayoría del software actual tiene soporte para SSE2 (si no, muy chungo lo tendría el P4)
Respecto a lo de las reglas de 3, quizás no sean completamente exactas, que no lo son, por tema de buses, memorias, etc, pero te invito a que en el sandra, por ser el programa que he hablado antes, testees un athlon a 700 mhz y otro a 1400, y verás como el 1400 saca matemáticamente el doble (con un error del 3-4%). Un micro a 1400 mhz hará el doble de trabajo que uno a 700, otra cosa es que después en la vida real el rendimiento sea el doble, que no lo será por los factores que ya he comentado.
En el caso de que las reglas de 3 fallasen, darían las mismas imprecisiones para el p4 que para el hammer, así que quizas mis cálculos no son tan 'de colegio'.Me parece muy curioso el modo que tienes de calcular el rendimiento de los procesadores, pero teniendo en cuenta que la propia AMD has establecido el rendimiento del Hammer en 3400 PR y dado que podemos aproximarlo a un P4 a 3,4 Ghz, siendo realistas el rendimiento estaria mas bien por ahi y no por mas del doble
En ningun momento he dicho que el rendimiento de un hammer a 2 ghz sea similar al de un p4 a 6, 7 o 10 ghz. te ha parecido que he dicho eso? si es asi, relee mi post porque te habrás perdido en algun sitio. Repito que de lo que hablo es del rendimiento del P4 en FPU pura, no del 'rendimiento de p4'.
Que pones en tela de juicio ese 40% de aumento al pasar de 32 a 64 bits?, me parece muy bien, si ni los que han diseñado el micro saben cual será la mejora, yo mucho menos.
Que me dices que no te crees que incluso a 32 bits un Hammer a 1400 mhz rinda como un Athlon 2200+, y por tanto un hammer a 2 gigas como un Athlon a 2600 reales?, perfecto, porque los unicos datos que tenemos es que un hammer a 1400 mhz puntúa igual en el 3Dmark que un Athlon 2200+ (1800 mhz), nada mas.
Pero vamos, lo que si esta claro, y lo puedes comprobar cuando tu quieras, es que en FPU sin optimización un Athlon a 2 ghz de los de ahora (2400+), da aproximadamente 2772 MFLOPS, y para igualar esta marca necesitamos un P4 a 5,3 ghz. (Y aquí en ningun momento hablo del hammer, que aún no está en la calle)
Los Athlon a 2 gigas existen, no hace falta ninguna regla de 3, y bueno, si miras la puntuación de un Pentium 4 a 3 gigas por ejemplo, y la comparas con la de un p4 a 2 gigas, te dará un 50% más casi exactamente (las reglas de 3 no fallan tanto como dices), así que por la 'regla de 3 de colegio' puedes calcular cuanto da un todavía inexistente pentium 4 a 5,3 ghz.
Claro que todo esto con la versión del sandra que yo tengo ahora mismo, ya que en la última 'curiosamente' y como ya nos tiene acostumbrados el sandra en cada versón, las puntuaciones de los pentium 4 han subido un buen porcentaje, y la de los Athlon siguen iguales, así que ese 5,4 gigas con el nuevo sandra se podría quedar a lo mejor en 4 o 4,5.
De todas formas, nos números exactos no es lo que yo pretendía, sino ver que la FPU del p4 es malísima, y que eso de 10 gigas para igualar un hammer a 2 no es tan descabellado, y que si no son 10, 6 o 7 seguro que si.
Yo en ningun momento intento desprestigiar a nadie ni poner en duda los conocimientos de nadie, y pakohuelva es alguien que controla mucho de todo esto, pero vamos, no me vengas con que ' Discutir por cosas que no existen me parece una tontería pero imagino que sabras que la regla de 3 vale para calculos lineales y no exponenciales, logaritmicos y de mas….', porque yo no hablo por hablar nunca, y todo lo que posteo por aquí lo hago con conocimiento de causa, otra cosa es que tu me hayas malentendido. Y por otra parte, no creo que el rendimiento de los procesadores sea exponencial o logarítmico.
-
Hola!
He estado leyendo este post y aparte de acabar con un lio tremendo con los nombres de los nuevos procesadores, y debido sin duda a mi tremenda ignorancia, me he enterado de muy poco
Pero si que me ha llamado mucho la atencion los 3 post larguisimos defender una comparacion tan extraña como curiosa entre un Hammer a 2 Ghz y P4 a 10.
Dices:
Así, un Hammer a 2 ghz daria (funcionando en modo 32 bits) 3562 MFLOPS, frente a 5200 de un P4 a 10 ghz
Que alguien me explique esto, porque que yo sepa, 5200 es muy superior a 3562 y eso sin contar con que al P4 le has quitado las instrucciones iSSE2, cosa que comentare luego.
Luego para explicar esta incoherencia, dices:
no creo que sea muy descabellado pensar que al pasar de 32 a 64 bits se obtendrá un aumento de rendimiento de un 40% en el FPU una vez los programas se hagan especificamente para x86-64, con lo cual esos 3562 MFLOPS se convertirían en 4986 MFLOPS, los cuales no andan muy lejos de los 5200 del un P4 a 10 Ghz que hemos calculado.
Que alguien me lo explique de nuevo, porque 4986, sigue siendo menor que 5200 y para colmo para conseguir ese numero en el Hammer, dices que los programas tienes que estar optimizados para el.
Y entonces por tu misma linea de razonamiento, si optimizas para el hammer, ¿porque no aplicas tb las optimizaciones iSSE2 del P4?. Yo mismo te lo dire: porque la puntuacion de este subiria mas de un 50%, doblaria totalmente la del Hammer y si hasta ahora tu razonamiento no tiene ni pies ni cabeza, entonces ya acabaria tirado por los suelos.
Vamos, que sinceramente no se que es lo que pretendes demostrar, no entiendo porque repites una y otra vez lo del rendimiento penoso del P4 sin iSSE2 y para hacer tus calculos se lo quitas, ¿porque se lo quitas?. Si estan ahi evidentemente es para algo no? o son un adorno?.
Eso es como si coges el P4, le quitas los 512k de cache y luego dices que el rendimiento sin ellos es una mierda…. oye pues si... pero es como lo del iSSE2... es que estan ahi para que el rendimiento no sea una mierda, no para que se los quites... sinceramente no entiendo nada
Asi que suscribo todo lo que te ha comentado pakohuelva, y que aparte de que tus calculos son todos hipoteticos, he mirado alguna de las cifras que das y segun el sandra que tengo instalado (ultima version) los procesadores dan mas puntuacion que la que tu dices (tanto los AMD como los Intel).
De todas formas, nos números exactos no es lo que yo pretendía, sino ver que la FPU del p4 es malísima, y que eso de 10 gigas para igualar un hammer a 2 no es tan descabellado, y que si no son 10, 6 o 7 seguro que si
Supongo que con esta frase lo explicas todo, pero leyendo eso, en vez de poner 3 post larguisimos con toda clase de operaciones extrañas y sin mucho sentido, lo podias haber resumido todo en esta frase:
"La FPU del P4 es una mierda!! abajo el iSSE2!!"
Asi a todos nos hubiese quedado mas claro lo que querias decir realmente
Seamos serios por favor…... (pero tampoco olvidemos mantener el buen humor
)Salu2
-
porque los unicos datos que tenemos es que un hammer a 1400 mhz puntúa igual en el 3Dmark que un Athlon 2200+ (1800 mhz), nada mas.
Que me indiques el 3DMark para darme el rendimiento de un procesador esta muy bien.
http://www6.tomshardware.com/cpu/20021114/p4_306ht-11.html
Este es sobre OpenGL asi que influye la grafica, mira estos mejor:
http://www6.tomshardware.com/cpu/20021114/p4_306ht-17.html
http://www6.tomshardware.com/cpu/20021114/p4_306ht-18.html
http://www6.tomshardware.com/cpu/20021114/p4_306ht-11.htmlComo puedes observar conforme va aumentando la velocidad del procesador el rendimiento va disminuyendo cada vez mas sobre el teorico que deberia dar. Fijate en el P4 a 1.8 y a 3.6
Sin embargo tienes razon en lo del Sandra, en ese test si que es el doble de rendimiento con lo que dice mucho de la validez del mismo. Eso si, en los test meten todo el conjunto SSE, 3DNow y demas para hacer los calculos.
Como ves, no soy el unico que cree que te has pasado.
Ademas tomas como referencia la unidad de calculo flotante que es la mayor ventaja de los Hammer ya que puede calcular numeros de mas bits en menos operaciones por ciclo de reloj que los P4, sin embargo el HT tambien tiene los registros duplicados y puede calcular dos nuemros de 32 bits en casi un ciclo de reloj, con lo que igualaria (teoricamente) los 64 bits del Hammer.
Si los Hammer hubieran salido cuando se anunciaron si hubiese supuesto una revolucion, pero a estas alturas la velocidad de los P4 hace que no se note tanto la diferencia de rendimiento, sobre todo valiendo lo mismo que van a valer.
Otra cosa que habeis comentado es lo de Intel y que no haga nada, pues no es asi. Hay un rumor bastante fuerte que apunta a que Intel esta preparando un micro con tecnologia x86-64, despues de todo esta tecnologia es bastante facil de evolucionar desde los 32 bits.
Por ultimo un pequeño detalle, Intel podria matar al Hammer o herirlo muy gravemente. Solo tendria que implantar la DDR-II muy rapidamente y el Hammer quedaria desfasado tecnologicamente.
-
Por ultimo un pequeño detalle, Intel podria matar al Hammer o herirlo muy gravemente. Solo tendria que implantar la DDR-II muy rapidamente y el Hammer quedaria desfasado tecnologicamente.
¿ein? eso mismo tiene previsto hacer igualmente en su momento AMD con Hammer…
Otra cosa que habeis comentado es lo de Intel y que no haga nada, pues no es asi. Hay un rumor bastante fuerte que apunta a que Intel esta preparando un micro con tecnologia x86-64, despues de todo esta tecnologia es bastante facil de evolucionar desde los 32 bits.
pufff si de rumores se trata… vamos a ser un poquillo más rogurosos, vamos digo yo
-
Juande te lo he demostrado ahora mismo en el otro post, yo no hablo por hablar, cuando digo algo es porque tiene veracidad.
No se si sabras que el Hammer lleva el controlador de memoria integrado en la CPU, una gran ventaja, pero un gran inconveniente a la vez. Ahora mismo ese controlador soporta DDR333, aunque podria ser que en el momento de salir soportara DDR400.
Si Intel fuerza la salida de la DDR-II, y lo tiene mas facil que con Rambus ya que nVidia y ATI la van a usar, AMD tendria que rediseñar el controldor de memoria de la CPU, lo que significaria cambiar la CPU, teniendo en cuenta que normalemte el rediseño de la misma se efectua cada 18 meses, menos para Intel mas para AMD, segun el momento. AMD se veria forzada a rediseñar su CPU muy rapidamente, aumentando el coste y los problemas. Intel por su parte solo tendria que implementar un nuevo chipset, cosa que viene apareciendo cada 6 meses, segun el momento y la necesidad, pero, desde luego, es mucho mas sencillo cambiar el controlador de memoria del Northbridge que de la CPU.
Se podria pensar que AMD podria resistir bastante tiempo sacando provecho a sus bus y a la menor latencia de memoria con DDR333, pero perderia toda la ventaja frente a la DDR-II y buses de 800 Mhz de Intel, con lo que tendriamos mismo rendimiento a mayor precio.
Sobre lo de Intel y la X86-64, me podrias dar una razon para que no la adoptase. Teniendo en cuenta que la tecnologia es abierta, de que ademas, Intel y AMD tienen contratos de cesion de tecnologias, que tarde o temprano hay que migrar hacia los 64 bits y esta es una manera comoda de ahcerlo y, por ultimo, de que microsoft ya tiene(tendra) un SO con soporte para esta arquitectura no se que razon tiene Intel para no sacarlo.
No te voy a poner enlces porque no me acuerdo de memoria, pero seguramente si buscas en los articulos tecnicos de anand sobre esta tecnologia encuentres algo.
Pero por si se te ocurre pensar que si tiene pensado algo asi porque no aparece en sus documentos la respuesta es simple, si lo hicera confirmaria que la arquitectura X86-64 es el futuro y no sus P4, porlo que resulta mucho mas sencillo tener un desarrollo sobre esta arquitectura y sacarlo o no en funcion de como funcione.
-
Pako, te vuelvo a decir lo mismo, todo lo que indicas, son simples especulaciones o elocubraciones sin que estén basadas en realidad de lo que hay hoy y se sabe habrá mañana, composiciones de lugar seguramente propias o que uno se va creando (yo incluído) en función de lo que se lee por ahí o por allá.
Cada uno tiene sus planes, Intel los suyos y AMD los suyos. Ahora mismo los planes de uno y de otro para el año 2003 están sobre la mesa y son los que señalaba en un post anterior de esta rama. Esto es lo que hay. ¿Que Intel trabaja en diversas posibilidades del pelaje que sea (implementar ddr-II, crear su propio x86-64, etc, etc)?, pues ni lo sabes tú, ni lo sé yo, ni lo sabe ninguno de nosotros, por no saberlo no lo saben ni los sitios más especializados en la materia, sólo lo sabrán los responsables de Intel, más allá de lo que quieran contar; como tampoco sabemos, más allá de como tambien AMD quiera contar, qué trabajos o proyectos viene desarrollando AMD, porque por la misma regla que comentas lo que crees sobre Intel… ¿quién te dice que AMD no tiene ya en desarrollo azanzado su micro Hammer con soporte DDR-II, pudiendo forzar a su vez, si Intel lo hace, su salida antes de lo que ellos tienen previsto? Pues esto, ni tú lo sabes, ni yo lo sé, ni nadie que no sean los propios de AMD lo saben. Por tanto, vuelvo al principio, lo que hay previsto y anunciado para todo el 2003 es lo que hay y he dicho en post anterior, lo demás, son suposiciones o composiciones de lugar, que igual pueden servir para Intel como para AMD, y no para uno sí, y para otro no.
Saludos.
-
Joder, la que se ha liado por lo de los 10 gigas, jeje, vamos a ver, vuelvo a repetir por enésima vez que no estoy diciendo que un Hammer a 2 gigas rinda igual que un Pentium 4 a 6, 7 o 10 ghz, y quien quiera seguir malentendiendome, que lo haga y que siga posteando diciendo lo tonto y lo ilógico que soy.
Todo esto viene a cuento de una simple frase, que puse inocentemente y sin darme cuenta de lo que se iba a liar, una simple frase que decia algo que puede ser totalmente cierto, y es que un hammer funcionando a 64 bits puede llegar a rendir en coma flotante como un p4 a 10 gigas usando la FPU. ¿Que esto es una tonteria y que no significa nada respecto al rendimiento de ambos procesadores? pues si, perfectamente, soy el primero que lo dice, para algo esta el SSE2 del P4, y si un programa esta optimizado para hammer, mucho antes para P4.
En cuanto a que 5200 es mas que 4900 y pico, lo se, pero vamos, 5200 es un 5% mayor que ese 4986 que dí, lo cual no considero que sea una diferencia abismal, cuando dije lo de los 10 gigas lo dice sin hacer los cálculos, solo teniendo mas o menos en mente todo lo que he dicho, no hice las cuentas como lo hice en el anterior post.
Con respecto a lo que dice cronos, pues por supuesto que si usas el SSE2 el P4 da más puntuacion (mas del doble), es que si no fuera asi, apaga y vámonos.
De todas formas, por lo que yo se el SSE2 es como el MMX y todo eso, se basa en hacer 'atajos' para hacer los cálculos.
No entiendo mucho de matemáticas pero en un simil es como si con FPU pura para calcular la longitud de un círculo haces PIdiametro, y con SSE 2 haces 3,1416diametro. El segundo cálculo es muchisimo mas facil que el primero, y mucho mas rápido, y para la mayoria de los casos nos servirá igual, pero para valores grandes y que requieran gran exactitud se produciran diferencias entre el valor real y el calculado. Otro símil es el logaritmo neperiano (o algun cálculo de esos, jeje, no estoy muy puesto en trigonometría), que para valores pequeños es igual a otra función trigonometrica, mucho mas fácil de calcular, pero conforme el numero al que se lo calculas es mayor, el error se va acrecentando.
Total, que en juegos el SSE2 irá de lujo, porque no vas a notar la diferencia entre que el punto de fuga de un pasillo este un píxel mas a la derecha de donde debería estar, pero habrá ciertos calculos científicos que requieran de una grandisima precisión, que no puedan permitirse el lujo de este pequeño o casi ínfimo error.Yo antes pensaba que el SSE2 era mucho mas preciso que la FPU, porque usa variables de 80 bits (no no estoy equivocado) frente a las 64 de las variables float normales, pero ya no es que las variables sean más exactas, que lo son en el SSE2, sino los cálculos que se hacen con ellas.
Y siento volver a soltar un rollo macabeo, pero a cuenta de todo esto fue cuando yo hice el comentario de los 10 gigas, y de que la FPU del p4 deja mucho que desear.
Total, que un Hammer a 2 ghz en general sera segun yo pienso, similar a un P4 a 3400 mhz.
-
Tassadar solo una cosa, las MMX no eran atajo, eran ¿32? instrucciones que aceleraban una serie de calculos, es algo similar a lo que hacen los chip graficos.
Por ejemplo, si girar una piramide se hace muchas veces se implementa una funcion que solo se dedique a eso, de esta manera no tienes que calcular todos los datos de manera individual.
En el caso de un procesador no se me ocurre ningun buen ejemplo bueno, pero te voy a poner uno malo, imaginate que siempre se hace la suma 3+3+3+3, pues eso se puede implementar como 4*3, pues algo asi, ya se que el ejemplo es muy malo.
En resumen se trata de implementar por "hardware" algunos calculos muy repetidos por "software".
-
Las mmx son como dices, un juego de instrucciones para acelerar cálculos, en este caso, cálculos de enteros, y creo si mal no recuerdo que eran 54 instrucciones, aunque no se, quizás eran 32, me pones en duda…... a ver si alguien nos lo puede confirma. los 3dnow de AMD y los SSE de intel son como los MMX, pero para cálculos en coma flotante.
Como bien dices, el cometido de las SSE2 es usar atajos para calcular cosas que se suelen calcular (valga la redundancia), pero más que calculos ya hechos del tipo 3+3+3 son funciones, no tiene sentido almacenar cálculos hechos con datos concretos. Lo que se hace es calcular funciones y procedimientos matemáticos comunes, mediante formulas ya prefabricadas, que son mas eficaces que hacerlos 'a mano', en este caso 'a FPU' jeje; pero eficaces en tanto a tiempo de computación, no en cuanto a exactitud, y no voy a repetir los ejemplos que di antes, si no me matais xDD.
La verdad que no conozco profundamente el funcionamiento de las SIMD, ya sea MMX, SSE, SSE, 3Dnow, enhanced 3Dnow..... , así que vendría bien que alguien con mas conocimientos que yo nos ilustrara un porquito, jeje :).
Un amigo mio me comentó que el flask tiene una opción de testear juegos de instrucciones (la exactitud de los resultados), y que el lo ha probado, y los resultados son:
-El FPU pura da prácticamente un error 0
-El MMX da algunas inexactitudes, pero es valido para comprimir (como ya digo trabaja con enteros, no con float)
-El SSE, SSE2 y los 3Dnow, ya sea el normal o el enhanced, dan bastantes mas inexactitudes, y el propio flask como consecuencia desaconseja su uso para la compresión de video.
Yo es que no tengo DVD ni he usado el flask en mi vida, pero a ver si alguien lo puede probar.....
-
Ya te dije que el ejemplo era malo:p pero veo que has piyado la idea, el de la piramide girando era mejor.
Ahora que mencionas 54 me suena mucho mas ese numero que el mio.
Como comentas mas que atajos son funciones predefinidas para acelerar determinados calculos.
Si es posible que se cometan mas errores al utilizar estas tecnologias porque no utilicen toda la precision de la FPU, pero es verdad que en la mayoria de los casos ni siquiera es necesario.
Yo si he usado el Flask y otros programas de ese tipo y siempre activo todas las instrucciones porque la diferencia de calidad para un Divx no compensa la diferencia de tiempo. Para otros temas mas profesionales si puede ser importante.
P.D.: Vamos con el ejemplo otra vez. Si tenemos 3+3+3+3, es decir simpre se suman 4 veces unos enteros pues me implemento la multiplicacion 4xn (3 en este caso). Algo ha mejorado el ejemplo.
Ahh, si quieres exactamente el tema de las MMX y demas te las puedo buscar a nibel de esamblador, creo recordar, que las tengo por algun sitio.
-
Hombre, ya es meterme en temas que no controlo del todo, pero esas inexactitudes tanto de los SSE como de los 3Dnow! (no solo es probrema de intel) son reales y ahí estan, si el flask desaconseja su uso por algo será, ya te digo que yo nunca he usado ese programa ni he comprimido divx, pero amigos mios que si lo han hecho me han dicho que se nota en la calidad cuando activas estos juegos de instrucciones (pero no lo he comprobado por mi mismo).
El tema está en que el P4 en FPU pura es bastante malo, mientras que los athlon son mucho mas eficientes, y aun sin usar sse o 3dnow dan buen rendimiento, frente al p4 que sin SSE2 está perdido.
En cuanto a hasta donde llegan esas inexactitudes no lo se, pero vamos, supongo que en la construcción de un gran puente o en calculos que vayan destinados a una construcción de ese tipo o cosas así muy delicadas que necesiten mucha exactitud, no se podrán permitir el lujo de esos fallos o inexactitudes, es lo que dije, en un quake te da igual que el punto de fuga del pasillo este un pixel mas a la derecha, pero hay cosas mas serias que un quake….
-
Dudo mucho que en la compresion a Divx nadie note la diferencia, mas que nada porque la perdida de esta formato en considerable.
Sobre la precision, no se yo que decirte, habria que ver que exactitud quieres y cual es el error cometido por estos calculos, pero te aseguro que no se va a romper un puente por ello.
Si te empeñas me busco las reperesentaciones de mantisa y esponente de arquitectura de computadores para ver la precision, pero, de cabeza, te aseguro que era muy grande.
-
Personalmente no se si se nota la diferencia al comprimir divx o no, ya que no lo he comprobado por mi mismo, lo del error, pues existe y sin llegar a ser grandisimo, es apreciable, y en ciertas aplicaciones en las cuales se necesita mucha exactitud se nota, si no es en las que he comentado, no se me ocurren otras mas delicadas, jeje.
En cuanto a averiguar la mantisa, el exponente y todo eso, te repito que no van por ahí los tiros, las variables usadas en el SSE2 seguramente tienen más precisión que las de la FPU, pero el fallo no viene de la precision de las variables, sino de los calculos que se les aplican. Por muy precisas que sean las variables, si los cálculos dan aproximaciones, no el resultado real (aunque sean aproximaciones muy grandes) los resultados tendrán ese error.
-
¿Quien ha hablado de variable?.
Con la representacion de mantisa y exponente me refiero a la que utiliza el procesador para calcularlas, no a la longitud de la variable. Supongo que sabras que cada procesador (o arquitectura) define o usa un estandar para las representaciones numericas.
Que los procesadores comenten errores es sabido, pero creo que te has pasado un poco. La precision al hacer calculos es imposible, pero de ahi a que se comentan errores tan sumamente grandes como para que se caigan puesntes y demas. Ten en cuenta que los estudios de arquitectura utilizan PCs en su mayoria y estos montan Pentiums, tambien en su mayoria. Ademas, ¿si no lo calculas con un procesador con que lo calculas?, o, ¿quieres decir que los Pentiums son los culpables de que la nave que tenia que aterrizar en Marte lo hizo en Jupiter y se podia haber evitado al usar Athlons.?
Lo dicho, que la teoria esta muy bien y sabemos que no son absoltamente precisos, pero cometer un error de 1 un milimetro en 1.000.000.000.000.000.000.000.000 de Km parece razonable (32 bits).
-
Con la representacion de mantisa y exponente me refiero a la que utiliza el procesador para calcularlas, no a la longitud de la variable. Supongo que sabras que cada procesador (o arquitectura) define o usa un estandar para las representaciones numericas
No van por ahí los tiros , la cuestión está en los calculos que se hacen, que no se calculan haciendo el calculo que se quiere hacer, sino otro que da resultados casi iguales, pero que es mucho mas rápido de calcular.
Es por decirlo de alguna manera, como un sucedáneo, que va a saber casi igual y es dificil notar la diferencia con el original, pero que es mucho mas barato que el de verdad. La extrapolación es que el sabor es la exactitud del resultado, y el precio es el tiempo de computación necesario.Respecto a el comentario que haces sobre los errores que se producen en computación, no confundamos las cosas, de lo que estamos hablando es de que las SSE y SSE2 (al igual que el 3DNow! de AMD), no realizan los calculos al igual que lo hace la FPU, sino mediante atajos (creo que lo he explicado mas de una vez y de dos en los anteriores posts), y que a causa de eso el uso de estos juegos de instrucciones en detrimento de la FPU se hace que los resultados no sean completamente exactos, siendo muchisimo mas inexactos que cuando se usa FPU. Vamos, que podemos considerar que la FPU da resultados perfectos y las SSE2 cometen inexactitudes.
No confundamos una pelota vieja con una vieja en pelotas, jeje
-
Yo no digo que no tengas razon en tu planteamiento, si no que tu planteamiento es erroneo.
Me explico, por lo que yo se de las MMX y 3DNow, no se como iran las SSE, los atajos se refieren a optimizar detarminadas operaciones muy repetitivas como ya te he explicado. Por ejemplo si para codificar sonido se utiliza mucho el coseno pues esta funcion matematica se implemente en el hardware, siendo mucho mas rapida.
Otro ejemplo, este mas abstarcto pero mas claro. Imagina te que tienes que hacer una integral, la integral es una suma de infenitesimos, pues en vez de sumerlos implementamos la integral por hardware.
Es que segun yo entiendo lo que tu dices, a lo que te refieres es que si tienes un numero con 30 decimales, la FPU los calcula todos y mediante estas instrucciones se reducen a 25 decimales, por ejemplo, y eso no es extrictamente asi, aunque no quita que la precision de estas funciones implementadas sea menor.
-
Packo, creo que a lo que se refiere Tassadar es a otra cosa. Más bien se refiere a que, por ejemplo, en vez de realizar un cálculo concreto difícil y largo, se aproxima por otra función distinta, pero que en un entorno de un punto puede aproximarla (¿recuerdas lo de los infinitésimos equivalentes?). O bien (otro ejemplo) utilizar métodos de integración más rápidos pero con más errores. O de interpolación…. hay muchísimos ejemplos en los que los cálculos matemáticos se pueden aproximar por otras funciones o cálculos distintos pero que en ciertas condiciones (entornos de un punto, etc) dan muy aproximadamente los mismos resultados.
Se calcula el error absoluto cometido en el cálculo y si es "aceptable" para la aplicación en que se necesita, se da por válido. Por ejemplo, imagínate que tienes que hacer unos cálculos basados en unas mediciones en milímetros que haces con una regla. Los cálculos los aproximas usando un método que te da un error a partir de la octava cifra decimal. Pues a tí te da exactamente igual, porque a tí te sobra con una cifra decimal (tu lápiz y tu regla no necesitan más precisión) y aunque el método sea "inexacto" a tí te da una precisión bestial (mucho más de la que necesitas).
Bueno, creo que a eso se refiere Tassadar. Lo que no tengo ni idea es de si las SSE y demás funcionan de esa forma o no....
-
Se que es a eso a lo que se refiere, ya lo he comentado, lo que haces utilizar menos bits para el calculo por lo que aumenta el error.
Lo que yo digo es que las MMX y 3DNow no funcionaban asi, ya que su objetivo era acelerar funciones muy repetitivas pero no necesariamente calculos.
Quiero decir que las MMX no tenian nada que ver con el calculo con flotantes y estabn destinadas a operaciones que no eran de calculo propiamente dichas como puede hacer la FPU.
De todas formas, funcione como funcione y sea como sea, los errores no afectan en la vida real en el sentido de que no se va a caer un puente por el error que cometa un procesador y donde si afecta, que es en la edicion de video, por ejemplo, no creo que en un Divx se note mucho la diferencia.
En resumen, que el error que comete un procesador no es razon para no comprarlo.
-
Cascaman, lo has bordado, jeje, lo has explicado muy bien, jeje.
Respecto a lo que dice pakohuelva de las 3dnow, pues no se si son exactamente como las SSE, que creo que son primas hermanas, ya que son todas SIMD. Lo que pasa es que Las SSE2 son digamos, por un nivel superior, y sustituyen a la FPU (estando el software optimizado), cosa que no se si hacen las demas, tanto el 3Dnow como las SSE1.
El MMX no trabaja con coma flotante, sino exclusivamente con enteros, asi que no es comparable a las otras en muchos aspetos.
Lo de si se cae el puente o no, pues no lo se, yo solo se que para ciertas aplicaciones es necesaria una exactitud super precisa, cosa que SSE2 no puede dar, ahora bien, no se que aplicaciones serán esas.
De todas formas si un programa no esta optimizado para SSE2, utilizará la FPU, y no se tendrán esos (ya sean significativos o no) problemas de exactitud.
Yo creo que seguir dandole mas vueltas a esto es marear la perdiz, yo ya he dicho todo lo que se, y ahí está, y personalmente considero que no tengo los suficientes conocimientos sobre estructuras y funcionamiento interno de microprocesadores como para ahondar mas en el tema de las SSE, sé lo que sé y no doy mas, podría buscar mas información y todo eso, pero la verdad, las SSE2 no es algo que me quite el sueño, jeje
Si hay alguien con vastos conocimientos del tema, que haya estudiado a fondo todo esto, que hable con propiedad y con datos concretos y demostraciones, si no, pues creo que nos quedaremos como estamos, ya que repito que llegado este punto estamos dando mas vueltas sobre lo mismo.
Es que vamos, nos metemos a veces en unos temas de microcomputación es estos foros que no veas, jeje.
Un saludo a todos
-
Se que es a eso a lo que se refiere, ya lo he comentado, lo que haces utilizar menos bits para el calculo por lo que aumenta el error.
Pues lo que yo digo y lo que tú afirmas en esa frase no se parecen en nada…..
No hemos hablado en ningún momento de "utilizar menos bits". Esa no es la cuestión. La cuestión es cambiar EL MÉTODO para hacer un cálculo, pero no reducir los bits. Aunque reduzcas bits, un método puede resultar exactamente igual de largo de realizar.
Ejemplo (a ver si con este dejo claro lo que pretendo decir): Supongamos que el ordenador necesita calcular la tangente de x. Y resulta que x está "próximo" a cero. Pues en lugar de calcular la tangente del número, se dice directamente que el resultado es el mismo número (infinitésimos equivalentes, tg(x)=x cuando x tiende a 0). Lo mismo con ln(1) (logaritmo neperiano) que es igual a x-1 cuando x tiende a 1. ¿Cuánto tarda en dar el resultado? Casi nada. Se ahorra todo el cálculo, pero el número de bits no lo ha tocado en ningún momento.
El error será mayor o menor según se considere que un punto está lo suficientemente "cerca" de 0 o de 1 (respectivamente) para aplicar el método.Lo mismo sucede si en lugar de calcular una función muy compleja en un punto, calculamos el valor en ese punto de su polinomio de interpolación. El cálculo se hace con el mismo número de bits, pero es erróneo. Si el error es aceptable, se usa el método porque me ahorra mucho tiempo de cálculo.
Al integrar, siempre hay error, porque en los métodos a usar (Simpson, trapecios, etc.) se termina aproximando una función por su polinomio de interpolación).
Bueno, espero no haber metido la pata (¿hay algún matemático por aquí?) porque he dicho todo eso de memoria, y hace tiempo que no lo uso.... (¡no me hago responsable de barbaridades!)
