Ah, you did mention Haswell. I completely overlooked that.
. . . and?
Would it then be using emulation or virtualization? I'm way over my head when it comes to technical issues like that and so would defer to you.
. . . and?
Would it then be using emulation or virtualization? I'm way over my head when it comes to technical issues like that and so would defer to you.
That still depends on what the piggybacking OS is built on. Let's say it's Windows 8 as the primary OS but you want to run Android 2.3 on it. That would be emulated if the only binary available is ARM-based. What version of Android are they running on it? If it's a newer version that runs on Intel than it would be virtualized and not only lose very little performance as opposed to be virtualized but also be much, much faster than any ARM version (assuming that they did a good job on that version of Android for x86/x86-64 and the virtualization layer is good. Considering both of these in 2013 I'd say Android on Haswell will look impressive.
So lets assume the best for Android OS. What about the apps? Can apps be compiled for both ARM and Intel as fat binaries? I ave absolutely no idea how Java works here. I'd think only the Java engine needs to be compiled for this, not the apps that run in Java, but I honestly have no idea.
"Your mama's so fat her binaries support multiple architectures."
. . . and?
Would it then be using emulation or virtualization? I'm way over my head when it comes to technical issues like that and so would defer to you.
Don't do it guys, it's a trap!
Virtual machines recompile bytecode into native machine code. Virtualization doesn't affect the application binary at all, it is used to abstract hardware to an OS in order to run native binaries. Emulation has to recreate hardware in software.
Adobe Flash is an example of a virtual machine - that's why Flash animations work on all hardware. It doesn't emulate or virtualize an OS like say VMWare. It takes Adobe's partially compiled bytecode and then recompiles it into native code.
The advantage is being able to target multiple architectures easily but there is a performance hit (I think estimates are typically around 10% hit - possibly why Android is laggy but probably not, most likely just because it's badly optimized for the hardware) and because authored software is only partially compiled, it can be reverse-engineered and stolen:
Think about that if you publish apps on Android. Someone could reverse-engineer your work, modify it and sell it as their own app. It's a wonder large publishers even publish on Android. They'd be as well making them open source:
That's interesting. I'm sure the Samsung semiconductor head isn't happy to lose business to Intel. Intel must have made a compelling case.
Clover Trail is an interesting product, intel literal threw the book out the window and started over with the design. Clover trail is SIGNIFICANTLY different than previous ATOMs.
Now that still doesn't mean that this new chip will cut it in a tablet, only time will tell there. It just means that Clover Trail isn't a complete failure all around like previous ATOMs. Lets face it AMDs low end APUs ran circles around previous ATOMs. With Clover Trail I suspect the results will be tied to Samsung's ability to optimize for the chip. This means getting the Java rip off to work well and to get proper native development working on the chip.
In any event what this does indicate is that Apple needs to really work hard on a high performance 64 bit chip. Frankly all those AMD engineers they recently hired are likely working on a project too far out. This will be most interesting.
That still depends on what the piggybacking OS is built on. Let's say it's Windows 8 as the primary OS but you want to run Android 2.3 on it. That would be emulated if the only binary available is ARM-based. What version of Android are they running on it? If it's a newer version that runs on Intel than it would be virtualized and not only lose very little performance as opposed to be virtualized but also be much, much faster than any ARM version (assuming that they did a good job on that version of Android for x86/x86-64 and the virtualization layer is good. Considering both of these in 2013 I'd say Android on Haswell will look impressive.
According to the story there's no Windows there at all. Acer is specifically avoiding it. So it would be using virtualization then? Thanks Soli. That was much easier to understand.
Hm, as was said before, running Android on an x86 architecture would be quite a surprise. I do not quite see Google porting Android to x86 at this point. Most of their tablet apps are scaled up phone apps already. Making it even more difficult does not make any sense.
Could that be a "Surface" competitor running Chrome OS instead?
It really isn't a big surprise, Android and Linux underneath are designed to run on a variety of hardware. I86 does give them more operating system flexibility though. As for "porting" much of Android runs on a Java virtual machine rip off.
Running MS Windows on a PPC Mac is emulation because Windows only had binaries for x86. Running MS Windows on an Intel Mac is virtualization because Windows understands the HW. That means it al had to be emulated so that the processor code understand what the OS was requesting. This made it very slow even on the fastest systems. Many Intel chips are even designed to allow a VM to take advantage of the HW with less overhead but the OS needs to understand x86 or x86_64 HW for this to work.
According to the story there's no Windows there at all. Acer is specifically avoiding it. So it would be using virtualization then? Thanks Soli. That was much easier to understand.
Without knowing anything about this Asus AIO I wouldn't know. Are you saying that Android would be only OS installed on it? In that case it's running natively, assuming it's an Intel version of the Android.
Without knowing anything about this Asus AIO I wouldn't know. Are you saying that Android would be only OS installed on it? In that case it's running natively, assuming it's an Intel version of the Android.
Correct. Reportedly Acer has decided to avoid Microsoft altogether on this particular AIO.
I see talk of virtualization. Is that one of the many reasons as to why Android runs like complete shit?
Virtualization isn't exactly the same thing as running a Java Virtual Machine. I won't go into it here but rather will say research this in depth because this thread is already filled with misleading information. As to your question many things involved in the design of Android make it sluggish.
Java code runs on a virtual machine in most cases and has since its development.
True, but I was trying to avoid Java 1) because I know little about it and 2) its virtualization seems be hard to grasp since the demarcation point is less obvious. With VMWare, Parallels, XenCenter, etc. the demarcation point is the kernel of the guest OS.
With JVM I guess it's the Java byte-code which talks to a Java engine so that any Java apps can run on any HW and OS that the the engine was for. The "build once" concept is great in theory but the resulting "build once, debug everywhere" reality always turned me off to liking it.
What is the actual benefit of a x86 CPU when running Android? A product needs at least one selling point. It won't be lighter, it won't be cooler, it can't be cheaper, and it definitely won't have more battery life... so, what is the point?
According to the story there's no Windows there at all. Acer is specifically avoiding it. So it would be using virtualization then? Thanks Soli. That was much easier to understand.
Something that is easy to understand doesn't imply correctness!
A Virtual Machine is a different concept than Virtualization. Marvin did a fairly good explanation above but I'm not sure I could clarify the concepts better in a post here so I will leave it alone.
As for Acer and Samsung with their i86 Androids I would want to even guess at what is native code and what is running on the Java/Dalvik Virtual Machine. Parts of Android could be improved with Native code but much of it wouldn't matter.
Not to confuse you even more but it isn't impossible to have Android, its operating system and its Virtual Machine running under virtualization on another platform.
A Virtual Machine is a different concept than Virtualization.
True, but VM has different meanings depending on the context. I'd classify it as a polyseme: same spelling, same pronunciation, but different albeit related meanings.
True, but I was trying to avoid Java 1) because I know little about it and 2) its virtualization seems be hard to grasp since the demarcation point is less obvious. With VMWare, Parallels, XenCenter, etc. the demarcation point is the kernel of the guest OS.
Yeah this can be very confusing to try to explain over the net. This is especially the case when the terms sound alike to un informed ears. You mention a couple of pieces of software that virtualize hardware above to allow running guest operating systems, this is Virtualization. Those guest operating systems could then be running a Java app which runs in a Java Virtual Machine that runs on top of that Virtualized operating system.
Without confusing people more, the Java Virtual Machine emulates and idealized processor that executes Java byte code. In other words Java programs aren't compiled (in most cases) to target an underlying hardware processor but rather they are compiled to target a virtual processor. That processor is emulated by the Java Virtual Machine. I will ignore JIT compiling as that throws a curve ball at people.
With JVM I guess it's the Java byte-code which talks to a Java engine so that any Java apps can run on any HW and OS that the the engine was for. The "build once" concept is great in theory but the resulting "build once, debug everywhere" reality always turned me off to liking it.
Yep. I never liked it either. There are some great apps out there written in Java so I'm not trying to dismiss it. Rather it just rubs name the wrong way.
There are some great apps out there written in Java so I'm not trying to dismiss it. Rather it just rubs name the wrong way.
The only app I use that I think is even Java-based is a Pearson-Vue app for practice exams. That looks alright. The UI doesn't appear to be created in Java. I wish it was as I assume that would make it easier to port to Mac OS.
I had thought that Wireshark uses Java since it's so incredibly ugly and clunky but Wikipedia says the UI is GIMP. I wish there was a native app for Mac OS X (or Windows) that can do what Wireshark can do.
True, but VM has different meanings depending on the context. I'd classify it as a polyseme: same spelling, same pronunciation, but different albeit related meanings.
Yes the usage of the terms is at times very loose. Virtualization is more specific in most usage though. It is unfortunate that the industry doesn't have a better grip on this as it can be very confusing. The usage of the phrase Java Virtual Machine (JVM) though becomes very specific.
JVM implies the emulation of an abstract machine defined buy Sun to support the Java programming language. When you see the term Virtual Machine, that is without the Java qualifier, the definition becomes much looser. A virtual machine could imply something offered up by virtualization software that allows multiple operating systems to exist on one piece of hardware or it could imply an abstract machine other than Java.
So when one sees "Java Virtual Machine" any ambiguity should be gone. It is also why the preferred abbreviation is JVM to reduce confusion.
It is unfortunate that the industry doesn't have a better grip on this as it can be very confusing.
I vote for the BASE-2 and BASE-10 for kilo, mega-, gigi-, et al. be addressed first. Using both 2^10 and 10^3 for kilo- is absurd. BASE-10 was first, and by a large margin, so I think the IEC Binary Prefixes of kebi-, mebi-, gibi-, et al. be utilized... but it might be easier to convince Americans to use the metric system for something other than 2 Liters of soda.
Comments
. . . and?
Would it then be using emulation or virtualization? I'm way over my head when it comes to technical issues like that and so would defer to you.
That still depends on what the piggybacking OS is built on. Let's say it's Windows 8 as the primary OS but you want to run Android 2.3 on it. That would be emulated if the only binary available is ARM-based. What version of Android are they running on it? If it's a newer version that runs on Intel than it would be virtualized and not only lose very little performance as opposed to be virtualized but also be much, much faster than any ARM version (assuming that they did a good job on that version of Android for x86/x86-64 and the virtualization layer is good. Considering both of these in 2013 I'd say Android on Haswell will look impressive.
So lets assume the best for Android OS. What about the apps? Can apps be compiled for both ARM and Intel as fat binaries? I ave absolutely no idea how Java works here. I'd think only the Java engine needs to be compiled for this, not the apps that run in Java, but I honestly have no idea.
"Your mama's so fat her binaries support multiple architectures."
Don't do it guys, it's a trap!
Virtual machines recompile bytecode into native machine code. Virtualization doesn't affect the application binary at all, it is used to abstract hardware to an OS in order to run native binaries. Emulation has to recreate hardware in software.
Adobe Flash is an example of a virtual machine - that's why Flash animations work on all hardware. It doesn't emulate or virtualize an OS like say VMWare. It takes Adobe's partially compiled bytecode and then recompiles it into native code.
The advantage is being able to target multiple architectures easily but there is a performance hit (I think estimates are typically around 10% hit - possibly why Android is laggy but probably not, most likely just because it's badly optimized for the hardware) and because authored software is only partially compiled, it can be reverse-engineered and stolen:
http://geeknizer.com/decompile-reverse-engineer-android-apk/
Think about that if you publish apps on Android. Someone could reverse-engineer your work, modify it and sell it as their own app. It's a wonder large publishers even publish on Android. They'd be as well making them open source:
http://insecurety.net/?p=641
Clover Trail is an interesting product, intel literal threw the book out the window and started over with the design. Clover trail is SIGNIFICANTLY different than previous ATOMs.
Now that still doesn't mean that this new chip will cut it in a tablet, only time will tell there. It just means that Clover Trail isn't a complete failure all around like previous ATOMs. Lets face it AMDs low end APUs ran circles around previous ATOMs. With Clover Trail I suspect the results will be tied to Samsung's ability to optimize for the chip. This means getting the Java rip off to work well and to get proper native development working on the chip.
In any event what this does indicate is that Apple needs to really work hard on a high performance 64 bit chip. Frankly all those AMD engineers they recently hired are likely working on a project too far out. This will be most interesting.
According to the story there's no Windows there at all. Acer is specifically avoiding it. So it would be using virtualization then? Thanks Soli. That was much easier to understand.
BTW there's mention of an x86 gaming project here, again with no mention of any OS other than Android.
http://www.zdnet.com/android-gaming-on-a-x86-powered-pc-with-iconsole-tv-7000015336/
It really isn't a big surprise, Android and Linux underneath are designed to run on a variety of hardware. I86 does give them more operating system flexibility though. As for "porting" much of Android runs on a Java virtual machine rip off.
Without knowing anything about this Asus AIO I wouldn't know. Are you saying that Android would be only OS installed on it? In that case it's running natively, assuming it's an Intel version of the Android.
Correct. Reportedly Acer has decided to avoid Microsoft altogether on this particular AIO.
Virtualization isn't exactly the same thing as running a Java Virtual Machine. I won't go into it here but rather will say research this in depth because this thread is already filled with misleading information. As to your question many things involved in the design of Android make it sluggish.
Edit: So native then. See, I told you I had no idea when it came to technical architecture questions. Thanks once again.
True, but I was trying to avoid Java 1) because I know little about it and 2) its virtualization seems be hard to grasp since the demarcation point is less obvious. With VMWare, Parallels, XenCenter, etc. the demarcation point is the kernel of the guest OS.
With JVM I guess it's the Java byte-code which talks to a Java engine so that any Java apps can run on any HW and OS that the the engine was for. The "build once" concept is great in theory but the resulting "build once, debug everywhere" reality always turned me off to liking it.
Quote:
Originally Posted by dreyfus2
What is the actual benefit of a x86 CPU when running Android? A product needs at least one selling point. It won't be lighter, it won't be cooler, it can't be cheaper, and it definitely won't have more battery life... so, what is the point?
You can put an "Intel Inside" sticker on it.
A Virtual Machine is a different concept than Virtualization. Marvin did a fairly good explanation above but I'm not sure I could clarify the concepts better in a post here so I will leave it alone.
As for Acer and Samsung with their i86 Androids I would want to even guess at what is native code and what is running on the Java/Dalvik Virtual Machine. Parts of Android could be improved with Native code but much of it wouldn't matter.
Not to confuse you even more but it isn't impossible to have Android, its operating system and its Virtual Machine running under virtualization on another platform.
Originally Posted by AppleInsider
Samsung's decision to use an Intel chip for an Android device was portrayed as a "coup" for Intel in the report.
It's a coup for Intel, yes, because they finally have a toe-hold (fingernail-hold ?) on the post-PC era.
And it's a coup for coffee and tea drinking Android device users.
They can set their coffee or tea cup on their Intel-based Samsung Galaxy Tab to keep their beverage piping hot.
True, but VM has different meanings depending on the context. I'd classify it as a polyseme: same spelling, same pronunciation, but different albeit related meanings.
Without confusing people more, the Java Virtual Machine emulates and idealized processor that executes Java byte code. In other words Java programs aren't compiled (in most cases) to target an underlying hardware processor but rather they are compiled to target a virtual processor. That processor is emulated by the Java Virtual Machine. I will ignore JIT compiling as that throws a curve ball at people.
I hope this doesn't confuse people even more.
Yep. I never liked it either. There are some great apps out there written in Java so I'm not trying to dismiss it. Rather it just rubs name the wrong way.
The only app I use that I think is even Java-based is a Pearson-Vue app for practice exams. That looks alright. The UI doesn't appear to be created in Java. I wish it was as I assume that would make it easier to port to Mac OS.
I had thought that Wireshark uses Java since it's so incredibly ugly and clunky but Wikipedia says the UI is GIMP. I wish there was a native app for Mac OS X (or Windows) that can do what Wireshark can do.
Yes the usage of the terms is at times very loose. Virtualization is more specific in most usage though. It is unfortunate that the industry doesn't have a better grip on this as it can be very confusing. The usage of the phrase Java Virtual Machine (JVM) though becomes very specific.
JVM implies the emulation of an abstract machine defined buy Sun to support the Java programming language. When you see the term Virtual Machine, that is without the Java qualifier, the definition becomes much looser. A virtual machine could imply something offered up by virtualization software that allows multiple operating systems to exist on one piece of hardware or it could imply an abstract machine other than Java.
So when one sees "Java Virtual Machine" any ambiguity should be gone. It is also why the preferred abbreviation is JVM to reduce confusion.
I vote for the BASE-2 and BASE-10 for kilo, mega-, gigi-, et al. be addressed first. Using both 2^10 and 10^3 for kilo- is absurd. BASE-10 was first, and by a large margin, so I think the IEC Binary Prefixes of kebi-, mebi-, gibi-, et al. be utilized... but it might be easier to convince Americans to use the metric system for something other than 2 Liters of soda.