4

It is known that floating point (FP) arithmetic is not supported inside the Linux/BSD based kernels. What's the overhead of dealing with FP registers inside the kernel?

Neel
  • 9,913
  • 16
  • 52
  • 74

1 Answers1

6

The usual answer is that if the kernel does not use floating point, it does not have to save the floating-point registers on entry to the kernel or restore them on exit. This shaves several hundred cycles off the cost of all system calls.

I do not know if anyone has tried to compare this savings against the performance improvements that might be available if the kernel could make indiscriminate use of those registers. Note that you can use them in the kernel if you take proper care, and this is done in contexts where tremendous speed benefits are available, e.g. using SSE instructions to accelerate memcpy and the like. (Look for calls to kernel_fpu_begin in the Linux sources.)

zwol
  • 135,547
  • 38
  • 252
  • 361
  • For real numbers the kernel also has to save the registers when one kernel thread is preempted by another. So, where is the penalty? – Neel Jun 18 '11 at 16:53
  • Ah, but it *doesn't*! With some help from the hardware, the kernel can avoid saving the FPU registers on a context switch to or from any thread that has never used the FPU. Also, many system calls do not involve a context switch, especially the really cheap ones where the cost of the system call itself dominates, which is precisely when this kind of optimization matters. – zwol Jun 18 '11 at 16:57
  • 1
    +1 for right answer. @user350129: A good example is `gettimeofday`, which a typical (e.g.) Web server will tend to call almost continuously. – Nemo Jun 18 '11 at 17:09