| 1 |
On Fri, 1 May 2015 05:09:51 +0000 (UTC) Martin Vaeth wrote: |
| 2 |
> Andrew Savchenko <bircoph@g.o> wrote: |
| 3 |
> > |
| 4 |
> > That's why kernel makes sure that no floating point instructions |
| 5 |
> > sneaks in using CFLAGS, you may see a lot of -mno-${intrucion_set} |
| 6 |
> > flags when running make -V. |
| 7 |
> |
| 8 |
> So it should be sufficient that the kernel does not use "float" |
| 9 |
> or "double", shouldn't it? |
| 10 |
|
| 11 |
No. Optimizer paths may be very unobvious, i.e. I'll not be |
| 12 |
surprised if under some conditions vectorizer may use float |
| 13 |
instructions for int code. |
| 14 |
|
| 15 |
> I can hardly imagine that otherwise the compiler converts integer |
| 16 |
> or pointer arithmetic into floating point arithmetics, or is |
| 17 |
> this really the case for certain flags? If yes, why should these |
| 18 |
> flags *ever* be useful? |
| 19 |
> I mean: The context switching happens for non-kernel code as well, |
| 20 |
> doesn't it? |
| 21 |
|
| 22 |
Yes, context switching happens for all code and have its costs. But |
| 23 |
for userspace code context switching happens for many other |
| 24 |
reasons, e.g. on each syscall (userspace <-> kernelspace switching). |
| 25 |
Also some user applications may need high precision or context |
| 26 |
switching pays off due to mass parallel data processing, e.g. SIMD |
| 27 |
instructions in scientific or multimedia applications. But unless |
| 28 |
special conditions mentioned above, fixed point is still faster in |
| 29 |
userspace, some ffmpeg codecs have both fixed and floating point |
| 30 |
implementations, you may compare them. Programming in fixed point |
| 31 |
is much harder, so most people avoid it unless they have a very |
| 32 |
goode reason to use it. And dont't forget that kernel is |
| 33 |
performance critical unlike most of userspace applications. |
| 34 |
|
| 35 |
Best regards, |
| 36 |
Andrew Savchenko |
Archives