switch to room list switch to menu My folders
Go to page: [1] 2 3 4 5 ... Last
↑↑↑ Old messages ↑↑↑            ↓↓↓ New messages ↓↓↓
[#] Mon Apr 23 2012 18:07:49 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

Android Is Suddenly In A Lot Of Trouble

Look sir, droids!

[#] Mon Apr 23 2012 21:27:03 EDT from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

These aren't the droids Oracle's
looki....what's that? Oh. Uhhuh. I see,

Apparantly, these ARE the droids they're
looking for.

[#] Mon Apr 23 2012 22:08:52 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

I would say that the Oracle lawsuit is pretty much the only thing Google needs to worry about right now; that's what I *thought* the BI article was going to be about. Alas, the word 'Oracle' does not appear anywhere on the page, not even in the comments.

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.

[#] Mon Apr 23 2012 23:49:57 EDT from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

Agreed on all accounts; however, my next
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)

[#] Tue Apr 24 2012 07:58:57 EDT from dothebart

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Tue Apr 24 2012 10:18:15 EDT from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

No interpreter exists, though. The Dalvic
"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

[#] Tue Apr 24 2012 10:46:50 EDT from dothebart

[Reply] [ReplyQuoted] [Headers] [Print]

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)

[#] Tue Apr 24 2012 10:48:23 EDT from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Tue Apr 24 2012 10:51:12 EDT from dothebart

[Reply] [ReplyQuoted] [Headers] [Print]

well, it was a typo...

but when I saw it after posting, I liked it ;-)

[#] Tue Apr 24 2012 10:53:48 EDT from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]

It's an inspired typo. I like it!

[#] Tue Apr 24 2012 11:17:27 EDT from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

You do understand that JIT #implies#
compilation, right? Full stop.

[#] Tue Apr 24 2012 11:42:52 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Tue Apr 24 2012 12:45:36 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

It 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 [] as they try to figure out a way around this problem).

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 13:01:16 EDT from dothebart

[Reply] [ReplyQuoted] [Headers] [Print]

Tue Apr 24 2012 11:17:27 EDT from kc5tja
You do understand that JIT #implies#
compilation, right? Full stop.

which happenes after the byte code interpreter did its job.


[#] Tue Apr 24 2012 13:15:30 EDT from dothebart

[Reply] [ReplyQuoted] [Headers] [Print]

Tue Apr 24 2012 12:45:36 EDT from IGnatius T Foobar
It 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 [] as they try to figure out a way around this problem).

i.e.  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.


[#] Tue Apr 24 2012 13:26:21 EDT from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

Either way you look at it, I think both dothebart and I agree that Java
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
completely native.

[#] Tue Apr 24 2012 13:32:31 EDT from dothebart

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Wed Apr 25 2012 05:33:38 EDT from the_mgt

[Reply] [ReplyQuoted] [Headers] [Print]

 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 

[#] Sun Apr 29 2012 22:31:29 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Enlightenment barely fits on a desktop computer. I can't imagine trying to run it on a mobile device. On the other hand it has been a while since I tried it. I got the impression that it was intended for people who bought a computer only to run a window manager and nothing else.

[#] Mon Apr 30 2012 09:51:42 EDT from dothebart

[Reply] [ReplyQuoted] [Headers] [Print]

most of us tried enlightment more than a decade ago, and I think the rasterman has been busy profiling, plus the computing gear one used to have in the late 90'ies was... a 200 mhz pentium or like that?

I guess a current smartphone (or even the entry level bada devices) easily outperform it.

plus, way back then you used to have primarily framebuffers as graphiccards, and the current mobile graphic chips are prety sophisticated, plus e supports them.

Go to page: [1] 2 3 4 5 ... Last