I understand what you are driving at and I agree with the point you are making. But you gotta understand that there is a major problem with interpreted applications. They are too damn slow! And the market place kind of reflect this: try to name any java games for sale that you can buy in stores. Even if you look at the benchmark that you gave, iphone has a bigger framesize and taking that into effect, they rule on framerate. If you put a java layer on top of it, you are going to make apps 5-10 times slower! Then the comparison is not even worthwhile. By the time you get new cpus that can run java apps approaching bare metal programs running on the old cpu directly, the competition will have 5-10 times faster speed on the same new chip running apps directly on the metal! You will always be one step behind waiting for moore's law. Most desktop cpu's go through 6 month cycles... you see new cpu's come out 6 months or less. Do you recompile your apps or games to run on them? No. They are all binary compatible, so this is not a problem. Also 18 month cycle is too long. New models of motorola and nokia come out every 3-6 months. You want short cycles, with binary compatibility. Instead of supporting many chips, just support a few. This way the next intel or amd can compete in the mobile area with binary compatibility in the speed and battery savings arena. Google is rich enough, they can handle two or three chips (there are not THAT many anyways... mostly ARM derivatives). Maybe flexible library modules for different hardware modules (gps, phone, acceleration, fm radio reception, etc) that work on different cpu. (mostly a fast table lookup of pointers) that don't change much. And the core library tailored for each specific cpu. You are also not taking into consideration that making a new java work on a new chip is harder (and takes longer) than just making a sdk for developers that go to the metal on the new chip.
Before I start a flame war, lets get the main point: I am asking for another sdk for programming to the metal, not get rid of the java sdk that is android now. Why limit your speed when you can get the android OS to run at full speed in assembly, and offer the java stuff as an optional MODULE for people interested in programming in it. If they want it, then their program will load the java modules for running it. While normal programs will be able to run at the speed of the chip directly without going through interpretation. Google can optimize the OS at the low level, and others good in java can optimize the java on top of the optimized OS. Have you tried any java games on mobile phones. You should try them then you can understand the main problem (slow! and sometimes freezing resulting from interpretation or garbage collection). On Oct 5, 2:08 am, Nikkelitous <[EMAIL PROTECTED]> wrote: > Hate to add more, but here are some details about the processor in the > G1:http://www.qctconnect.com/products/msm_7201.html > > Look at some of those. Note particularly the "Java® hardware > acceleration" and the "4 million triangles per second". > > Also athttp://www.glbenchmark.com/result.jspwhere they actually > benchmark the GL speed of many systems, nothing can match the raw > triangles/sec of the MSM7201A in the G1. True, the N95 has INCREDIBLE > implementation of GL that can knock the socks off of anything else > right now, but with the open source nature of Android I'm certain > we'll get there with any other devices. Also one thing to note is > that the iPhone falls below pretty much every device in pretty much > every area EXCEPT for Floating point operations. In fact, it falls > below even devices running Java using the same exact GPU. > > I think this wraps that up, but I may add more if I really feel like > adding more. > > On Oct 4, 10:36 am, Nikkelitous <[EMAIL PROTECTED]> wrote: > > > I disagree with many of your points here. First of all let me address > > the idea that compatibility is somehow less important than speed. > > This I vehemently disagree with. I think it's far more important for > > upgrades and alternate hardware configurations than for high speed > > NOW. > > > You see, if we follow Moore's Law and Gene's Law we see that > > processors double in speed and half in power consumption every 18 > > months. Now some may argue it's slowing down, but on mobile > > processors I actually see it speeding up as they implement older > > desktop processor improvements into the mobile cores. > > > Now, the big thing about this is that these improvements, when dealing > > with mobile hardware, usually require a COMPLETELY new processor. > > This means that someone on the "Cutting edge" will have to replace > > their processor every 18 months to get double the speed. Even worse, > > this means the "operation window" on compiled apps is 18 months as > > well! This is unacceptable to many companies and especially difficult > > when you consider that in addition to recompiling everything for every > > device, you'll likely have to use new APIs for everything. > > > This is INSANE! It's one of the biggest problems with Windows Mobile > > devices. I had a Jornada running Windows Mobile and I pretty much > > just gave up because applications were out there, but it was > > incredibly difficult to find one that ran on the processor I was using > > and didn't require newer libraries. I think that Google's approach > > with Android is incredibly forward thinking and likely the only reason > > that in the end Android will win out against others. > > > Now, you mentioned flash as fast. Guess what? Flash is an > > interpreted language JUST LIKE JAVA! You mentioned it runs quickly > > but in my experience there is nothing slower than Flash. Now, I agree > > Java is slow. One thing I don't agree with, however, is Dalvik being > > slow. Dalvik, the Virtual Machine and Bytecode that Android uses is > > *HIGHLY* optimized for mobile RISC processors and I believe it's well > > worth the speed loss. > > > From what I've seen (Android running on Nokia N810) I've noticed that > > Dalvik based applications actually run significantly faster than Maemo > > applications. Now, I'm sure this is primarily limited to the simpler > > GUI design with less overhead and maybe computational intensive apps > > will run faster on Maemo, but isn't that what cloud computing is all > > about? > > > Now, the only thing you can't really "cloud compute" is games. It's > > true that games are intensive apps requiring tons of resources and > > "bare metal" tends to work best on that. I don't believe this is the > > supreme end-all though. Games are definitely possible on mobile > > environments even without "bare metal" access. iPhone has bare metal > > sure, but you know what? It, as hardware, wasn't designed for games. > > It's processor/GPU combo were selected for playing music and youtube > > videos, not for games. As such it's severely limited when games are > > running on it. It's true that due to that "bare metal" perspective > > it's still quite decent. However, a newer ARM CPU with any of the > > newer mobile GPUs will burn any of that speed away EVEN WHEN THE CODE > > IS INTERPRETED! > > > Let me say that again, interpreted Dalvik games will likely run better > > than native iPhone games! Now, many may disagree with this, but my > > argument on future-proofing stands. iPhone will never be able to > > change CPUs or even GPU architectures without a total rebuild of all > > applications. Android, however, will run on ANYTHING (even X86) and > > so is quite literally and thoroughly future-proof. > > > On Oct 3, 9:36 pm, Vinegar Tasters <[EMAIL PROTECTED]> wrote: > > > > I can understand the Android tries to be one operating system on > > > multiple mobile devices (and their associated chips and CPUs) using > > > java as an intermediate compatibility layer. However, as many people > > > found out wish java, javascript ecmascript, python, and other > > > interpreted languages, they are slow, too slow for cpu intensive > > > applications like 3D apps (including games), apps needing lots of > > > calculations (lots in this group like software based movie players and > > > other things). I think in order for android to succeed it needs to > > > basically go the pedal to the metal route and simply offer different > > > SDK for different mobile devices that use different cpu chips. This > > > way people can program in C or C++ or even assembly language to get > > > the maximum out of the phone. admit it, most java apps on mobile > > > phone are too damn slow, and given that the cpu technology in mobile > > > phones are usually many times slower than desktop versions (in order > > > to save costs and power), this is a very serious problem. another > > > way is to just get android and the OHA to simply choose what chips > > > they support (the faster the chip the better) and develop an OS around > > > it. You don't find any java applications or games in the marketplace > > > that people buy for their desktop simply because they are sluggish > > > compared if you program in C or C++ or even assembly. This is partly > > > why flash succeeded whereas java applets failed, because flash is fine > > > tuned to run at full speed of the chip underneath, and there are > > > multiple versions of flash for multiple OS and chips. I won't go into > > > flash apps being compiled scripts (yes they are compiled, but faster > > > than java applets, but you still don't buy flash apps in stores, only > > > c and c++, or assembly apps), but the main point is that when you go > > > closer to the metal, and offer direct access to the hardware, the > > > better apps and chance for success there is for it. So maybe google > > > can wake up and offer choices. Java based sdk for casual stuff, and C > > > or C++ based sdk for people who want access to the hardware without > > > going through an intermediate layer like java. The Android OS should > > > not be java based, but should be in assembly or C. If it is java > > > based, it may doom like most people using mobile phones these days > > > don't buy java based mobile apps. I have nothing against java, just > > > interpreted stuff that are slow, even if it is "compiled at runtime". > > > I only wish for options for developers to get to the metal directly. > > > Because nothing compares to having access to the chips directly and > > > not through interpretation. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
