But that's not what happens in real life. A 2x performance difference means 1000ms instead of 500ms to load a page - and that is noticeable. It's also the difference between 30 fps in a game vs. 15 fps - that is really noticeable.
The list goes on. A 2x performance penalty is huge. For desktop applications, our hardware is so ludicrously overpowered for what we do with it that this penalty large doesn't matter (as you said, 1ms vs. 2ms), but in mobile land, where hardware constraints are still very, very real, this is absolutely a critical issue still.
Apple's platform is by far the most responsive out of all of the current smartphones, and I think it'd be foolish to discount native code as one of the primary factors in this. The responsiveness is also part of what attracts users - people want their machines to work on human time, not slower-than-human time.
A machine with a 1Ghz processor, a half a gig of RAM, dedicated video processing hardware, dedicated audio compression hardware (the GSM modem, etc.), and so on is "constrainted".
The premise of the article is that's impossible to achieve reasonable performance on a mobile device while using a virtual machine. This is obviously false, as Android performs wonderfully on my phone. A call comes in, the "slide to accept" action works smoothly. I visit a web page, it loads as fast as the network can give it to me.
Apple's OS may be more responsive, but I'm not really sure about that. The browser feels the same. Maps feels the same. Receiving a call feels the same.
We've passed the point where every bit of performance matters. Now, it's about features -- let me know when I can use irc over ssh on the iPhone or use Google Voice to make calls from the native Dialer application. "Slow" VM or not, my Android phone can do that stuff, but the iPhone can't.
We really haven't. In a twitter client? Sure. In a real-time game? Hell no.
Don't assume that all software is the same, or that it will never change (See Bill Gates's famous '640k is enough memory for anyone' comment).
source: http://code.google.com/p/android/issues/detail?id=6914
A 2x performance difference means 1000ms instead of 500ms to load a
page ... It's also the difference between 30 fps in a game vs. 15 fps - that
is really noticeable.
In web apps it really depends on where your bottleneck is. A 2x performance difference could mean just a 5% difference in response time.
On the other hand, go ahead and try handling 100.000+ connections on a single server from C/C++, like these dudes right here ... http://amix.dk/blog/viewEntry/19456
Of course it can be done, but you'll need to read a whole book about it, and at the end of the day your app also has to do something useful other than returning "Hello".
And as game development goes, game developers have been using high-level languages for the business logic for years, including Lua, Python, Java and C#.
The responsiveness is also part of what attracts users
This doesn't really help make your point. With libev or libevent, it's very easy to do this in C or C++... or Perl, or Java, or Python, or Ruby. The OS does all the heavy lifting and the OS is native code.
For the differences in responsiveness between iOS and Android look elsewhere.
Java is still much slower than native code, and you can see it clearly just by looking at any app
Let's see some numbers. Oh, here are some:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
2x difference. Yeah, it's slower, but do you really notice the difference between 2ms and 1ms when your web page loads? Didn't think so.
With people regularly writing server-side apps that handle millions of users a day in languages whose benchmarks run 50x slower than C++, and those apps working fine, it's not really a stretch to pick a language that runs 2x slower than C++ on a device that doesn't even do anything computationally intensive. ("Received 'incoming call interrupt'. Display something pretty on the screen." Guess what, not CPU intensive!)