You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
http://evan.nemerson.com/2021/05/04/portability-is-reliability/ is an interesting article. The real point is that you should run your code through multiple compilers and on multiple architectures where possible (with the warnings turned on) because different compilers catch different problems and different architectures may be sensitive to different problems. Such practices will help find bugs that may be very subtle and may not be triggered in most circumstances.
So I would not call it reliability in the sense that the scientific community uses it, but rather a debugging technique or software quality technique. But I think it is a useful idea.
There may be other resources out there where can supplement or better express this argument.
The text was updated successfully, but these errors were encountered:
Didn't read the ref. but title, Portability is Reliability reminds me of a project I worked part-time on years ago. It was a graphics library called VGL (Virtual Graphics Library -- developed by Jim Reus a colleague of mine at LLNL who has since retired), which was routinely built and run on Mac, Windows, Linux, Vax VMS, Amiga, Solaris and HP-UX, each with their native compilers.
We always wound up finding issues that were unique to one context and that were indeed real problems that other builds didn't catch. It gave us a lot of confidence that the code was pretty decent quality.
http://evan.nemerson.com/2021/05/04/portability-is-reliability/ is an interesting article. The real point is that you should run your code through multiple compilers and on multiple architectures where possible (with the warnings turned on) because different compilers catch different problems and different architectures may be sensitive to different problems. Such practices will help find bugs that may be very subtle and may not be triggered in most circumstances.
So I would not call it reliability in the sense that the scientific community uses it, but rather a debugging technique or software quality technique. But I think it is a useful idea.
There may be other resources out there where can supplement or better express this argument.
The text was updated successfully, but these errors were encountered: