Back in the day when I was learning to work on cars, I firmly believed using carburators. But fuel injection does give much better fuel efficiency, and better power in stock configurations. Plenty of guys will say that they can make more power with a carburated car, but hey, if you're upgrading, you can upgrade fuel injection too. It just costs more.
Fuel injection also has other added benefits. Economy, power, and smoothness, can not be overlooked. In spite of all the money that is spent on R&D for intakes, it's a really tough nut to get it to deliver fuel/air evenly, throughout the entire powerband, to every cylinder. Thusly, with carbs, you often wind up with one cylinder running rich and another running lean, somewhere within it's power curve. This leads to rough engines (thank god for rubber engine mounts), less than smooth power, and less than ideal economy.
On the other hand, if you use a good FI system with a good set of sensors, the FI system can compensate for less than ideal intakes to provide smoother power, better economy, more power.
Long story short, FI is one of the reasons so many powerful cars (e.g. camero, fireibrd and vet) are still able to get reasonable fuel mileage. Of course, aerodynamics also plays a role. Just the same, FI truly does deliver what it promises.
paticularly those frustrated by the C++/EMACS/Shell
Or, they can use C++/XEMACS/Shell and everything is easy as pie. Unless you're willing to argue that pushing a "compile" or "debug" button is too hard.;)
I strongly point out that I have NOT seem the film. It's not high on my list of films to see, especially since I can't remember the last time I went to see a film. At any rate, I've been told by press and friends alike that the film is about as much a documentary as the early nazi propaganda films. In otherwords, I'm sure there are hints or truth spattered throughout, however, link any good propaganda, it runs with a selective memory and perhaps revised history.
Documentaries are recorded life which have not been cookie-cuttered to meet an agenda. Inversely, propaganda is not.
The above review does seem to hint that the flim is much, much closer to propaganda. Throw in the fact that MM is anti-Republican, actively so, it's not hard to see why he's sharpened his film, such as he has. Sure, if he was a quiet American with a quiet view, he might of been able to make a documentary. But, he's loud and seems to rumble around like an angry holla-dancer on the dash of car, while it drives down a dirt road. I doubt unbiased, fair, or especially the word, "documentary", aptly apply. Thusly, I have no immediate desire to see the film.
That's correct. If you read the news much, you'll hear stories of lighters exploding. Often seriously injuring or disfiguring it's victims. Does it happen often? Not that I know of. In fact, I would consider it to be very rare. Consider the number of lighters, which are very cheaply made, that are in circulation right now. Now, consider how rarely it happens and I think you still have what is a fairly safe device.
Unless someone more schooled than myself can offer more information, I think the risk to terribly, terribly tiny.
Oh, and the Borg have to show up to make things interesting. And the Science officer has to wear a Catsuit. (Do you what kinds of problems that would cause on a REAL ship like Enterprise? You'd constantly be having to deal with situations of attempted rape!)
Oh shesh already! Get with it man! Everyone knows that in the future, man will evolve without a penis. Thusly, your comment of rape is completely unsupportable!;)
Just the same, I really liked the following quotes: Zoe: Preacher, don't the Bible have some pretty specific things to say about killing? Book: Quite specific. It is, however, somewhat fuzzier on kneecaps.
Mal: Ship like this, be with you until the day you die. Zoe: That's because it's a deathtrap.
Wash: Little River just gets more colorful by the minute. What will she do next? Zoe: Either blow us up or rub soup in her hair. It's a toss-up. Wash: I hope she does the soup thing. It's always a hoot, and we don't all die from it.
Those all sound like my kind of humor and fairly intelligent writing too. Well, as I said in another thread, if it comes on as a re-run, I'll check it out again.
I completely agree with you. Seven of Nine, by far, was what easily kept the show on the air.
Thank god they abandoned that formula for Enterprise. While flawed, it's still a big step up from that crapfest.
Well said. I agree.
and IMHO later seasons didn't get any better.
No better? How about worse. Every now and then (maybe twice a year), late at night, I'll catch a re-run of a show from a later season. Rarely am I able to finish an episode. It clearly got worse.
The really, really sad thing is, they had a twnety mile wide door to pull some really great shows through. But, nope, they (the writers) blew it horribly.
Well, like I said, I guess I didn't get it. Sometimes you have to be in the right mood for a type of movie. Other times, knowing a certainly amount of background certainly helps too. I knew and know pretty much nothing about the show. Perhaps I judged too harshly. I dunno. I do recall, while making this post, that I did not catch any episode from the beginning. So, perhaps I missed key elements which would of helped make things a little easier to understand and follow. Some shows are like that; miss the first 5-minutes and your screwed.
The odd things is, when I was watching it, I didn't feel lost or like I didn't understand it. Sure, I had questions, but I didn't FEEL lost. Just the same, I guess I just didn't get it.
I guess if it ever comes back on in re-runs, I'll try to scope it out again to see if I missed anything the first time around.
Hmm...it was so long ago, I'm sure I don't recall the name..I rarely pay attention to the episode titles anyway...of any show.
I remember a ray-gun shootout at an O-K coral of sorts and another episode where some succubus type women was aboard the ship. I think there was some lesbo sexual tension on the later, maybe even a lesbo kiss. Sorry, I really don't remember much beyond that.
Place it with its contemporaries of the time and it actually was pretty good. It's even watchible today. Compare Voyager with its contemporaries and it will make you vomit in any time.;):P
I realize that was tongue and cheek. I don't have a problem giving a show a fair chance. I watched it for something like two seasons. In the second season, it was clearly worse than the first. Yet, I kept hoping. After the second season, I hardly watched it, if ever. The details in my mind, of my watching habbits are somewhat hazzy simply because the show was not memorable and time has passed.
I watched two shows of that. I was like watching a bad western serial, crossed with day time soaps and ray guns. I've asked this before and got modded down before anyone could respond. What is so great about that seemingly backward and awkward show known as, "firefly"? Because I don't get it?!?
I think that DS9 and TNG have a good number of episodes that I'd have to rank as tied. Over all, I think DS9 offered more over a longer period of time. TNG was often good simply because we were all so hungry for some new scifi; especially trek scifi. On the other hand, Voyager, IMO, is the biggest peice of crap to ever become part of the trek genre. I used to piss my wife off by watching the lead-in to the show and tell her exactly what was going to happen, including the really impossibly stupid and lame decisions that Janeway would make. Sure enough, we'd watch the show and it would unfold exactly like I said. I think I was entirely wrong twice out of countless times. Basically, Voyager became unwatchably horrible. Basically, the Janeway moto was, if it's stupid and makes me flawed, I'll do. In a nut shell, anyone as stupid and flawed as the Janeway character would of never made bridge officer, let alone captain; unless she's good at giving head, and then, just maybe.
Enterpise, on the other hand, actually has some shows worth watching from time to time. The characters are developing and plots lines are getting better. Compare that to TNG and you'll see a very strong parallel. Voyage just got worse, tragically so. Janeway became more stupid and pethetic with each show. Enterprise and TNG got better with each show. DS9 often got better by leaps and bounds as the shows continued to be made.
While I'm sure that many love to hate Enterprise, I remember one of the big reasons that I heard about for a long time. That was the intro-theme song. Talk about closed minded, easily ignored opinions. Sure, maybe you hate the song, but who cares. Does it provide a good trek-fest for you? Is it entertaining? The answer is yes, or mostly so. Yet, it's still trying to find it's place, just as TNG did for the first three seasons. IMO, Voyager is what destroyed the value of the trek franshise. If Enterprise can find it's place this next season, then I'll consider it a success. If not, then I'll probably have to write it off. Just the same, Enterprise is a fairly interesting take on the trek-verse, even if there are many plot lines that I personally don't like how they rolled them out.
And, there is still significant room for improvement in the C++ implementation. I see that some have even done GC work which specifically targets transient object creation and destruction. My point being, there is nothing but up for the C++ objinst benchmark. Other prospects would be to simply look at other heap managers as well as simply writing a custom heap manager specifically targeting these transient benchmarks which would reduce the number of deletes to two or three (versus 200,000,000) and completely avoid the overhead of object destruction (currently, 200,000,000). This final solution, I believe, would put it on par (implementation wise) with what the JVM is doing. But, even without an apples to apples comparison, C++ is already taking the lead.
Thus far, I have submitted back four improved benchmarks back to the tester. All that I have submitted back, have been faster than the java implementation. Oddly enough, while attempting to create some additional benchmark runs which would help further remove noise, I started running into some serious problems with java. Bluntly, some of the benchmarks can not be run with java because java runs out of memory on my system (I only have 512M). Even after increasing java's memory up to the ceiling of my free ram, java is unable to complete the benchmark, having run out of memory. In one such test, the c++ code finished in 1.99s while the java code ran out of memory after 6+s. Worse, the c++ code used about 50+M of ram while the java code ran out while attempting to use 380M. Oddly enough, the more work you asked of java, the worse java seemed to do. In my additonal tests of the strcat benchmark, performance tilted toward C++ ranging from 29% to over 300%, depending on the amount of data being processed and which JVM options were being used.
The benchmarks are only flawed in that respect if you want to generalize them for 'big' applications where gc will hamper processing
Actualy, the benchmarks are only flawed if you expect them to reflect server class applications, many workstation class applications, or think that hot spot is able to do so well outside of recursive call chains and/or tight loops where little work is actually being done. In other words, a very broad class of problems may not do so well.
Well duh. That is only surprising if you don't know Java at all.
Well, except that your remark is fairly out of bounds. If you apply that knowledge to real world applications which may collect, especially if they are multithreaded, it shows that someone can be in for some real surprises. Furthermore, I now know (based on some other runs I did), that it takes only a modest number of runs from the collector to significantly effect performance.
Creating good benchmarks (where the results are accurate and meaningful) is very hard and I'm certainly not able to do so (since it requires you to know every possible way to skew the results, knowledge that few people possess, and a certain attitude). Trust me, you can't do it either, so go easy with the wise old sage stuff.
Actually, I have a long history of measuring benchmarks which actually have meaning. I realize you're happy to ignore the ad hok results, however, I understand what they imply. I'm comfortable with the results that it provided. I took my grain of salt and am content.
Lastly, let me say that I think you overly object to the use of java's collector. A foolish amount of overhead was purposely allowed to kill c++'s performance yet if I artificially do the same with the java benchmark, you suddenly cry flaw and bias. Well, I happen to agree (sorta), which I've previously explained several times. Either you level the playing field so that both are flawed or you level the playing field so that both are equal. I purposely knee capped the java benchmark to attempt to level it with C++. The grain of salt is, the playing field was never leveled. Just the same, the knowledge gained underscorded the serious cost accociated with java's collection. Clearly, 1:1 implementation is far more than knee capping. The real problem is, I have no idea how much use of System.gc constitutes a level field knee-cap, thusly, I take my grain of salt and place the known performance data into contect of real world applications. In otherwords, it doesn't look good. Given the time constraints of my desire to contribute something here, the path I followed offered the shortest path while requiring the largest grain of salt.
One of the areas that I must admit I am becoming more impressed with is the call overhead of java. It appears that java is able to significantly reduce call overhead in recursive call chains. The level of reduction is simply nothing more than awesome. Of course, as I stated above, I currently have no idea if that translates into recursivce calls for anything other than trivial work in tight recursive loops.
Sure, gc collection libraries exist for c++. That would be so much more meaningful than simply killing Java's performance by doing something Java programmers are told not to do the instant they are introduced to gc.
Well, the trick is to find a collector that actually performs well, or at least on par in performance with Java's. On the other and, the best c++ solution would be to simply implement a deferred delete method. As an example, ideally, the 200,000,000 deletes presented in one of the benchmarks could be deferred and optimized away into as little as two deletes. I would guess that java is smart enough to be able to do such heap tricks too. My casual playing with it suggests that it can, given some of the benchmarks.
FYI, I've already optimized two C++ benchmarks which are now faster than the java implementations. One of them is 2.2 - 2.7x times faster than java. I've sent my work to the tester. He's accepted them and stated he woudl take the fastest code for each benchmark (Cpp or java) which he gets. So, feel free to check the original pages sometime again in the near future. I suspect there will be many updates.
Java never sold itself as the fasted gun in the west.
This is certainly true. They sold it as write once, run everywhere.
because for the time being (up until the GC turns over) you end up with an app that can rub noses with C++. This article does prove that.
Actually, that's been pretty well debunked within the many threads offered here. What is seems is that it proves that given non-realistic corner cases where hot spot shines versus poorly written C++ code compiled via a less than optimal compiler, java can be as fast, if not faster.
You need to add all the other great features of Java... the most important being that it's a very pragmatic system to code in (no need to explicitly free memory etc etc), Java is a fantastic thing.
That, I certainly agree with. In fact, I'm willing to admit that the many studies which show higher deliverability with Java are probably true. Thus far, to date, I've yet to actually ever see a valid java benchmark which put java on the same page as C++, in terms of performance. While I've not finished looking at all the code, thus far, it does not appear that these will be that exception.
The fact that it can HotSpot and have parts of an application go toe to toe with C++... it makes me a truly happy Java programmer.
But, thus far, we have no proof to support such a statement.
It's another topic, but people also deny its cross platform nature, but it does deliver on this promise. I needed to quickly run a complex IDE (IntelliJ's IDEA) on a linux box, but no Linux version of it. By simply copying the Jars from a windows box and starting it up, it was usable without a problem.
Again, I good point, which I agree with. Java is a very good system for pragmatists. It's just not a high performance system in the real world.
So basically, proper code yields a little over twice (2.2x the server version and 2.7x the client version) the performance of a best-corner case for java's hotspot. That's not exactly close.
Except that, as I understand it, Java, by far, used used in server applications. Thusly, high load over extended durations should be considered the norm and not the exception.
Shocking! Program takes advantage of language features! How dare they!
Coward is right! It is shocking because they took advantage of a language feature under java but failed to do so under C++. Likewise, the benchmark is built around the entire concept of creating a best case situation for java and crap design/code for C++.
I run all of my tests with -server, however, I had already change my config file to do that by default, thusly, making the common line option redundant. I used it mostly just so I could cut-n-paste the commands here so that its use would be obvious.
I should offer, than for the few tests I can, I did not seem much of a difference between -client and -server, though, I sure there are many situations where that would not hold true.
I feel that there are two primary objectives any language comparison tests; one is to test optimizations done by compiler/JVM and two is to compare "normal programming style" from both languages.
I think you have a valid point there. Just the same, it's fairly well known that it requires more skill to get good performance out of C++ than it does for Java. After all, C++ isn't exactly the easiest of languages to master. Likewise, this is why java programmers are often compared to VB programmers (not that I support that view; I see real skill in many java progammers which never existed in the hordes of VB guys). In attempting to comment on the benchmarks, my goal was not to talk poorly about how well hot spot is performing. In fact, if you check my profile and read the many messages on the topic, I'm actually impressed with hot spot and how well it's working. It's just that these benchmarks, while impressive, paint a completely unrealistic view of java's performance as users are likely to encounter them in the wild.
Based on what we've learned, it would probably be fair to asses the results as, in absoluete ideal situations, java can be as fast, if not faster than very poorly coded and less then well optimized c++ in less than ideal situations. Which, doesn't exactly match the original author's voice. Not by a long shot.
I do agreee with you that tests are not fare from the first stand point, as C++ test incurs overhead of destroying objects. However, isn't this standard programming style for C++?
Again, I think your point certainly has merit. Just the same, if you look at the code, one could argue that the c++ code was put together in a manner to represent a worst case performance picture.
As for programming style, I think it's unreasonable to think that most C++ programmers would of implemented most of the code as had been done, at least the code that I've looked at. You could argue that the C++ was a literal translation of the java code, whereby, it avoided many obvious and common sense implementation, "styles".
I do agreee with you that tests are not fare from the first stand point, as C++ test incurs overhead of destroying objects. However, isn't this standard programming style for C++? How often have you built resource managers and how often have you used them for small objects, like strings?
Well, it depends. I have built and implemented my own heap managers, even under C. If absoluete performance is the goal, as one would expect of a benchmark, then it's certainly not out of the ordinary to implement your own new/delete operators. In other words, it's actually not that uncommon. If you look at fairly popular toolkits, such as ACE, you find that many/most of the objects and patterns specifically allow for your own memory management implementations. The reason being, that's the power of C++. Which is often the reason why C++ is used. To be redundant, it's silly to purposely avoid areas open to significant optimizations when performance is the stated goal. Thusly, it highlights just how unfair the tests were.
Just FYI, even a moderately decent heap implementation could of optimized the current 200,000,000 deletes, within the objinst benchmark, into something as little as two deletes, assuming enough memory exists. If we assume enough memory doesn't exist for all object instances, then we could still easily reduce the number of deletes by something in the area of 10,000 orders of magnatude. Regardless, either provides significant reduction in workload, to say the least. That translates into a TON of work suddenly removed from the C++ side of the scale.
I like java very much and I am very glad to see that these days it is being compared to C++ and people ARGUE about which one is faster. Just few years ago the argument would be about "hey, performance is not what Java is all about!
I can't argue with that. Just the same, I think pragmatically, java is going to be significantly slower
Garbage collection has long be heralded as a faster solution than explicit new/delete handling of memory allocation.
This is true, but the experts fairly regularly point at java as an example of what not to do. In otherwords, as far as GC implementations go, Sun's java GC implementation is not considered very technically advanced nor Earth shattering.
Well, as I understand it, it's supposed to collect as time allows AND when it's triggered predefined thresholds, as derived from things like maximum allowed memory and current free heap, etc., etc. I'm sure I'm over simplifying, but I think the point stands.
Beyond that, an explicit call to System.gc(), means, if you are not already doing so, please start attempting to collect. The collector then runs in a low priority thread, which was kicked off by the System.gc() call, again, assuming it's not already running.
Slashdot Mirror
Back in the day when I was learning to work on cars, I firmly believed using carburators. But fuel injection does give much better fuel efficiency, and better power in stock configurations. Plenty of guys will say that they can make more power with a carburated car, but hey, if you're upgrading, you can upgrade fuel injection too. It just costs more.
Fuel injection also has other added benefits. Economy, power, and smoothness, can not be overlooked. In spite of all the money that is spent on R&D for intakes, it's a really tough nut to get it to deliver fuel/air evenly, throughout the entire powerband, to every cylinder. Thusly, with carbs, you often wind up with one cylinder running rich and another running lean, somewhere within it's power curve. This leads to rough engines (thank god for rubber engine mounts), less than smooth power, and less than ideal economy.
On the other hand, if you use a good FI system with a good set of sensors, the FI system can compensate for less than ideal intakes to provide smoother power, better economy, more power.
Long story short, FI is one of the reasons so many powerful cars (e.g. camero, fireibrd and vet) are still able to get reasonable fuel mileage. Of course, aerodynamics also plays a role. Just the same, FI truly does deliver what it promises.
paticularly those frustrated by the C++/EMACS/Shell
;)
Or, they can use C++/XEMACS/Shell and everything is easy as pie. Unless you're willing to argue that pushing a "compile" or "debug" button is too hard.
Between wxWindows and ACE, you have an entire crossplatform framework to build just about any type of application you can dream up.
I strongly point out that I have NOT seem the film. It's not high on my list of films to see, especially since I can't remember the last time I went to see a film. At any rate, I've been told by press and friends alike that the film is about as much a documentary as the early nazi propaganda films. In otherwords, I'm sure there are hints or truth spattered throughout, however, link any good propaganda, it runs with a selective memory and perhaps revised history.
Documentaries are recorded life which have not been cookie-cuttered to meet an agenda. Inversely, propaganda is not.
The above review does seem to hint that the flim is much, much closer to propaganda. Throw in the fact that MM is anti-Republican, actively so, it's not hard to see why he's sharpened his film, such as he has. Sure, if he was a quiet American with a quiet view, he might of been able to make a documentary. But, he's loud and seems to rumble around like an angry holla-dancer on the dash of car, while it drives down a dirt road. I doubt unbiased, fair, or especially the word, "documentary", aptly apply. Thusly, I have no immediate desire to see the film.
That's correct. If you read the news much, you'll hear stories of lighters exploding. Often seriously injuring or disfiguring it's victims. Does it happen often? Not that I know of. In fact, I would consider it to be very rare. Consider the number of lighters, which are very cheaply made, that are in circulation right now. Now, consider how rarely it happens and I think you still have what is a fairly safe device.
Unless someone more schooled than myself can offer more information, I think the risk to terribly, terribly tiny.
I'm assuming you working the humor angle. Just in case...
but I don't believe you can concentrate methanol at all.
I think he meant pure. It was stated that 99.5% pure was to be used.
Errr.. another point of error: being a liquid at normal temperature, methanol is virtually incompressible.
I think he meant pressurized.
Oh, and the Borg have to show up to make things interesting. And the Science officer has to wear a Catsuit. (Do you what kinds of problems that would cause on a REAL ship like Enterprise? You'd constantly be having to deal with situations of attempted rape!)
;)
Oh shesh already! Get with it man! Everyone knows that in the future, man will evolve without a penis. Thusly, your comment of rape is completely unsupportable!
Seriously, you make a look for good points!
Cheers!
I'll pass on the download. Thanks.
Just the same, I really liked the following quotes:
Zoe: Preacher, don't the Bible have some pretty specific things to say about killing?
Book: Quite specific. It is, however, somewhat fuzzier on kneecaps.
Mal: Ship like this, be with you until the day you die.
Zoe: That's because it's a deathtrap.
Wash: Little River just gets more colorful by the minute. What will she do next?
Zoe: Either blow us up or rub soup in her hair. It's a toss-up.
Wash: I hope she does the soup thing. It's always a hoot, and we don't all die from it.
Those all sound like my kind of humor and fairly intelligent writing too. Well, as I said in another thread, if it comes on as a re-run, I'll check it out again.
I completely agree with you. Seven of Nine, by far, was what easily kept the show on the air.
Thank god they abandoned that formula for Enterprise. While flawed, it's still a big step up from that crapfest.
Well said. I agree.
and IMHO later seasons didn't get any better.
No better? How about worse. Every now and then (maybe twice a year), late at night, I'll catch a re-run of a show from a later season. Rarely am I able to finish an episode. It clearly got worse.
The really, really sad thing is, they had a twnety mile wide door to pull some really great shows through. But, nope, they (the writers) blew it horribly.
Well, like I said, I guess I didn't get it. Sometimes you have to be in the right mood for a type of movie. Other times, knowing a certainly amount of background certainly helps too. I knew and know pretty much nothing about the show. Perhaps I judged too harshly. I dunno. I do recall, while making this post, that I did not catch any episode from the beginning. So, perhaps I missed key elements which would of helped make things a little easier to understand and follow. Some shows are like that; miss the first 5-minutes and your screwed.
The odd things is, when I was watching it, I didn't feel lost or like I didn't understand it. Sure, I had questions, but I didn't FEEL lost. Just the same, I guess I just didn't get it.
I guess if it ever comes back on in re-runs, I'll try to scope it out again to see if I missed anything the first time around.
Thanks for the feedback.
Hmm...it was so long ago, I'm sure I don't recall the name..I rarely pay attention to the episode titles anyway...of any show.
I remember a ray-gun shootout at an O-K coral of sorts and another episode where some succubus type women was aboard the ship. I think there was some lesbo sexual tension on the later, maybe even a lesbo kiss. Sorry, I really don't remember much beyond that.
LOL. Fair enough. ;)
;) :P
Place it with its contemporaries of the time and it actually was pretty good. It's even watchible today. Compare Voyager with its contemporaries and it will make you vomit in any time.
I realize that was tongue and cheek. I don't have a problem giving a show a fair chance. I watched it for something like two seasons. In the second season, it was clearly worse than the first. Yet, I kept hoping. After the second season, I hardly watched it, if ever. The details in my mind, of my watching habbits are somewhat hazzy simply because the show was not memorable and time has passed.
I watched two shows of that. I was like watching a bad western serial, crossed with day time soaps and ray guns. I've asked this before and got modded down before anyone could respond. What is so great about that seemingly backward and awkward show known as, "firefly"? Because I don't get it?!?
I think that DS9 and TNG have a good number of episodes that I'd have to rank as tied. Over all, I think DS9 offered more over a longer period of time. TNG was often good simply because we were all so hungry for some new scifi; especially trek scifi. On the other hand, Voyager, IMO, is the biggest peice of crap to ever become part of the trek genre. I used to piss my wife off by watching the lead-in to the show and tell her exactly what was going to happen, including the really impossibly stupid and lame decisions that Janeway would make. Sure enough, we'd watch the show and it would unfold exactly like I said. I think I was entirely wrong twice out of countless times. Basically, Voyager became unwatchably horrible. Basically, the Janeway moto was, if it's stupid and makes me flawed, I'll do. In a nut shell, anyone as stupid and flawed as the Janeway character would of never made bridge officer, let alone captain; unless she's good at giving head, and then, just maybe.
Enterpise, on the other hand, actually has some shows worth watching from time to time. The characters are developing and plots lines are getting better. Compare that to TNG and you'll see a very strong parallel. Voyage just got worse, tragically so. Janeway became more stupid and pethetic with each show. Enterprise and TNG got better with each show. DS9 often got better by leaps and bounds as the shows continued to be made.
While I'm sure that many love to hate Enterprise, I remember one of the big reasons that I heard about for a long time. That was the intro-theme song. Talk about closed minded, easily ignored opinions. Sure, maybe you hate the song, but who cares. Does it provide a good trek-fest for you? Is it entertaining? The answer is yes, or mostly so. Yet, it's still trying to find it's place, just as TNG did for the first three seasons. IMO, Voyager is what destroyed the value of the trek franshise. If Enterprise can find it's place this next season, then I'll consider it a success. If not, then I'll probably have to write it off. Just the same, Enterprise is a fairly interesting take on the trek-verse, even if there are many plot lines that I personally don't like how they rolled them out.
Eh....but that's all just one man's opinion.
Just FYI, using a GC with C++, changed the benchmark to:
c++: 14.66user 0.02system 0:15.14elapsed 97%CPU
java-server: 17.60user 0.62system 0:18.84elapsed 96%CPU
And, there is still significant room for improvement in the C++ implementation. I see that some have even done GC work which specifically targets transient object creation and destruction. My point being, there is nothing but up for the C++ objinst benchmark. Other prospects would be to simply look at other heap managers as well as simply writing a custom heap manager specifically targeting these transient benchmarks which would reduce the number of deletes to two or three (versus 200,000,000) and completely avoid the overhead of object destruction (currently, 200,000,000). This final solution, I believe, would put it on par (implementation wise) with what the JVM is doing. But, even without an apples to apples comparison, C++ is already taking the lead.
Thus far, I have submitted back four improved benchmarks back to the tester. All that I have submitted back, have been faster than the java implementation. Oddly enough, while attempting to create some additional benchmark runs which would help further remove noise, I started running into some serious problems with java. Bluntly, some of the benchmarks can not be run with java because java runs out of memory on my system (I only have 512M). Even after increasing java's memory up to the ceiling of my free ram, java is unable to complete the benchmark, having run out of memory. In one such test, the c++ code finished in 1.99s while the java code ran out of memory after 6+s. Worse, the c++ code used about 50+M of ram while the java code ran out while attempting to use 380M. Oddly enough, the more work you asked of java, the worse java seemed to do. In my additonal tests of the strcat benchmark, performance tilted toward C++ ranging from 29% to over 300%, depending on the amount of data being processed and which JVM options were being used.
The benchmarks are only flawed in that respect if you want to generalize them for 'big' applications where gc will hamper processing
Actualy, the benchmarks are only flawed if you expect them to reflect server class applications, many workstation class applications, or think that hot spot is able to do so well outside of recursive call chains and/or tight loops where little work is actually being done. In other words, a very broad class of problems may not do so well.
Well duh. That is only surprising if you don't know Java at all.
Well, except that your remark is fairly out of bounds. If you apply that knowledge to real world applications which may collect, especially if they are multithreaded, it shows that someone can be in for some real surprises. Furthermore, I now know (based on some other runs I did), that it takes only a modest number of runs from the collector to significantly effect performance.
Creating good benchmarks (where the results are accurate and meaningful) is very hard and I'm certainly not able to do so (since it requires you to know every possible way to skew the results, knowledge that few people possess, and a certain attitude). Trust me, you can't do it either, so go easy with the wise old sage stuff.
Actually, I have a long history of measuring benchmarks which actually have meaning. I realize you're happy to ignore the ad hok results, however, I understand what they imply. I'm comfortable with the results that it provided. I took my grain of salt and am content.
Lastly, let me say that I think you overly object to the use of java's collector. A foolish amount of overhead was purposely allowed to kill c++'s performance yet if I artificially do the same with the java benchmark, you suddenly cry flaw and bias. Well, I happen to agree (sorta), which I've previously explained several times. Either you level the playing field so that both are flawed or you level the playing field so that both are equal. I purposely knee capped the java benchmark to attempt to level it with C++. The grain of salt is, the playing field was never leveled. Just the same, the knowledge gained underscorded the serious cost accociated with java's collection. Clearly, 1:1 implementation is far more than knee capping. The real problem is, I have no idea how much use of System.gc constitutes a level field knee-cap, thusly, I take my grain of salt and place the known performance data into contect of real world applications. In otherwords, it doesn't look good. Given the time constraints of my desire to contribute something here, the path I followed offered the shortest path while requiring the largest grain of salt.
One of the areas that I must admit I am becoming more impressed with is the call overhead of java. It appears that java is able to significantly reduce call overhead in recursive call chains. The level of reduction is simply nothing more than awesome. Of course, as I stated above, I currently have no idea if that translates into recursivce calls for anything other than trivial work in tight recursive loops.
Sure, gc collection libraries exist for c++. That would be so much more meaningful than simply killing Java's performance by doing something Java programmers are told not to do the instant they are introduced to gc.
Well, the trick is to find a collector that actually performs well, or at least on par in performance with Java's. On the other and, the best c++ solution would be to simply implement a deferred delete method. As an example, ideally, the 200,000,000 deletes presented in one of the benchmarks could be deferred and optimized away into as little as two deletes. I would guess that java is smart enough to be able to do such heap tricks too. My casual playing with it suggests that it can, given some of the benchmarks.
FYI, I've already optimized two C++ benchmarks which are now faster than the java implementations. One of them is 2.2 - 2.7x times faster than java. I've sent my work to the tester. He's accepted them and stated he woudl take the fastest code for each benchmark (Cpp or java) which he gets. So, feel free to check the original pages sometime again in the near future. I suspect there will be many updates.
Java never sold itself as the fasted gun in the west.
This is certainly true. They sold it as write once, run everywhere.
because for the time being (up until the GC turns over) you end up with an app that can rub noses with C++. This article does prove that.
Actually, that's been pretty well debunked within the many threads offered here. What is seems is that it proves that given non-realistic corner cases where hot spot shines versus poorly written C++ code compiled via a less than optimal compiler, java can be as fast, if not faster.
You need to add all the other great features of Java... the most important being that it's a very pragmatic system to code in (no need to explicitly free memory etc etc), Java is a fantastic thing.
That, I certainly agree with. In fact, I'm willing to admit that the many studies which show higher deliverability with Java are probably true. Thus far, to date, I've yet to actually ever see a valid java benchmark which put java on the same page as C++, in terms of performance. While I've not finished looking at all the code, thus far, it does not appear that these will be that exception.
The fact that it can HotSpot and have parts of an application go toe to toe with C++... it makes me a truly happy Java programmer.
But, thus far, we have no proof to support such a statement.
It's another topic, but people also deny its cross platform nature, but it does deliver on this promise. I needed to quickly run a complex IDE (IntelliJ's IDEA) on a linux box, but no Linux version of it. By simply copying the Jars from a windows box and starting it up, it was usable without a problem.
Again, I good point, which I agree with. Java is a very good system for pragmatists. It's just not a high performance system in the real world.
Reference: Fixed hash code thread
Latest results:
cpp-optimized: 6.54user 0.02system 0:06.77elapsed 96%CPU
cpp-slight-opt: 7.99user 0.02system 0:08.21elapsed 97%CPU
cpp-original: 19.65user 0.07system 0:20.17elapsed 97%CPU
java-server: 14.93user 0.10system 0:15.67elapsed 95%CPU
java-client: 17.43user 0.10system 0:19.01elapsed 92%CPU
So basically, proper code yields a little over twice (2.2x the server version and 2.7x the client version) the performance of a best-corner case for java's hotspot. That's not exactly close.
Consider a GUI which spends
Except that, as I understand it, Java, by far, used used in server applications. Thusly, high load over extended durations should be considered the norm and not the exception.
Shocking! Program takes advantage of language features! How dare they!
Coward is right! It is shocking because they took advantage of a language feature under java but failed to do so under C++. Likewise, the benchmark is built around the entire concept of creating a best case situation for java and crap design/code for C++.
I run all of my tests with -server, however, I had already change my config file to do that by default, thusly, making the common line option redundant. I used it mostly just so I could cut-n-paste the commands here so that its use would be obvious.
I should offer, than for the few tests I can, I did not seem much of a difference between -client and -server, though, I sure there are many situations where that would not hold true.
LOL. You seriously think you offered something to the topic here?
You have decided to temporarily "leak" memory which can be a precious commodity.
That's sooo funny. If we run with your logic, then that means java is one huge memory leak. That's funny.
I feel that there are two primary objectives any language comparison tests; one is to test optimizations done by compiler/JVM and two is to compare "normal programming style" from both languages.
I think you have a valid point there. Just the same, it's fairly well known that it requires more skill to get good performance out of C++ than it does for Java. After all, C++ isn't exactly the easiest of languages to master. Likewise, this is why java programmers are often compared to VB programmers (not that I support that view; I see real skill in many java progammers which never existed in the hordes of VB guys). In attempting to comment on the benchmarks, my goal was not to talk poorly about how well hot spot is performing. In fact, if you check my profile and read the many messages on the topic, I'm actually impressed with hot spot and how well it's working. It's just that these benchmarks, while impressive, paint a completely unrealistic view of java's performance as users are likely to encounter them in the wild.
Based on what we've learned, it would probably be fair to asses the results as, in absoluete ideal situations, java can be as fast, if not faster than very poorly coded and less then well optimized c++ in less than ideal situations. Which, doesn't exactly match the original author's voice. Not by a long shot.
I do agreee with you that tests are not fare from the first stand point, as C++ test incurs overhead of destroying objects. However, isn't this standard programming style for C++?
Again, I think your point certainly has merit. Just the same, if you look at the code, one could argue that the c++ code was put together in a manner to represent a worst case performance picture.
As for programming style, I think it's unreasonable to think that most C++ programmers would of implemented most of the code as had been done, at least the code that I've looked at. You could argue that the C++ was a literal translation of the java code, whereby, it avoided many obvious and common sense implementation, "styles".
I do agreee with you that tests are not fare from the first stand point, as C++ test incurs overhead of destroying objects. However, isn't this standard programming style for C++? How often have you built resource managers and how often have you used them for small objects, like strings?
Well, it depends. I have built and implemented my own heap managers, even under C. If absoluete performance is the goal, as one would expect of a benchmark, then it's certainly not out of the ordinary to implement your own new/delete operators. In other words, it's actually not that uncommon. If you look at fairly popular toolkits, such as ACE, you find that many/most of the objects and patterns specifically allow for your own memory management implementations. The reason being, that's the power of C++. Which is often the reason why C++ is used. To be redundant, it's silly to purposely avoid areas open to significant optimizations when performance is the stated goal. Thusly, it highlights just how unfair the tests were.
Just FYI, even a moderately decent heap implementation could of optimized the current 200,000,000 deletes, within the objinst benchmark, into something as little as two deletes, assuming enough memory exists. If we assume enough memory doesn't exist for all object instances, then we could still easily reduce the number of deletes by something in the area of 10,000 orders of magnatude. Regardless, either provides significant reduction in workload, to say the least. That translates into a TON of work suddenly removed from the C++ side of the scale.
I like java very much and I am very glad to see that these days it is being compared to C++ and people ARGUE about which one is faster. Just few years ago the argument would be about "hey, performance is not what Java is all about!
I can't argue with that. Just the same, I think pragmatically, java is going to be significantly slower
Garbage collection has long be heralded as a faster solution than explicit new/delete handling of memory allocation.
This is true, but the experts fairly regularly point at java as an example of what not to do. In otherwords, as far as GC implementations go, Sun's java GC implementation is not considered very technically advanced nor Earth shattering.
Well, as I understand it, it's supposed to collect as time allows AND when it's triggered predefined thresholds, as derived from things like maximum allowed memory and current free heap, etc., etc. I'm sure I'm over simplifying, but I think the point stands.
Beyond that, an explicit call to System.gc(), means, if you are not already doing so, please start attempting to collect. The collector then runs in a low priority thread, which was kicked off by the System.gc() call, again, assuming it's not already running.