x86 FPU Optimizations Land In Linux 5.2 That Torvalds Loves But Worries Of Regressions

[schmidtbag]

You're only having low expectations in others.

I do expect people here on a technical web site to be accurate and not inaccurate. Go and be inaccurate on Facebook or Twitter or some other social networking site if you must.

It's not a low expectation, it's called "the benefit of the doubt". I suggest you have one - it makes you a more likable person.

[sdack]

Was that generalization inaccurate? Yes. Was it necessary for you to correct it? No, not really. ...

You're only having low expectations in others.

I do expect people here on a technical web site to be accurate and not inaccurate. Go and be inaccurate on Facebook or Twitter or some other social networking site if you must.

Thank you.

[starshipeleven]

I certainly enjoyed hearing the negative expurt opinions from all those that are not using a Pentium based system.

Are you assuming other people's Pentium based system use?

[schmidtbag]

It's not what he was writing, but only what you now read into it. You're then interpreting me, too. Try to read only what is in front of you and not what you believe is written between the lines. And when you believe someone doesn't mean it then it's up to them to say so or else might you be patronising them. People actually often mean what they say even when what they say is wrong.

Look, you're the one who disagreed with a point that others for the most part seem to have understood was a broad generalization. Was that generalization inaccurate? Yes. Was it necessary for you to correct it? No, not really.
Your point of "reading strictly what is in front of you" ironically admits my interpretation of you was correct: you're taking things too literally. So no, not everyone means exactly what they say. People exaggerate things all the time. When you're out with friends and one of them says "I'm starving", no, they're not. They ate a few hours ago and they're not going to suffer health issues if they don't eat for the rest of the night. But, it's widely understood that the statement is hyperbole, so everyone just takes the statement with a grain of salt.
Not really sure what your point about being patronizing; if you felt my first response to you as patronizing, I don't think your response to milkylainen was any less so in comparison.
TL;DR
If you see a comment with a lot of upvotes and you decide to correct it, there's a pretty good chance this means your correction is a misinterpretation of the message, hence my response to you.

I then didn't say the FPU code was bad, because it's getting a reasonable improvement and it's previous behaviour also had it's reasons - as well as you have observed correctly was there nothing wrong with it. So that's not the code I was referring to. The change could possibly have a side effect on other parts of the kernel or code in user land. If so then one shouldn't jump to the conclusion that the change itself was bad, but to look at the other code, too. If the affected code makes false assumptions or otherwise relies on kernel internals and unspecified, undocumented behaviour, which it shouldn't do instead of sticking to the API, and it turns out that this is the reason for the regression then the changed FPU code isn't to blame. Yet, one sometimes has to make sacrifices even in such a case and allow the bad code to exist and to revert the improvement (i.e. when it requires a lot of extra work to fix the bad code). I'm sure you already know all this.

Ah ok, that I'll admit was a failed interpretation on my part.

[rogerx]

I certainly enjoyed hearing the negative expurt opinions from all those that are not using a Pentium based system.

[sdack]

I think you're taking his statement a bit too literally. He's saying that failures/problems are to be expected when meddling with something complex. Doesn't mean it is inevitable, just very probable and therefore the concept of there being an issue is implied.

That I think is a fair interpretation, though at this point, I don't think the FPU code was ever a turd considering how well it has held up over the years. Linux's FPU performance, to my knowledge, has been good.

It's not what he was writing, but only what you now read into it. You're then interpreting me, too. Try to read only what is in front of you and not what you believe is written between the lines. And when you believe someone doesn't mean it then it's up to them to say so or else might you be patronising them. People actually often mean what they say even when what they say is wrong.

I then didn't say the FPU code was bad, because it's getting a reasonable improvement and it's previous behaviour also had it's reasons - as well as you have observed correctly was there nothing wrong with it. So that's not the code I was referring to. The change could possibly have a side effect on other parts of the kernel or code in user land. If so then one shouldn't jump to the conclusion that the change itself was bad, but to look at the other code, too. If the affected code makes false assumptions or otherwise relies on kernel internals and unspecified, undocumented behaviour, which it shouldn't do instead of sticking to the API, and it turns out that this is the reason for the regression then the changed FPU code isn't to blame. Yet, one sometimes has to make sacrifices even in such a case and allow the bad code to exist and to revert the improvement (i.e. when it requires a lot of extra work to fix the bad code). I'm sure you already know all this.

[Sniperfox47]

i just have a question: why not turn them into raspberry pis and save on bills?

In some industries it's because they have ancient legacy software written in obscure niche programming languages that almost nobody still writes and modernizing that software may not be feasible due to monetary costs, engineering costs, or the need to reverse engineer sensitive hardware to redesign proprietary code.

If your code only runs reliably on certain systems because it expects bugs with those certain systems, for whatever reason can't run through x86 emulation, or has no ARM version available then it may be seen as worth it to continue running it on older systems.

Although why in such a use case you'd want a modern kernel is beyond me. If you have ancient hardware you want it hidden away, isolated, and sandboxed from the rest of your hardware anyways because of hardware vulnerabilities, so having kernel patches for security is most likely not worth the risk of breaking other software.

[sireangelus]

To my knowledge, x86 (eg. 32 bit) is alive and well on smaller platforms. Most current and newer software drivers will execute just fine on 32 bit platforms as long as they're re-compiled against the newer kernels. Also, my Dell Inspiron laptop with a Pentium 3 chip runs just fine and still connects to the Internet. (Granted, MS Windows being a security risk.) I welcome the change, as long as the change does not purposely break code. (Ahem.) I also have a 2xP3 750 w/ 1G RAM server, that I ran 24/7 up until a few years ago, now temporarily mothballed as I need room for it, but will likely have it operational again. Nice item to have, a well tested backup computer! (If one builds a computer correctly, no need to toss it in the garbage after only a few years use!)

i just have a question: why not turn them into raspberry pis and save on bills?

[starshipeleven]

At this point nobody should care if Pentium era hardware fails.

I wouldn't mind if they decided to drop Pentium hardware officially, but breaking old hardware that is officially still supported is BAD.

[starshipeleven]

Is Linus referring to Pentium-era or modern Pentium CPUs?

Pentium-era.
Has this gone through lots of testing, particularly with things like
FP signal handling and old machines that don't necessarily have
anything but the most basic FP state (ie Pentium class etc)?

That's old crap in x86 arch (so the historical Pentiums) and slightly less old crap in ARM arch (ARMv6 or v5 I think, where the FPU was optional and you could get away with anything you decided to call FPU).