pouët.net

Sidenote:

A map, a brain and a mouth to ask people is usually enough for me... :)

Haha.. 200% agreed :)



We've been hearing this pretty much since the late 90s when Java VMs started to see regular use in business and a little later when it started to creep it's way into the first handheld devices.

The problem is that, especially for handhelds, the functionality and multimedia requirements of the devices has simply not stopped evolving at a rapid pace.

So there simply is *no* redundancy left in terms of excess processing power on these devices to accomodate the VM, however good, and still get even near-native performance.

So we're just always crippled by it, even when an application does just use Java or what have you for lightweight code and defers heavy processing to a GPU or native call (most phone apps don't do any kind of heavy processing): there's still some speed wasted and most definately a considerable amount of RAM. Because 20 of these processes run at once today.

And if 10 of those are badly coded (which is realistic alas): exponential increase in footprint.

End of the day: it's just not a realistic solution for the product phone vendors are trying to make. And it remains beyond my comprehension why some developers feel that it is :)



It's not very comfortable. The NDK itself comes across as a niche to me, which again leads me to believe that the Android team has a lot to learn about usability. Which is weird since I believe that Google is packed with decent developers. At least they should be given what they're shelling out in terms of salary.

When I first heard about Android being a Java VM on top of a Linux kernel, I was like: "WTF?! Are that must be horrible!". Until it got a JIT (2.3.something) it actually was. Now it is at least usable imo. I agree on the wasted cycles, on the concept lacking in some parts.
Anyways. The thing is that Android's there and not going to go away very soon probably... ;)
I hope they can fix the speed, fragmentation, security and API issues and do a more anal check on Apps before they go to the store.

Wonder how ICS performs on my phone btw, let's hope it becomes faster... ;)

Btw. How does "Eigen" work in the Android NDK? Anyone experience with that?

In the city yes, but I mostly use it to drive into the mountains. A mouth isn't so much use when there's only sheep to ask :) This is where anything cloud-based tends to fail too, because there's sometimes no phone network at all, never mind 3g.

A paper map is ok, because the phone still gives GPS coordinates even if it's totally offline, but it means stopping to check. Why bother if the phone is there at your side anyway? (Mine is almost always on in the car, because it plays all my tunes too.)

Plus an even more anal check for each new device that a phone vendor ships and we'll be on the right track to something that's, yes, usable.

In my experience, people who slam Java have usually been exposed to J2ME on mobile. J2ME is shit. Java on Android is acceptable, and Java on webservers is often the best possible option, both for speed and scalability. It's all about context :)

Good to know that today we regard "acceptable" as a quality when it comes to an OS-integrated language. Because battling inherent slowness is a very good use of the chic 4 cores in today's modern phone.

Sad, sad and once again: sad.

plek: I didn't say it was good on Android, I said it was acceptable -- because it is. :) That said, at work we do all our Android work in C++ (NDK) anyway so we're not really affected by the Java-"issue" because we don't really have to deal with it at all.

@gloom
Actually I was talking specifically about Java on Android, and my bad experience with it that made me think that it's unacceptable for even minimal floating point computation.
Java on webservers -- yes, under some conditions it can get even faster that native.

is it the cloud thing again? No VM can be faster than native. It can be the same speed, it can't be faster. Native code doesn't imply leaking every single alloc, you know? :P

http://www.engadget.com/2012/02/26/orange-santa-clara-intel-medfield/

So, next year, when Intel starts shipping Android phones powered by Atom CPUs, you'll need to provide two different binaries for each architecture for your client's fart app / website app? Java is slower than native code, but it has other advantages. Remember, we're not in Wintel-land anymore, Dorothy.

I envy you for working in an environment where there is time to do proper application memory management. In my work development cost is so high and deadlines so close, there is no time to juggle malloc's and free's. The client simply does not pay that much.

And just what is the percentage of apps people actually use that require serious number crunching? I know I don't use any. But you still have the choice to use the NDK if you must.

The C++0x evangelists tend to disagree.

@xernobyl
Not VM, but JIT that has enough statistics about runnig the code in question on real production data. Also, if you haven't noticed, I'm the one here for native and against VMs :D.

i wonder how big is the java server market share for online games these days. i would assume very small, only old companies with lots of legacy code still walk that road. no?

nginx+nodejs getting a big rise last year aparently. wonder how much of that is new thing hype talk and how much is actual usage.

Re. Medfield, you can put binaries for more than one architecture in an apk (APP_ABI=ALL). Furthermore you might be surprised at just how well Intel's binary translation technology works.

Well, the original post is very cool...but the thread turned into garbage quickly. Props to the MoSync guys.

[rant]Once you have to write a software renderer for a platform that had its GPU capabilities castrated by the OS developer you should instead go the extra mile and and kick their heads in...[/rant]

Else than that: Hooray for software renderers. Boo to M$.

Topic closed.

It's not a software renderer

When microsoft first took a crack at making a JVM, iirc it was pretty good... faster than Sun's but sun sued them. Microsoft's Eric Traut has done great work with JIT stuff, and even has some patents in that area. So far as I understand, MSIL/CIL has never been anything like this.

Programmable shaders where promised for Windows Phone from the very beggining, so I am surpised that they still do not allow that.

I confused the XNA->OGL conversion and the software shaders. sorry.