Elysian Shadows

+1 to christo

yes, except that a software-based VM by definition is incapable of running faster than actual statically compiled code.

In theory, yes.
In practice, no.

Ginto8 wrote:

N64vSNES wrote:These high level V low level wars are so entertaining

All I'm saying on this is that you simply can't predict the future.

yes, except that a software-based VM by definition is incapable of running faster than actual statically compiled code.

That is only if they're running the same operation. If you have two different potential methods of returning a result (let's use just two for simplicity), and those two methods make use of two entirely different approaches to the problem, and each performs substantially better than the other under certain conditions, then the approach that detects the optimal approach will come out on top. In other words, obtaining what you need dynamically in order to select/change the instructions actually performed at run-time has the ability to run with the best performance in all situations.

Of course, the caveat here is that there actually has to be warranted variability in conditions at run-time in order for this to make any difference, and the overhead of running that "meta-analysis" of dynamic conditions needs to have small enough overhead relative to the penalty of choosing the wrong operation. Also, you need to have an "intelligent" enough system that it can make that optimization, and that means (potentially) a startling level of complexity/innovation that may or may not exist for the problem at hand.

Static instructions will run faster than the exact same dynamic instructions, but it's not true that something at the dynamic level will be implemented the same way it is at the static level. Through JIT optimizations it may be implemented in a very different and much more efficient way at the static level (perhaps based upon conditions at run-time that couldn't be accounted for in all cases during static compilation).

@christo
I have to agree with Gyro that your horse analogy seems off. I'd imagine it more like you have several horses to choose from at the starting gates rather than a single horse lined up to run the race. When the gates open, you suddenly get information about the upcoming track and now must choose which horse to send out, all while the other (statically compiled) horses are running out of the gates. If this was a straight race from one end of a track to the other end, you wouldn't be gaining anything (but if that was the case you would have known the requirements right from the beginning thus killing the advantage of choosing your approach/optimization dynamically as the gates open). However, if it was a complex race track full of water traps, cross country races, jumps, hurdles, etc; keeping in mind that many horses are terrible with water, many are not trained to jump hurdles, some have better endurance, some are better sprinters, etc; then you might have a major advantage by selecting the correct mount for the situation.

By selecting your horse, you lose a bit at the beginning, but you may make major gains by making the best selection overall that gains you the biggest net advantage. A counterpoint to this might be that you might as well just pick the best horse ahead of time and have them queued up at the gate. That assumption is fine if you have information about the track ahead of time, but that kind of information is often not readily available for many real-world problems (although I think that depends upon the situation too - Gyro pointed out several examples, like embedded applications, where your requirements are pretty much set from the get-go).

Remember that one movie where the zebra won the big horse race?

That's how the future is going to play out.

bnpph wrote:Remember that one movie where the zebra won the big horse race?

That's how the future is going to play out.

Are you saying that JIT languages are small, light, contenders that will win based upon some attribute of litheness? I don't think you understand the nature of JIT. Java and C# are beasts that are slow to start. They're like man-bear-pig crossed with an eagle, a yeti, and an octopus. They can do everything, they have so many organs and limbs that you can pull one out to tackle any problem; but they are hardly small and agile. It's going to be easier to get your man-bear-pig-eagle-yeti-octopus to swim and fly than your zebra, and because it's part human let's say it has some knowledge about how to use its own limbs optimally, but it's not a fricking agile zebra. Sorry, it's just that the analogy seems totally off the mark. I mean, you could probably use the analogy I just made when comparing something like C++ to C as well, but the point still stands.

EDIT: Btw, I think someone who's good with photoshop should make an image this ^. I'd definitely lol

Ginto8 wrote:

N64vSNES wrote:These high level V low level wars are so entertaining

All I'm saying on this is that you simply can't predict the future.

yes, except that a software-based VM by definition is incapable of running faster than actual statically compiled code.

At this point in the thread you'd have to work pretty hard to reach that conclusion without some justification.

"It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so." - Mark Twain