So what is your argument then? That a C program with a JIT compiler can be more efficient than a JVM with a JIT compiler? Fine, I yield, but I think it's highly misleading to say C is faster than Java for this reason. Java comes with a JIT compiler just by its very nature. Including a JIT compiler in a C program is unorthodox to say the least.
Incidentally, there's no reason Java can't use MMX instructions. You have a point on controling memory allocation though.
Are you being dense on purpose? I'm talking about a value the program gets from its input data at runtime. I think you should re-read my post with that understanding. (Boy, you really need to spell things out for some people.)
However, any Java advantages you can name could be themselves implemented in C++.
The difference is the presence of the JIT compiler at runtime. If you're talking about keeping some or all of the C++ compiler around while the program is running, then you're talking about a very unusual runtime environment. You'd be talking about JIT-compiled C++.
Re:Java is not faster than optimized c++
on
Java Faster Than C++?
·
· Score: 2, Informative
Runtime optimization analyzes the bytecode that's running and can come up with ways of optimizing things at runtime. However, this optimization was coded into the JVM, and there's absolutely nothing that stops you from emulating that approach in C.
Wrong. JIT compilation offers you two things you can't get from a static compiler: (1) dynamic information about a particular run of the program, and (2) the opportunity to make optimistic assumptions, knowing you can re-compile if your assumptions are violated.
Suppose that during a particular run, there is a particular variable x that, whenever we look at it, always has the value 42. Now we want to compile a method that uses that value. A JIT can optimistically assume that value will always be 42. Now it can go to town on optimizations involving that variable. Got an "if(x > 10)" statement? You can omit the compare and branch. Got a division with x as the denominator? You can omit the divide-by-zero check, and turn the divide into a cheaper multiply-by-reciprocal. And so on, and so on.
Then, you register your assumptions with a runtime service that is capable of re-compiling the method of your assumptions turn out to be incorrect. If you ever see that variable with a value other than 42, you recompile it (and do some fancy footwork to deal with threads that might already be running the obsolete version).
What you end up with is a method implementation that a static compiler just could not produce. Perhaps, if it were very smart, it could use profile-directed feedback to create a specialized version of the method for each of a number of "likely" values of x. However, unless you want to try to cover all 4 billion possible integer values, you must include a backup version for when you turn out to be wrong. Plus, you'll always have the overhead of choosing which of the specialized versions to call in the first place. This is all overhead the dynamic version doesn't have.
So it is definitely not impossible for a dynamic compiler to outperform a static one. It is just very rare, given the current state of the art of compilers.
Our 486 had 16MB of ram, which I thought was bordering on absurd at the time. I didn't know anyone else with more than 4MB. But when time came to do a video for a class project, I did all the sound editing on that thing. For the 7-minute video, we had about 9MB of audio, and so I was able to edit it effortlessly with the Sound Blaster software.
The argument changes if you consider programmer effort. C easily outperforms ASM on large programs because to match a decent optimizing C compiler with hand-coded ASM would make the project too expensive to be feasible, especially if developing for multiple target platforms.
To me, that's a much more relevant discussion than whether one language is more "powerful" than another in some abstract theoretical sense. When discussing a language's expressive power, I like to make an analogy with physics, where power is work divided by time. Thus, if a language can allow a developer to do the same work in less time, that makes it more powerful.
You shouldn't feel scared if you do it right. It's just that we as a species are so new at software that we don't know what "right" is.
Do you think architects and builders quake with fear the first time someone walks into a new building because the walls might come crashing down? Of course not.
Look, maybe I'm not being clear enough. Let me give an example.
If you look at a human being in isolation (or pretty much any mammal for that matter) you'll find one of the most astounding feats of reverse entropy in existence. It is an exquisitely ordered piece of matter. It consists of trillions of highly complex cells in a highly complex arrangement.
You could use the "entropy will win" argument to conclude that the human body is impossible. That is why the argument is bollocks.
While I am impressed by your vocabularial perspicacity, there's no way spontaneous mutations occur quickly or often enough to explain death by old age, or else you need to come up with a good reason why they don't affect the gonads just like the rest of the body. Otherwise, we'd be riddled with life-threatening defects in just a few generations.
Bollocks. First, entropy doesn't enter into it because a human being is not a closed system. Second, your "mutations" theory is complete fiction, because if that were the case, then the defects would be inherited by offspring.
I think you missed the point. He's saying he finds Python without an IDE to be harder than C++ with an IDE. (Not that I agree.) Your arguments don't address that point.
Assuming 19 TBps is the right number, that's 1.2 million libraries of congress per fortnight. (Actually, more interesting is that it's just about one LOC per second.)
Sure. I computed this myself, so I wouldn't mind some corroboration.
Gravitational acceleration falls with the square of distance, so let's define a=k/r^2 for some constant k.
For escape velocity, imagine dropping an object from infinite distance. It starts with a certain amount of gravitational potential energy, and by the time it reaches a given distance r, it has converted some of that to kinetic energy. Since work equals force times distance, and f=ma, the potential energy converted will be the integral of mk/r^2 by dr from infinity to the given distance r. I'll let you verify that this equals mk/r. Setting this equal to kinetic energy, mk/r=(mv^2)/2, or v=sqrt(2)*sqrt(k/r).
Then, for all circular motion, v^2=ar. Again substituting a=k/r^2 for the circular orbit, we have v^2=k/r, or v=sqrt(k/r). Note that this is smaller than escape velocity by sqrt(2). Ergo, a circular orbit at a given distance always has 1/sqrt(2) of escape velocity at that distance.
First, escape velocity is about getting you permantly out of earths gravity well. Not something you want if your destination is a stable orbit around the earth.
A circular orbit always has 71% of escape velocity, so escape velocity is not a bad rough estimate of the velocity needed to maintain orbit.
Second, escape velicity is a ballistic value, ie. the speed required to kick your butt off the planet from ground level going straight up.
But the ballistic speed is exactly what's important when it comes to talking about going into orbit. Unless you want to thrust the whole time you are in "orbit", you must become ballistic at some point.
Third, pushing "a big inflated condom" around in the upper atmosphere is not really a problem since there isn't much air to create drag.
There must be enough air to create buoyancy. How do you know it doesn't create drag?
Slashdot Mirror
Incidentally, there's no reason Java can't use MMX instructions. You have a point on controling memory allocation though.
Suppose that during a particular run, there is a particular variable x that, whenever we look at it, always has the value 42. Now we want to compile a method that uses that value. A JIT can optimistically assume that value will always be 42. Now it can go to town on optimizations involving that variable. Got an "if(x > 10)" statement? You can omit the compare and branch. Got a division with x as the denominator? You can omit the divide-by-zero check, and turn the divide into a cheaper multiply-by-reciprocal. And so on, and so on. Then, you register your assumptions with a runtime service that is capable of re-compiling the method of your assumptions turn out to be incorrect. If you ever see that variable with a value other than 42, you recompile it (and do some fancy footwork to deal with threads that might already be running the obsolete version).
What you end up with is a method implementation that a static compiler just could not produce. Perhaps, if it were very smart, it could use profile-directed feedback to create a specialized version of the method for each of a number of "likely" values of x. However, unless you want to try to cover all 4 billion possible integer values, you must include a backup version for when you turn out to be wrong. Plus, you'll always have the overhead of choosing which of the specialized versions to call in the first place. This is all overhead the dynamic version doesn't have.
So it is definitely not impossible for a dynamic compiler to outperform a static one. It is just very rare, given the current state of the art of compilers.
That's a good point. If people are trying to write a parser, the code should probably look like productions rather than line noise.
Our 486 had 16MB of ram, which I thought was bordering on absurd at the time. I didn't know anyone else with more than 4MB. But when time came to do a video for a class project, I did all the sound editing on that thing. For the 7-minute video, we had about 9MB of audio, and so I was able to edit it effortlessly with the Sound Blaster software.
To me, that's a much more relevant discussion than whether one language is more "powerful" than another in some abstract theoretical sense. When discussing a language's expressive power, I like to make an analogy with physics, where power is work divided by time. Thus, if a language can allow a developer to do the same work in less time, that makes it more powerful.
What happens in your fairytale land of music when everyone is paying except you?
The good thing about classical is that the CDs still cost a reasonable $5-$8 canadian.
-1: Missed the joke.
The transit would be utterly undetectable from Venus, just like when there's a transit of Earth from the point of view of Mars.
Do you think architects and builders quake with fear the first time someone walks into a new building because the walls might come crashing down? Of course not.
If you look at a human being in isolation (or pretty much any mammal for that matter) you'll find one of the most astounding feats of reverse entropy in existence. It is an exquisitely ordered piece of matter. It consists of trillions of highly complex cells in a highly complex arrangement.
You could use the "entropy will win" argument to conclude that the human body is impossible. That is why the argument is bollocks.
While I am impressed by your vocabularial perspicacity, there's no way spontaneous mutations occur quickly or often enough to explain death by old age, or else you need to come up with a good reason why they don't affect the gonads just like the rest of the body. Otherwise, we'd be riddled with life-threatening defects in just a few generations.
So?
Bollocks. First, entropy doesn't enter into it because a human being is not a closed system. Second, your "mutations" theory is complete fiction, because if that were the case, then the defects would be inherited by offspring.
I think you missed the point. He's saying he finds Python without an IDE to be harder than C++ with an IDE. (Not that I agree.) Your arguments don't address that point.
If a company can't adapt to new circumstances, and therefore becomes obsolete, it has no right to be in business.
Take a look at the sample programs.
Somewhat unrelated, but perhaps they could use something along the lines of this.
Assuming 19 TBps is the right number, that's 1.2 million libraries of congress per fortnight. (Actually, more interesting is that it's just about one LOC per second.)
Gravitational acceleration falls with the square of distance, so let's define a=k/r^2 for some constant k.
For escape velocity, imagine dropping an object from infinite distance. It starts with a certain amount of gravitational potential energy, and by the time it reaches a given distance r, it has converted some of that to kinetic energy. Since work equals force times distance, and f=ma, the potential energy converted will be the integral of mk/r^2 by dr from infinity to the given distance r. I'll let you verify that this equals mk/r. Setting this equal to kinetic energy, mk/r=(mv^2)/2, or v=sqrt(2)*sqrt(k/r).
Then, for all circular motion, v^2=ar. Again substituting a=k/r^2 for the circular orbit, we have v^2=k/r, or v=sqrt(k/r). Note that this is smaller than escape velocity by sqrt(2). Ergo, a circular orbit at a given distance always has 1/sqrt(2) of escape velocity at that distance.
Please, no more comments about isolation. It has been covered already.
Glad to see you took my reply in good humour. :-)