ARM Readies Cores For 64-Bit Computing 222
snydeq writes "ARM Holdings will unveil new plans for processing cores that support 64-bit computing within the next few weeks, and has already shown samples at private viewings, InfoWorld reports. ARM's move to put out a 64-bit processing core will give its partners more options to design products for more markets, including servers, the source said. The next ARM Cortex processor to be unveiled will support 64-bit computing. An announcement of the processor could come as early as next week, and may provide further evidence of a collision course with Intel."
wut (Score:0, Informative)
hi
Re:What's the point? (Score:5, Informative)
Arm servers make sense in two places: the small and the giant. They fall down in the medium and large space.
In other words, my personal server currently runs a "low power" AMD Sempron. The CPU uses something like 40 Watts, and it is plenty fast enough for my needs. It makes my RAID work, and it serves stuff over NFS and Samba. There are only ever a few clients, and the CPU spends most days nearly idle. It's a small box with a small workload, and it would work just fine with an ARM CPU instead of an x86. (Assuming the hypothetical ARM system could physically connect my external RAID enclosure.) More CPU wouldn't hurt, and it would occasionally make a few things faster, but mostly putting a Xeon in this box would just make it louder.
In the realm of giant workloads, you have jobs that can't possibly be done by a single machine, no matter the budget. You are looking at needing many hundreds of even the biggest machines you can get. If you have a job that parallelizes that well, doing it with 1000 x86 boxes or 4000 ARM boxes isn't that big of a difference. If the ARM boxes are smaller, cheaper, and lower power enough that it outweighs the fact that you need more of them, then it would be crazy to go with whizzy Xeon boxes instead of Arm. Buzzword enthusiasts will throw labels like "Cloud scale computing" at this sort of thing.
Where ARM falls down on the job is anything that can be done by a 4 core Xeon, up to a handful of 32 Core Xeons. That's a big chunk of what we normally think of as the Server market. ARM doesn't compete very well in this space. When people say that ARM is a ridiculous idea for servers, this middle segment of the market is generally what they are thinking of. A cluster of a dozen little ARM boxes competes rather poorly with a single machine with four Xeon sockets in terms of management overhead, and the amount of effort required to parallelise workloads, and the amount of bandwidth between distant cores. If you have an application that has an expensive per-machine license, that speaks in favor of a single big machine, etc.
So, small office that needs a little NAS server to stash under the secretary's desk? ARM can pwn the market. Giant research institution with some parallelisable code trying to figure out how molecules do something naughty during supernovas? ARM can pwn the market. "Enterprise" level IT in a smallish, but uncrowded data center with adequate, already provisioned power and cooling... ARM may well be suitable in some cases, but it's certianly not an easy sell.
And, relatively common cell phones have 1 GB of RAM. In two years or so, a cell phone with 4 GB of RAM will seem perfectly reasonable. At that point, 64 bit ARM stops being a data center/desktop issue, and is simply required to hold onto the existing ARM core market.
Re:Slashdot's ARM wet dreams. (Score:2, Informative)
Mind you, if ARM ever gets there, there will be a Windows version almost immediately. NT is actually quite portable. Historically, it's been on MIPS, Alpha, and PPC, in addition to x86, x64, and Itanium (the currently available ports). There's no reason Microsoft couldn't port it to ARM, and if they see a reason to do so (such as a servers-running-ARM market) they will certainly do so.
Re:So where is my ARM desktop yet? (Score:4, Informative)
You can get a $50 zipit z2 and run debian arm on that. Fits in the palm of your hand and does all that.
Re:Slashdot's ARM wet dreams. (Score:3, Informative)
But by the time you get to end-user applications, all of that is long gone.
C and the C like bits of C++ are a very leaky abstraction.
Take unaligned accesses for example. Some architectures will just quietly fix them up. Some will terminate your app with a sigbus and some will return bogus results (with older arm chips arm did the last of these, with modern arm chips the kernel can trap it but iirc it doesn't by default).
And then there is the fun of va_list. on x86 it's a simple pointer, on other architectures it's a more comlex structure and this can cause problems if you try to use it in certain ways.
As someone who has watched debian rc bugs architecture specific failures are not at all unusual. Sometimes it is actual bugs in the toolchain, other times it's portablity issues in the user code.
For common FOSS these issues have already been largely fixed (at least to the extent that they broke something obvious) because of the work of projects like debian but if you have custom C or C++ code written by code monkeys then you have a problem.
And if your custom code is in java you potentially have a much bigger problem. There is an arm port of openjdk but it's rather immature at the moment. There is gcj too but don't expect good compatibility there.