AMD Clawhammer Vs Intel Pentium 4 XEon e Itanium
-
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.
