[EMAIL PROTECTED] wrote:
> >
> > > Hi,
> > >
> > >Can anyone tell me the performance penalty when i use floating
> > > point operation in my rt tasks.
> >
> >
> > Apart from cache misses, about 200 CPU cycles for fPU save and
> > restore. On a UP/MUP neither that if Linux is not using the FPU, at
> > least that is the RTAI way.
>
> What will be the increase in the latency when using FP.
A CPU will start responding to a hardware interrupt as soon as the
current operation is completed, and the CPU state has been saved. So
if it is an FP operation it can add at least about 200 CPU cycles to the
interrupt latency, depending on when the interrupt happened during the
FP operation.
To figure out how much extra time this might be, take 200 cycles and
divide it by your CPU speed to get the worst extra time for FP save.
For example, a 100 MHz CPU:
200 cycles / 100 MHz
= 200 cycles / 100 X 10^6 Hz
= 2 x 10^-6 Sec
= 2 uSec.
Add to this the number of cycles it takes to execute the longest FP
operation in your code.
Add this to the worst case interrupt latency for RTL on your machine.
This will give you a rough idea of how much extra latency, not including
cache misses. Cache misses are dependent on your code.
- Kal.
> >
> > Ciao, Paolo.
> >
> -Santhosh
>
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
