🚀 go-pugleaf

Hola, Recurrente:

Recurrente wrote:
> Hola de nuevo, ante todo gracias por los que me respond�steis a mi 
> pregunta sobre Fortran. Estuvimos probando los dos compiladores (el 
> f2c+fort77 y el Intel Fortran Compiler) y el de Intel produce mejores 
> resultados, lo cual era de esperar. Adem�s desaparecieron esos problemas 
> de arrays que perd�an su valor y cosas as�.
> 
> Ahora tengo una peque�a cuesti�n, a ver si pod�is aconsejarme. Tengo una 
>  simulaci�n escrita en C bastante costosa en tiempo/memoria, pero lo que 
> m�s me preocupa es el tiempo. He estado pensando posibles formas de 
> mejorarla y  en concreto la de incluir c�digo en ensamblador. 
> Especialmente lo pienso utilizar para realizar operaciones elemento a 
> elemento con dos matrices muy grandes (suma, multiplicaci�n, etc). Ahora 
> lo hago con un bucle for.
> 

Lo primero que se me ocurre es pensar si el bucle puede ser optimizado: 
normalmente el bucle for puede ser optimizado si el step *no* es 1 
(++variable, variable++, --variable o variable--).
Pero donde de verdad est� "la chicha" es en lo que ocurre *dentro* del 
bucle (como se va a ejecutar muchas veces, una peque�a mejora de 
rendimiento se traduce en una ventaja total de delta*n, donde delta es 
la mejora para una iteraci�n y n el n�mero de iteraciones).
Por lo que dices, si se trata de operaciones aritm�ticas simples, puede 
que ganes mucho si las orientas como operaciones orientadas a bit, bien 
moviendo bits hacia derecha o izquierda -multiplicaci�n/divisi�n-, bien 
utilizando operaciones con m�scara de bits AND/OR (en general, 
suma/resta).  En realidad, como esos operadores son parte del lenguaje, 
entre una implementaci�n orientada de esa manera y otra en ensamblador 
no deber�a haber grandes diferencias de rendimiento.

> Ya que estamos tengo otra consulta relacionada: en el programa tengo que 
> dividir frecuentemente los elementos de grandes matrices por potencias 
> de 2. Si los elementos fueran enteros esto ser�a muy f�cil , pero al ser 
> de tipo float no tengo muy clara la estructura. Con un peque�o programa 
> y usando el "oj�metro" me he hecho una idea de la estructura y he 
> escrito un peque�o programa que realiza divisiones por 2 en variables 
> float usando solo operaciones l�gicas elementales, con objeto de 
> implantarla en ensamblador, pero claro as� a ojo suena un poco chapuza. 
> Estuve buscando por la red documentaci�n sobre el formato espec�fico de 
> la variable float (que depender� supongo de cada m�quina, estamos 
> hablando de linux-pc), pero no encontr� nada. �Alguien sabe d�nde puedo 
> encontrar dicha informaci�n?
> 

Para una cosa tan "sencilla", lo mismo de antes: considera dos cosas:
1/ Si son datos "ingenieriles", normalmente el n�mero de cifras 
significativas es relativamente reducido: averigua cu�ntas son realmente 
necesarias y te encontrar�s muy probablemente con que puedas sustituir 
tus operaciones por an�logas de aritm�tica de enteros.  El ejemplo m�s 
sencillo: 123'5/2 == 1235/20 == (1235/2)/10.

O sea, que utilizas un multiplicador potencia de 10 al principio de las 
operaciones, para que todos los datos sean enteros y s�lo al final, 
reescalas otra vez el resultado.

Complicaci�n a�adida (pero sencilla de implementar) es reescalar el 
�mbito de los operandos para que, una vez pasados a enteros, "quepan" en 
el rango de un 'int' o un 'long int'.  O sea, que si tus c�lculos 
necesitan seis d�gitos significativos y est�n en el rango 1 000 a 1 000 
000, dividiendo todo por mil te quedan en el rango 1 a 1 000 sin perder 
precisi�n en los c�lculos.

2/ Una vez que puedes meter los datos en un int o long int, para 
dividirlos por 2^n basta con mover los bits n posiciones a la derecha y 
rellenar con ceros a la izquierda (operaci�n �sta que suele ser autom�tica).

Aunque es un poco complicado de explicar, suele ser muy sencillo de 
implementar (si tienes claro el objetivo a resolver y los rangos de datos).
-- 
SALUD,
Jes�s
***
jesus_navarro@undominio.net
***