low speed logaritmith calculation

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi all

In my application I am displaying bipmap image
I am using the log10() function, but it takes very
long time to display the image, the pixel array size is
1272x1003 pixels.

I am looking for a some tricks thats helpme to
improve the speed of this function

below find a pice of code that I am using

for (i=0;i<iDepth;i++)
{
for (j=0;j<aLength;j++)
{
lpBmpValue = lpBmp1 + j + i*(iDepth+2);
*lpBmpValue =dContrast*(10*log10(S[j])+dBrightness);

}
}
this part of the code takes 200mSec

Is it possible to improbe?
Thanks
 
rogerzar said:
Hi all

In my application I am displaying bipmap image
I am using the log10() function, but it takes very
long time to display the image, the pixel array size is
1272x1003 pixels.

I am looking for a some tricks thats helpme to
improve the speed of this function

below find a pice of code that I am using

for (i=0;i<iDepth;i++)
{
for (j=0;j<aLength;j++)
{
lpBmpValue = lpBmp1 + j + i*(iDepth+2);
*lpBmpValue =dContrast*(10*log10(S[j])+dBrightness);

}
}
this part of the code takes 200mSec

Is it possible to improbe?


Use a table of logarithms instead of calculating it. You didn't show any of
the types involved, but presumably you're using 8 bits per pixel (or per
component), so a 256-entry table would suffice.

-cd
 
Hi all

In my application I am displaying bipmap image
I am using the log10() function, but it takes very
long time to display the image, the pixel array size is
1272x1003 pixels.

I am looking for a some tricks thats helpme to
improve the speed of this function

below find a pice of code that I am using

for (i=0;i<iDepth;i++)
{
for (j=0;j<aLength;j++)
{
lpBmpValue = lpBmp1 + j + i*(iDepth+2);
*lpBmpValue =dContrast*(10*log10(S[j])+dBrightness);

}
}
this part of the code takes 200mSec


I don't know the type of S[][], but even if it is double you can
probably create a reasonable table of doubles, there is a range limit
on the output (one byte I assume), so accuracy is not the ultimate
need. You need sufficient accuracy to produce valid output.

If S[][] are bytes, you need a simple 256-byte lookup table, as Carl
suggested. Otherwise, you may need a bit wider table -- but I would
think no larger than 64KB. if S[][] are doubles, you'll need to reduce
them to fit the table; but considering the limited output range, this
shouldn't be a problem.

Once built, this table will allow you to do your calculations in a
tiny amount of time.
 
You can simplify one of the inner equations like so. Multiplying two
thirty-two bit numbers takes many cycles.

for (i=0;i<iDepth;i++) {
int c = i*(iDepth+2);
for (j=0;j<aLength;j++) {
lpBmpValue = lpBmp1 + j + c;
*lpBmpValue =dContrast*(10*log10(S[j])+dBrightness);
}
}

mosimu

Severian said:
Hi all

In my application I am displaying bipmap image
I am using the log10() function, but it takes very
long time to display the image, the pixel array size is
1272x1003 pixels.

I am looking for a some tricks thats helpme to
improve the speed of this function

below find a pice of code that I am using

for (i=0;i<iDepth;i++)
{
for (j=0;j<aLength;j++)
{
lpBmpValue = lpBmp1 + j + i*(iDepth+2);
*lpBmpValue =dContrast*(10*log10(S[j])+dBrightness);

}
}
this part of the code takes 200mSec


I don't know the type of S[][], but even if it is double you can
probably create a reasonable table of doubles, there is a range limit
on the output (one byte I assume), so accuracy is not the ultimate
need. You need sufficient accuracy to produce valid output.

If S[][] are bytes, you need a simple 256-byte lookup table, as Carl
suggested. Otherwise, you may need a bit wider table -- but I would
think no larger than 64KB. if S[][] are doubles, you'll need to reduce
them to fit the table; but considering the limited output range, this
shouldn't be a problem.

Once built, this table will allow you to do your calculations in a
tiny amount of time.
 
The log is definitely where the performance is going though; one of our
applications (without the vectorised maths code we use) spends over 20% of
its calculation time in each of a log and exponential calculation that can't
be tabulated unlike (as Carl pointed out) this case. We've found this on
both PCs and Macs, where other maths operations are relatively inexpensive.

Steve

mosimu said:
You can simplify one of the inner equations like so. Multiplying two
thirty-two bit numbers takes many cycles.

for (i=0;i<iDepth;i++) {
int c = i*(iDepth+2);
for (j=0;j<aLength;j++) {
lpBmpValue = lpBmp1 + j + c;
*lpBmpValue =dContrast*(10*log10(S[j])+dBrightness);
}
}

mosimu

Severian said:
Hi all

In my application I am displaying bipmap image
I am using the log10() function, but it takes very
long time to display the image, the pixel array size is
1272x1003 pixels.

I am looking for a some tricks thats helpme to
improve the speed of this function

below find a pice of code that I am using

for (i=0;i<iDepth;i++)
{
for (j=0;j<aLength;j++)
{
lpBmpValue = lpBmp1 + j + i*(iDepth+2);
*lpBmpValue =dContrast*(10*log10(S[j])+dBrightness);

}
}
this part of the code takes 200mSec


I don't know the type of S[][], but even if it is double you can
probably create a reasonable table of doubles, there is a range limit
on the output (one byte I assume), so accuracy is not the ultimate
need. You need sufficient accuracy to produce valid output.

If S[][] are bytes, you need a simple 256-byte lookup table, as Carl
suggested. Otherwise, you may need a bit wider table -- but I would
think no larger than 64KB. if S[][] are doubles, you'll need to reduce
them to fit the table; but considering the limited output range, this
shouldn't be a problem.

Once built, this table will allow you to do your calculations in a
tiny amount of time.
 
Carl said:
Use a table of logarithms instead of calculating it. You didn't show any of
the types involved, but presumably you're using 8 bits per pixel (or per
component), so a 256-entry table would suffice.

Another solution could be to approximate the logaritm function with
precomputated taylor polynomials (it depends on the precision you need),
maybe it may be a little faster... but I'm not sure about that. Any opinion?
 
Back
Top