Re: Computer architects leaving Intel...

In article <vasruo$id3b$1@dont-email.me>, david.brown@hesbynett.no (David
Brown) wrote:

On 30/08/2024 17:42, John Dallman wrote:

Plain old compiler bugs, introduced while fixing other ones, are
quite enough to make me assume that I'll find problems on each
change of compiler.

 
I always keep old versions of compilers around, and don't change
compilers (or libraries) in the middle of a project. 

I always have at least a couple of machines at the previous build
standard of any platform, often more machines and/or older build
standards.

Changing compilers or libraries is done at new major releases.

If you want to write software that is "correct because it passed
its tests", you can only expect it to be reliable when it is run
exactly as tested.  That means it must be compiled as it was during
tests (same compiler, same options, same library), and arguably
even run only on the same hardware (if you only test on one
particular cpu, OS, etc., you can only be sure it works on that
cpu, OS, etc.).

This is simpler when you produce closed-source binary software. We only
ship builds we've tested. That means the /same binaries/ as we tested,
not rebuilt or modified. This requires a separate test harness, rather
than testing code compiled into the binaries.

We test on a wide variety of hardware for the most-used platforms, by
putting it into the distributed testing pools and always knowing which
machine an individual test case ran on, because it's recorded in the test
results.

That's why a lot of pre-compiled commercial software gives
particular versions of particular OS's or Linux distributions in
their lists of requirements - even though the software would
probably work fine on a much wider range.

We specify what we specifically support, because we've tested that, plus
the much broader requirements that it should work on. For Linux those are
a GCC runtimes version (currently 8.x) or later and a glibc version
(currently 2.28) or later. We don't seem to have problems with
compatibility since we understood how the compatibility works with those
libraries, and started doing it that way.

If there's a problem on a specifically supported Linux, we'll fix it
unless that's impossible. If there's a problem on one where it should
work, we'll investigate it, and fix it if we can, which may cause a
distribution to be added to the specifically supported list. If we can't
fix a problem, we'll explain why not, and normally add the problem to the
documentation. We can't do miracles, but we do pretty well.

Yes, doing good support is expensive, but it pays off in customer loyalty,
which means money.

John