AMD Clawhammer Vs Intel Pentium 4 XEon e Itanium
-
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!)
-
Se a lo que te referias, lo que ocurre es que para hacer aproximaciones pierdes tiempo de calculo, tendras que saber a que numero lo aproximas.
A lo que yo me referia es que si con la FPU utilizas una representacion de 30 bits para la coma, en MMX puedes utilizar 16 por ejemplo, lo que a la larga produce menos precision.
De todas formas estamos hablando tonterias, primero poruqe ninguno sabemos muy bien como funcionan, yo me quede en las MMX y, segundo, porque en la vida real, repito, las imprecisiones de los calculos son inexistentes, mas que nada porque, en el caso del puente, el Autocad no utiliza estas instrucciones.
P.D.: Me referia a Tassadar
-
Cascaman, leyendo tu post voy asintiendo a todo y pensando 'es que yo no se matematicas, jejeje', pero todo lo que tu dices es a lo que yo me refiero.
Vuelvo a decir que creo que las SSE2 usan variables de 80 bits, por lo cual son mas exactas que las variables float de 64 bits que utiliza normalmente la FPU. Pero que el tema como ya sabemos no está en la exactitud de las variables, sino en las operaciones que se realizan con ellas.
….porque en la vida real, repito, las imprecisiones de los calculos son inexistentes, mas que nada porque, en el caso del puente, el Autocad no utiliza estas instrucciones
Claro, el autocad al no usarlas, no tendra el problema de esas pequeñas o grandes (segun la exactitud que se necesite) impreciones, así que dependerá de la potencia de la FPU del micro que se esté utilizando.
