Android barely qualifies as a form of "Linux." Yes, it uses a Linux kernel, but the fact is largely incidental - there's no real technical reason that Android couldn't be built on BSD or even WinCE if Google or an OEM wanted it. It isn't close to POSIX-compatible, it only runs "managed" (VM-based) apps, and it isn't even open-source as of 3.0.
Of course, this will result in a wave of posts about how Google loves open-source, about how Linux is Linux, and how Google has assured us that the 3.0 source is coming Real Soon Now...
Every time I've been to the post office, there's been 15+ people in line. I have a hard time believing the mail system is on the way out any time soon. Telegraphs didn't kill it, telephones didn't kill it, why would email kill it?
Blackberries use J2ME, which is as close to straight Java as you can get. It's true that there are custom RIM libraries available, but you can write a Blackberry app without every touching them and the resulting binary will run on any J2ME-compliant VM (even featurephones!)
A PCmark bench is cited that shows a ~15% percent increase over the X6 while adding two cores (33%.) That implies BD has either a lower clock speed or lower instructions-per-cycle.
I fully acknowledge that this is largely rooted in speculation at this point, but what's come out so far isn't encouraging - the openbenchmarking results based on an engineering sample, for instance, showed performance that was not substantially improved from the Magny-Cours processor.
Bulldozer is looking increasingly underpowered compared to Sandy Bridge, with some benchmarks indicating potentially worse performance per cycle than the existing K10.5 core.
This thread has some interesting information on possible BD performance.
Oh, please. For consumer parts, the best price/performance by far is offered by Intel, specifically the i5-2500K. Intel doesn't price-gouge on consumer chips.
Oracle Enterprise is actually $47,500 per core base rate. Where it gets interesting is the fact that different processors are given different "core factors" based on their performance and/or Oracle's business interests that you multiply by the base price; so, for instance, Power7 and Itanium 9300 both have a core factor of 1.0 (full price) whereas various SPARC chips have 0.5 or 0.25.
I'm kind of surprised that large-hardware support is that low. There are plenty of large RISC or mainframe commercial systems with more than 64 cores and 512GB.
Floating point is not good on SPARC at this point. The T2 processors have a best-case floating-point performance of between ten and fifteen gigaflops, if I recall, and that's only if you can keep it saturated from all 64 threads. Figure that the T3 doubles that to 20-30, but again, only if you can continuously issue floating-point instructions from all 128 threads. The SPARC64 VII, the "high-performance" chips, have a theoretical performance of around 10GFLOPS per core (40GFLOPS per processor) but rarely (if I recall) achieve it.
By comparison, Power7 is capable of 256GFLOPS per processor and 32 per core; Nehalem can do four FLOPS per cycle per core, which puts the high-end Nehalem parts around 75GFLOPS.
A T2/T3 would not be on par with x86 for normal uses due to the annoying fact that a single thread runs at approximately 200MHz on them.
You don't want a SPARC T2, T3, or any other recent SPARC design in your desktop or laptop. Performance of a T3 is, accoridng to SPEC, very similar to a hugely cheaper and less power-hungry AMD Magny-Cours for massive-threaded applications... and much, much worse for few-thread apps. The "high-end" Fujitsu SPARC64 VII+ is also pretty damn slow.
It won't be that simple. Microsoft is probably going to be targeting a specific hardware reference design with specific firmware. "ARM" is not a standardized computing platform like PC or CHRP or various others.
A 1.6GHz Atom is probably a fair bit faster than the "Broadway" G3 derivative. It has a faster clock speed, a much wider set of vector instructions, and (presumably) substantially fewer cycles of latency for cache and memory access. I'll go out on a limb a little and estimate a 60% performance increase going from Broadway to Atom, and I wouldn't be surprised if it were more.
IBM doesn't sell the Power7 processor, except in a limited form to Hitachi and Bull, who sell rebranded Power machines. This is why I said "embedded" in my post.
Slashdot Mirror
Whether or not the Apache license requires source code release, Android 3 is not under the Apache license. It isn't open-source, period.
Android 3 has been released in multiple commercial tablets, including the Motorola Xoom. Binaries have been released, source has not.
Bull GCOS 7 would never have these kinds of vulnerabilities.
It could potentially be done very, very slowly, with nuclear reactors and ion engines.
I agree, though, that it is not particularly likely any time within the next hundred years.
In Android, the VM normally manages NDK classes just like Java classes, so that it can do things like GC'ing them to kill up resources.
I know how the NDK works. It's still managed by the VM, just like Managed C++ on .NET.
Whether or not that's the reason, a product without released source code just isn't open-source, and no amount of rationalizing it will change that.
Android barely qualifies as a form of "Linux." Yes, it uses a Linux kernel, but the fact is largely incidental - there's no real technical reason that Android couldn't be built on BSD or even WinCE if Google or an OEM wanted it. It isn't close to POSIX-compatible, it only runs "managed" (VM-based) apps, and it isn't even open-source as of 3.0.
Of course, this will result in a wave of posts about how Google loves open-source, about how Linux is Linux, and how Google has assured us that the 3.0 source is coming Real Soon Now...
Every time I've been to the post office, there's been 15+ people in line. I have a hard time believing the mail system is on the way out any time soon. Telegraphs didn't kill it, telephones didn't kill it, why would email kill it?
Plenty of the Oracle customers on HP-UX and VMS are not particularly happy with them right now...
Blackberries use J2ME, which is as close to straight Java as you can get. It's true that there are custom RIM libraries available, but you can write a Blackberry app without every touching them and the resulting binary will run on any J2ME-compliant VM (even featurephones!)
A PCmark bench is cited that shows a ~15% percent increase over the X6 while adding two cores (33%.) That implies BD has either a lower clock speed or lower instructions-per-cycle.
I fully acknowledge that this is largely rooted in speculation at this point, but what's come out so far isn't encouraging - the openbenchmarking results based on an engineering sample, for instance, showed performance that was not substantially improved from the Magny-Cours processor.
Bulldozer is looking increasingly underpowered compared to Sandy Bridge, with some benchmarks indicating potentially worse performance per cycle than the existing K10.5 core.
This thread has some interesting information on possible BD performance.
Oh, please. For consumer parts, the best price/performance by far is offered by Intel, specifically the i5-2500K. Intel doesn't price-gouge on consumer chips.
Oracle Enterprise is actually $47,500 per core base rate. Where it gets interesting is the fact that different processors are given different "core factors" based on their performance and/or Oracle's business interests that you multiply by the base price; so, for instance, Power7 and Itanium 9300 both have a core factor of 1.0 (full price) whereas various SPARC chips have 0.5 or 0.25.
The "power" of Android? What is that, the power to run a locked-down J2ME on steroids with a shitty UI?
NetFlix's streaming selection is awful, and for what they have, the quality isn't great. I can't speak for iTunes.
I'm kind of surprised that large-hardware support is that low. There are plenty of large RISC or mainframe commercial systems with more than 64 cores and 512GB.
Floating point is not good on SPARC at this point. The T2 processors have a best-case floating-point performance of between ten and fifteen gigaflops, if I recall, and that's only if you can keep it saturated from all 64 threads. Figure that the T3 doubles that to 20-30, but again, only if you can continuously issue floating-point instructions from all 128 threads. The SPARC64 VII, the "high-performance" chips, have a theoretical performance of around 10GFLOPS per core (40GFLOPS per processor) but rarely (if I recall) achieve it.
By comparison, Power7 is capable of 256GFLOPS per processor and 32 per core; Nehalem can do four FLOPS per cycle per core, which puts the high-end Nehalem parts around 75GFLOPS.
A T2/T3 would not be on par with x86 for normal uses due to the annoying fact that a single thread runs at approximately 200MHz on them.
So how do the open-source drivers do at 3D, exactly? Last time I looked, Nouveau was highly unstable and 15-20x slower than the official driver...
You don't want a SPARC T2, T3, or any other recent SPARC design in your desktop or laptop. Performance of a T3 is, accoridng to SPEC, very similar to a hugely cheaper and less power-hungry AMD Magny-Cours for massive-threaded applications... and much, much worse for few-thread apps. The "high-end" Fujitsu SPARC64 VII+ is also pretty damn slow.
It won't be that simple. Microsoft is probably going to be targeting a specific hardware reference design with specific firmware. "ARM" is not a standardized computing platform like PC or CHRP or various others.
A 1.6GHz Atom is probably a fair bit faster than the "Broadway" G3 derivative. It has a faster clock speed, a much wider set of vector instructions, and (presumably) substantially fewer cycles of latency for cache and memory access. I'll go out on a limb a little and estimate a 60% performance increase going from Broadway to Atom, and I wouldn't be surprised if it were more.
The Cell is a PPC 970 core with some vector units bolted on.
IBM doesn't sell the Power7 processor, except in a limited form to Hitachi and Bull, who sell rebranded Power machines. This is why I said "embedded" in my post.