New peer reviewed paper finds the same global forecast model produces different results when run on different computers
Did you ever wonder how spaghetti like this is produced and why there is broad disagreement in the output that increases with time?
![CMIP5-73-models-vs-obs-20N-20S-MT-5-yr-means1[1]](http://wattsupwiththat.files.wordpress.com/2013/06/cmip5-73-models-vs-obs-20n-20s-mt-5-yr-means11.png?resize=640%2C480&quality=75)
Graph above by Dr. Roy Spencer
![CMIP5-73-models-vs-obs-20N-20S-MT-5-yr-means1[1]](http://wattsupwiththat.files.wordpress.com/2013/06/cmip5-73-models-vs-obs-20n-20s-mt-5-yr-means11.png?quality=75)
Increasing mathematical uncertainty from initial starting conditions is the main reason. But, some of it might be due to the fact that while some of the models share common code, they don’t produce the same results with that code owing to differences in the way CPU’s, operating systems, and compilers work. Now with this paper, we can add software uncertainty to the list of uncertainties that are already known unknowns about climate and climate modeling.
I got access to the paper yesterday, and its findings were quite eye opening.
The paper was published 7/26/13 in the Monthly Weather Review which is a publication of the American Meteorological Society. It finds that the same global forecast model (one for geopotential height) run on different computer hardware and operating systems produces different results at the output with no other changes.
They say that the differences are…
“primarily due to the treatment of rounding errors by the different software systems”
…and that these errors propagate over time, meaning they accumulate.
According to the authors:
“We address the tolerance question using the 500-hPa geopotential height spread for medium range forecasts and the machine ensemble spread for seasonal climate simulations.”
…
“The [hardware & software] system dependency, which is the standard deviation of the 500-hPa geopotential height [areas of high & low pressure] averaged over the globe, increases with time.”
The authors find:
“…the ensemble spread due to the differences in software system is comparable to the ensemble spread due to the differences in initial conditions that is used for the traditional ensemble forecasting.”
The initial conditions of climate models have already been shown by many papers to produce significantly different projections of climate.
It makes you wonder if some of the catastrophic future projections are simply due to a rounding error.
Here is how they conducted the tests on hardware/software:
Table 1 shows the 20 computing environments including Fortran compilers, parallel communication libraries, and optimization levels of the compilers. The Yonsei University (YSU) Linux cluster is equipped with 12 Intel Xeon CPUs (model name: X5650) per node and supports the PGI and Intel Fortran compilers. The Korea Institute of Science and Technology Information (KISTI; http://www.kisti.re.kr) provides a computing environment with high-performance IBM and SUN platforms. Each platform is equipped with different CPU: Intel Xeon X5570 for KISTI-SUN2 platform, Power5+ processor of Power 595 server for KISTI-IBM1 platform, and Power6 dual-core processor of p5 595 server for KISTI-IBM2 platform. Each machine has a different architecture and approximately five hundred to twenty thousand CPUs.
And here are the results:
While the differences might appear as small to some, bear in mind that these differences in standard deviation are only for 10 days worth of modeling on a short term global forecast model, not a decades out global climate model. Since the software effects they observed in this study are cumulative, imagine what the differences might be after years of calculation into the future as we see in GCM’s.
Clearly, an evaluation of this effect is needed over the long term for many of the GCM’s used to project future climate to determine if this also affects those models, and if so, how much of their output is real, and how much of it is simply accumulated rounding error.
Here is the paper:
An Evaluation of the Software System Dependency of a Global Atmospheric Model
Abstract
This study presents the dependency of the simulation results from a global atmospheric numerical model on machines with different hardware and software systems. The global model program (GMP) of the Global/Regional Integrated Model system (GRIMs) is tested on 10 different computer systems having different central processing unit (CPU) architectures or compilers. There exist differences in the results for different compilers, parallel libraries, and optimization levels, primarily due to the treatment of rounding errors by the different software systems. The system dependency, which is the standard deviation of the 500-hPa geopotential height averaged over the globe, increases with time. However, its fractional tendency, which is the change of the standard deviation relative to the value itself, remains nearly zero with time. In a seasonal prediction framework, the ensemble spread due to the differences in software system is comparable to the ensemble spread due to the differences in initial conditions that is used for the traditional ensemble forecasting.
h/t to The Hockey Schtick
Discover more from Watts Up With That?
Subscribe to get the latest posts sent to your email.
MarkG says:
July 28, 2013 at 7:20 pm
“Out-of-order execution produces the same results as in-order execution, because it has to wait for the previous operation on the data to complete before it can continue.”
First you need to chose an appropiate example i.e. if we four floating point values A, B,C,D and we want to add B, C,D, to A. In the C language we wpould write:
A += B + C + D;
The compiler with optimisation turned off would move A into a register ( if necessary ) and then add B followed by C followed by D.
The CPU is free to re-order these instructions and becazuse of differing intermediate values with rounding the result is not the same.
The CPU is free tp re-oder instructions that follow the above statement as long as the do not read from A or write to B,C, or D. The rules against writting to B,C,D can be releaxed as long as temp copies of the values of B, or C, or D, are saved.
/ikh
How embarrassing. The problems of rounding issues and library differences, and the subsequent effects on cluster runs, have been known in the HPC (High Performance Computing) community for a long time. That some modellers chose to ignore this issue suggests a lack of professionalism.
When I did my computer science degree (many years ago) there was a course on numerical analysis. A big part of that was trying to get us to understand just how bad rounding errors can get, in very few iterations. There was an example that was used (which I have forgotten completely) where just dropping a digit or two from each partial result resulted in complete nonsense at the end.
A core concept was that you had to fully understand the mathematical construct that you were coding in order to be able to spot these pitfalls. There was a time when I thought that this was just a maths professor trying to remain relevant in the computer age, but I now realize that he was absolutely right. The same principle applies everywhere in computing — you had darn well better understand what you are attempting to represent in code.
One of the sad but true things about computers is that real arithmetic is something that they actually do quite poorly compared to many other application.
I spent time after my degree running “surgeries” for undergraduates doing computer science, helping them to debug their coding problems. Quite a few post-grads turned up too. Mainly from the “soft-sciences”, they would have found some equation in a book, or maybe an algorithmic description of some statistical manipulation/test and tried to code it up themselves. I used to look forward to these guys, they provided a much bigger mental challenge than undergrads fighting to find where the missing close bracket was. Most often, once we had it running and spitting out numbers, they would show no interest at all in constructing some tests to validate that it was working correctly for all values, and particularly for the edge cases.
Inappropriate statistical models, incorrectly coded …
I now realize that I may have failed the world in not strangling these guys there and then.
Re: Pipe-lined instructions and out of order execution.
All of the comments are correct. If we are dealing with integers, you can do the operations in any order. With floating point, you may get different answers depending on overflow, rounding etc.
But the big killer is where any of the values you are using may be changed by external influences, such as reading a value from a register which is hardware and affected by changing some other variable.
Even harder to detect and deal with are multi-threaded applications, where variables being used in calculations may be changed asynchronously by another thread of execution. If you are writing the code, you are totally responsible for ensuring that multiple threads don’t tread on each other.
Most of the code I have seen that the climate dweebs play with is written in single-thread of control languages such as Fortran (which quite honestly should have died about 30 years ago).
To get performance out of modern super-computer clusters, this monolithic, single threaded code is compiled with compilers that attempt to break it down into separate components that can be run in parallel on multiple CPUs or even multiple computers. That is placing a LOT of trust in the compilers and support libraries. It would be instructive to see if the compilers used are the latest patch levels, and if not, what bug fixes are listed in each release subsequent to the one being used.
The combination of multi machine, multi cpu with each cpu pipelining and using out of order execution applied to code which was written to be executed linearly with a single thread of control written by someone with a poor grasp of numerical analysis is … well … worrying.
jimmi_the_dalek says (July 28, 2013 at 6:17 pm):
Having worked on developing 5 compilers, for various computer manufacturers, I’m chomping at the bit as I type, because someone needs to point out that “quite often ‘mis-optimise’” paints its generalization with a overly broad brush.
Such compiler failures should certainly not be “quite often“. Certainly not for compilers from any established company, especially one that supplies the hardware the compiler is targeted for.
I confess that I’d be really reluctant to make any bets on compilers from (unidentified) start-up companies, whose engineers might be much stronger in enthusiasm than experience, and who are self-motivated much more by the fun of invention than the drudgery of compiler testing. And testing. And retesting.
I’m writing on the crucial assumption that the compilers we’re discussing are serious commercial products. So you and your colleagues work closely with your compiler vendors, providing them promptly with minimal-size test cases for each bug you’ve discovered, right? Each compiler vendor should have some way to force their code-generator–or optimizer–to replicate its behavior in your computing environment, e.g.: your combination of multiple processors and vector sizes. But simply shipping out the latest version of the 10-million lines-o’-code lump is now even less productive for all concerned, than it was back when high-performance computers were typically single high-speed processors.
LdB says:
July 29, 2013 at 7:36 am
“Technically what happens with inertia is it creates integratibility over the chaos which is technical speak for saying that the chaos can not take only any value it can only change at some maximal rate. In layman speak a plane or rocket when trying to go chaotic can only bank and turn at a maximal rate which you would already know from common sense.
So butterfly effects and other chaotic behavior which exists and is unsolvable in mathematics and some fields holds little relevance to many real world physics where the chaos mixes with inertia components.”
All nice and well, but radiative energy exchange in the atmosphere is a fast process. Kevin Trenberth’s infamous energy balance diagram that 90 % of the energy that leaves the Earth come not from the surface but from the atmosphere. (Yeah I know that’s a fantasy. But it’s probably what the models do.) So one would think positive water vapor feedback can accelerate about as quickly as a thunderstorm in the tropics develops (yeah I know they don’t do thunderstorms. Just a comparison). Thermal runaway within an afternoon. Assuming their positive water vapor feedback existed.
Or shorter: Chaos in CO2AGW models is just as fast as weather.
I re-engineered an exist custom Integrated Circuit. I had to create a 32bit adder, for the last stage I use 2 4bit overflow adders, one tied to the other. I think I created test vectors that tested each adder, and both together, but the case of (I think) both set to 16, and getting them to add correctly I don’t think I had a test case. In use the chip acted odd, triggered more often than it was suppose to. Fortunately, while my vectors didn’t detect the problem, the problem was a bad 4 bit adder macro that I used, that had apparently never been tested. They re-spun the chip, we added some extra vectors. Didn’t cost us anything, new chip worked great.
Compu Gator,
The compilers I am referring to are by major companies – Intel, Sun (now Oracle), Portland Group. They all make mistakes on large scale codes. We report errors where practicable, otherwise go through lengthy test suites, identify the problem routines, and reduce the optimisation level on those. It’s fact of life I’m afraid, and has been on every machine/operating system/compiler combination I have seen in 20 years. The operating system itself is rarely a problem, and neither are the maths libraries, fortunately.
Frank K. says:
July 29, 2013 at 6:19 am
Robert – I’d like to hear more about your experiences with Model E. Perhaps you could write up a short essay that Anthony could publish.
Some of the details of my experience are at
http://mc-computing.com/qs/Global_Warming/Model_E/index.html
I never posted the proposed paper and some other stuff because journals refuse to consider anything previously published.
Based on that research, I have developed a number of related pages, such as
http://mc-computing.com/Science_Facts/Water_Vapor/index.html
For instance, at 0.01°C, the saturation vapor pressure of water is 611.657 ± 0.01 Pa. Model-E uses 610.8 Pa. As a result, the model will use the wrong value for water vapor absorption. However, it is not clear if their algorithm gives too much or too little absorption. In my programs, there are 28 different formulas for computing saturation vapor pressure – Model-E uses 2 of them, one over water and another over ice. While the difference in the amount of vapor is very small, the difference in the amount of IR radiation absorbed and emitted is quite large when compared to what they claim changes in CO2 are causing.
One of the reasons I tried to run Model-E was so that I could change parameters, like the saturation algorithm, and see what effect, if any, it had. I also wanted to change the number of days from 365 to 366. Basically, I wanted to determine which constants and algorithms were important and which weren’t. Since “they” claim that “water vapor feedback” is what causes the real problem, I think that this type of analysis is important.
For additional information, contact me via the provided links at the bottom of my pages.
Wow. I understood about 1/4 of what was said above, but, it was well worth the effort to understand that much. From their failure to: hindcast or forecast the real data (oxymoron, I know, but, so often needed that I use it for clarity), I already knew GCM’s were piles of junk, now, I understand a bit more (maybe a whole byte more!) why.
2 (of the many) fine quotes from above:
***************************************************************
“… the entire range of past variation is equally likely under their assumptions and procedures… .”
[Brian H 12:22 PM 7/29/13 – edited emphasis]
That says it all.
******************************************
“Weather is the atmosphere stabilising itself.”
[AndyG 1:51PM 7/28/13]
Nicely put.
ummm…
It used to be much worse – but what’s going on here is a problem arising from the interaction between the job management software (e.g. openmpi) and the model. The models run to a level of detail set by the number of available processors (or run time maxima), the job management software sets that at the start based on what’s available then. Run the same openmpi job on a heavily used machine first and then on the same machine running idle and this type of application will get different results.
jimmi_the_dalek says:
July 29, 2013 at 1:11 pm
We report errors where practicable, otherwise go through lengthy test suites, identify the problem routines, and reduce the optimisation level on those.
Every compiler I have ever used has documentation describing what you can and can not do at a particular optimisation level. If your programmers ignore the rules then youn deserve everything you get. And that is a much higher cost of maintenance than is necessary.
Before you can blame the compiler optimiser you have to eliminate programmer errors from using constructs that break the rules for that optimisation level.
Compilers from harware vendors are “Flagship” products. They do not make profits for the vendor and I suspect they rarely cover costs, but they do help to sell their hardware. Which is where the big monrey is. As such, they put huge effort into making sure that they are correct, otherwise it refelects on the computers and chips that they sell.
That is not to say that there is never a bug oin the compiler, but it will be a lot less common than a comercial or in house piece of software breaking the optimisation rules.
/ikh
Janice Moore says:
July 29, 2013 at 2:40 pm
“Wow. I understood about 1/4 of what was said above, but, it was well worth the effort to understand that much.”
It is not surprising that for somone reading a climate blog, you can not understand some serrious Computer Science. It is a valid and seperate discipline in its own right. And one that is not generrally taught in school unless you study it at University.
And yet, the first quote you chose:
“… the entire range of past variation is equally likely under their assumptions and procedures….”
Is probablly the most important phrase in the post.This means that the same magnitude of variation that comes from running a single model as an ensamble by changing some of the parameters ( initial conditions ) can just as easily be achieved by changing the compiler optimisation level ( with out changing the parameters ) or by changing the hardware.
Does this automatically invalidate a model. No. We would need multiple runs of a model with identical starting conditions to show rounding errors.
/ikh
Ikh,
You are over optimistic.
Compilers frequently make mistakes. If that were not the case then successive issues would not contain, in their release notes, long lists of problems which have been fixed. For example Intel releases bug fixes to there compilers every couple of months – see http://software.intel.com/en-us/articles/intel-compiler-and-composer-update-version-numbers-to-compiler-version-number-mapping and the detailed list of bugs runs to several pages each time – see for example http://software.intel.com/en-us/articles/intel-composer-xe-2011-compilers-fixes-list
I assure you there are problems with all compilers when applied to large scale codes, and not just the loss of a few digits precision which might come from rearranging the arithmetic operations, and which could be due to the programmer writing unstable code, but outright blatant failures with totally wrong answers.
son of mulder says:
July 29, 2013 at 8:35 am
How does this differ from adjusting models to hindcast? Try applying it to tossing a coin or predicting percentage of time the jetstream will pass south of the UK or north of the UK, or over the UK, in 100 years time, in 50 years time, in 10 years time and so define a main driver of the UK’s climate.
They are very different techniques in your full hindcast model you assume that you have faithfully described the model correctly at the beginning the second method is called “Sliding mode control” or sometimes “sliding window control” because you essentially realize at the start that you don’t know the exact values so the system adjusts them as they go.
http://en.wikipedia.org/wiki/Sliding_mode_control
The obvious difference is that the sliding mode control has a “lock” condition which is move the sliding window forward and failure for the prediction to be in that window means you have lost lock on the target. Look for example at how the bug with the patriot missile was reported
http://sydney.edu.au/engineering/it/~alum/patriot_bug.html
=> Discovery of the Bug
Ironically, Israeli forces had noticed the anomaly in the Patriot’s range gate’s predictions in early February 1991, and informed the U.S. Army of the problem. They told the Army that the Patriots suffered a 20% targeting inaccuracy after continuous operation for 8 hours.
Obviously in the patriot missile case the “lock” signal is reported to the operator.
Sometimes when you aquire “lock” it is interesting to then hold the current parameters and turn the model around and run it backwards thru the hindcast to see if the lock can hold. Again in a military sense this is how you back track a missile launch site to greater accuracy than the initial detection.
If your lock parameters can’t reverse thru the hindcast then you don’t have a complete description of the terms involved in the process and it is possible you may lose lock in the future.
In your case your jetstream should be within the range the sliding window from whatever time it takes to build up. Essentially a jetstream doesn’t just appear instantly or disappear overnight there are process required for it to form and those processes take time because they involve alot of energy. That is the same restriction placed on the ability of plane or rocket to turn or bank even when trying to avoid the patriot which is hunting it down.
eric1skeptic says:
July 29, 2013 at 8:45 am
I’m not sure that matters since the differences between various predictions or projections are all well within the maximal rates of change of al the values involved. You appear to be talking about trimming an enormous space of possible solutions which still leaves behind a fairly large space.
You will always have a window when trying to “lock” to a chaotic signal that is true, and in the same sense you also always have jitter on phase locked loop. These processes lock by continual adaption of the sliding window.
So the forward prediction is more strict locally and much wider as you go out longer.
Take our humble patriot missile once it has “lock” on a missile it has a tight window on the target and will put a square to look at in front of the target and it will be centred at the position it is most likely to be. It also provides a longer much bigger window right out to an impact target if required but one can not say with absolute certainty what the end value will be you have a probability range.
Really the result is no different to the IPCC models they have a central value they predict and a range either side they look like this
http://www.realclimate.org/images/model122.jpg
Philip Peake says:
July 29, 2013 at 10:56 am
It did – See Fortran 90, Fortran 2013 and others. Now you have teach the old user community how to write good Fortran.
Dear I. K. H. (I just cannot bear to write and, thus, THINK, “ick” for you, wonderful scientist!),
Thank you, so much, for taking time out from your excellent, high-level, discussion to encourageme by affirming my reading of the information presented. That YOU said so makes me highly value the compliment.
I heartily agree. Computer Science is a rigorous, high-level intelligence, area of study. The logic and analytical thinking skills of computer scientists are second to none. Also, almost without exception, as I know from talking with my software engineer brother and IT geeks (even really young ones), they are and take great pride in being very patient with non-computer saavy people and extremely good at “translating” into layperson’s language technical talk and computer science concepts.
Your grateful student,
Janice
P.S. I think what MOST makes me realize how smart you C.S. people are is how challenging I found my computer science courses (for a B.S. in Computer Science-Business). LOL, and they were just starting to offer “C” (a NEW language) my senior year. No, I did not take it! Pascal is as much as I learned. Anyway, knowing a little of the area makes me doubly aware of how amazingly bright software engineers are. BTW, I was surprised to read above that FORTRAN was still used; it was considered obsolete (or so I thought!) by my freshman year of college (1982-83). We did learn COBOL (just in case we came upon it — (smile)).
This is one of a number of current jobs for FORTRAN developers that do not have a degree in computer science. Because this is in Greenbelt, I assume that this is related to NASA (GSFC – Goddard Space Flight Center). (There are lots of hits when you search for “Goddard Space Flight Center” and FORTRAN.)
Scientist
Contribute to the development of two-moment cloud microphysical scheme in GEOS-5 model and its successors. Run GEOS-5 model and produce higher level diagnostics related to clouds, aerosol, and precipitation to compare with observations. Link GEOS-5 cloud microphysical scheme with aerosol microphysical scheme.
Job Experience: PhD in atmospheric science, oceanography or geoscience. Experience in working on and running large-scale Earth-System models. Experience in working in supercomputer computational environments. Proficient in Fortran, Unix shell script, GrADS.
Job Location – Greenbelt, Maryland, United States
” LdB says:
July 29, 2013 at 6:54 pm
In your case your jetstream should be within the range the sliding window from whatever time it takes to build up. Essentially a jetstream doesn’t just appear instantly or disappear overnight there are process required for it to form and those processes take time because they involve alot of energy. ”
But that is only useful in very short term prediction like required in weather forecasting. One doesn’t have the feedback mechanism when looking say 100 or 50 years into the future when trying to assess what cost effective, justifiable precautionary actions should be taken to mitigate the dangerous model predicted changes in climate that may or may not occur in a region. This is the practical purpose of climate models that most on this site are sceptical about.
They misuse computers the same way they misuse statistics.
Nice detective work, Robert Clemenzi (7/29, 10:22PM). Veehhlly eentehrehsteeeng.
ikh says (July 27, 2013 at 4:06 pm):
FORTRAN was originally designed, in effect, as a medium-level language for the IBM 704 mainframe. Its half-century (semicentennial?) could’ve been celebrated as early as 2004 (based on its preliminary report being completed in 1954; the FORTRAN I compiler was first released in 1957). The language was a hard sell at the outset, because its potential customers were skeptical that adequate speed could possibly be obtained in programs not coded in assembler. So the optimizations by that compiler were crucial to its acceptance, even when it was a product confined to IBM computers. As a result, expectations of compiler optimizations and their benefits became an early & permanent part of the FORTRAN culture. A paper published in 1964 counted 43 FORTRAN compilers in existence across the computer industry; FORTRAN I for UNIVAC’s Solid State 80 seems to’ve been the first running outside IBM (Jan. 1961).[*1] The famously effective optimizing compiler known as IBM FORTRAN H (‘H’ encoding its compilation main-memory requirement) had appeared by 1969.
The primary historical reasons for not using FORTRAN in “the commercial world” was that its alphabetic character-manipulation was so awkward in what was fundamentally a computer-word oriented language (a word being 30-something or 40 bits long on many early mainframes), plus its complete neglect of the Binary-Coded Decimal (BCD) data type that was typically unimplemented in the “scientific” lines of the mainframes of the era. FORTRAN’s lack of pointers largely disqualified it for “systems” programming; altho’ they could be emulated via excursions into assembly code, and sneakiness with customarily unchecked subroutine parameters, such
subterfugestechniques were not portable across any architectures that weren’t plug-compatible.In the early years of FORTRAN, the “the commercial world” used separate lines of “commercial” mainframes, without binary floating-point. They using other languages that were specialized for their distinct categories of programming, featuring BCD. I’m assuming that you wouldn’t want binary-floating-point approximation or round-off errors to affect your bank accounts.
So to be fair, the arguably venerable FORTRAN language was not designed to be suitable for those categories of programming (even tho’ its wide-spread availability has allowed really determined programmers to use it successfully for some “system” or character-manipulation categories, despite the programming pain that was undoubtedly involved).
Ric Werme says (July 27, 2013 at 5:58 pm):
FORTRAN has proven to be an unusually long-lived programming language. Not because it’s a language of elegant beauty (APL has the edge on elegance for writing code), nor because it provides the best of all possible worlds (PL/I, Ada, or Algol 68 are probably among the closest to ideals of universality), but because it’s remained very effective at coding the kinds of software that it was designed for.
Notes:
*1: Programming Research Group of IBM Applied Science Div.: “Preliminary Report: Specifications for the IBM Mathematical FORmula TRANslating System, FORTRAN”. Nov. 10, 1954). The software itself was apparently not available (or at least not outside its mostly-IBM “working committee”) until 1957. (Jean E. Sammet 1969: Programming Languages: History and Fundamentals, § IV.3.1, p. 143–150.) An impressive on-line source that I’ve recently discovered is the “History of FORTRAN and FORTRAN II“: a project of the Software Preservation Group of the Computer History Museum.
Seeing another reader give undue praise, in this topic, to a programming language that’s not renowned for its use in numerically-intensive code, perhaps Mr. Watt would be willing to just stand by and see if anything interesting emerges after I kick a particular ant-hill.
ikh says (July 27, 2013 at 4:06 pm):
C !? A language in which every array is formally and practically equivalent to a pointer? And in which programmers blithely perform arithmetic on pointers, not only for sequential access to dynamically-allocated data based on pointer syntax, but also to variables declared using array syntax, and even for the mundane purpose of retrieving main-program and
functionparameters? Maybe there’s been a concerted effort to tighten up the language as compiled, but back when I last used it for something largish, any combination of C’s inside-out pointer syntax was valid, and may the Good Lord help you if it wasn’t the syntax that you really needed to code to access your data-structure as you intended. Because you could be sure that the generated code would heedlessly access some memory somewhere.Even the language’s principal designer Dennis Ritchie admitted [*2]:
The phrase “pointer aliasing“, when submitted to search engines, provides a good start
in learning about this compiler-optimization issue that’s especially important to C.
The only silver lining is that early C zealots disparaged compiler optimization, boasting of their ability to produce highly efficient code simply by careful crafting of their C source code. So it might still be that the much larger modern C culture continues to follow the lead of their earlier evengelists, thus remaining somewhat indifferent to having compilers optimize their code.
Ric Werme says (July 27, 2013 at 5:58 pm):
C is not much more than a medium-level language for the DEC pdp-11 minicomputer. Its ANSI standard (1989) even kept its
gotostatement. At least C++ prohibitsgotointo a compound statement.Ric Werme says (as linked above):
True, but wouldn’t you say that was a major rationale for the invention of C++?
Notes: *2: Dennis M. Ritchie 1993: “The Development of the C Language”. http://www.cs.bell-labs.com/who/dmr/chist.html.