The Care and Feeding of the Android GPU 307
bonch writes "Charles Ying argues that Android's UX architecture has serious technical issues because, unlike the iPhone and Windows 7, Android composites the interface in software to retain compatibility with lower-class devices. Additionally, Android runs Java bytecode during animation, and garbage collection blocks the drawing system. Google engineers dismiss the desire for hardware-accelerated compositing and cite more powerful hardware and an avoidance of temporary objects as a solution to the collection pauses, but Ying argues that will just lead to [a lower] average battery life compared to devices like the iPhone."
I've complained about this more times than i care. (Score:2, Insightful)
the interface never seems as polished without hardware acceleration, Just look at Mesa and a full linux desktop running ATI or Nvidia drivers with compiz.
Re: (Score:2)
I find it funny that the article mentions Galaxy S, and the browser from the recent JPU/X/Y firmware. I've used the JPU/Y browser on a day to day basis, and it's horrible. Pinch-to-zoom is very smooth, and the tiling isn't really an issue, but the page sometimes gets very distorted when panning. I haven't noticed any improvements when scrolling, it's choppy as it ever was. The JPU/Y browser has made me even consider changing to Opera/Firefox/Miren or something else as my day to day browser.
Sent from my Ga
Re:I've complained about this more times than i ca (Score:5, Funny)
Speaking as a former Googler, the smart people spin is somewhat overrated. Arrogant people is closer to the truth, and "smart" tends to mean "good at avoiding work".
Re: (Score:2)
Speaking as a former Googler, the smart people spin is somewhat overrated.
And you say that as an unbiased observer with no axe to grind, right? :-)
Re:I've complained about this more times than i ca (Score:5, Interesting)
And you say that as an unbiased observer with no axe to grind, right? :-)
Right. I still own all my Google shares. However I am now properly disillusioned about a number of Google myths, but don't trust me. Ask any Googler, former or otherwise. In the latter case, make sure to do it out of earshot of other Googlers.
There are smart people at Google, and if they are really smart they learn early to keep their heads down. This seems to be the main sequence for large tech companies. Microsoft is far advanced on that path and Google seems more than a little determined to follow. The stack ranking system is nearly a carbon copy of Microsoft's, which in turn was copied from GE, and look how well that worked out. The result is inevitable degradation of the engineering culture. Now, warning about the negative consequences is not the same as axe grinding, quite the opposite.
Doesn't Optimizing for GPU Exacerbate Fragmenting? (Score:3, Insightful)
Look at Samsung's Galaxy S browser. GPU accelerated and tile-based. I’m told it’s a result of Samsung’s PowerVR GPU optimizations.
Doesn't that require that the device have a PowerVR GPU on board? What about devices without PowerVR like the NexusOne, does it run on that?
When you optimize to GPUs, you have to optimize to all GPUs. I realize there are common instruction sets but the main selling point of Android is its versatility. If I start coding for only Snapdragon processors with PowerVR GPUs because it has a better UX, then it sort of destroys any benefit I get from Android and I might as well code for iOS because I know what that hardware will always be. A lot of the benefits of Android applications being Java byte code completely independent of the hardware are overlooked in this proposition.
The developers don't know what future devices are going to use for GPUs or their instruction sets. From one of the links Romain says:
New devices might allow us to overcome the past limitations that made GPU support a not-so-good solution.
Doesn't optimization for particular hardware exacerbate their issues with fragmentation?
Well, it's open source, there's always the smug answer that Charles Ying can go fork Android himself and add this and watch all the handset manufacturers flock to his side. If you think it's best, get a team together and do it.
From Ying's article:
Wake up, Android team. Windows Phone 7 just lapped you [anandtech.com].
Can anyone tell me why that AnandTech article from March is evidence that Windows Phone 7 has lapped Android? And why it just happened?
Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (Score:4, Insightful)
There is this new thing called "conditional compilation" which allows one to include code that both optimizes for certain hardware and contains generic code that could work on all devices. I hear it's the new rage of how you make code work on multiple hardware and software platforms.
Re: (Score:2)
There is this new thing called "conditional compilation" which allows one to include code that both optimizes for certain hardware and contains generic code that could work on all devices. I hear it's the new rage of how you make code work on multiple hardware and software platforms.
You mean like the rage of having your code get more and more complex every time a handset comes out?
Re: (Score:2)
You mean like the rage of having your code get more and more complex every time a handset comes out?
So basically the situation that already exists. All these new devices tend to need new drivers added to the kernel and they usually do some sort of tweaking to the kernel. Seriously, if they can't handle complexity then they shouldn't be the ones maintaining and developing an OS. Such work is just inherently complex.
Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (Score:5, Interesting)
Debian seems to handle it just fine and (based on gcc) they're compiling for 14 different platforms* and 3 different kernels (linux, hurd, freebsd)
Is it that difficult to setup a similar thing in the app store? "Oh it looks like you're running an ARMv5 and a PowerVR GPU. We'll give you this binary."
Or, you do what Apple has always done with Fat Binaries. 68k to PPC. PPC to PPC64. PPC* to i386. i386 to x86_64. You could have one single fat binary that supported ppc, ppc64, i386 and x86_64. And it "Just worked". They were literally checkboxes in XCode. How many GPU and CPU solutions are there for the Android? This isn't low level Assembly code, it's compiled Java.
*alpha amd64 armel hppa hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mipsel powerpc s390 sh4 sparc sparc64
Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (Score:5, Insightful)
That depends on the optimization and how that chipset actually handles throwing stuff on the screen. 'Optimize' may not just mean "format the data this certain way and it'll fly through the processors more quickly", it could also mean "use more polygons and lower-res textures because the chipset is better at moving verts around than filling texels". It doesn't matter that it's not low-level if it affects how the whole engine works.
Re: (Score:2)
No. You only take the complexity hit on the second device.
The rest rely on the well known and well used methodology for dealing with diverse hardware you've already constructed.
It's like the 80s and 90s never happened or some such.
"mobile" doesn't change any of the problems.
Re: (Score:2)
Yeah and now you're talking about a massively different user experience on different devices ... that's really annoying to application developers.
So basically no different than the current situation [appleinsider.com]?
Re: (Score:3)
But how is that any different than the massively different user experience between the iPad and a Touch and an iPhone 4? Rovio's popular Angry Birds game has more choppy animations on the iPad than on some of the unsupported Android devices, btw.
Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (Score:5, Insightful)
massively different user experience on different devices
consider: different user experience on massively different devices
Why should it be otherwise? Should a quad-core i7 SLI provide exactly the same 'user experience' as an Atom netbook? Obviously not. It is not reasonable to expect the same results from increasingly diverse hardware. Android will be found on the lowest end freebee 'smart' phone China can make, while also appearing on the most outrageous hardware that doesn't present an immediate fire hazard. Where, exactly, was it written that the limits of one must apply to the other?
This problem has been solved over and over again. An architecture must exist that provides fall-back software implementations of hardware accelerated functions. When some app performs poorly due to inadequate hardware the user may find some other preoccupation or upgrade to a sufficient device.
What is the problem? At the moment it appears to be Google's obstinacy. This is a losing battle for them; they're creating a differentiating point among the manufacturers because the manufacturers can alter Android, including accelerating stuff with hardware. Marketing will then make claims about how xyz's Android is better than the other Androids because of xyz's special sauce (that may or may not port easily to some other collection of chips.) If the manufacturers don't the users will.
Lets hope Google wises up and deals with the issue properly.
Re: (Score:3)
Can anyone tell me why that AnandTech article from March is evidence that Windows Phone 7 has lapped Android? And why it just happened?
He's talking about the fact that Windows Phone 7 has advanced GPU acceleration built in from the beginning in several facets of the environment. Android doesn't and it's a few years older.
It certainly hasn't lapped it in terms of sales or momentum, but it could. Android has both the advantage and the curse of being more open and versatile - WP7 has the possibility of a more restrained set of hardware differences and can build in more low-level functionality.
Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (Score:5, Insightful)
Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (Score:5, Insightful)
Re: (Score:3)
Ahem...
Add to that this... Most SoC's run a fairly narrow and slow memory bus. Also, GPU's tend to be WAY slower than CPUs...
Fancy racing a 4 * 150Mhz pipe GPU against a 1 Ghz, superscalar CPU with 64/128 bit SIMD extensions?
Who will win?
Answer... the memory bus. You can TRY and get the CPU and GPU to work together but all that will happen is that the memory bus will get swamped and everything slows down.
GPUs can render polys with straight edges. UIs frequently want curved, rounded objects with complex grad
Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (Score:5, Insightful)
You mean it's like a real, honest to goodness, computer operating system? Oh no! The horror! Guess you should stop making software for Windows, Linux, and OSX then, since the hardware can provided different capabilities for systems using the same operating system!
Re: (Score:2)
You mean desktop computers, those complicated machines that mobile devices and tablets are replacing? People are trying to get away from managing device drivers and hardware compatibility bugs.
Re: (Score:2)
People are trying to get away from managing device drivers and hardware compatibility bugs.
Maybe I'm just weird, but that's not why my desktop and laptop computers have been getting lonely lately. It's because my mobile device is, you know, mobile.
Re: (Score:3)
Having a few 'better' options isn't going to be worse than the lowest common denominator crap that's going on now.
Re:Doesn't Optimizing for GPU Exacerbate Fragmenti (Score:5, Insightful)
Re: (Score:2)
Have we not learned anything from the desktop ? In 2011, as an app developer, you shouldn't be optimizing for any specific GPU. The platform's graphics API should be optimizing for whatever hardware it supports. New device ? New drivers! If Samsung's PowerVR implementation makes such a big difference, then we will see other hardware designs adopt the PowerVR. You don't need to reinvent the wheel every single time. Media-minded people will favour devices with faster GPUs, just like we do with PCs.
I'm
Re: (Score:2)
When you optimize to GPUs, you have to optimize to all GPUs. I realize there are common instruction sets but the main selling point of Android is its versatility.
Yes
That's why Apple uses LLVM to compile from 'generic GPU code' to 'GPU code optimized to Blah', that's on Mac OS and maybe on the iPhone as well
http://llvm.org/Users.html [llvm.org]
Re: (Score:2)
Java is the language used to program for Android, but the code compiles into Dalvik bytecode. There is no J2ME support at all, or any Java virtual machine on the device.
http://en.wikipedia.org/wiki/Android_(operating_system)#Features
Look at Java Support.
Re: (Score:2, Informative)
No, that one game everyone talks about doesn't count; it's not a result of OS fragmentation, but a result of some devices not meeting minimum hardware requirements.
What do you think fragmentation is?
What I find funny about this argument is that the same group of people claiming fragmentation will never be an issue is also the same group of people that claims that PC games aren't as good as they could be (graphically) because they cater to the lowest common denominator.
Re: (Score:2)
Nice try. You slipped in the phrase "OS fragmentation" when what people refer to is hardware fragmentation, which is what the last part of your statement is describing.
sounds like a job for JIT (Score:2)
Re: (Score:3)
Which means you now have to support how many cards? Are the vendors going to provide drivers that can even go into the android project?
Re: (Score:3)
Cell phones are not known for having many kinds of graphic cards available. Heck, they're not even known for using many kinds of discrete graphics chips. I will even go so far as to say that they draw from a rather narrow set of embedded graphics cores.
PowerVR is pretty much the market leader, ARM is playing catch-up with Mali, and then you get the long tail. GPU core and SoC vendors know how to work together to deliver usable libraries for chip buyers -- witness the OpenGL ES acceleration that is availa
Re: (Score:2)
Usable for chip buyers, which means probably not generally available. Thus meaning as google is not a chip buyer what are the odds they will get gpl, bsd or apache licensed code?
Re: (Score:2)
Google gets GPL-, BSD- and Apache-licensed code all the time. If you meant to ask whether Google will get device driver code that falls under those licenses for the various cores and system-on-chip platforms that are out there, the answer is that Google doesn't need that. Google needs an API like OpenGL ES for Android to use. The component vendors typically make sure that OpenGL ES drivers for Linux exist in distributable form.
Re: (Score:2)
Which means kernel updates become a huge pain. I buy desktops and laptops with open drivers for a reason, I want a GPLed drivers on my phone too.
Re: (Score:2)
Good luck with that windmill, Senor Quixote.
And yet, somehow, it's WORKING!? (Score:3, Interesting)
OMG Android is making a play that's designed to let lower cost, highly capable devices subsist in the marketplace? How horrible is that?
I switched from Evil Major Network (TM) to Metro PCS a little over a year ago, and haven't regretted it for a SECOND. It is so nice, getting what you paid for, rather than wondering how much you'll be overcharged for what you aren't even sure you got... it's the ONLY way to survive teen children!
And even Metro PCS, the low price leader, offers a couple of Android phones that are highly capable and useful. For less than $300 I was able to upgrade my wife's shatty phone with a nice, capable Android phone with GPS, navigation, browser, email, games, full-screen youtube, Facebook, Marketplace et al (AKA "the works") and a good, full day of battery life. She LOVES the phone! In case you are wondering, it was the Samsung LG Optimus. And the network cost went from $40/month to (gasp!) $50...
Talk about having your cake and eating it too?
Say what you want, Android's strategy is working, as demonstrated by its continuing skyrocketing market share.
Re: (Score:2, Insightful)
Pretty bad actually. Considering we've been using APIs that allow hardware acceleration with fallback to software implementations like OpenGL to handle JUST THIS EXACT PROBLEM for the last 25-30 years, I'd say it was absolutely shitty for Google to fuck up this badly.
Of course, perhaps thats cause I understand the problem as stated where as you're comparing service provide
Re: (Score:2)
Re: (Score:2)
Horrible enough to hurt the user experience, unless you think it's okay for software-based compositing to inefficiently drain your battery or for scrolling to be choppy years after the iPhone 1 on less powerful hardware was smooth and responsive. If you don't think it's important for animated user elements on a touchscreen to not pause, then you're just being a fanboy. If A
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
But best of all is unlimited data/text/messaging and 300 minutes for $25/month, and no contract. I can't see paying AT&T prices, even though the iphone is a bit nicer.
Your wife must be different from my wife, who manages to exceed her 1500 minutes/month allocation. Is your wife a deaf/mute, by any chance?
Re: (Score:2)
Get her a damn job. Both me and the live in girlfriend only use about 150 minutes a month, maybe another 100 verizon to verizon.
Re: (Score:3)
The best advertisement a company can get is word of mouth.
Feeding the what? (Score:4, Informative)
Let me tell you one thing about that: Java isn't the problem. In my definition of feeding the GPU: triangles/sec, fillrate and OpenGLES objects/sec, Java is just 10% behind a raw C benchmark like glbenchmark 1.1/2.0. They quoted 880kT/s, I managed 750kT/s in non native code. And to get that, you have to carefully feed the GPU with the right batch sizes, don't issue too many state changes, pack things interleaved in the video buffer, don't use dynamic point lights, etc etc. It isn't as bad as an NDS, but the Snapdragon GPU is quite hard to tame.
The problem with using the GPU is that every context switch requires a complete reinitialization of the GL context, even on a PC, alt tabbing into and from fullscreen games takes ages - it's fine when specific applications which requires the speed use it directly, but it's not when going from one activity to another gives you a loading screen.
Animation performance and touch responsiveness? Is that the best he can come up with for such a title? I have no idea what he's talking about, but scrolling the browser works just fine here on a not-so-recent HTC Desire. The only time things break down is when the garbage collector halts everything for a third of a second (see DDMS/logcat messages), and those pauses are reduced to sub 5ms in the new builds. That's tons more useful than rendering surfaces to quads and using OpenGL ES to draw them, and IMO, the Android team made the right decision.
Re: (Score:2)
Odd, I've never noticed such problems in Mac OS X, even though every window in the OS is composited by the GPU. Maybe it's not so much that GL is inherently flawed s
Re: (Score:2)
Re: (Score:2)
The G1 can run Froyo. I would imagine Gingerbread will soon be available for it as well.
http://forum.cyanogenmod.com/index.php?/files/category/3-htc-dream-htc-magic/ [cyanogenmod.com]
Given that phones are still an 'embedded' platform (Score:2)
It seems like something like Meego (Linux+GL+Qt) would be the best way to go, if you are not an Apple device.
I never understood why anyone would want to interpret byte-code on a battery powered device. Or give up control of garbage collection. Maybe the VM enforces things like local file system access, but a few lines in the kernel can enforce that too.
Also Poor compared To Symbian Battery life ..... (Score:2)
Symbian^3 also needs a GPU and has very good power management and doesn't support older hardware ... oh, but wait, this is Slashdot....Symbian bad and old fashioned and hopeless...Android good.....
Average? (Score:2)
GC vs. temp objects (Score:2)
and cite more powerful hardware and an avoidance of temporary objects as a solution to the collection pauses
LOL.
Java is pretty much only GC language I'm aware of where temp objects are passed to GC. Perl (and I'm sure myriad of other GC languages) at compile time takes note what objects are not used outside of the context and destroys them immediately. IIRC Java is the only language where they blankly send all stuff to GC, regardless. Obviously that that in long term hurts latencies: GC has to recycle them eventually and if there is no spare CPU/core, then it has to take the time from other threads.
Re: (Score:2)
Java is pretty much only GC language I'm aware of where temp objects are passed to GC. Perl (and I'm sure myriad of other GC languages) at compile time takes note what objects are not used outside of the context and destroys them immediately. IIRC Java is the only language where they blankly send all stuff to GC, regardless. Obviously that that in long term hurts latencies: GC has to recycle them eventually and if there is no spare CPU/core, then it has to take the time from other threads.
You're forgetting InterLisp (which probably is best forgotten). When Xerox released the InterLisp D machines, even files were garbage collected, meaning that if you deleted a large file, the machine went into a 10 minute garbage collection cycle, effectively blocking it from doing anything else. I'm sure there are other languages that use poorly-designed GC as well. I've never really liked garbage collection, but the alternative is to use IBM MVS like static preallocation of a "dataset" fpr everything. This
Re: (Score:2)
[...] but memory is dirt cheap these days.
On embedded platforms there are no cheap resources.
I once was asked, as a software developer, by my friend how it could be that iPhone with its measly CPU/GPU has smoother UI animation than the monster of a phone which is the HTC Desire HD. And I have reminded him that long long time ago, in ages when 640K of RAM was a lot and high-end CPUs were 25MHz, animation in games was too smooth. It does depend more on the software developer's skills than on hardware. Apple takes time to polish it to perfection -
Re: (Score:2)
This isn't true with modern JVMs and JIT compilers. Almost all of the modern JVMs perform escape analysis for hot code to determine if an object can become visible outside the local scope, and using stack allocation instead of heap if appropriate.
Re: (Score:2)
Any pointers to the Java specific information?
We did recently long term latency-centric tests and we clearly have seen that Sun's Java 6 doesn't do it. The stateless network server literally halts for 500ms/more every time GC runs - while the server is supposed to run with latencies >100ms. Memory allocation is also OK as (1) there is no global state/data/etc and (2) the work of the server is to essentially dump to disk some of the incoming traffic and send a response back.
Re: (Score:2)
doesn't matter (Score:2)
no android based system will ever, ever be as great as the iPhone. clearly it is foolish to even dream of such a thing.
what is becoming more and more obvious with each passing month is that nobody cares. Android is outselling everything else by an ever increasing margin.
Testing (Score:2)
It sounds like the Google engineer is taking the sane approach. He is trying stuff and testing the speed. Sounds like he'd try GPU if it helped.
Who? (Score:2)
So some random person on the Internet who doesn't appear to have much to do with Android points out a couple of not-really-problems, and suddenly everyone is supposed to drop everything and fix them?
If you search for "charles ying android" every link comes back with a reference to this single blog post. I could take him seriously if I'd ever heard of him in the context of Android development, or even at all...
Java bytecode? (Score:4, Informative)
Additionally, Android runs Java bytecode during animation
Except in the real world, where Android uses a non-Java VM with its own bytecode, and doesn't run Java bytecode at all.
Not about battery life (Score:5, Interesting)
Re: (Score:2)
I watch youtube on my netbook just fine. It has 2GB of ram and an SSD. WTF are you on about?
Re: (Score:2)
Re: (Score:2)
Hmm, let me check, nope no one mentioned that, so I fail to see why it matters. If I want to use skype I do it from the nice beefy HTPC and use the nice camera there too.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2, Insightful)
A shoddy workman blames his tools.
And a great workman knows that certain tools are shitty and worthless.
... and the expert gets to chose his own tools. (Score:2)
Re: (Score:2)
Then don't bother with Android. Even if you use the NDK you are still having your program sandboxed in the VM and you get no real speed benefits.
Re: (Score:2)
O rly? [android.com]
If you write native code, your applications are still packaged into an .apk file and they still run inside of a virtual machine on the device.
It's funny that you claim it doesn't run within the VM yet Google says just the opposite. Oh who to believe...
Re: (Score:2)
Then fragmentation really does become a problem because the processor is not guaranteed to be any particular model. You'd have to manually compile for each one.
That's why the JVM (or .NET CLR) is so nice. You can compile once and have it run on all devices.
Re: (Score:2)
.NET on all devices? Are you mad?
No matter what MS likes to claim .NET is not portable in any meaningful way. The day I see MS made virtual machines for linux and mac is the day .NET becomes portable.
Re: (Score:2)
Ported != Portable.
Most of .NET is very platform agnostic.
Re: (Score:2)
A shoddy workman blames his tools.
Unless the tool is the thing that is shoddy.
Re: (Score:2)
And in this case the particular programming language, Java, is shoddy.
Re: (Score:2)
A shoddy workman blames his tools.
Unless the tool is the thing that is shoddy.
A particular hammer might be shoddy, but hammers in general are not. A good workman might blame a particular hammer, and switch to a different hammer, but only a shoddy workman would blame hammers in general, and starting hammering with a crowbar.
Of course, the OP might be suggesting that Java on mobile devices might be like using a sledgehammer for hanging a picture frame. I'm not sure I agree with that assessment, but your rebuttal is a straw man argument.
Re: (Score:3)
At least a sledgehammer is an actual hammer. Using Java on a mobile devices is more like using a whale to hammer in screws.
Re: (Score:2)
Hmm. I guess the fact that java* has been working just fine on mobile devices from a decade ago bears no relevance to discussion I guess?
Can we please stop mixing up the java APIs (and some of them do contain horrible bloat), "libraries" (but nobody really forces you to build your app around that 30MB OpenGL/DirectX software renderer), and the language itself (that allows to implement memory-copy-less networking stacks, in example, and once you've cleaned your critical execution paths from needless memory a
Re: (Score:2)
Re: (Score:2)
Java failed on the desktop because it tried to do too much and failed to provide a consistent, native-like user experience.
Dalvik on Android provides a very consistent, native experience because the platform is built around it.
And it provides a level of abstraction away from hardware that allows an Android app to run on any number of Android devices, if it's well written (i.e. can handle different screen resolutions, etc. - if you hard code tons of shit, you can still write apps that suck or don't work well
Re: (Score:2)
What about the collector pauses?
Re: (Score:2)
Actually, it is. Garbage collector stalls have been a problem that has consistently plagued Java for as long as it has existed. Those of us who have been around long enough still remember Java apps hanging for tens of seconds at a time while the garbage collector ran. These days, the user would force quit long before the app came back to life if an app were to hang that long. It isn't nearly as bad these days, of course, but on a slow CPU, it can still be a problem. That is
Re: (Score:2)
Yet perl does not have that problem. Almost as if GC is not the problem, but the particular implementation is.
Re:Java, the original sin (Score:4, Interesting)
Interesting theory. I've been working with Java since version 1.0 on devices as slow as an embedded 100Mhz device with 128MB RAM and I never remember GC taking seconds.
Just because I'm curious I tried to push our Java application (Data integration engine) to use both CPUs at 100% and dump the Garbage Collection stats to disk. Here's a typical sample:
133,091: [GC 30567K->10559K(60160K), 0,0052000 secs]
133,447: [GC 34943K->10347K(64832K), 0,0036360 secs]
133,873: [GC 39659K->10347K(63872K), 0,0028940 secs]
134,286: [GC 38699K->10531K(63104K), 0,0033140 secs]
134,674: [GC 37923K->10263K(61952K), 0,0019690 secs]
135,072: [GC 36759K->10351K(61184K), 0,0024490 secs]
135,462: [GC 36015K->10339K(60352K), 0,0022610 secs]
135,797: [GC 35171K->10739K(59840K), 0,0039780 secs]
136,134: [GC 34803K->10679K(59008K), 0,0033120 secs]
136,479: [GC 33975K->10567K(58048K), 0,0029140 secs]
136,801: [GC 33159K->10647K(57472K), 0,0026420 secs]
Note that this is without incremental garbage collection enabled. It might be possible for graphics intensive applications to notice the fraction of a second of delay but something tells me that this just might not be the case.
Re: (Score:2)
Don't blame java for that...
Re:Java, the original sin (Score:4, Informative)
until the iphone came around RIM and others would have low end, mid and high end devices with different hardware. i've even seen dumb phones run java. it allowed hardware makers to have a ton of devices out there for every niche and cut down on dev costs. Java was cool since you only write the app once.
then the iPhone came and killed that model. the cost of the iphone is something like $2200 over 2 years. Droid is about the same. any other smartphone on AT&T or VZW will be within $200. i tell people to get the best phone they want since the cost is negligible over 2 years.
Re: (Score:2)
Android is going to get even more fragmented in the future, but that's not a bad thing. It just shows how versatile Linux can be.
Re: (Score:2)
If you say so, true believer.
How does it show how versatile it can be? Running with different hardware capabilities isn't something operating systems haven't done before. It is a bad thing because it increases development and support costs for app developers and forces bugs and design compromises onto consu
Re: (Score:3)
Re: (Score:2)
Is there some reason people continue to think Java is a good idea in handhelds? It's almost a religion, and no amount of dissuading seems enough to change people's minds.
Probably because for the mobile market, a managed environment and relatively easy hardware compatability trump performance as concerns.
Which doesn't make you feel any better when an app runs like crap on your phone, but, there it is.
Re: (Score:2)
As opposed to what? Python? Ruby? PHP?
Unless you want to get down and digging into mallocs Java works just fine. And as long as your little tetris clone doesn't depend on spring webapp supplying the board representation each frame to canvas via CORBA on localhost (can be done, can actually be done...) will probably won't differ all that much from what can be done by writing the app in assembler.
And if you really are incapable writing code that doesn't feed off heap constantly - you can develop in C on andro
Re:Java, the original sin (Score:4, Funny)
If one is incapable of writing Java/Dalvik code that runs well then I pitty the C code they will churn out.
Re: (Score:2)
Re: (Score:2)
There's this thing called 'modular programming'. You program things in coherent chunks. For example, you could program a good bit of the lower-level UI level stuff in a chunk (window/panel handling, for example) to handle any system. Now later, you could say "Wait, we could make this faster with Accelerated Hardware X) and then make a second module, that can be accessed in the same way, but uses Accelerated Hardware X. Now, at load time (or install time, or configuration time), it could spend a half dozen c
Re:Lead to... as in the future? (Score:4, Informative)
All the expensive devices uses capacitive screens, nice multitouch ones too.
Resistive is usually the cheap kind.
Re: (Score:2)
Great, so you want another pile of suboptimal backward compatibility to win rather than a well engineered solution?
If you want your software to run on really cheap and nasty hardware you have to make some pretty unforgivable software compromises. At least Microsoft, Apple and others have standards.
Re: (Score:2)
If success of the sub-optimal solution prevents the ascendancy of a monopoly even worse than Microsoft's then HELL YES.
Of course pointing to either Apple or Microsoft as the "savior" here is a fallacy. Each has it's own problems, even at the "engineering" level.
Re: (Score:2)