On Mon, Sep 17, 2012 at 11:02 PM, jamb <[email protected]> wrote: > Thanks for the reply, Kris > > There are some monumental misunderstandings going on here, so I'm not sure > where to begin... I have absolutely no intention of starting a flame war, > that is totally counter to the point of a forum. However, you clearly > misunderstood my post, or you are defending your beliefs out of a sense of > loyalty. Let me clarify a few points, and maybe get some input from others! >
I don't disagree with all of your points, and I don't have a loyalty, you can design the platform differently, but I'm used to hearing "this platform is built on a vm, that seems like a dumb idea" without *any* substantiation as to why this is the case. You still haven't provided any concrete evidence as to why this is bad... It's a design choice, and a different one from the typical system. I'm very much with you on the fact that it seems strange, but for different reasons: I would like a much more power efficient system, and I'm not convinced Android's architecture does enough to address that... So don't read this as me beating down your points, but rather analyzing them based on my experience in hacking on the platform.... > First and foremost, I didn't know this wasn't a Google "official" forum. The > fact that I'm staring at a Google logo in the upper left hand corner of my > screen while typing this, indicates they SHOULD have some interest in what's > being said about their flagship enterprise! If Android isn't Google's top > ticket item these days, I have no idea what is. Probably search, I would suspect, considering Android doesn't generate much revenue? > If there's a better place to ask this question, I humbly ask a moderator to > move this discussion to a more appropriate thread. Thanks in advance. I suggested android-platform, didn't I? If you read the guide for this list, you will see that it is exclusively for SDK related questions, not questions about methodology. > I never suggested I was an expert in software architecture, thus the > question in my original post. I've built numerous computers, and suggested > only that I have a fairly comprehensive understanding of hardware > architecture. It actually goes a bit beyond building computers, I also have > a great deal of experience in troubleshooting hardware -- down to the > circuit level. > Okay, fair. > And yes, why Java? The whole point of my question is: Why base an operating > system on a VM?! It's a design decision, with proper JIT, you can see the vm not really as an interpreter as but as a runtime environment. I believe that having a garbage collector and runtime system under you does provide a lot of good things. And by the way, Objective C has a runtime system as well! A quite nontrivial one... > I never said a VM obviated the security architecture of Linux -- I said > Linux had a great security architecture without the need to sandbox it. I'm not sure I believe you on this... what would you suggest instead? Running all apps in the same process? If you run something in a different process it's going to be sandboxed to a certain level instead. Perhaps you are speaking to the user IDs that differentiate each process? Please clarify a concrete example of how the Android additional security (largely introduced to fit their new security model) hurts developers? In my experience, the added security in Android it to support a new model, but I don't know what you think is bad about this. For full disclosure, I do think there are potential bad things about it. It would be cool to have apps use 'higher order' behavior without heavyweight RPC, by having pieces of the other app run in process or something, I can imagine that as a possibility. > The fact that a VM is slow, wouldn't just be my thought if it's so common. > The simple fact is that a VM cannot possibly execute bytecode as fast as > native code. Even with processor extensions that give VMs direct access to > to CPU (VT-x and AMD-V) there's still I/O (including display and memory), > meaning computational throughput cannot possibly match native code. My > contention that a VM is slow isn't my imagination, it's rooted in direct > evidence that a VM cannot, by base virtue, perform as well as the host > machine. And JIT (Just-In-Time) compilation doesn't mean the code is > executed the same speed as native. It means the code is compiled on-demand > to native machine code - and then executed. It still has the overhead of > being compiled on the spot. Native code doesn't need to be compiled JIT! > Are you sure you understand the Android JIT model, code can be JITd once and stored in cache so that it does not need to incur this constant time behavior every time the app is executed. And no, JIT code won't run as fast as native code, for a bunch of reasons, at the same time there are optimizations under a JIT environment that you can't do in a compiled environment, mostly because of very good profifiling capabilities and knowledge about the hardware. Is it as fast as if you wrote your app in C. No, I'm certainly not arguing that, so don't interpret it that way. But I do believe the slowdown that you experience is worth the trade off for having a simple runtime system. Should all apps be written inside bytecode? No. Graphics apps certainly should not, and they are written in the NDK. Would it be cool to have a way to write apps entirely in C without needing any of the VM? Yes, but also, the zygote process model wouldn't fit this as easily. Again, a tradeoff, you can certainly argue it's a bad one of you want... > The argument about Haskell is ... what did you say? Uninformed? There is a > vast difference between bytecode executed in a virtual machine, and high > level compilers. A high level compiler is often considered "slow" compared > to C because of the assembly/machine code that comes from it.... not because > the code is being executed in a VM environment. I'm not really sure what you're saying here... You can compile OCaml to within 2x times the speed of C... I suppose it's often considered slow compared to C, but then again, there are tons of things I would write in some higher level language I wouldn't want to write in C, it's worth the trade off. Are there resource intensive parts of the code that should be in C or inline assembly. Hell yes.. A vast difference bytecode executed in a virtual machine and high level compilers? Well, yes, but again, there's a lot of JIT that goes on. Is managed code slower than native code. Yes, that's not debatable. Would the vast number of apps in Google play if everyone was forced to write in C and manage their own pointers and program with it's system (remember, Java is just stupid easy..)? ... I severely doubt it... Is the high code generated from a compiler slow? Most of the compilers I know generate bytecode or native code. Look at ocaml (or haskell), you can dump out bytecode (STG code, ocamlbyte, etc...). Then you write an optimizer that optimizes the hell out of that code (ocamlopt really just beats the pants out of that stuff...).. > I understand completely how register based code executes faster than stack > based - it's the same difference between pascal calling convention and c > calling convention. By most/many estimations the register based calling > convention of pascal makes the code execute faster -- in that regard c is > usually preferred because the difference in speed is relatively minor > compared to the raw power (access) of c. But this isn't a discussion about > the virtues of pascal and c calling conventions. Really? Because any real java implementation won't actually execute that code using a stack... that would be really sucky... The conversion to a register based allocation is trivial enough that the change is mostly cosmetic, once it actually gets pulled into the vm it will do whatever it wants, usually something much faster (for java...), such as throwing it through a JIT... So is implementing a register based vm the naive way faster than a stack based one? Perhaps, but it doesn't matter, because it never works this way in reality... > Side note: Objective C is just another compiler - it still compiles to > native code. Cocoa is just a library that Objective C programs build > against. It's a "high level" language, yes - but the compiled code does NOT > run in a virtual environment. Huge difference. a "virtual environment?" You mean an interpreter. If you want to say it's strange that Android code runs in an interpreter, I agree. The interpreter is pretty damn fast, but is it weird that you have to run it in one and can never escape? Sure, it is. I agree with you there. Do I think you shouldn't worry about it because a trace based JIT will take the code that actually matters and turn it into native code? Yes. Also, I think you underestimate code time is actually spent inside the VM, in reality a lot of time is spent in the system, which is all native code without executing inside a "virtual environment" > And to address your final point: if I thought Android was "bad" I certainly > wouldn't have spent $800 on Android powered devices. Apple iOS devices are > crippled in a different way: they assume too much for their user, and leave > little in the way of customization. They also lack a rather robust, > open-source development community. In the end, I will choose any alternative > on my mobile devices to Microsoft and Apple. That leaves Android. > > So, I've addressed all of your points. And I still submit my question: why > Java? Or rather, why a virtual machine built on top of Linux, rather than > Linux itself?? > I don't disagree, but I don't think you have much evidence to support why the VM based architecture is so bad. Is it a little weird you can't write your own apps that run natively? Sure, it is. Is it weird that code through the NDK has to run through a VM. Yes. So yes, Android has made some tradeoffs. Everything runs in a VM, sure, and it's a bit strange. Why are you so opposed to this? I can think of a few reasons: -- it boxes you into a single runtime, severely. You can't easily write up your own environment to actually write Android apps, they have to go through the VM, and the GUI primitives are through the API, which has to be accessed through the VM. -> Completely valid argument... -- It's slow. -> Not as bad as you would think. If you're going to argue this you need firm numbers, and I believe the contention is that the use of a VM along with proper JIT means that it's not really bad enough to hurt perf in a real way... If your point is the first one, that's valid, I'd like to write other kinds of apps in Android too, I'd like to port a haskell or ocaml runtime and run it without having to go through the trudgery of the NDK. I get that, completely... If it's the "you have a VM, your code will never be fast enough," well then I just get tired of that argument by uninformed parties trolling without really comparing the numbers... In the end, this was how Android designed, and if you have a use case that doesn't fit with the system, you will be working against it, and if you really hate it, you might need to consider a different system. kris -- 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
