Active Topics
-
The N900 is now 15 years old! (8)
to Nokia N900 by whayong - 9 hrs ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 5 days, 5 hrs ago - more...
 |
|
2009-11-02
, 21:59
|
|
Posts: 1,878 |
Thanked: 646 times |
Joined on Sep 2007
@ San Jose, CA
|
#132
|
Dalvik (Android's runtime) isn't really Java. It's an optimized subset of Java (they eliminated things that would slow it down).
I'm not sure you can really say which is better. Each one makes it choice based on larger issues than just executable code speed.
Android is designed to run on multiple hardware platforms (the multiple ARM variants, MIPS, x86, etc.). For that to work, while still providing a single user experience, native code just wasn't an option. And, this approach is probably a factor in why we're seeing Android pop-up on so many different devices (official, and unofficial). Why bother if you can't run any apps on it? or if you have to get vendors to port their apps to N different CPUs.
Maemo, on the other hand, only runs on a single specific hardware design. It doesn't need that support for multiple platforms. On the other hand, that also means it doesn't have the benefit of running on multiple platforms from multiple vendors. And, its approach would be awkward at best (for the consumer market) if it was deployed on those same platforms as Android.
So, one approach gets you CPU flexibility/independence and proliferation. The other approach gets you speed and maximum hardware utilization. Each one fits the higher goals of the people who made that platform. You can't really say which is better without addressing which of those higher level goals is better ... which, IMO, isn't an answerable question. It depends on what you/they want.
I'm not sure you can really say which is better. Each one makes it choice based on larger issues than just executable code speed.
Android is designed to run on multiple hardware platforms (the multiple ARM variants, MIPS, x86, etc.). For that to work, while still providing a single user experience, native code just wasn't an option. And, this approach is probably a factor in why we're seeing Android pop-up on so many different devices (official, and unofficial). Why bother if you can't run any apps on it? or if you have to get vendors to port their apps to N different CPUs.
Maemo, on the other hand, only runs on a single specific hardware design. It doesn't need that support for multiple platforms. On the other hand, that also means it doesn't have the benefit of running on multiple platforms from multiple vendors. And, its approach would be awkward at best (for the consumer market) if it was deployed on those same platforms as Android.
So, one approach gets you CPU flexibility/independence and proliferation. The other approach gets you speed and maximum hardware utilization. Each one fits the higher goals of the people who made that platform. You can't really say which is better without addressing which of those higher level goals is better ... which, IMO, isn't an answerable question. It depends on what you/they want.
__________________
My Personal Blog
My Personal Blog
| The Following User Says Thank You to johnkzin For This Useful Post: | ||
|
|
2009-11-02
, 22:03
|
|
Posts: 203 |
Thanked: 68 times |
Joined on Oct 2009
|
#133
|
Originally Posted by johnkzin
I didn't mean that I don't see the point of the d-pad in and of itself. You quoted me out of context. People seem to love to do that on this forum. Quote someone out of context, make them appear to say something they didn't say, and then respond to the thing they didn't say. What's the point?
Not baffling at all.
Touch screens are imprecise. They're good for fat fingers, and broad/continuous gestures. Dpads are good for precise and discrete movements/gestures. Incremental movements of small widgets works very well with a dpad. Touch screens, with inertial scrolling and such, are much better suited for fast movement and selecting large widgets. Incremental or precise movements of small widgets on a touch screen is abysmally annoying and error prone.
Dpads are great companions to a touch screen. The one that's baffling is the HTC Android phones that all pair a trackball with a touch screen (since tiny trackballs, especially on Android where you can't adjust the sensitivity, are suited for fast and imprecise movement, just like touch screens).
Or did you mean the gold color of the dpad? yeah, that's kinda garish.
Anyway, I said I didn't see the point of the d-pad, given that the scrunched up keyboard on the Droid is supposed to suck. So is the benefit of the d-pad worth the trade off of having a keyboard that sucks so badly some reviewers are reporting it's better to just give up and use the onscreen keyboard? There are obviously a lot of touch based phones out there now without d-pads that people are happy with. If both a d-pad and a decent keyboard couldn't be squished together into the Droid's form factor, I would have far preferred a good keyboard.
 |
