Am 09.12.2012 04:51, schrieb Michael Mol: > On Sat, Dec 8, 2012 at 10:25 PM, Grant <emailgr...@gmail.com> wrote: >> It seems like ARM processors will destroy x86 before too long. Does anyone >> think this won't happen? > > It's looking promising. Not that I have a horse in the race, but I > very much like ARM's low power consumption. The way I see it, they're > only a short list of features away from obliterating x86: > > * I'd like to see fast division. > I keep hearing about how this or that is slow because of ARM's lack of > strong division. > > * I'd like to see a modern baseline of strong instructions. > x86 kept continually improving in a very fragmented way, but there > were, from time to time, baseline collections of feature sets you > could expect all processors to have. i386 represented one. i686 > represented one. Currently, it's x86_64, which implies not only a > 64-bit flattened address space and a departure from real mode, but > also a collection of SIMD instruction sets and other features > developed between the release of the Pentium Pro and AMD's Hammer > architecture. > > ARM just feels...fragmented. And I don't have the impression I could > write my code assuming the availability of SIMD (presuming I use > things like OpenMP to expand my code to leverage it, rather than > writing processor-specific code. Though OpenCL could very well > alleviate that issue.) >
+1 with regard to fragmentation. What I especially despise is the lack of a common boot infrastructure. If I'm not mistaken, it is still impossible to make a kernel that boots on all (or at least a large subset of all) ARM platforms [1]. And then, there is the simple fact that current ARMs lack the raw power of an x86 and I guess if you scale them up to the point where they can compete with x86s with regard to computing power per core, there is no point in switching to ARM to begin with. Sure, you can parallelize and make a large array of "wimpy" nodes, but you cannot fool Amdahl's law. And even where you can parallelize nearly 100%, you risk high latency [2, 3]. [1] https://lwn.net/Articles/496400/ [2] http://pages.cs.wisc.edu/~jignesh/publ/nonwimpy.pdf [3] http://research.google.com/pubs/archive/36448.pdf Regards, Florian Philipp
signature.asc
Description: OpenPGP digital signature
