Correct, but it does not change the premise. Actually, all major C++ compilers are well aware about the situation and are very good at optimizing inlines (and not optimizing when it does not make sense).
They can only really do a good job if they're taking into account the size of the caches, and that's not portable at all. A lot of people don't have the luxury of only ever coding for one processor variant.
First, in real modern CPUs _practical_ differences are not that big. E.g., put the inlining limit to 32 bytes (for fast code) and you will hardly see performance degradation anywhere.
But the main issue: inlining often leads to code that is actually shorter than the call.
(Curiously, I work somewhere where that level of optimization is sometimes used for real.
So do I. I have spent years optimizing stuff in C++. Benchmarking and examining produced assembly is my second nature. That is why I am pretty sure I could not achieve C++ levels in any other language, assembler included.
In fact, what really counts is not inlining itself, but optimization across multiple functions call - in C++, multiple calls can get collapsed into a couple of assembly instructions. Often, such collapsing leads into less code bytes than required to perform function call.
If you're only inlining trivial accessors then you're correct, but that's not the only case that people inline. For something longer, it's a much trickier tradeoff.
Specifically, in my C++ code, String comparison inlined fast path collapses to 5 assembler opcodes. That is about as long as function call.
And I would not call String comparison trivial accessor.
But even so, the problem of even trivial accessors is that they often tend to go deep. In container intense code, without inlines, you might end spending 50% of time just managing stack frames for element retrieval calls.
(And inlines have that ABI-bake-in problem which you ignored, which really bites in production libraries. Mainline developers don't see the issue, but maintenance programmers and deployment engineers do.)
No dispute there, there is a big problem with C++ and maintaining shared library compatibility.
For most applications it can be easily solved by not using shared libraries... Facebook would be a nice example. After all, PHP does not produce.so libraries as well...
All of that is expecting that C++ would just replace PHP scripts.
Anyway, if you want to be really fast, you could completely rewrite the whole thing and add huge data caches managed by C++, removing most of DB traffic in the process.
C/C++ is mabye 10-100x faster and more efficient for carefully written inner loops. At the level of whole systems, it's an entirely different story. Because C++ lacks garbage collection, people end up retaining far more memory than they need to.
Only people still using manual memory management.
Because algorithms are far harder to express in C++, people end up using brute force algorithms (linear search, etc.) a lot.
Is this some kind of joke? I would swap C++ for PHP anytime to actually GAIN possibility to express algorithms easily.
There is no such language where experienced programmer could do refined algorithm a well as in C++.
Because templates need specially compiled versions for each combination of template arguments, you end up with dozens of different instances of basically the same code.
Yeah, app code might occupy a little bit more. Really big apps in C++ have say 20 MB compiled. So they would be only 15MB without extensive template use. Hardly any difference if your memory space is in gigabytes.
But for many applications, like GUIs, C++ not only fails to be faster, it also ends up making everything a lot slower and more bloated.
It is hard to make general statements about C++ and GUI. In some cases, like MFC, you are certainly true. Other like Qt are better. Some claim to outrun everything else in terms of both development costs and runtime performance:
If our desktops were largely written in Python, Ruby, or Smalltalk, we'd be using a lot less energy and be able to get by with smaller, less-powerful machines. That's in addition to all the savings from the reduced number of bugs and reduced development costs.
What a pity they are mainly written in C (GTK, Windows), Java (Android) and Objective C (MacOS X) then...
Seriously, if you take into account templates and inlining, there is a good chance that moderately good C++ code will run faster than moderately good assembly, on x86-64 of course - simply because assembler coder would not have the patience to take all opportunities of inlining.
You might think so, but it's not as simple as all that. You also have to take into account the CPU's caching behavior; large numbers of inlines can (i.e., I've seen it happen) make the size of the working set too large to fit in L1 (or even L2) cache.
Correct, but it does not change the premise. Actually, all major C++ compilers are well aware about the situation and are very good at optimizing inlines (and not optimizing when it does not make sense).
In fact, what really counts is not inlining itself, but optimization across multiple functions call - in C++, multiple calls can get collapsed into a couple of assembly instructions. Often, such collapsing leads into less code bytes than required to perform function call.
BTW, branch prediction does not have anything to do with unconditional procedure calls. Branch prediction is about conditional jumps. That said, yes, modern CPUs are pretty good at about everything.
Seriously, if you take into account templates and inlining, there is a good chance that moderately good C++ code will run faster than moderately good assembly, on x86-64 of course - simply because assembler coder would not have the patience to take all opportunities of inlining.
Umm, no one is arguing that. There is not one single AGW proponent out there that would claim that global warming is going to destroy all live as we know it.
Sorry, I can agree with above points, but where is the "settled science"?
There are good reasons to get aways from fossil fuels, but that does not prove or disprove AGW theory, correct?
That's probably not going to sit well with the rest of the world, besides being impossible and causing serious economic problems.
See? Right here you say that artificially increasing prices of oil via carbon tax is OK, but if prices will go up because of economy (that happens if some resource becomes scarce), all sudden everything is wrong and we will have serious problems.
Don't you see that carbon taxes will create exactly the same problem, this time possibly for some artificial reson?
Does anyone else have any ideas how we might go about solving the population problem should we obtain the ability to keep people alive much longer and fight back death? A solution that can realistically be achieved in at most, the next 91 years.
Interestingly, all you need to limit the immortal population is to allow a maximum of two children per parents (or maximum one child per person).
Not that big deal IMO. China was able to do even better:)
Of course, there would still be much more people. We will still need to move out to the space.
OTOH, in most advanced countries we have a population decline. Immortality is one way to deal with the problem:)
A solution that can realistically be achieved in at most, the next 91 years.
That is in fact quite a long time. 91 years ago was the time of first cars, planes and electronics...
Also, thinking about it.... Does not "hibernation" technology also give you means to deal with growing population? Would not be bad if you get bored to hibernate until more interesting times. Putting to the extreme, you can hibernate large fraction of population until you develop technology to colonize the space:)
Well, the second link only shows data since the little ice age. Nobody disputes that it is now warmer than in those times (a nobody sane really complains). So it is mostly irrelevant to the issue. You cannot base any claims on last 500 years.
Nice. So we expect some unknown environmental factor after 1960, but we know for sure this or other enviromental factor was not present for the rest 1000 years, correct?
Do you seriously believe that such thinking is not logically flawed? Really?
Nah. Everybody alarmist knows that volcanic activity cannot rise CO2 levels:)
It is interesting how nature always seems to cooperate with AGW theory. If it is warming, we have no explanation other than CO2 and strong positive feedback. Natural cycles? Impossible! They are not powerful enough!
If warming stops while CO2 goes up, we know for certain that it has stopped because of something else, like, uhm, natural cycles?
The researchers did not use certain tree ring data post 1960 because it was not properly calibrated to instrumental data.
"not properly calibrated" means they did not match temperature, were pointing down while temperature up. And there was no way to "calibrate" them.
There has been much hoo-hah about this "throwing out" of data when really it is the instrumental data that matters, not the proxy data. If temperature is what you are after, thermometers are the gold standard. Therefore the post 1960 results really aren't in question.
Yes. But if post 1960 results of proxy vs temperature do not match, PRE 1960 proxy temperatures ARE in question.
In other words, how can we know that proxy shows correct temperature for MWP, if it cannot be "calibrated" to match instrumental record?
If one completely ignores any of the above data sets (whether they be direct measurements or proxies), there exist many disparate observations of global warming ranging from the rise in sea level which threatens various nations' lands to the melting of the arctic tundra to the loss of glaciation document global warming independently of these scientists' data.
No dispute about that.
All the data seem to indicate is that the warming is happening on a scale that it has not before.
But a lot of question here. Was there MWP? Was there little ice age? Is this really happening on a scale not known before?
By itself, this should indicate that the hockey stick curve is real.
It can only indicate that there was warming 1975-2000. Nothing more.
If you join random noise for 1000-1960 and then put 1975-2000 intrumental record next to it, you will get the curve too.
This year, the Chinese government limited fossil fuel burning before the Olympics with apparently stunning results. When I was in Beijing for nearly a month 10 years ago, smog was a daily occurance. Even miles outside the city at Badaling (the Great Wall), it was hard to see for more than a mile. Smog is considered to be the third most important greenhouse gas by the IPCC. Evidence that we are changing our own atmosphere by fossil fuel emission is obvious just by looking.
Nice anectodal story, but what that has to do with AGW?
I notice you don't mention which data had arbitrary fudge factors applied to it - probably because it sounds more ominous that way. Data from tree cores taken in the Nothern hemisphere post-1960 had arbitrary fudge factors applied to it, and as far as anyone can tell the results were thrown away. It appears the code was part of an attempt to determine why and how the temperatures claculated from the tree cores diverged from the actual temperature. In the end, the researchers didn't find an answer and just advised not using that data.
Well, but you should tell the whole story then. In IPCC graphs these records were simply replaced by instrumental data.
Now, if they "didn't find an answer", it makes the whole reconstruction a little bit strange. If proxies do not match temperatures when you have the most accurate datasets, how can you tell they correctly represent temperatures 1000 years ago?
Please carefully read what I wrote. You response is absolutely out of context.
Really, I do not care about about cheering somebody's death or calling sceptics crackpots. I understand that emails were private.
But if you raise the issue of "trick", I thought I will help you to understand the problem.
Maybe the term "deleted" is wrong, but these data were simply removed from the hockey stick graph, replaced by instrumental record, creating false illusion of "unprecendented warming". And then the graph is used in Al Gore's presentations.
Deleting 30 years of inconvinient data and replacing it with something else is now considered the "standard statistical technique"?
See, nobody disputes that instrumental records for past 30 years are more accurate than data obtained by proxy. Anyway, if there is such a divergence of proxy data and instrumental record (proxy data pointing downwards), it casts serious doubts about validity of proxy data of the past.
Also, it means that to show the hockey stick, you in fact do not need care about proxy data too much. Instrumental record will make the right shape even if you feed anything before with noise.
I guess that the most important issue in Mann's and Briffa reconstruction is that MWP was downplayed and current warming thus became "unprecedented". Which is exactly what you get if you choose noisy unreliable proxy data, and 'stick' real temperature records where it fits...
If you see any flaws in this analysis of "trick to hide the decline", I would be glad to hear your objections.
Uh huh...and pull this leg, it plays jingle bells! Seriously, how many times have you had to go CLI in the past month?
Less often than I had to use that fancy Registry editor in Windows to solve issues with broken installs or drivers.
See, if everything goes fine, GUI is all that you need in both Win32 and Linux. If things get broken (e.g. because some app installs get them broken, which happens on both platforms), you need to get yout hands dirty, in any OS.
Accidentally, if things get broken, there is much higher chance that they get fixed in Linux, with its CLI and text based configs (and even with those opened sources, ya know?).
Contrary, common practice to repair Windows is reinstall. Maybe that is why you live in impression that GUI is fine to manage Windows. When Linux user uses CLI to fix the problem, Windows user reinstalls....
Slashdot Mirror
Correct, but it does not change the premise. Actually, all major C++ compilers are well aware about the situation and are very good at optimizing inlines (and not optimizing when it does not make sense).
They can only really do a good job if they're taking into account the size of the caches, and that's not portable at all. A lot of people don't have the luxury of only ever coding for one processor variant.
First, in real modern CPUs _practical_ differences are not that big. E.g., put the inlining limit to 32 bytes (for fast code) and you will hardly see performance degradation anywhere.
But the main issue: inlining often leads to code that is actually shorter than the call.
(Curiously, I work somewhere where that level of optimization is sometimes used for real.
So do I. I have spent years optimizing stuff in C++. Benchmarking and examining produced assembly is my second nature. That is why I am pretty sure I could not achieve C++ levels in any other language, assembler included.
In fact, what really counts is not inlining itself, but optimization across multiple functions call - in C++, multiple calls can get collapsed into a couple of assembly instructions. Often, such collapsing leads into less code bytes than required to perform function call.
If you're only inlining trivial accessors then you're correct, but that's not the only case that people inline. For something longer, it's a much trickier tradeoff.
Specifically, in my C++ code, String comparison inlined fast path collapses to 5 assembler opcodes. That is about as long as function call.
And I would not call String comparison trivial accessor.
But even so, the problem of even trivial accessors is that they often tend to go deep. In container intense code, without inlines, you might end spending 50% of time just managing stack frames for element retrieval calls.
(And inlines have that ABI-bake-in problem which you ignored, which really bites in production libraries. Mainline developers don't see the issue, but maintenance programmers and deployment engineers do.)
No dispute there, there is a big problem with C++ and maintaining shared library compatibility.
For most applications it can be easily solved by not using shared libraries... Facebook would be a nice example. After all, PHP does not produce .so libraries as well...
But that, as you correctly conlude, in C++ affects mainly switch statements or inter-shared library (or dll) calls and has little to do with inlines.
Anyway, if you want to be really fast, you could completely rewrite the whole thing and add huge data caches managed by C++, removing most of DB traffic in the process.
C/C++ is mabye 10-100x faster and more efficient for carefully written inner loops. At the level of whole systems, it's an entirely different story. Because C++ lacks garbage collection, people end up retaining far more memory than they need to.
Only people still using manual memory management.
Because algorithms are far harder to express in C++, people end up using brute force algorithms (linear search, etc.) a lot.
Is this some kind of joke? I would swap C++ for PHP anytime to actually GAIN possibility to express algorithms easily.
There is no such language where experienced programmer could do refined algorithm a well as in C++.
Because templates need specially compiled versions for each combination of template arguments, you end up with dozens of different instances of basically the same code.
Yeah, app code might occupy a little bit more. Really big apps in C++ have say 20 MB compiled. So they would be only 15MB without extensive template use. Hardly any difference if your memory space is in gigabytes.
But for many applications, like GUIs, C++ not only fails to be faster, it also ends up making everything a lot slower and more bloated.
It is hard to make general statements about C++ and GUI. In some cases, like MFC, you are certainly true. Other like Qt are better. Some claim to outrun everything else in terms of both development costs and runtime performance:
http://www.ultimatepp.org/www$uppweb$vsswing$en-us.html
If our desktops were largely written in Python, Ruby, or Smalltalk, we'd be using a lot less energy and be able to get by with smaller, less-powerful machines. That's in addition to all the savings from the reduced number of bugs and reduced development costs.
What a pity they are mainly written in C (GTK, Windows), Java (Android) and Objective C (MacOS X) then...
Seriously, if you take into account templates and inlining, there is a good chance that moderately good C++ code will run faster than moderately good assembly, on x86-64 of course - simply because assembler coder would not have the patience to take all opportunities of inlining.
You might think so, but it's not as simple as all that. You also have to take into account the CPU's caching behavior; large numbers of inlines can (i.e., I've seen it happen) make the size of the working set too large to fit in L1 (or even L2) cache.
Correct, but it does not change the premise. Actually, all major C++ compilers are well aware about the situation and are very good at optimizing inlines (and not optimizing when it does not make sense).
In fact, what really counts is not inlining itself, but optimization across multiple functions call - in C++, multiple calls can get collapsed into a couple of assembly instructions. Often, such collapsing leads into less code bytes than required to perform function call.
BTW, branch prediction does not have anything to do with unconditional procedure calls. Branch prediction is about conditional jumps. That said, yes, modern CPUs are pretty good at about everything.
Actually, no. C does not have templates and inlines are a little bit more limited.
Seriously, if you take into account templates and inlining, there is a good chance that moderately good C++ code will run faster than moderately good assembly, on x86-64 of course - simply because assembler coder would not have the patience to take all opportunities of inlining.
Simple question: What if it is methan or NO2 instead of CO2? Will we spend trillions and achive nothing by cap&trade then?
Oh not, you missed the point again. The real question: Is CO2 pollution?
Umm, no one is arguing that. There is not one single AGW proponent out there that would claim that global warming is going to destroy all live as we know it.
Really?
That's probably not going to sit well with the rest of the world, besides being impossible and causing serious economic problems.
See? Right here you say that artificially increasing prices of oil via carbon tax is OK, but if prices will go up because of economy (that happens if some resource becomes scarce), all sudden everything is wrong and we will have serious problems. Don't you see that carbon taxes will create exactly the same problem, this time possibly for some artificial reson?
The most trivial solution to every problem is always death, of course.
Does anyone else have any ideas how we might go about solving the population problem should we obtain the ability to keep people alive much longer and fight back death? A solution that can realistically be achieved in at most, the next 91 years.
Interestingly, all you need to limit the immortal population is to allow a maximum of two children per parents (or maximum one child per person).
Not that big deal IMO. China was able to do even better :)
Of course, there would still be much more people. We will still need to move out to the space.
OTOH, in most advanced countries we have a population decline. Immortality is one way to deal with the problem :)
A solution that can realistically be achieved in at most, the next 91 years.
That is in fact quite a long time. 91 years ago was the time of first cars, planes and electronics...
Also, thinking about it.... Does not "hibernation" technology also give you means to deal with growing population? Would not be bad if you get bored to hibernate until more interesting times. Putting to the extreme, you can hibernate large fraction of population until you develop technology to colonize the space :)
Yes. And the conclusion?
How can you provide evidence of something like that?
Well, the second link only shows data since the little ice age. Nobody disputes that it is now warmer than in those times (a nobody sane really complains). So it is mostly irrelevant to the issue. You cannot base any claims on last 500 years.
Do you seriously believe that such thinking is not logically flawed? Really?
Overal trend is rising since little ice age... No need to involve CO2 into the process.
It is interesting how nature always seems to cooperate with AGW theory. If it is warming, we have no explanation other than CO2 and strong positive feedback. Natural cycles? Impossible! They are not powerful enough!
If warming stops while CO2 goes up, we know for certain that it has stopped because of something else, like, uhm, natural cycles?
Sorry, but I do not buy that. Call me denier.
The researchers did not use certain tree ring data post 1960 because it was not properly calibrated to instrumental data.
"not properly calibrated" means they did not match temperature, were pointing down while temperature up. And there was no way to "calibrate" them.
There has been much hoo-hah about this "throwing out" of data when really it is the instrumental data that matters, not the proxy data. If temperature is what you are after, thermometers are the gold standard. Therefore the post 1960 results really aren't in question.
Yes. But if post 1960 results of proxy vs temperature do not match, PRE 1960 proxy temperatures ARE in question. In other words, how can we know that proxy shows correct temperature for MWP, if it cannot be "calibrated" to match instrumental record?
If one completely ignores any of the above data sets (whether they be direct measurements or proxies), there exist many disparate observations of global warming ranging from the rise in sea level which threatens various nations' lands to the melting of the arctic tundra to the loss of glaciation document global warming independently of these scientists' data.
No dispute about that.
All the data seem to indicate is that the warming is happening on a scale that it has not before.
But a lot of question here. Was there MWP? Was there little ice age? Is this really happening on a scale not known before?
By itself, this should indicate that the hockey stick curve is real.
It can only indicate that there was warming 1975-2000. Nothing more. If you join random noise for 1000-1960 and then put 1975-2000 intrumental record next to it, you will get the curve too.
This year, the Chinese government limited fossil fuel burning before the Olympics with apparently stunning results. When I was in Beijing for nearly a month 10 years ago, smog was a daily occurance. Even miles outside the city at Badaling (the Great Wall), it was hard to see for more than a mile. Smog is considered to be the third most important greenhouse gas by the IPCC. Evidence that we are changing our own atmosphere by fossil fuel emission is obvious just by looking.
Nice anectodal story, but what that has to do with AGW?
I notice you don't mention which data had arbitrary fudge factors applied to it - probably because it sounds more ominous that way. Data from tree cores taken in the Nothern hemisphere post-1960 had arbitrary fudge factors applied to it, and as far as anyone can tell the results were thrown away. It appears the code was part of an attempt to determine why and how the temperatures claculated from the tree cores diverged from the actual temperature. In the end, the researchers didn't find an answer and just advised not using that data.
Well, but you should tell the whole story then. In IPCC graphs these records were simply replaced by instrumental data.
Now, if they "didn't find an answer", it makes the whole reconstruction a little bit strange. If proxies do not match temperatures when you have the most accurate datasets, how can you tell they correctly represent temperatures 1000 years ago?
Really, I do not care about about cheering somebody's death or calling sceptics crackpots. I understand that emails were private.
But if you raise the issue of "trick", I thought I will help you to understand the problem.
Maybe the term "deleted" is wrong, but these data were simply removed from the hockey stick graph, replaced by instrumental record, creating false illusion of "unprecendented warming". And then the graph is used in Al Gore's presentations.
See, nobody disputes that instrumental records for past 30 years are more accurate than data obtained by proxy. Anyway, if there is such a divergence of proxy data and instrumental record (proxy data pointing downwards), it casts serious doubts about validity of proxy data of the past.
Also, it means that to show the hockey stick, you in fact do not need care about proxy data too much. Instrumental record will make the right shape even if you feed anything before with noise.
I guess that the most important issue in Mann's and Briffa reconstruction is that MWP was downplayed and current warming thus became "unprecedented". Which is exactly what you get if you choose noisy unreliable proxy data, and 'stick' real temperature records where it fits...
If you see any flaws in this analysis of "trick to hide the decline", I would be glad to hear your objections.
Uh huh...and pull this leg, it plays jingle bells! Seriously, how many times have you had to go CLI in the past month?
Less often than I had to use that fancy Registry editor in Windows to solve issues with broken installs or drivers.
See, if everything goes fine, GUI is all that you need in both Win32 and Linux. If things get broken (e.g. because some app installs get them broken, which happens on both platforms), you need to get yout hands dirty, in any OS.
Accidentally, if things get broken, there is much higher chance that they get fixed in Linux, with its CLI and text based configs (and even with those opened sources, ya know?).
Contrary, common practice to repair Windows is reinstall. Maybe that is why you live in impression that GUI is fine to manage Windows. When Linux user uses CLI to fix the problem, Windows user reinstalls....