Device for cooling infant's brain (they should cite Terry Pratchett here.)
Android Is Suddenly In A Lot Of Trouble
Look sir, droids!
looki....what's that? Oh. Uhhuh. I see,
Apparantly, these ARE the droids they're
Instead, I read a bunch of wishful thinking. Haters gonna hate, I guess.
Meanwhile the latest comScore data shows Android now capturing majority market share and growing faster than any other platform.
There's a certain group of people that simply want to hate whoever is on top. Right now that's Google. I would prefer to hate the company that is the most pathetic of smartphone OS suppliers: Microsoft. They still suck and they're still evil.
Apple ... meh. Decent platform but the closed ecosystem is a turnoff.
phone buy will almost certainly be an iphone
because I'm just sick of what appears to be
garbage collection delays in the UI. Not
only that, but it loves to run out of space
extremely quickly, even with large SD cards.
I had to correct 5 typos caused in large part
by UI unresponsiveness on this message (6
now) alone. (7 now)
yes, having an interpreter inbetween is just another source of errors.
but... you might be able to tune it better than native apps, which were the problem of windows phone up to their switch to their see-carpet interpreter with their latest release.
install wrong/badly coded app, battery declines faster than you can watch it.
the other alternative is the apple way; no background tasks.
"vm" is a native code compiling system, like
OS/400. It works great for batch operations,
but unlike OS/400, its threading model proves
utterly inappropriate for interactive
its a bytecode interpreter <fullstop>
it knows howto group or optimize several groups of unstructions at runtime, also known as jit.
however, it doesn't remember these optimizations and has to find them again on restart.
and no, dalvik bytecode isn't native. you need the dalvik interpreter to translate it into your system bytecode (strongarm for the most androids, but not all)
I have to remember that.
Those are commands issued to prevent you from performing a particular function, rather than to instruct you to perform a particular function. Or, at least, that's how I want to interpret the word.
well, it was a typo...
but when I saw it after posting, I liked it ;-)
It's an inspired typo. I like it!
compilation, right? Full stop.
You're both wrong... yeah, it's a JIT, it's an interpreter, it's a compiler... all of these things are true. Different tradeoffs. The optimization algorithms used by a compiler are inherently NP-complete, always will be unless a miracle happens and somebody proves that P=NP. A JIT can't afford to spend as much time searching for the optimal solution as an ahead of time compiler could spend. But in some cases it can do better because it gets better profiler feedback.
That's also in the nature of NP-complete problems. Clever approximate algorithms can often do surprisingly well.
In layman's terms, what good is a JIT if you can't run Angry Birds on your non-ARM device?
Given that situation, combined with Oracle breathing down Google's neck (Larry vs. Larry?) ... perhaps Google should simply dump Dalvik altogether and simply make ARM the native environment just like Apple has done. Downloading a legacy app would then compile it, either on the device itself or in the cloud.
I'm sure this strategy has problems too, I'm just thinking out loud here.
There are devices out there now that seem to be translating ARM code to x86 or MIPS on the fly. This essentially makes the ARM instruction set the *real* bytecode, although I'm sure it doesn't work as well as Dalvik for that purpose because it was not designed for it.
Tue Apr 24 2012 11:17:27 EDT from kc5tjaYou do understand that JIT #implies#
compilation, right? Full stop.
which happenes after the byte code interpreter did its job.
Tue Apr 24 2012 12:45:36 EDT from IGnatius T FoobarIt should be noted that about 25% of all Android apps are either built in native code or are making calls to native libraries (this is by Intel's estimation [http://goo.gl/fss0B] as they try to figure out a way around this problem).
i.e. http://www.xcsoar.org/ is a native compiled app which has an as thin as possible java layer around it; yes.
if you want decent speed, an interpreter simply doesn't cut it. (jit or no jit... who cares...)
oh, and one of the reasons why compiling firefox requires > 8G ram is because of they run an automatic profiler over all their regression test suite.
btw, CLang has possibilities to optimize beyound object borders, (link time optimization similar to a JIT) though it doesn't reach the speed of gcc. Gcc in term produces lots less fast code than ICC or SunCC.
is wholesale unsuitable for what Android is attempting to use it for,
Dalvik or not. :)
In my happy world, I'd have a handset that ran something with either
Qt-based toolkit (but not KDE; KDE looks nice, but is really unstable in
my experience) or a Gtk+-based toolkit. If it's one thing iOS has
proven, when it comes to overall user experience, you can't beat
yup, its a real pity novel bought the c-carpet guys, and nokia the trolltecs.
we would be in a much better place if it'd been the other way around.
novel and SuSE haviing lots of kde / qt relationships being forced to
and nokia / mameo starting out with gtk and converting to qt afterwards... a real mess.
yea, you realy want some GL based userinterface so it can utilize as much hardware as it can.
I am still waiting for a 100% linux device from Samsung or some similiar asian manufacturer.
The Rasterman works for Samsung and I have seen the EFL (Enlightenment Foundation Libraries) running natively on a Samsung device. It didn't really matter if it used software or GL rendering, it was lightning fast and looked far better then ios. Even the scrolling through large lists (contatcs, for example) was done completely "real", not with fake interpolated images (whatever ios is using, they are faking fluidness) and fast. So if i ever want to see a gui on a mobile device it is enlightenment or elementary
PS: It is already running on a fridge and some other embedded devices