|
2009-11-02
, 22:04
|
|
Posts: 5,478 |
Thanked: 5,222 times |
Joined on Jan 2006
@ St. Petersburg, FL
|
#134
|
Originally Posted by Capt'n Corrupt
Android's trading compatibility and speed for portability. An unwise compromise to make with mobile devices, in my opinion.
Android apps (AFAIK) are written in Java with (hopefully) a Java JIT compiler to compile the bytecode, whilst maemo apps are coded in whatever, and compiled to native ARM code. Which is the better strategy? Why?
__________________
Ryan Abel
Ryan Abel
Last edited by GeneralAntilles; 2009-11-02 at 22:05. Reason: Scratch that, reverse it.
| The Following 2 Users Say Thank You to GeneralAntilles For This Useful Post: | ||
|
|
2009-11-03
, 00:04
|
|
Posts: 607 |
Thanked: 450 times |
Joined on Sep 2009
@ Washington, DC
|
#135
|
Originally Posted by GeneralAntilles
Running at a slower but acceptable speed on more devices versus running at a faster speed on fewer devices makes the latter strategy much more device dependent. If you're the device manufacturer, you can control that but Google must rely on a number of manufacturers using their OS and apps.
Android's trading compatibility and speed for portability. An unwise compromise to make with mobile devices, in my opinion.
Plus, don't forget Moore's law. With faster CPUs the relative speed advantage decreases.
I'm old enough to remember writing in assembler language. If you want the absolute fastest program, it's still the way to go but very few people think it's worth the trouble.
 |
|
2009-11-03
, 00:31
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#136
|
@johnkzin,
An incredibly insightful and eloquent explanation. Thank you for that (especially the Dalvik bit, which is exciting news to me). But I'm really curious to hear *your* personal commentary regarding the architectural choices upon which each platform is engineered.
PS. Do you know of any dalvik benchmarks that compare execution timings to java/C/etc?
}:^)~
Last edited by Capt'n Corrupt; 2009-11-03 at 00:53.
An incredibly insightful and eloquent explanation. Thank you for that (especially the Dalvik bit, which is exciting news to me). But I'm really curious to hear *your* personal commentary regarding the architectural choices upon which each platform is engineered.
PS. Do you know of any dalvik benchmarks that compare execution timings to java/C/etc?
}:^)~
Last edited by Capt'n Corrupt; 2009-11-03 at 00:53.
|
|
2009-11-03
, 00:35
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#137
|
Originally Posted by DaveP1
There are also java bytecode assemblers out there! Though I would imagine that any optimization would have to be time tested on the target platform(s) as the interpreter/JIT could yield very different results across architectures. Still, interesting for eeking out a bit more performance here and there.
Running at a slower but acceptable speed on more devices versus running at a faster speed on fewer devices makes the latter strategy much more device dependent. If you're the device manufacturer, you can control that but Google must rely on a number of manufacturers using their OS and apps.
Plus, don't forget Moore's law. With faster CPUs the relative speed advantage decreases.
I'm old enough to remember writing in assembler language. If you want the absolute fastest program, it's still the way to go but very few people think it's worth the trouble.
}:^)~
|
|
2009-11-03
, 00:47
|
|
Posts: 3,524 |
Thanked: 2,958 times |
Joined on Oct 2007
@ Delta Quadrant
|
#138
|
Here's an interesting read on Dalvik. The 'iphone hate' in the last paragraph made me laugh out loud as it comes out of nowhere!
http://www.betaversion.org/~stefano/linotype/news/110/
And here's a link to the wikipedia entry on Dalvik:
http://en.wikipedia.org/wiki/Dalvik_virtual_machine
A good read!
Here's a talk by the creator of Dalvik:
http://sites.google.com/site/io/dalvik-vm-internals
}:^)~
Last edited by Capt'n Corrupt; 2009-11-03 at 01:03.
http://www.betaversion.org/~stefano/linotype/news/110/
And here's a link to the wikipedia entry on Dalvik:
http://en.wikipedia.org/wiki/Dalvik_virtual_machine
A good read!
Here's a talk by the creator of Dalvik:
http://sites.google.com/site/io/dalvik-vm-internals
}:^)~
Last edited by Capt'n Corrupt; 2009-11-03 at 01:03.
 |
