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 at http://www.glbenchmark.com/result.jsp where 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
