3 ms·

What's the issues with floats? Everyone is casually talking about this issue like it's common knowledge. Online searches of floating point panics doesn't real

What's the issues with floats? Everyone is casually talking about this issue like it's common knowledge. Online searches of floating point panics doesn't really bring up any information beside bug reports. Is it something about floating point operations not actually being fixed-sized?

crocarneiro 6y ago
I would like to know about this too. Did you find any interesting article?
tialaramex 6y ago
In a modern pre-emptive multitasking operating system, the kernel needs to be able to stop what your user task was doing, do its own thing for a while or even run a different task entirely - and then put everything back apparently as it was and allow your task to carry on. The CPU affords this capability by providing a way to bottle up all its internal state, store that somewhere, and then put it back later. Operating system kernels don't generally need floating point math (some of them use it anyway, lots don't). So if your CPU has a way to say "Bottle your state, but er, don't worry about the floating point stuff" and it's faster, or uses less memory, or both, which are common, all the kernels (like Linux) which do not use floating point know they aren't touching that anyway and needn't bottle it up. This is potentially an important performance win. If you try to take this performance win, but then you actually do use floating point in the kernel, the world suddenly changes beneath the feet of user tasks. A program is adding up some floating point numbers, and then, huh, suddenly the total is now negative? Wait, now it's zero? Nope, negative again? What's happening! If the program was aware of being interrupted this makes sense, but the whole point of pre-emptive multi-tasking is not to need to custom design every program to be interrupted everywhere. So Linux (mostly) never uses floating point.
gpm 6y ago
To say what tialaramex said in a different way, the OS needs to save all the user space registers to the stack when it interrupts a task, so it can do it's own thing. Floats are held in separate registers, so as an optimization it can skip saving those registers to the stack and just not use them (as long as it doesn't call any code that might use floats, and returns back to the same task afterwards). This turns out to be a substantial performance improvement, because there are lots of small syscalls that return quickly. 128 bit integers not working is a bit dumber, the compiler relies on some functions being implemented for them to work, and for whatever reason the people behind rust in linux just haven't implemented those functions (yet?). They use the normal (non floating point) registers though, so there is nothing stopping them from being implemented. https://github.com/Rust-for-Linux/linux/issues/11#issuecomment-778606676 https://github.com/Rust-for-Linux/linux/issues/11#issuecomme...

crocarneiro 6y ago

I would like to know about this too. Did you find any interesting article?

tialaramex 6y ago

In a modern pre-emptive multitasking operating system, the kernel needs to be able to stop what your user task was doing, do its own thing for a while or even run a different task entirely - and then put everything back apparently as it was and allow your task to carry on. The CPU affords this capability by providing a way to bottle up all its internal state, store that somewhere, and then put it back later. Operating system kernels don't generally need floating point math (some of them use it anyway, lots don't). So if your CPU has a way to say "Bottle your state, but er, don't worry about the floating point stuff" and it's faster, or uses less memory, or both, which are common, all the kernels (like Linux) which do not use floating point know they aren't touching that anyway and needn't bottle it up. This is potentially an important performance win. If you try to take this performance win, but then you actually do use floating point in the kernel, the world suddenly changes beneath the feet of user tasks. A program is adding up some floating point numbers, and then, huh, suddenly the total is now negative? Wait, now it's zero? Nope, negative again? What's happening! If the program was aware of being interrupted this makes sense, but the whole point of pre-emptive multi-tasking is not to need to custom design every program to be interrupted everywhere. So Linux (mostly) never uses floating point.

gpm 6y ago

To say what tialaramex said in a different way, the OS needs to save all the user space registers to the stack when it interrupts a task, so it can do it's own thing. Floats are held in separate registers, so as an optimization it can skip saving those registers to the stack and just not use them (as long as it doesn't call any code that might use floats, and returns back to the same task afterwards). This turns out to be a substantial performance improvement, because there are lots of small syscalls that return quickly. 128 bit integers not working is a bit dumber, the compiler relies on some functions being implemented for them to work, and for whatever reason the people behind rust in linux just haven't implemented those functions (yet?). They use the normal (non floating point) registers though, so there is nothing stopping them from being implemented. https://github.com/Rust-for-Linux/linux/issues/11#issuecomment-778606676 https://github.com/Rust-for-Linux/linux/issues/11#issuecomme...