Forgot your password?
typodupeerror

Comment: Re:Why stop there? (Score 1) 752

by luzr (#30510496) Attached to: The Environmental Impact of PHP Compared To C++ On Facebook

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...

Comment: Re:Why stop there? (Score 1) 752

by luzr (#30506366) Attached to: The Environmental Impact of PHP Compared To C++ On Facebook
OK, you are correct that unconditional but indirect procedure calls (where target address is not a constant) are wholy different kind of beast.

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.

Comment: Re:C++ is bad for the environment (Score 1) 752

by luzr (#30505510) Attached to: The Environmental Impact of PHP Compared To C++ On Facebook

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...

Comment: Re:Why stop there? (Score 1) 752

by luzr (#30504980) Attached to: The Environmental Impact of PHP Compared To C++ On Facebook

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.

Comment: Re:Why stop there? (Score 1) 752

by luzr (#30504568) Attached to: The Environmental Impact of PHP Compared To C++ On Facebook
Because C++ is faster?

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.

Comment: Re:Can we please stop with the "denialist" crap? (Score 1) 1093

by luzr (#30421406) Attached to: The Limits To Skepticism
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?

Comment: Re:The Future Of Medicine (Score 1) 193

by luzr (#30364042) Attached to: Zombie Pigs First, Hibernating Soldiers Next

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 :)

System checkpoint complete.

Working...