|
2009-11-03
, 01:30
|
|
Posts: 4,930 |
Thanked: 2,272 times |
Joined on Oct 2007
|
#139
|
Originally Posted by johnkzin
Dalvik is two things -- a class library (analogous to a J2SE or J2ME implementation -- and Dalvik's doesn't match either), which is where your statement holds true, and the bytecode interpreter, which differs in less clear-cut ways.
Dalvik (Android's runtime) isn't really Java. It's an optimized subset of Java (they eliminated things that would slow it down).
The bytecode interpreter differs from many Java implementations because it _is_ a pure interpreter, not a JIT compiler. Also, and most significantly IMO, it's a register-based (instead of stack-based) VM. For those not familiar with this architecture debate, think of RISC/CISC, and don't ask "which is better" unless you like flamewars.
__________________
World's first inductively-charged N900!
World's first inductively-charged N900!
Last edited by Benson; 2009-11-03 at 06:15.
| The Following User Says Thank You to Benson For This Useful Post: | ||
|
|
2009-11-03
, 01:32
|
|
Posts: 1,878 |
Thanked: 646 times |
Joined on Sep 2007
@ San Jose, CA
|
#140
|
Originally Posted by Capt'n Corrupt
I don't consider it to be an "either-or". I think the best approach is "both".
@johnkzin,
An incredibly insightful and eloquent explanation. Thank you for that (especially the Dalvik bit, which is exciting news to me). But I'm really curious to hear *your* personal commentary regarding the architectural choices upon which each platform is engineered.
PS. Do you know of any dalvik benchmarks that compare execution timings to java/C/etc?
}:^)~
If I were to win the lottery tomorrow, I'd hire a couple of engineers to take an Android dist. and add something like Cygwin to it (so it uses the Android display model, and not X, but provides API and ABI compatibility with X based applications), and then port GTK+ and Qt to that. I'd add bin-utils, shells, some other programming/development stuff (Sun Java, Python, Perl, Tk, maybe Tcl and Ruby), and a vt100 compatible "droid-terminal". Then I'd port a few common things to it (firefox, thunderbird, mplayer, a few others), and add a "me" account to it. I'd also look into adding the debian style package management to it, for the non-Dalvik apps (and the Ubuntu graphical counterpart, whose name I forget.. starts with an S I think).
That's how I'd approach it ... but I have an anti-X bias that says "it's better to start with the non-X platform and work toward the middle, than to start with the X platform". If I was Nokia, I'd start at the other end of that bias (due to the investment in an X based platform). I'd leverage the work the one guy at Canonical did (porting Dalvik to Ubuntu), and get Dalvik working on Maemo.
Though, the other thing I'd probably do, is see about supporting/leveraging fat binaries (1 executable file with multiple executable segments, each for a different platform). If I could work it into the native tools, it would be the default, with an option to allow developers to narrow it down if they feel it's strictly necessary. That would add some degree of flexibility to the native code developers, as well.
In general, I don't think it's reasonable to make developers or users choose between the two approaches (whether you're talking about Dalvik specifically, or Java generically). Evolution will determine if bytecode apps will do well enough to thrive alongside native apps (and visa-versa). Let the developers gamble, and the users decide. IMO, the OS platform designers job is to enable those two groups, not pigeon hole them.
__________________
My Personal Blog
My Personal Blog
| The Following User Says Thank You to johnkzin For This Useful Post: | ||
Android apps (AFAIK) are written in Java with (hopefully) a Java JIT compiler to compile the bytecode, whilst maemo apps are coded in whatever, and compiled to native ARM code. Which is the better strategy? Why?
I'm genuinely interested to hear what you think!
}:^)~