sorry, read my post (and the paper) again: "original c++" > "original java". After expert improvements (Jeremy Manson): "original c++" == "improved java" (see my orignal quote). I am assuming here that by "original C++ implementation" the article refers to the c++ version without any tuning (mainly no hash_set, which is not official standard, yet).
My point is that, you can get pretty much the same performance out of java and c++, but you need a good java programmer to do that. On the other hand you need a failry good programmer to get a working c++ version at all.
Jeremy Manson brought the performance of Java on par with the original C++ implementation
essentially they say that you need some kind of expert to produce java code that is on par with "straight forward c++". This corresponds somehow to my own experience (java can be fast, if you put in the effort). On the downside, you need some kind of expert to create normal (=good) c++ code in the first place...
It is relevant, because Java (especially the SUN hotspot VM, so this includes scala) must have been the most ambitioned attempt to create a fully hw-independent, garbage collected and jit-ed "language platform" ever. Java is the best representative for any comparison of "non-native" vs. "native". Still, contrary to what has been claimed, in most cases you can only achieve "sub-native" performance (especially when you consider that the java vm, by design, makes it impossible to directly exploit stuff like SSE, which can have a huge impact).
*warning: false dilemma ahead*
BUT: If I was, for any reason, forced to choose a single language to use (i.e. get work done) in the future, it would probably be c++.
yes, it is much better to make things clear to other programmers (which most of the time also helps the compiler find potential errors better). Without much effort, I only could only reproduce a speedup of about 1.5% using stl iterators vs. array indexing in a micro benchmark (max element in an int-array). The original scenarios are harder to reproduce in an isolated benchmark. Anyway, it is only measurable on intel core/core2/nehalem cpus. On recent amd cpus there is no difference. My original point was to counter the STL-is-100-times-slower-than-anything-else comments, though.
yes, that seems to be the common knowledge and i am still avoiding pointer arithmetics where possible (recently i like stl iterators though, as a way to give the compiler (and other humans) as much information as possible about the real intention of the code). And still, replacing the array indexing got me speedups >5% for inner-loop stuff on gcc, on more than one occasion (i don't remember the details using icc).
don't forget that "printf("0x%08x\n", x);" is still completely valid c++ code. The fact that some people prefer iostreams is no reason eveyone should use them (c++ is not pre 1.5 java!).
IMHO no one should use c++ exceptions before reading and understanding at least some parts of GOTW.ca or the nicer version in Herb Sutters's 'exceptional c++' .
how true
I had this funny 'aha' moment doing some simple operations on all elements of an int array: using a stl::vector and an iterator is actually faster than a plain-c int-array indexed by the loop-counter. The stl version boils down to pure pointer arithmetics, while the c version has the indexing overhead. Sure you can do the equivalent in c (as fast as an stl iterator, surprise, surprise), but honestly I like to keep away from this kind of stuff, most of the time.
well, now that he knows which chemicals to use and which wires to tap, it should take considerably less than 6 months to do it again. Basically the security of this tpm seems to be mainly based on obscurity (in this case complicated hardware).
even though it is not up to date, I found http://xkcd.com/195/ to be quite interesting. It is surprising (well not quite surprising) that halliburton owns a/8 block...
How do you say widget.visible = true in English? "Set widget's visible to true"? "Set the visible of the widget to the value true"? "Set visible of window to true"?
or more basic, wouldn't a non-programmer expect it to be just 'make widget visible' or 'show widget'? In the end it seems to come down to introducing shitloads of special purpose keywords.
It's actually kind of funny how many countless tons of shit I had to go through with Windows computers to get the sound working.
you mean, stuff like waiting two years for a certified 64bit Vista driver (not everyone has time to spend hours trying to get vista64 to accept an uncertified driver)? Meanwhile the linux driver was there as soon as I installed the first 64bit kernel. And the sound card wasn't even some prehistoric piece of junk, but a quite reasonable and still-in-production M Audio delta 44.
The EC has to stop interfering in things it does not understand.
First the ridiculous Microsoft case, and now this?
The easiest way to stop the EC from interfering is by not selling your products on the European market.
Use our market, obey our rules. Simply put. (It's a bit like the old American saying about 'eating cakes'...)
The real problem was that most large distributions (fedora in my case) dropped KDE 3.5 support entirely as soon as 4.0 came out. This forced me to completly skip the FC9 release, and eventually to move on to a distribution without the continuous half-year release terror.
Slashdot Mirror
Don't forget c++0x and the Chevy volt!
they actually needed to do a study?
sorry, read my post (and the paper) again: "original c++" > "original java". After expert improvements (Jeremy Manson): "original c++" == "improved java" (see my orignal quote). I am assuming here that by "original C++ implementation" the article refers to the c++ version without any tuning (mainly no hash_set, which is not official standard, yet).
My point is that, you can get pretty much the same performance out of java and c++, but you need a good java programmer to do that. On the other hand you need a failry good programmer to get a working c++ version at all.
Jeremy Manson brought the performance of Java on par with the original C++ implementation
essentially they say that you need some kind of expert to produce java code that is on par with "straight forward c++". This corresponds somehow to my own experience (java can be fast, if you put in the effort). On the downside, you need some kind of expert to create normal (=good) c++ code in the first place...
It is relevant, because Java (especially the SUN hotspot VM, so this includes scala) must have been the most ambitioned attempt to create a fully hw-independent, garbage collected and jit-ed "language platform" ever. Java is the best representative for any comparison of "non-native" vs. "native". Still, contrary to what has been claimed, in most cases you can only achieve "sub-native" performance (especially when you consider that the java vm, by design, makes it impossible to directly exploit stuff like SSE, which can have a huge impact).
the firefox team already divided it by infinity five years ago
*warning: false dilemma ahead*
BUT: If I was, for any reason, forced to choose a single language to use (i.e. get work done) in the future, it would probably be c++.
yes, it is much better to make things clear to other programmers (which most of the time also helps the compiler find potential errors better).
Without much effort, I only could only reproduce a speedup of about 1.5% using stl iterators vs. array indexing in a micro benchmark (max element in an int-array). The original scenarios are harder to reproduce in an isolated benchmark. Anyway, it is only measurable on intel core/core2/nehalem cpus. On recent amd cpus there is no difference. My original point was to counter the STL-is-100-times-slower-than-anything-else comments, though.
yes, that seems to be the common knowledge and i am still avoiding pointer arithmetics where possible (recently i like stl iterators though, as a way to give the compiler (and other humans) as much information as possible about the real intention of the code). And still, replacing the array indexing got me speedups >5% for inner-loop stuff on gcc, on more than one occasion (i don't remember the details using icc).
don't forget that "printf("0x%08x\n", x);" is still completely valid c++ code. The fact that some people prefer iostreams is no reason eveyone should use them (c++ is not pre 1.5 java!).
IMHO no one should use c++ exceptions before reading and understanding at least some parts of GOTW.ca or the nicer version in Herb Sutters's 'exceptional c++' .
how true
I had this funny 'aha' moment doing some simple operations on all elements of an int array: using a stl::vector and an iterator is actually faster than a plain-c int-array indexed by the loop-counter. The stl version boils down to pure pointer arithmetics, while the c version has the indexing overhead. Sure you can do the equivalent in c (as fast as an stl iterator, surprise, surprise), but honestly I like to keep away from this kind of stuff, most of the time.
you are right. The original author must have confused them with SUN.
well, now that he knows which chemicals to use and which wires to tap, it should take considerably less than 6 months to do it again. Basically the security of this tpm seems to be mainly based on obscurity (in this case complicated hardware).
It's good to know that Jack Bauer is out there to protect us! (uuhmm, wait...)
even though it is not up to date, I found http://xkcd.com/195/ to be quite interesting. It is surprising (well not quite surprising) that halliburton owns a /8 block ...
I had an Ayn Rand quote in my sig until recently but got tired of it. It just didn't work (as in 'clever'). Who knows why...
You should heed your own words there. Talking about epic failure on slashdot is all kinds of epic failure, you pathetic keyboard warrior.
None of them will be compatible, and FAT32 somehow remains the only viable option for removable media.)
So in one of your possible ideal worlds, I would have to use ZFS on a 2GB SD card? Sounds interesting.
How do you say widget.visible = true in English? "Set widget's visible to true"? "Set the visible of the widget to the value true"? "Set visible of window to true"?
or more basic, wouldn't a non-programmer expect it to be just 'make widget visible' or 'show widget'? In the end it seems to come down to introducing shitloads of special purpose keywords.
It's actually kind of funny how many countless tons of shit I had to go through with Windows computers to get the sound working.
you mean, stuff like waiting two years for a certified 64bit Vista driver (not everyone has time to spend hours trying to get vista64 to accept an uncertified driver)? Meanwhile the linux driver was there as soon as I installed the first 64bit kernel. And the sound card wasn't even some prehistoric piece of junk, but a quite reasonable and still-in-production M Audio delta 44.
If I want to walk a windows user through ...
Never quite unerstood why I should want to do that.
The EC has to stop interfering in things it does not understand.
First the ridiculous Microsoft case, and now this?
The easiest way to stop the EC from interfering is by not selling your products on the European market. ...)
Use our market, obey our rules. Simply put. (It's a bit like the old American saying about 'eating cakes'
On the other hand I don't think that carrying around data on a (normally unencrypted) harddisk naturally is a better solution either...
The real problem was that most large distributions (fedora in my case) dropped KDE 3.5 support entirely as soon as 4.0 came out. This forced me to completly skip the FC9 release, and eventually to move on to a distribution without the continuous half-year release terror.