Re: Have we become too Intel x64 centered?

From: Gavin Lambert (boost_at_[hidden])
Date: 2021-01-25 21:04:19

On 26/01/2021 9:44 am, Edward Diener wrote:
> My main thought is that, while you are correct about not testing on 
> something other than Intel x64, from the programmers viewpoint he is 
> writing code in C++ and not for a particular platform/architecture. At 
> the most he may be writing code with attention to a compiler or OS, but 
> hardly ever does a particular CPU itself come into play unless lower 
> level assembly code, tailored to a CPU, comes into play. So 
> realistically the programmer does not care about a CPU at all. Even if a 
> test were to fail on some other platform/architecture, where it normally 
> passes on Intel x64, what would a programmer do about it ? Probably very 
> little. Maybe, at the very most, report a problem to the compiler 
> running on that platform/architecture that their is something wrong 
> somewhere. But for the vast, vast majority of times such a problem would 
> hardly indicate anything wrong with the code itself. I offer all this up 
> as a possibly valid reason why testing a Boost library on some other 
> platform/architecture, other than the usual Intel x64 on 
> Mac/Linux/Windows, is not going to be a big priority for any Boost 
> library developer/maintainer.

This isn't really a good way of thinking.

Despite C/C++ supposedly being portable languages, the truth is that 
each platform and compiler have their own quirks -- mostly stemming from 
implementation-defined parts of the language, including such fundamental 
things as the sizes of primitive types and overall endianness, along 
with some higher-level concepts such as whether certain operations are 
lock-free or not, etc.  (And even, in theory, whether two's complement 
encoding is used; although I'm not aware of any modern platforms at 
least where that's not the case, they certainly did exist in the history 
of the language.)

While a library author perhaps doesn't have to care about such 
differences quite as much as an application author does (as the 
implementation-defined differences are more significant in the 
multi-threading arena, and libraries usually stay out of that space), 
they're not something that can be ignored entirely.

It is absolutely possible to write code that works perfectly on Intel 
x64 but is utterly broken on other architectures (or worse: mostly works 
except for some corner cases, or works but with pathologic performance), 
and that is the fault of the code, not of the compiler or platform.

But even outside of that, it is a useful exercise to run code through 
multiple compilers, as each have a different suite of warnings, and 
trying to get code to compile warning-clean in most compilers can lead 
to an overall improvement in quality (although not always).