I still think it's important to fight the misinformation.

Programmers have been conditioned to be so afraid of floats that many believe that doing a + b has an essentially random outcome when it doesn't work that way at all. It leads people to spend a bunch of effort on things that they don't need to be doing.

The same series of operations with the same input will always produce exactly the same floating point results. Every time. No exceptions.

Hardware doesn't matter. Breed of CPU doesn't matter. Threads don't matter. Scheduling doesn't matter. IEEE floating point is a standard. Everyone follows the standard. Anything not producing indentical results for the same series of operations is *broken*.

What you are referring to is the result of different compilers doing a different series of operations than each other. In particular, if you are using the x87 fp unit, MSVC will round 80-bit floating point down to 32/64 bits before doing a comparison, and GCC will not by default.

Compliers doesn't even use 80-bit FP by default when compiling for 64 bit targets, so this is not a concern anymore, and hasn't been for a very long time.

This is true for any kind of transformative technology. Marketing and lobbying can only get you so far. If something has enough utility, it will be used regardless of what people say they want.

Works fine.

This is a not a small code base, and no particular care has been taken with the floating point operations used.

https://youtu.be/9KJTWmRrneo?si=I9mvSPfDnhkckb9n

Hell, I've slung C structs across the network between 3 CPU architectures. And I didn't even use htons!

Maybe it's not portable to some ancient architecture, but none that I have experienced.

If there is undefined behavior, it's certainly never been a problem either.

And I've seen a lot of talk about TLB shootdown, so I tried to reproduce those problems but even with over 32 threads, mmap was still faster than fread into memory in the tests I ran.

Look, obviously there are use cases for libraries like that, but a lot of the time you just need something simple, and writing some structs to disk can go a long way.

No need to add complexity, dependancies and reduced performance by using these libraries.

Of course since Proton uses Vulkan to implement DX12, it means that our Vulkan implementation is simply worse than the one that Valve created to emulate DX12.

I'm sure it's possible to improve that, but it implies that there way to get the best performance out of Vulkan is less obvious than the way to get it out of DX12.

I'm making a joke, but it's also true.

Depends on how you feel about Roko's basilisk.

At every performance review I tell all the people who don't do this that they need to do it more. None of them ever do.

For all I can tell, it's an immutable characteristic that 90% of people will never bring something up unless you ask them.

If you grew up doing windows C++ development, looking at things in a debugger is your first step. You only resort to printing values if you can't immediately see what happened in the debugger.

A lot of other envioronment/language cultures are the opposite. Obviously both have their place, but I do feel like more people should use the debugger as the first step instead of the last.

But some people view it as a seperate entity that writes code for you. And if you view AI like that, then “The AI did it” becomes an excuse that they use.

And in practice that means that I won’t take “The AI did it” as an excuse. You have to stand behind the work you did even if you used AI to help.

I neither tell people to use AI, nor tell them not to use it, and in practice people have not been using AI much for whatever that is worth.

We already have an entire platform like that (steam deck), and it's the best linux development experience around in my opinion.

The code says that if x is true then a=13 and if it is false than b=37.

This is the case. Its just that a=13 even if x is false. A thing that the code had nothing to say about, and so the compiler is free to do.