ARM Readies Cores For 64-Bit Computing

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."

Comments

wut

[Anonymous Coward]

hi

Slashdot's ARM wet dreams.

[Anonymous Coward]

True Windows does not run in ARM. More ARM means more linux. Orgasmic.

Re:Slashdot's ARM wet dreams.

[bradgoodman]

MOD UP!

Re:Slashdot's ARM wet dreams.

[hairyfeet]

Can you please explain the advantage of ARM over X86 in the server room because this one has me scratching my head. While I'm all for different arches (I have a PPC G3 Mac just so I could play with non x86) I thought the whole point of ARM was it was super low power for mobile devices? while I'm sure cutting down power usage in the server room would not be a BAD thing, considering how much software, both for Windows AND Linux, that isn't for ARM based CPUs I just don't get what the advantage of this would be over say a Bobcat, Nano, or Atom based solution.

Now in mobile I get it, as you can make a cheap iPad knockoff that can get 8+ hours of battery life, but in servers? Maybe there is a use case I don't know of, but when I was setting up servers while power was a consideration it certainly wasn't looked at as a priority over the performance in server roles. How well does ARM handle large amounts of users? How well does it scale with increased demands? While I wish them all the best I just haven't seen a screaming need for these, not when you already have Atom and Nano and are about to have Bobcat and Bulldozer (which from the looks of it will be nice as it has a well built GPU in the Bobcat and Bulldozer so AMD stream coding could be used) all in that same market. What am I missing here?

Re:Slashdot's ARM wet dreams.

[del_diablo]

It should in theory scale better than x86-64 anyhow, and the performance per watt is quite superior, so yes, it has a major place in the server room.

Re:Slashdot's ARM wet dreams.

[cbhacking]

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:Slashdot's ARM wet dreams.

[del_diablo]

Sure, but they will lose markedshare on the initial wave when the markeds starts appearing. When it finally comes to "5% of desktop(desktop+laptop,+etc) sales and rising?!", then Windows will pull out a version.
Before that, Linux will gain markedshare, most likely, unless they mess up attempts at markeding again.

Re:Slashdot's ARM wet dreams.

[Anonymous Coward]

Did he mention servers? Oh well then.
I laughed.

Re:Slashdot's ARM wet dreams.

[Anonymous Coward]

Sure, but they will lose markedshare on the initial wave when the markeds starts appearing. When it finally comes to "5% of desktop(desktop+laptop,+etc) sales and rising?!", then Windows will pull out a version.
Before that, Linux will gain markedshare, most likely, unless they mess up attempts at markeding again.

Are you redarded?

Re:Slashdot's ARM wet dreams.

[LWATCDR]

Funny but in 1990 I bet the said the same thing about Intel.
In any office of say 50 or so people a 64 bit ARM would probably do just fine. NAS and SANs in bigger installations would probably also run very well on a 64 bit ARM. And then one has to wonder just how many ARM cores might fit on a die?
ARM is a much more modern ISA than X86 so it will be interesting to see just where it goes. Trust me if you had told anyone in 1982 that someday there would be an X86 that was faster per clock cycle than a Cray1, ran with a multi ghz clock, and had a 64 bit address space they would have locked you in a rubber room.

Re:Slashdot's ARM wet dreams.

[Pentium100]

Current Windows software won't run on ARM. Maybe that's not a big concern for Linux, since most of the Linux software is open source and can be compiled on whatever platform you want, but I don't see companies buying ARM computers instead of x86 ones (you know, the ones that still use IE6 because some business app requires it, going to ARM will be even worse, since all their current apps won't work, not just the badly written ones).

Re:Slashdot's ARM wet dreams.

[h4rr4r]

For windows maybe, but what popular software for linux is tied to x86?

I have run lots of stuff on Debian arm.

Re:Slashdot's ARM wet dreams.

[Caerdwyn]

He's a marked mad.

Re:Slashdot's ARM wet dreams.

[ensignyu]

Microsoft could write an emulation layer to run x86 code on ARM. Apple created a 68000 emulator when they transitioned from 68k to PowerPC, and then a PowerPC emulator (Rosetta) when they switched to Intel x86 processors.

x86 isn't as easy to emulate, and the performance would probably be terrible, so it's not too likely. But it's an option if some future architecture beats the pants off x86 enough to make emulating x86 for legacy apps run at a reasonable speed.

Re:Slashdot's ARM wet dreams.

[Pentium100]

Yes, emulation is an option, but I don't think that ARM running x86 emulation layer will be competitive with native x86 CPUs. Didn't this happen to Itanium? Slow x86 performance and AMD's x86-64 resulted in virtually zero market for Itanium.

Re:Slashdot's ARM wet dreams.

[imroy]

...considering how much software, both for Windows AND Linux, that isn't for ARM based CPUs...

CPU architecture doesn't really matter with FOSS - once you have a working compiler, you just compile everything from source. Alright, you need some arch-specific work in the kernel and a few other places too. But by the time you get to end-user applications, all of that is long gone. So I would reply with "almost all Linux software already is for ARM-based CPUs". Or MIPS. Or POWER/PowerPC. Or whatever architecture you want.

And one advantage that ARM's low power/heat could bring is high density. Take a look at the Gumstix boards. Now imagine a "blade server" board with 16 or more processors crammed onto one board. You could easily get at least a few hundred CPU's in a 19 inch rack, with each CPU draining less than a watt of power. Now I'm not really sure what could be done with such a system - either do everything over the network (NFS or ATAoE), or equip each CPU with a good lump of flash storage for data and programs. But it would draw very little power and is something to think about.

Re:Slashdot's ARM wet dreams.

[Confusador]

There are a lot of boxes out there doing nothing but serving files and printers, if ARM did start to be popular you can be sure that MS would be sure not to lose that business. And then, once you have the things installed, it suddenly makes sense to write some of your new programs to run on them...

Re:Slashdot's ARM wet dreams.

[keith_nt4]

What you should be asking "how many VMs will it run?". That's where servers are now really. If it has some similar VM CPU extension like the current intel/AMDs do and it gets superior performance-per-watt there could be a big argument for using ARM in the server room...

Re:Slashdot's ARM wet dreams.

[hairyfeet]

That reminds me of something else I don't get: why didn't they just drop a single X86 CPU into Itanium for running needed x86 code? in the old days we often had several different chips working together, ala the Amiga. Now it is all or nothing, and that makes NO sense to me! We should be able to just drop in a PPC, or ARM, or hell even custom ASICs, and be able to get the best of ALL platforms, just as we are able to get vector processing now with Stream and CUDA thanks to GPUs.

I just don't get why we don't go back to that, especially since we have high speed interconnects like HT on AMD. So why are we all or nothing now? Wouldn't it make more sense to have highly specialized chips in the server for specific needs than trying to force X86 to do it all?

Re:Slashdot's ARM wet dreams.

[Pentium100]

I think I saw a coprocessor that worked with AMD's HT and plugged in place of another CPU (on a motherboard with multiple sockets).

Itanium+x86 CPU would be expensive and still slow, I mean if all your current programs are x86 (because Itanium was a new CPU, it did not have any software written for it at first) it does not make much sense to buy a CPU that is slow on x86 but would be faster if you rewrote or recompiled your software (in case of locally written apps) or bugged the developer to do it (in case of licensed apps). Also, IIRC, Intel was trying to get away from x86.

It probably is also much more expensive to get the specialized chips and write software specifically for them instead of just buying a faster general purpose CPU. CUDA and similar are useful in only a minor subset of jobs (ones that can be split to a huge number of cores, do not need a lot of memory and do not need to access it often).

Re:Slashdot's ARM wet dreams.

[froggymana]

What you should be asking "how many VMs will it run?". That's where servers are now really. If it has some similar VM CPU extension like the current intel/AMDs do and it gets superior performance-per-watt there could be a big argument for using ARM in the server room...

But would you really need to even have any VMs if you can 10-20x as many servers in the same amount of space? Instead of running server on a VM you could just dedicate it to its own ARM computer.

Re:Slashdot's ARM wet dreams.

[dbIII]

Can you please explain the advantage of ARM over X86 in the server room

Some stuff just needs to get to a lot of disks and does not need much in the way of CPU power, such as the 500MHz Sun stuff I already have in my server room to run tape drives, or a webserver with some simple static pages that gets about 3 hits a day etc. Other functions such as local DNS, ntp, dhcp and a pile of others really don't need much grunt and are sometimes handy to have on a bit of hardware that isn't doing anything else that is taxing. Then there's the file server/NAS situation where so long as the CPU can feed what comes off the disk controller card to all the NFS and SMB connections then it's fast enough. All niches, but one or two niche devices in every server room adds up to a lot. The 64 bit nature is just icing on the cake for future compatability while the real driving force is less watts and space to get tasks done. WE don't need it much while there is Atom and others, but ARM might need it to continue as a platform despite the obvious killer apps in mobile/embedded devices.

Re:Slashdot's ARM wet dreams.

[petermgreen]

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.

Re:Slashdot's ARM wet dreams.

[pantherace]

They basically did add an x86 to Itanium. I think the Itanium 2 had an updated Pentium core on it, to improve the emulation speed. Frankly, though that took up a lot of die room, and was very slow.

Comparatively, I've seen x86 emulation be faster in many cases than native x86. Granted, this was with Alphas and fx!32, where the chip simply was faster. Trying that with a slower chip, much as Transmeta tried, didn't work so well. One of the problems with just using HT on AMD, is that there wasn't really a standard interface, and let's face it FPGAs are rare. FPGAs also require a design to run.

The thing that most people don't get is this: compilers are not magic. Special hardware almost always require special code. Code is relatively expensive/time-consuming to create. With compilers being unable to automagically generate great code (on of the major reasons for Itanium failing-Intel bet compilers would be a lot better than they were, or currently are) for even a VLIW as the IA-64 is, it basically killed any performance of Itanium. (Nevermind a lot of (at least from the outside) stupid design decisions, that got reversed when Intel brought in the HP engineers from PA-RISC & what remained of the Alpha engineers from DEC via Compaq, and produced the relatively much better Itanium 2.)

Now, as to why not differing architectures, it's hard. The hardware has to support it well, which can be done somewhat, the OS has to support it. Right now, there isn't a mainstream OS which is well setup to handle non-SMP multiprocessor. Usually if it does, that's only clockspeed differences, and maybe slightly different chips of the same architecture. (It was somewhat common on older SGI and Sun MP boxes.) Granted, Linux can be worked into doing cross-architecture MP (such as with IBM's RoadRunner), but it's not common and needs a lot of tweaking. You will note that there is only one RoadRunner system. Some of the Crays (also Linux) are that way as well. However, those are top10 level supercomputers, with a dedicated and usually very highly competent & trained staff. They would likely be useless without that staff. The only reason things like CUDA or OpenCL are useful is they are well defined interfaces, with a lot of hardware, and it doesn't really need to alter the Operating System.

For a custom piece of hardware, if it's deployed widely enough, it might be useful, see for example cell on the PS3, where you have a slightly different kind of semi-MP setup. Mostly older machines are coming to mind here for examples, some of them successful (PS2 emulation of PS1 via a chip which was usually used for sound) and the Nintendo DS, but most others have failed. Again, code is time-consuming, and unless you either have a very large base (DS/PS2) or a very specific reason(Supercomputers), you don't really want to deal with anything excessively complicated.

Re:Slashdot's ARM wet dreams.

[dutchwhizzman]

It's a large and accepted platform. We don't want to be stuck with x86 forever just because there is no valid alternative and no innovation because it's dominating the market.

The other main reason is that power actually is very important in the data center. Everything you power, you have to cool. All large server room users, the cloud providers and firms that need their own centers because they have a whopping amount of servers for their use, are looking at moving to colder climates, using natural resources to get a more friendly power bill and carbon footprint and all. Sun is playing the power consumption card with their latest SPARC generation and it seems to be very beneficial for certain usages.

Re:Slashdot's ARM wet dreams.

[Anonymous Coward]

ARM is a much more modern ISA than X86.

Yes - there are about 5 years difference between them.

You might not fully appreciate it - but ARM is 27 years old by now. I wonder what percentage of slashdot readers wasn't born when the first ARM driven machine (Acorn's Archimedes) was introduced.

(I do take your point of it being more modern - but please also place it into perspective - it's not the latest/greatest thing that hasn't had time to prove itself in the market - it's been around for a large part of my lifetime...)

Re:Slashdot's ARM wet dreams.

[Phoghat]

When I was a youngster like you, we had 200Mhz, single core ARM processors and we liked it! Get off my lawn!

Re:Slashdot's ARM wet dreams.

[hairyfeet]

I get what you're saying but I don't think I explained myself well. what I was talking about was like this: Think of distributed computing...in a box. Instead of send a job to another machine, you would send it to another part of the box itself. With things like virtualization and hypervisors this should be possible. And I'm not talking about having a dozen different CPUs running full bore 24/7, what I was thinking of was more like what we have with CUDA, where specialized jobs that can be done much better by CPU B will be sent to CPU B instead of trying to power through it with CPU A.

Let me give an example: Say you have a server and part of its job is encryption. Let us say that PPC does encryption 1000% faster than X86, then my question would be "Why can't we using hypervisors allow chips for certain tasks while having the "main CPU" for others?". I mean we already have such a thing in mobile with Broadcom and specialized chips that let Atom CPUs decode BD content they would never otherwise be able to process, why can't we do the same in the server?

Now I'll admit I'm not a coder and I'm sure as you pointed out there would be some pretty big hurdles to overcome, but considering how much money there is in datacenters anything that made these machines even 30% more efficient energy and processor wise would save billions and be worth the effort. And it isn't like there aren't plenty of jobs that could probably be done better by a custom ASIC or separate arch with the main CPU conducting, like encryption, Java and Silverlight VMs, certain math like they use in HPCs which IIRC Itanium excelled at, etc. I remember when HT first came out there was all this talk of plugging different chips into the socket to allow the Opterons to have a fast link to communicate, but then the multicore war heated up and the idea seemed to be forgotten. I simply think it is an idea worth revisiting is all.

Re:Slashdot's ARM wet dreams.

[TheRaven64]

Current Windows software won't run on ARM.

We're talking server software so...

All of those Java web apps will work. All of those ASP / ASP.NET web apps will work. All of those PHP web apps will work...

Re:Slashdot's ARM wet dreams.

[TheRaven64]

Actually, Apple did not create Rosetta. They licensed it from a spin-out from Manchester University, called Transitive. The same company also sells x86 to MIPS translators and has demo'd SPARC to PowerPC and vice versa emulation. I don't know if they make x86 on ARM emulators, but I'd be surprised if they didn't.

The neat thing about the Transitive stuff is that it makes it very easy to call native libraries from emulated code. This is really useful when you have a binary-only app that uses a lot of shared libraries. If you ran on Windows/ARM, any x86 code would call native code for any of the Windows system DLLs, which accounts for quite a large proportion of their CPU time.

Re:Slashdot's ARM wet dreams.

[TeknoHog]

There are a lot of boxes out there doing nothing but serving files and printers,

running on ARM for a couple of years already. It's funny how many comments are talking about hypothetical situations, while home servers like Buffalo Linkstations have been available for years. You can install a proper distro (at least Debian or Gentoo) on one and see for yourself, then imagine what they could do with more CPU power and RAM.

Re:Slashdot's ARM wet dreams.

[Dogers]

But that's where virtualisation comes into play on x86. Run lots of little machines on one bigger one..

Re:Slashdot's ARM wet dreams.

[dbIII]

It's sometimes handy to have an extra bit of hardware (eg. the example above where you need a machine to physically connect to the tape drives). For the sort of tasks I was talking about (DNS, DHCP, low end httpd etc) you don't need the overhead of virtualisation to run a lot of them on the same host with any sort of modern operating system - one very low end machine can run a lot of things.
I'll bet virtualisation has inspired a lot of people to do really stupid stuff like run a MS Windows PDC and BDC on the same bit of hardware or outside the MS Windows world multiple DNS servers in the same box.

Re:Slashdot's ARM wet dreams.

[itsdapead]

I thought the whole point of ARM was it was super low power for mobile devices?

The ARM didn't start off that way: the first ARM chips (back when the "A" stood for "Acorn" not "Advanced") were designed as tasty desktop/workstation processors for systems like this which could seriously put the wind up the x86s (for x in 2,3,4) of the day. There was even an add-on "accelerator" card for PCs (PDF file). The shift of emphasis to embedded/mobile processors was because Wintel had the desktop market sewn up.

while I'm sure cutting down power usage in the server room would not be a BAD thing,

For anybody with a significant sized server farm, power consumption is a very BIG thing - first you have to pay for all that energy, then you have to pay again for all the air conditioning to get rid of the resulting heat. Also, less heat means you can pack more processors into a smaller space.

considering how much software, both for Windows AND Linux, that isn't for ARM based CPUs

Possibly true for Windows, but no so much for Linux, where most software is distributed as source and there's a long tradition of supporting multiple processor architecture. Debian supports ARM, for example. Heck, how many ARM-based NAS boxes are already out there running Samba and LAMP stacks? If you have Samba, Apache, PHP/Perl/Python and MySQL or PostgreSQL then that's already a pretty big range of server apps.

Re:Slashdot's ARM wet dreams.

[amorsen]

They did effectively drop a single x86 CPU into one of the Itanium chips. However, since the (Windows) customers wanted to use x86 programs almost exclusively, they weren't so impressed with their new Itaniums performing like 400MHz Celerons.

There is practically no reason to prefer a specific instruction set for specific tasks. POWER isn't incredibly fast because it uses the POWER instruction set; you could use the exact same design techniques to make an incredibly fast ARM (or even x86, with a little more trickery). Good luck with selling a $20k ARM or x86 though.

Re:Slashdot's ARM wet dreams.

[TheRaven64]

What you say is true in general, but x86 and ARM provide almost identical C-level abstractions. Both are little-endian. Both are 32-bit. Both support unaligned access, but it's very slow[1]. Both support the same set of GCC intrinsics for atomic operations. I don't recall how va_list is implemented on ARM, but I've never seen any code that does anything with this other than use the standard macros, which are portable.

[1] Not true for all ARM chips, but the ones that we're talking about all trap to the OS for unaligned loads and stores. This is very slow, but it's pretty slow on x86 if it spans a cache line too.

Re:Slashdot's ARM wet dreams.

[amorsen]

You can gain 30% CPU efficiency just by picking the L series Xeons. Or delaying your purchase by a year. Chip architectures are only orders-of-magnitude faster than other architectures at specific jobs in the small window until the other CPU designers catch up. Notice SSE vs. Altivec, or the various dedicated crypto/hash instructions.

The only place where it makes sense to have different architectures for different jobs is in GPU's, and you can already mix-and-match those to your heart's content.

Re:Slashdot's ARM wet dreams.

[TheRaven64]

The buzzword that ARM server vendors are spouting is physicalisation. The idea is that you get something with an ARM core or four (with integrated network controller), a blob of RAM and a blob of flash all stacked onto the same package. You put these densely on a board, probably an 8x8 arrangement, giving 64 discrete computers, connected to a SAN for anything that doesn't fit on the flash (probably 1-2GB in a single chip for the OS). Each one consumes 1-2W and can be powered down when not in use. If you want a new server, you flash a new chip with your boot image and power it up.

That said, the Cortex A15 does support virtualisation, up to four cores per die, and a 40-bit physical address space.

Re:Slashdot's ARM wet dreams.

[Anonymous Coward]

Isn't the main problem with IA64 is that it's slow executing its own code, possibly due to quality of compilers, let alone emulating that of another chip?

Re:Slashdot's ARM wet dreams.

[petermgreen]

the ones that we're talking about all trap to the OS for unaligned loads and stores.
While modern arms can trap to the OS and the OS can fix them up that isn't the default behaviour.

http://lecs.cs.ucla.edu/wiki/index.php/XScale_alignment#Have_the_kernel_find_the_problem_for_you

This is very slow, but it's pretty slow on x86 if it spans a cache line too.
IIRC kernel traps are extremely slow (for example reports i've seen say that kernel floating point emulation is 10 times slower than pure software floating point) which may be why this was never turned on by default. Is unaligned access on x86 really THAT slow?!

Re:Slashdot's ARM wet dreams.

[TheRaven64]

It's not as slow on x86, but it's sufficiently slow that you want to avoid it. Basically, no one is the kind of horrible pointer casting that generates this kind of access on x86 in anything performance critical.

It's also worth noting that compilers will never generate unaligned loads if they can avoid it. If the compiler can tell that the load might be unaligned, it will generate a pair of load-mask-shift sequences and xor the results together (the shift is free on ARM, so this is not as expensive as it could be). It's only if you do some evil pointer arithmetic and casting that makes the compiler think it's got an aligned pointer when it actually has an unaligned one that you get problems.

Re:Slashdot's ARM wet dreams.

[marcosdumay]

Just imagine some 32 or so ARM cores in a chip. With x86, that thing would probably melt, but ARM power requirements are way lower.

Re:Slashdot's ARM wet dreams.

[drsmithy]

But would you really need to even have any VMs if you can 10-20x as many servers in the same amount of space? Instead of running server on a VM you could just dedicate it to its own ARM computer.

Yes. VMs are massively easier to manage than physical machines.

Re:Slashdot's ARM wet dreams.

[Rockoon]

The main problem isnt so much that compilers werent good enough.. the main problem was the expectation that compilers *could* be good enough.

Intel's asymmetric execution unit philosophy only goes so far.. sure, you can get an extra amount of performance from the same number of transistors, but only for problems for which that asymmetry doesnt become a barrier.

The proper way to design asymmetric execution units is to sample lots of existing code and then produce an optimal set for that sample set.

This is how Intels x86/x64 line of CPU's has been optimized and it works. The Itanium on the other hand was done backwards. They designed the asymmetric units first and then expected compilers to eventually produce code which leverages the asymmetry well..

AMD has always been more symmetric in its design. Each ALU can handle of all the same operations, and so forth.

Re:Slashdot's ARM wet dreams.

[Anonymous Coward]

You also have to remember that many large 'web-properties' (top websites) all run on Linux or BSD. And that for example Google is supposedly the largest designer of motherboards only behind HP and Dell.

Only a quarter of the websites run on Windows, so that is still a lot of servers that could be replaced over the years with more efficient processors.

Re:Slashdot's ARM wet dreams.

[hairyfeet]

That isn't necessarily true. For an example look up the Via Nano design and check it out. They have placed a good chunk of silicon specially designed for crypto and RNG, with higher AES and Blowfish going through that chip like crap through a goose. Now I can't picture Intel and AMD suddenly deciding to just add a big chunk of silicon for a specific job like that which would only help in certain roles. But in a server I can definitely see how having that chip cranking the crypto while a nice Opteron or Xeon does the heavy lifting would be good.

The whole "we'll make it bigger LOL!" is how we ended up in the MHz wars in the first place. There is a GOOD REASON why ARM is having more and more things like BD encoding done off chip, it is because often a specialized chip can do it MUCH better than a general CPU. That is why you don't see Xeons in TV sets, and why Intel is making an in order CPU that is like a cranked up P1. I simply think it is an avenue worth exploring and that someone with a "new way" that came up with a drop in design could make serious $$$$$. Just look at those shops that have turned Atom into a blade server chip. By splitting the work to hundreds of smaller chips you end up with pretty significant power savings and that turns into damned good profits for the company that thought it up.

If ARM tries to put everything on chip they will end up just as power hungry as any Intel chip so it is pretty obvious they will probably go multi-chip, so maybe that route is worth exploring? Breakthroughs often come down to "hey why don't we try" in the tech field, and I still say this is a good niche which could make some good money. Imagine being able to boost performance and add server roles by simply dropping in an HT chip or even a PCIe board with the RAM and CPU onboard?

Re:Slashdot's ARM wet dreams.

[amorsen]

That isn't necessarily true. For an example look up the Via Nano design and check it out. They have placed a good chunk of silicon specially designed for crypto and RNG, with higher AES and Blowfish going through that chip like crap through a goose. Now I can't picture Intel and AMD suddenly deciding to just add a big chunk of silicon for a specific job like that which would only help in certain roles.

It's a shame you can't picture it, because at least Intel has already implemented AES acceleration. I haven't followed AMD closely, but I doubt they'll let themselves fall behind for long.

Re:Slashdot's ARM wet dreams.

[Lennie]

I could be wrong, but having an ARM-based system with Linux/btrfs as iSCSI SAN target doesn't sound to bad either.

Re:Slashdot's ARM wet dreams.

[Dogtanian]

Can you please explain the advantage of ARM over X86 in the server room because this one has me scratching my head.

Perhaps the type of "servers" they had in mind were more akin to the SheevaPlug.

Re:Slashdot's ARM wet dreams.

[Lennie]

Let me rephrase that, if the hosts using it are Linux-based, why not use Ceph instead of iSCSI ?

Re:Slashdot's ARM wet dreams.

[Tuoqui]

Advantage of ARM over X86 is lower power consumption. They are prsumably at a point where they can replace an X86 with an ARM processor and both will be able to do the job. It's just keeping an ARM one on 24/7/365 is cheaper on the electric bill than a X86... At least that is how I understand it.

Re:Slashdot's ARM wet dreams.

[LWATCDR]

i would put it 9 years since it was an evolution of the 8080 and 8085. Even when new it was considered primitive and limited. The 386 and 64bit version have helped a lot but ARM has also evolved a lot more then
But the ARM has had the advantage of a much more advanced starting point the X86 did.
This arm has proven it's self in the market. That is just it as the x86 has creeped up so has the ARM and soon just like as the X86 has grown from the bottom up so has the ARM.

Re:Slashdot's ARM wet dreams.

[cbhacking]

That's why I said servers, specifically. If MS produces an ARM port of NT, they'll port over IIS, Active Directory, Exchange, SQL Server, Sharepoint, and all the rest - everything that they need to tell people "you can run our software on your servers, no matter the architecture!" Third-party proprietary software will be slower, of course, but open-source stuff should also be ported quickly. In the end, the ecosystem for server software is actually a lot more architecture-flexible anyhow.

The thought of an ARM server hosting IE6-only ActiveX controls in x86 binary makes me several kinds of sad, but there's no reason it couldn't happen. IIS doesn't care what instruction set the bits it serves are intended for.

Re:Slashdot's ARM wet dreams.

[Muad'Dave]

Are you redarded?

No, he just has a head cold.

Re:Slashdot's ARM wet dreams.

[Dogers]

True enough, for the physical connection stuff, but for pretty much everything else (bar the really (cpu|memory) intensive servers) can be virtualised :)

Running things on the same box is a problem if you don't have something like vSphere or Citrix XenServer, with their live migration abilities.

What's the point?

[pablodiazgutierrez]

ARM has to walk the power way up. I don't see how 64 bit computing would let them snatch server oriented clients. Similarly, I doubt Intel would be wise to deliver chips for the wristwatch market without first having something more compelling for the smartphone.

Re:What's the point?

[MarcQuadra]

You don't see the use?

low-latency bare-metal fileservers that consume only a few watts, but can natively handle huge filesystems and live encryption? It's a lot easier to handle a multi-TB storage array when you're 64-bit native, same for encryption. Look at Linux benchmarks for 32 vs 64-bit filesystem and OpenSSH performance.

Do you have any idea how many $4,000 Intel Xeon boxes basically sit and do nothing all day at the average enterprise? If you can put Linux on these beasties, you could have a cheap and inexpensive place for projects to start, if load ever kills the 2GHz ARM blade, you can migrate the app over to an Intel VM or bare metal. I'll bet 80% of projects never leave the ARM boxes, though.

My whole department (currently seven bare-metal Intel servers and five VMs) could run entirely off of a few ARM boxes running Linux. It would probably save an employees'-worth of power, cooling, upkeep, and upgrade costs every year.

Re:What's the point?

[PCM2]

I'm seeing 64-bit ARM powered NAS boxes, too, dontchathink?

Re:What's the point?

[vadim_t]

Cell phones with ARM CPUs and 512MB RAM already exist. That's a pretty big chunk of the 32 bit address space, so it seems to make a lot of sense to be ready for when it's exhausted.

Re:What's the point?

[TheRaven64]

Look at Linux benchmarks for 32 vs 64-bit filesystem and OpenSSH performance

What benchmarks are you looking at? If you're comparing x86 to x86-64, then you are going to get some very misleading numbers. In addition to the increased address space, x86-64 gives:

• A lot more registers (if you're doing 64-bit operations, x86-32 only has two usable registers, meaning a load and a store practically every other instruction).
• The guarantee of SSE, meaning you don't need to use (slow) x87 instructions for floating point.
• Addressing modes that make position-independent code (i.e. anything in a .so under Linux) much faster.
• Shorter instruction sequences for some common instructions, replacing some short-but-rarely-used sequences.

Offsetting this is the fact that all pointers are now twice as big, which means that you use more instruction cache. On a more sane architecture, such as SPARC, PowerPC, or MIPS, you get none of these advantages (or, rather, removal of disadvantages), so 64-bit code generally runs slightly slower. The only reason to compile in 64-bit mode on these architectures is if you want more than 4GB of virtual address space in a process.

The ARM Cortex A15 supports 40-bit physical addresses, allowing up to 1TB of physical memory to be addressed. Probably not going to be enough for everyone forever, but definitely a lot more than you'll find in a typical server for the next couple of years. It only supports 32-bit virtual addresses, so you are limited to 4GB per process, but that's not a serious limitation for most people.

ARM already has 16 GPRs, so you can use them in pairs and have 8 registers for 64-bit operations. Not quite as many as x86-64, but four times as many as x86, so even that isn't much of an advantage. All of the other advantages that x86-64 has over x86, ARM has already.

Re:What's the point?

[forkazoo]

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:What's the point?

[rsborg]

Arm servers make sense in two places: the small and the giant. They fall down in the medium and large space.

That is only because of the WinTel duopoly of the past decade and a half. Given a decent enough operating system (ChromeOS, OSX-iOS hybrid, Ubuntu Unity) and either a standards based information access model (html/http) or native app-stores, the requirement for x86(-64) disappears and we can liberate ourselves from the Intel processor hegemony... and the world will be a better place for it. (note: Intel isn't going away anytime soon, and neither is Windows... but they won't exist as we have known them for the past decade)

Re:What's the point?

[Anonymous Coward]

Cell phones with ARM CPUs and 512MB RAM already exist. That's a pretty big chunk of the 32 bit address space, so it seems to make a lot of sense to be ready for when it's exhausted.

What does 32 vs 64 bit cpu's have to do with ipv4 (32 bit) vs ipv6 (128 bit, not 64) address space? The whole IP scheme has nothing to do past the NIC. Even if your talking about storing IP's in memory or whatnot, it's just XXXX bit variable.

Re:What's the point?

[gotpaint32]

Makes sense but most enterprises are moving towards high density virtualization. This seems to be going the other direction towards specialized appliances rather than.general purpose computing. I could see workstations/terminals going the arm route as well as highly customized and code optimized app servers. But I don't think you'll see many enterprises switching over just yet.

Re:What's the point?

[sa666_666]

What are you talking about? Is this a joke that I'm missing?? The GP is talking about 512MB being a fair size chunk out of the possible address space of 4GB (ie, 32-bit address space). It has nothing to do with networking.

Re:What's the point?

[Anonymous Coward]

40-bit physical addresses sir... not 32-bit thats a Tb not 4Gb

Yes a program can only access memory within its 32bit address space but you can run many programs with a much larger address space. Which means you could have 4 VMs on a 32bit arm using 8Gb each for a total of 32Gb... or something like that.

Re:What's the point?

[KonoWatakushi]

ARM already has 16 GPRs, so you can use them in pairs and have 8 registers for 64-bit operations. Not quite as many as x86-64, but four times as many as x86, so even that isn't much of an advantage. All of the other advantages that x86-64 has over x86, ARM has already.

The amd64 architecture gets away with so few registers only because it can operate on memory directly. With a load-store architecture, eight registers would be extremely constraining. If anything, ARM should expand the register set for 64-bit mode.

Re:What's the point?

[Anonymous Coward]

>Giant research institution with some parallelisable code trying to figure out how molecules do something naughty during supernovas?

ARM is competitive with x86 in terms of FLOPS per anything? I don't think so, Tim.

That leaves only the ultra low end for ARM.

Re:What's the point?

[oiron]

Memory address space, not IP, you dolt!

Re:What's the point?

[laffer1]

I see a huge difference in 4000 arm vs 1000 x86.. someone has to manage 4 times the machines! System administrators cost money too.

ARM chips make sense for home servers or small business devices in some cases. Maybe something rather custom with many cores could work for higher end products. I guess I'm skeptical after I watched x86 take over the server space. x86 always seems to win. This time Intel and AMD want to keep it that way.

Re:What's the point?

[Anonymous Coward]

There's no way they can compete in scientific computing, but sufficiently power-efficient ARM servers might have a chance at large-scale business processing, databases and web servers and that kind of thing.

Re:What's the point?

[petermgreen]

I see a huge difference in 4000 arm vs 1000 x86.. someone has to manage 4 times the machines! System administrators cost money too.
They do but once you've got that many machines working on the same problem you are likely to put in place a management system that allows you to manage the machines without working on each one individually.

Re:What's the point?

[yupa]

But 64 bits is really interesting for the kernel. With Linux you can only map 1G of map without using segmentation (highmem).

Using 64 bits kernel with 32 bit programs solve the issue. And that's what is done on sparc, ppc, mips...

Also some algorithm really need 64 bits arithmetic to be faster.

Re:What's the point?

[forkazoo]

>Giant research institution with some parallelisable code trying to figure out how molecules do something naughty during supernovas?

ARM is competitive with x86 in terms of FLOPS per anything? I don't think so, Tim.

That leaves only the ultra low end for ARM.

Yeah, ARM does well per Watt and per square meter.

Re:What's the point?

[TheRaven64]

The Cortex A15 uses 40-bit physical addressing, so the kernel can have its own 4GB of private real memory, while each app has its own 4GB. The kernel can also bypass the MMU and use the 40-bit (1TB) address space directly.

Re:What's the point?

[TheRaven64]

Kind of. Compilers try very hard to avoid using the memory-register instructions, because their performance is hard to predict. If you're in the top couple of stack slots, the address will be aliased with a register, so you will get the same performance as the register-register version. If it is not, then you will have to fetch the value from the cache, which can cause a brief stall in the pipeline (if it's some random heap address, it will cause a much longer stall if it's not in the cache, but the top few stack frames are pretty much always there).

The only time that the register-memory instructions are usually generated is when you have a load then operate sequence where you never access the original value again. In this case using the register-memory version has the same performance but uses fewer instructions, so improves icache usage. In all other cases they'll be avoided. This means that a compiler will try to use the same number of registers on both x86-64 and ARM.

The biggest problem for ARM is on stupid ABIs (*cough* Debian *cough*) where floating point values are passed in integer registers (to support FPU-less variants), which causes an FPU pipeline flush before and after every function call that takes a floating point argument.

Re:What's the point?

[TheRaven64]

FLOPS matter for HPC, not so much for server workloads. Server tasks are typically limited by integer ops or by I/O. Relatively poor FPU performance is irrelevant there.

Re:What's the point?

[yupa]

Yes but linux kernel need a direct ram mapping. And kernel mapping is 1G.
That's why highmem exist http://linux-mm.org/HighMemory .

However, many people insist on using more than 1GB of physical memory on such a 32 bit system. This makes it necessary for the Linux kernel to jump through some interesting hoops... Basically the system uses the following tactics: * Memory above the physical address of 896MB are temporarily mapped into kernel virtual memory whenever the kernel needs to access that memory. * Data which the kernel frequently needs to access is allocated in the lower 896MB of memory (ZONE_NORMAL) and can be immediately accessed by the kernel (see Temporary mapping). * Data which the kernel only needs to access occasionally, including page cache, process memory and page tables, are preferentially allocated from ZONE_HIGHMEM. * The system can have additional physical memory zones to deal with devices that can only perform DMA to a limited amount of physical memory, ZONE_DMA and ZONE_DMA32. * Allocations and pageout pressure on the various memory zones need to be balanced (see Memory Balancing).

Cortex A15 uses 40-bit physical addressing is really useless : it is x86 PAE

Re:What's the point?

[TheRaven64]

Please stop thinking x86 limitations are intrinsic to all 32-bit platforms.

On x86, the MMU is very badly designed. This means that the kernel must have its own address space mapped into every userspace process's address space with no permissions granted to ring 3 code. If you use the RHEL kernel, you have the option to disable this (the 4GB-4GB memory split), which gives the kernel its own 4GB address space. The problem with this is that you then need to flush the TLB at the start and end of every system call, which is not good for performance. Neither is the fact that, to copy data to and from the userspace process's address space the kernel needs to walk the page tables itself and load the data using instructions that bypass the MMU.

ARM, in contrast, has a tagged TLB in recent implementations. This means that the kernel can have its own 4GB address space and the process can have its own one. The kernel can access its address space by writing one value to the process ID register and access another active process's address space by writing a different value to this register.

Unlike x86, there is no overhead from having completely distinct address spaces for kernel and userspace apps.

Re:What's the point?

[Bengie]

the enterprise is moving into a virtual environment where you can live migrate images off of idle machines and consolidate them to reduce power. If the current server is getting too loaded, just migrate from that machine to another will less load.

You can already do this with current software, give it 5-10 years and this will be standard.

I mostly see a low power ARM being good for dedicated SAN/NAS/Firewall. Most other SQL/Web stuff will be on VMs where you can dynamically add/remove Memory/CPUs and migrate between physical machines without the user noticing.

Re:What's the point?

[Rockoon]

AMD64 does not have "so few registers"

Not including RSP and RIP, there is RAX, RBX, RCX, RDX, RBP, RSI, RDI, R8, R9, R10, R11, R12, R13, R14, R15, MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, XMM8, XMM9, XMM10, XMM11, XMM12, XMM13, XMM14, and XMM15

Each of them is at least 64 bits in size and can perform 64-bit integer operations. Limitations include that only the first 7 are available as pointers, the MMn registers cant be mixed with non-MMn registers in a single operation, and ditto for the XMMn registers.

Thats not "so few" is it? Thats 39 registers that can perform 64-bit integer work...

Re:What's the point?

[KonoWatakushi]

If you are going to throw in the vector registers, why not the FP stack; that can be used to do "integer operations" as well if you are careful. However, neither provide the same "integer operations" as the GPRs. Whether you spill to other registers, or memory, it is still an ugly mess.

There are still only 16 GPRs, and then the compiler resorts to memory operands. Maybe some masochistic programmer could cobble together some assembly that made use of the assortment of heterogeneous hardware available, but claiming that amd64 has more than 16 registers is disingenuous.

Re:What's the point?

[runningduck]

FLOPS per dollar is the only measure that matters. With ARM's low cost, low footprint and low power consumption you would be surprised at the potential disruptive ability of ARM in the data center.

Re:What's the point?

[KonoWatakushi]

No matter how hard the compilers try, if the problem doesn't fit in register, it will spill. Sixteen registers is not exactly abundant, so this is not at all uncommon. One does need to account for the extra latency in the using memory operands, but this can often be done. (Though it is obnoxious when one has to do it by hand.)

It is also obnoxious that certain operations need to be done in certain registers, yet further increasing the amount of registers which must be shuffled around. (As if it weren't bad enough dealing with this and register spillage, the two-operand instructions also add to the problem.) I have to wonder just how much of the width of a modern x86 processor is wasted shuffling data around.

All modern (performant) RISC architectures have 32/32 gp/fp registers. (Alpha, PowerPC, SPARC, MIPS, ...) If ARM wants to compete in this space, that is what they should do. Where 64-bit code isn't necessary, there is no loss in continuing to run 32-bit. (Unlike the backwards x86 architecture, where amd64 brings many other crucial advancements.)

Re:What's the point?

[Rockoon]

If you are going to throw in the vector registers, why not the FP stack; that can be used to do "integer operations" as well if you are careful.

(1) Because they are both vector and simple registers, depending on the instructions used.

(2) The x87 is either in MMX mode (the mm# registers) or FPU mode (the st# registers) .. mode switches trash the registers.

Re:What's the point?

[KonoWatakushi]

You are missing the point. No matter what convoluted reasoning you use, you can't just add together GPR + vector and say that amd64 has 39 registers. It doesn't matter if the registers exist if they can't be used together.

Re:What's the point?

[Rockoon]

You are missing the point. No matter what convoluted reasoning you use, you can't just add together GPR + vector and say that amd64 has 39 registers. It doesn't matter if the registers exist if they can't be used together.

You keep saying they are vector registers while ignoring the fact that the low 16/32/64 bits of each are special cases.

You were wrong when you stated that AMD64 has few registers. Its OK to have been wrong.. going on and on in an effort to semantically make yourself right after being caught talking out your ass.. well.. thats not OK. Its just pathetic.

64-bit embedded possibilities...

[MarcQuadra]

I know folks think it's 'overkill' to have 64-bit CPUs in portable devices, but consider that the -entirety- of storage and RAM can be mmapped in the 64-bit address space... That opens up a lot of options for stuff like putting entire applications to sleep and instantly getting them back, distributing one-time-use applications that are already running, sharing a running app with another person and syncing the whole instance (not just a data file) over the Internet, and other cool futuristic stuff.

I'm wondering when the first server/desktop OS is going to come out that realizes this and starts to merge the 'RAM' and 'Storage' into one 64-bit long field of 'fast' and 'slow' storage. Say goodbye to Swap, and antiquated concepts like 'booting up' and 'partitions'.

Re:64-bit embedded possibilities...

[Monkeedude1212]

I know folks think it's 'overkill' to have 64-bit CPUs in portable devices

I don't think of it that way - I think of it as laying foundations for the future. I would much rather be prepared for when 64bit CPUs in mobile devices is a necessity instead of trying to play catchup when it does. We have the technology, so why not? Like the whole limitted IPv4 Address Space - wouldn't it have been sweet if we switched to IPv6 BEFORE it became an issue?

Re:64-bit embedded possibilities...

[noidentity]

You can do all this with a 32-bit address space as well. The only thing that must be swapped is the data. All the code can have its own addresses, unless you plan on having more than 4GB of application code on your mobile device. 4GB should be enough for anybody...

Re:64-bit embedded possibilities...

[newcastlejon]

Don't you count laptops as portable? I realise that you were talking about smartphones but I'm skeptical that having wider use of 64-bit processors will bring about all the cool future stuff you name.

Having decayed into a near-layman when it comes to CS I'm also curious as to why we need those extra bits for said stuff in the first place. It seems that there ought to be a reason why fast and slow storage is separated logically, and I would also say that - on first glance - there's no reason why needing to boot and have FS partitions has anything to do with having a 32/64-bit CPU.

Do please enlighten me, and if you'd be so kind to do it without just listing vague but cool-sounding concepts I'd be ever so grateful.

Re:64-bit embedded possibilities...

[0123456]

Having decayed into a near-layman when it comes to CS I'm also curious as to why we need those extra bits for said stuff in the first place.

You can't map a complete 2TB disk into a 32-bit address space.

However, I think the idea is kind of bogus, because you don't want every application having access to all blocks on the disk, you don't want every application having to deal with filesystem layout (you can't just write to byte 42 on the disk without ensuring no-one else is going to) and you do want to keep applications' memory separate. And at some point you have to reboot even if just because you upgraded your OS kernel.

Re:64-bit embedded possibilities...

[KiloByte]

n900 may be a nice device otherwise but only 256MB is totally crippling. Most recent smartphones come with 512MB these days. So even for just RAM, having merely "plans" about migrating to 64 bit today is not overkill, it's long overdue.

About your idea of just mmapping everything: the speed difference between memory and disk/flash is so big that the current split is pretty vital to a non-toy OS. I'd limit mmap to specific tasks, for which it is indeed underused.

Re:64-bit embedded possibilities...

[newcastlejon]

You can't map a complete 2TB disk into a 32-bit address space.

That I can understand.

...putting entire applications to sleep and instantly getting them back, distributing one-time-use applications that are already running, sharing a running app with another person and syncing the whole instance (not just a data file) over the Internet...

This stuff, however, defies comprehension.

Re:64-bit embedded possibilities...

[MarcQuadra]

Just because the distinction between RAM and disk would go away doesn't mean that all access-control goes with it, I don't see how that's implied. An application would just be running in a sandbox that's really just a 'file' sitting in the portion of the address space that's hosted by RAM. If the app doesn't get used, or the kernel needs to 'swap' it to free up resources closer to the 'hot' side of the stack, or gets put to sleep for any other reason, it migrates out of RAM and back to disk.

Same with user sessions... Imagine that you log in and your session was actually brought back for you. Not the way Gnome/KDE does it now by opening apps with the same name, I'm talking about -actually getting your session back-. When you log out, all memory that's owned by you (all apps and data you have open) gets compressed and moved to disk until you return.

Re:64-bit embedded possibilities...

[0123456]

An application would just be running in a sandbox that's really just a 'file' sitting in the portion of the address space that's hosted by RAM. If the app doesn't get used, or the kernel needs to 'swap' it to free up resources closer to the 'hot' side of the stack, or gets put to sleep for any other reason, it migrates out of RAM and back to disk.

And you don't need a 64-bit address space to do that, if it was really important we could have done it long ago.

Re:64-bit embedded possibilities...

[KiloByte]

Also, the idea of persistent programs has been thought before. Heck, I once came up with it myself when I was studying (>12 years ago), and talked about it with a professor (Janina Mincer). She immediately pointed a number of flaws:
* you'll lose all your data the moment your program crashes. Trying to continue from a badly inconsistent state just ensures further corruption. COWing it from a snapshot is not a solution since you don't know if the original snapshot didn't already have some hidden corruption.
* there is no way to make an upgrade -- even for a trivial bugfix
* config files are human-editable in sane systems for a reason, having the setup only in internal variables would destroy that

Re:64-bit embedded possibilities...

[Jah-Wren Ryel]

That's called checkpoint/restart and it's been around on 32-bit machines for decades. Its not commonly used, maybe internet ubiquity might change that, but 64-bitness isn't even close to necessary.

Re:64-bit embedded possibilities...

[DragonWriter]

However, I think the idea is kind of bogus, because you don't want every application having access to all blocks on the disk

Just because you have hardware that allows for something to be done doesn't mean that the OS has to allow "every application" to make full unsupervised use of that capability.

OTOH, if the hardware doesn't support it well, then no application -- and no part of the operating system -- can effectively leverage the capacity.

And at some point you have to reboot even if just because you upgraded your OS kernel.

There is no reason that needs to be the case. Even though most operating systems are currently not designed to avoid that need, there is at least one combination of software and service for Linux (Ksplice) which obviates the need for that for Linux kernel updates, and there is no reason that an OS couldn't be maintained in such a way that that was the norm for updates in the form usually distributed rather than something done by a combination of third-party software (automatically handling most of the work) and aftermarket programming effort (adding code to handle the minority of changes that the automated software can't handle.)

Re:64-bit embedded possibilities...

[DragonWriter]

Also, the idea of persistent programs has been thought before. Heck, I once came up with it myself when I was studying (>12 years ago), and talked about it with a professor (Janina Mincer). She immediately pointed a number of flaws:
* you'll lose all your data the moment your program crashes. Trying to continue from a badly inconsistent state just ensures further corruption. COWing it from a snapshot is not a solution since you don't know if the original snapshot didn't already have some hidden corruption.

This isn't any different from traditional saved data separate from the program, really.

* there is no way to make an upgrade -- even for a trivial bugfix

Hot upgrades to running code are very common in certain environments. They certainly are not impossible.

* config files are human-editable in sane systems for a reason, having the setup only in internal variables would destroy that

Having the setup live in internal variables doesn't prevent either having the program itself having a user-friendly method of accessing the configuration data, or having a mechanism where it can receive such updates from the outside.

Re:64-bit embedded possibilities...

[MarcQuadra]

That's because your professor is locked-in to the model we've been using, one that evolved when resources were scarce. That's no longer the case.

-Losing data: Obviously, we're not talking about getting rid of files, just pre-packaging apps in a running state between sessions. Your word processor is going to save the data to a 'file' that by requirement, must live on 'cold' storage (disk-backed or network) or in the cloud. The session of the app would have a little check when it is restored to verify if the file has changed since the app was last awake, and if so, ask you if you want to reload it.

-Upgrades/Patches: If there's a need for one, it is applied to the 'root files' (that are backed on disk) that spawn the app sessions and the app sessions are marked 'dirty' so they can't restore, they must be restarted. There would have to be a system in the hypervisor to track dependencies and mark things as 'dirty' as their dependencies were patched.

-Config files: Would remain the same... See my reference to 'root files' previously. Most software would still be 'files on the disk', but their running state would be saved. In the case of a config change that required the app to be restarted, the app would obviously be able to mark itself 'dirty' and reload the next time you tried to restore it. Software that isn't 'yours', like Google Apps, or game demos, or restricted freeware, or University-owned expensive software, would be distributed over the network in time or session-limited 'stored sessions'.

Re:64-bit embedded possibilities...

[MarcQuadra]

"there ought to be a reason why fast and slow storage is separated logically"

The entire computing paradigm that we're familiar with is based on the idea that address space is very limited, RAM is expensive, and disk is cheap. That's not true anymore; with 64-bits of address space, you could have access to a 'field' of over 2000 petabytes. That's more than the entire storage available at the research university I work at. You could literally have common address pointers and direct, unbrokered access to vast amounts of data, migrate running apps and sessions between machines, and break free from the limits we have built computer science around.

Re:64-bit embedded possibilities...

[MarcQuadra]

The limits were always right around the corner with 8-to-32 bit computing. Everyone knew that 4GB hard drives were coming when the 386 came out. With 64 bits of address space, there's 2048 petabytes to play with. That's not coming to a PC or a business near you anytime soon.

Re:64-bit embedded possibilities...

[CODiNE]

Rumor is that's what Apple is working towards with Lion and iOS API's being added to the Desktop OS.

With built in suspend and resume on all apps it becomes trivial to move a running process over to another device. I suppose they'll sell it to end-users as a desktop in a cloud, probably a Me.com service of some kind.

Re:64-bit embedded possibilities...

[noidentity]

I'm still not imagining how this helps. OK, so you've got let's say 64 GB of Flash memory, and say 1 GB of RAM. You don't want to just map all this into each user process, especially not writable, otherwise you'll have corruption. So you only map things in when the process opens the file, where you give it a pointer that it is mmap()'d to. And you can do this with a 32-bit address space as well, as long as the process doesn't open more than a couple of GB of memory-mapped files at once. That doesn't seem like a notable limitation; if it's a media file, it's going to be using normal I/O calls for streaming, not reading it all from memory. Maybe I'm missing something here, but it seems a 32-bit CPU with some kind of memory controller could map files just as well.

Re:64-bit embedded possibilities...

[VortexCortex]

...That opens up a lot of options for stuff like putting entire applications to sleep and instantly getting them back, distributing one-time-use applications that are already running, sharing a running app with another person and syncing the whole instance (not just a data file) over the Internet, and other cool futuristic stuff.

You can do this "futuristic stuff" on both 32 bit and 64 bit platforms. I had to write my own C++ memory manager to make it easy to store & restore application state.

To do real-time syncing applications (esp. games) over the Internet I implemented another layer to provide support for mutual exclusion, client/server privileges, variables with value prediction and smoothing -- which I needed anyhow for my Multi-Threaded JavaScript-like scripting language (Screw coding for each core separately, I wanted a smarter language).

I've also achieved distributing "applications that are already running", (I hear smalltalk has this feature as well as other languages that support VM Images).

It would be nice if these features were supported by the OS, but I'm not waiting around for something I can do right now.

Also: I'm not sure I want all of these features built in to the OS (complexity = potential security holes), esp. when I can achieve them via cross platform libraries and/or an even higher level programming language on our current OSes & hardware.

Re:64-bit embedded possibilities...

[newcastlejon]

RAM is still expensive, and storage is still cheap. The number of addresses you can, well, address is irrelevant to the problems of making RAM cheaper or storage faster.

You say that you can address a gajillion bytes with a 64-bit CPU. So what? That won't make the spindles spin any faster, or multiply the RAM cells you have and magically do away with NUMA.

Correct me if I'm wrong, but a narrow address bus isn't the reason memory and storage are separate. Even if they are, what's so special about moving from 32 to 64 bits (which we've already done in servers, desktops and portables alike) that makes it a more game-changing improvement than the move from 16 to 32?

Re:64-bit embedded possibilities...

[jcr]

You should look up Shapiro's work on EROS, and read up on its predecessor, KeyKOS. The problems you list above have been solved, decades ago.

-jcr

Re:64-bit embedded possibilities...

[newcastlejon]

Again, the ability to access more than x bytes of storage isn't the issue. What I asked - and what you've yet to answer - is how the more widespread adoption of 64-bit processors is going to mean we can do the "cool" stuff you mention*

*I should point out that you still haven't defined what, for example, a one-time-use application is supposed to be, because frankly it sounds like just another meaningless marketing term. After that perhaps you might explain why it needs 64-bits' worth of address space to pull off?

Re:64-bit embedded possibilities...

[h4rr4r]

RAM is cheap as hell. $50 will get you as much ram as 32bits can address. So for $100 you are talking twice as much as it could address. Kids these days.

Re:64-bit embedded possibilities...

[dreamchaser]

Also, the idea of persistent programs has been thought before. Heck, I once came up with it myself when I was studying (>12 years ago), and talked about it with a professor (Janina Mincer). She immediately pointed a number of flaws:
* you'll lose all your data the moment your program crashes. Trying to continue from a badly inconsistent state just ensures further corruption. COWing it from a snapshot is not a solution since you don't know if the original snapshot didn't already have some hidden corruption.
* there is no way to make an upgrade -- even for a trivial bugfix
* config files are human-editable in sane systems for a reason, having the setup only in internal variables would destroy that

Your professor wasn't very smart then. All of those problems are easily addressed, as other posters have pointed out.

You know what they say. Those who can do, do. Those who can't, teach.

Re:64-bit embedded possibilities...

[oji-sama]

I'm pretty sure you don't need 64 bits to get above 512MB. Once we're having phones with 2GB we're on our way to problems.

Then again, I agree that a bit more memory would be nice for heavy(ish) web-use. (Tried to check from Apple's tech specs the amount of memory in iPad for comparison, but curiously this detail is omitted. Found that there's the same 256MB from Wikipedia)

Re:64-bit embedded possibilities...

[Anonymous Coward]

Fear the Libertarians! If they get their way, the corporations will have nothing stopping them from completing the transition to oligarchy and will fuck over anything or anyone that stands between them and profit and have even less stopping them from doing so than they do now.

Re:64-bit embedded possibilities...

[dbIII]

n900 may be a nice device otherwise but only 256MB is totally crippling

Which applications running out of memory have crippled yours?
Did it really happen?
You are just making an ungrounded assumption here aren't you?
It's not as if the things are used for complex photo editing of multiple images at once.

Re:64-bit embedded possibilities...

[willy_me]

You know what they say. Those who can do, do. Those who can't, teach.

Ha!! My father, who works in education, always told me this one; "Teaching is what you do if you can't get a real job." Guess the phrase was popular back in the 60s.

But the point should be that the real world and the theoretical are not always the same. I took an electronics program at BCIT (British Columbia Institute of Technology) and they made a point of hiring professors from industry. So when you were taught about generating power from hydroelectric dams, it was from people who designed / built such dams... I later attended university - the experience was quite different.

Re:64-bit embedded possibilities...

[tangent3]

64 bit CPUs are godsend for chess, checkers and reversi programs making use of 64-bit bitboards.

Re:64-bit embedded possibilities...

[dwater]

> n900 may be a nice device otherwise but only 256MB is totally crippling

Well, it *is* quite old now...but I do wonder why you think that. I can't say I've had any problem with its supposed lack of memory. No, the most serious problem with the n900, in my opinion, is the battery life, and that certainly is a problem with all smart phones these days, to a varying degree. I "manage" by carrying several batteries "just in case" and a smaller charger...and plugging it in is pretty much the first thing I do where ever I go. If I know I'm going to be away from power for extended periods, I start turning apps off.

Yes, I am one of those users who are always online on pretty much all networks, and have GPS on and 'internet connection' set to automatic too. IMO, this is the way such phones are supposed to be used, and I prefer suffering the poor battery life than compromising the way I use it. It's a choice though and, like I say, in some situations I will choose to be offline 'by default' (like international travel or long walks, for example) so that the battery lasts long enough to cover the situations where I will want to use it.

Most people complain about the resistive touch screen, but I mostly prefer it to capacitative ones. I'd prefer the improved scratch resistance of capacitative's typically harder surface , but that's about the only thing I prefer....everything else is better for resistive (at least on the n900's).

Re:64-bit embedded possibilities...

[KiloByte]

Uhm... are you really doing nothing more than running "apps"? If so, you could as well buy a dumbed down toy like iPhone.

Unlike a phone with a few fart "apps", n900 can run any Linux program you want. It is a full-blown portable computer. Too bad, there's little you can do with only 60MB left after Nokia's crap without a massive swappeathon.

Re:64-bit embedded possibilities...

[jcr]

If you believe that governments protect you from corporations, you're out of your mind.

-jcr

Re:64-bit embedded possibilities...

[chthon]

Yeah, well, IBM already does this since about the end of the '70s, I think, with their line of minicomputers (currently called i Series I think), mapping indeed everything into a 128-bit address space.

Re:64-bit embedded possibilities...

[dbIII]

So what did you run that ran out of memory?
OK nothing, so what did somebody you heard of run that ran out of memory?
Still nothing, so what were you thinking of running that probably would run out of memory if you did it and why would you want to run it on your phone with awkward input and a small display compared to a PC?
You have nothing!

Your turn, tell me the above is wrong and tell me why with an example instead of mindless handwaving.
IMHO the inputs and outputs dictated by the form factor limit it more than the memory. It's hard to use it like a desktop computer so people don't run video editing applications or CAD programs on the thing.

Re:64-bit embedded possibilities...

[TheRaven64]

We did do it a long time ago. Read up on a little project called MULTICS, which worked in exactly this way.

Re:64-bit embedded possibilities...

[TheRaven64]

iOS doesn't have built-in app suspend, it has sudden termination, which is also in OS X 10.6. The program advertises that it has no unsaved data, and the OS is free to kill -9 it at will. When it is restarted, it is expected to restore itself in the same state, but it's not automatic.

Re:64-bit embedded possibilities...

[Anonymous Coward]

I'm wondering when the first server/desktop OS is going to come out that realizes this and starts to merge the 'RAM' and 'Storage' into one 64-bit long field of 'fast' and 'slow' storage. Say goodbye to Swap, and antiquated concepts like 'booting up' and 'partitions'.

You can stop wondering. What you're describing is a combination of single-level store (http://en.wikipedia.org/wiki/Single-level_store). It was proposed in the early 60s and there are commercial products (http://en.wikipedia.org/wiki/System_i)

Re:64-bit embedded possibilities...

[Bengie]

I remember my dad paying $800 for 16MB of edo-dram

Re:64-bit embedded possibilities...

[Bengie]

ummm.. what?

Transistor counts double every 18 months, how long until 4GB smart phones? 5 years?

With Linux taking over these parts of the market, how long until someone finds a good use to run MySQL on a smart phone? Web server? I'm sure IPv6 coupled with high bandwidth of future nation wide WiMAX/etc, we will want to connect our phones and vew data.

How long until some major breakthrough will make SSDs crazy small and we have smartphones with 2TB of storage and we bring them to our friends and want to file share?

Add a lightpeak connection, plug your phone into a 19" monitor, hook up a mouse and keyboard and play games. It won't be long.

Re:64-bit embedded possibilities...

[KiloByte]

Have you fucking read my reply? No you just repeat inane statements, shouting around. And insult people.

Just think: what do you use your computer for? Not fart "apps" and stuff like "torchlight" which sets the display to all-white.

Even the basics like a WWW browser or an usable e-mail program don't really fit in the 60MB left. Nokia's microb is a bad joke -- unusably slow, no tabbed browsing, controls that make you weep. Their e-mail client, "modest", can't even do SSL (wtf?) and has no working IMAP support.

You can install Firefox which, especially with Fennec 4, is pretty good and fast, but will often swap even if you don't have anything else running.

And running only one program at once -- is that a freaking iPhone? The last single-tasking system I used was MS-DOS and I don't want to go there ever again.

Maemo isn't a really sane system, so for anything more complex you need to install Debian, at least in a chroot. And this means there are two sets of all libraries and basics like bash in memory -- which leads to swapping right at the start. Now what about decompressing something? A modern compressor like xz takes ~90MB to unpack things -- and note that even before the second set of libraries we had 60MB.

The keyboard is not that hot but it's only a bit worse than laptops -- and look at how many people use laptops exclusively. Have you ever been away from home and had to quickly fix some bug? Around here, pings over the air start at 400-600ms, making interactive ssh a bad joke. I compiled and tested stuff right on the phone on a couple occasions, quite comfortably except for the massive swappeathon during link -- c++ code takes gobs of memory then. A bit more memory would make that fine.

Not everyone is a developer, but more common tasks are hurt as well -- like, the very video editing you mentioned. A device with _two_ video cameras naturally can be expected to be able to edit the output, what's wrong with that? And, haven't you read /. articles about face recognition projects using n900 as the platform -- since it has decent video input, a good CPU, 32GB disk and doesn't go out of its way to prevent people from running custom code. And for face recognition you obviously need some memory.

Re:64-bit embedded possibilities...

[oji-sama]

Their e-mail client, "modest", can't even do SSL (wtf?) and has no working IMAP support.

Umm. Are you really talking about N900 or just trolling? N900 has SSL support. There's SSL support in the old N810 also... And both have working IMAP. [*]

And running only one program at once -- is that a freaking iPhone? The last single-tasking system I used was MS-DOS and I don't want to go there ever again.

You aren't talking about N900, are you? I mean, all the programs are indeed running and you can switch between them.

Maemo isn't a really sane system, so for anything more complex you need to install Debian, at least in a chroot.

Are you sure a small laptop wouldn't be better for your requirements? I do agree that a bit more memory wouldn't hurt. Then again, the current amount is probably enough for almost all users...

Just asked a coworker about how much memory he has free on his N900. He had 80MB free. I pointed him to your message and he said that he ran out of hands while facepalming. He thinks that you might be a troll, and considering how many things I know to be incorrect here based on using N810 and testing N900 I may have to agree. Thank you for your time.

[* Perhaps you have issues with certificates?]

Re:64-bit embedded possibilities...

[oji-sama]

ummm.. what?

Transistor counts double every 18 months, how long until 4GB smart phones? 5 years?

I consider 5 years rather long time when talking about electronics.

How long until some major breakthrough will make SSDs crazy small and we have smartphones with 2TB of storage and we bring them to our friends and want to file share?

64 bits is (necessarily) required for this?

Add a lightpeak connection, plug your phone into a 19" monitor, hook up a mouse and keyboard and play games. It won't be long.

Basically you can already do that on N900. Not just very heavy ones. No idea if the same is possible on N8, but it has HDMI output and you can connect bluetooth devices. So probably yes.

Re:64-bit embedded possibilities...

[KiloByte]

Their "IMAP support" means logging on into the server once in 15 minutes to check mail. And even that is buggy. Sorry, but IMAP without IDLE is about as useless as a server with greylisting. And to even connect I have to stunnel it through, as I'm not suicidal enough to send everything in plain text.

About SSL: it's not a certificate issue, as the server logs don't even show a connection attempt.

Multitasking: of course n900 does it, duh. The GP said that it's "impossible to run out of memory", my response was about a single program routinely running into swap, and running multiple ones making things even worse.

Are you sure a small laptop wouldn't be better for your requirements?

You can't put a laptop into a pocket, and unless it's a little dingy netbook even a bag would have little space left. N900 fits into a pocket.

I do agree that a bit more memory wouldn't hurt. Then again, the current amount is probably enough for almost all users...

I'd say that if every single newer smartphone has 512MB or more (Milestone 2, Nokia N9, iPhone 4), this suggests at least all producers say it's not enough.

Just asked a coworker about how much memory he has free on his N900. He had 80MB free.

Uhm, freshly rebooted, PR1.3, a few daemons disabled but not browserd (yet), the only extra daemon is batterygraph, titan's kernel -- 54MB free. Of course, it goes up and down as things get swapped away, but sadly, there's a daemon that ensures all of preloaded stuff stays in memory rather than swap -- they will get briefly swapped out then quickly loaded again.

Re:64-bit embedded possibilities...

[h4rr4r]

I remember paying more than $100/MB once upon a time.

Re:64-bit embedded possibilities...

[Lennie]

Depends how you look at it, $100 also gives you 2TB of western digital HDD storage. So I guess that is cheaper then. :-)

Re:64-bit embedded possibilities...

[Anonymous Coward]

Said the guy who designed IPv4.

Re:64-bit embedded possibilities...

[dbIII]

So that completely "cripples" it does it?
To add some perspective I don't consider my router crippled because it would take forever to compile code for it and that it's better to cross compile on something else.
What is your real agenda here?

Re:64-bit embedded possibilities...

[dbIII]

The GP said that it's "impossible to run out of memory"

What an incredibly blatant and stupid lie that can easily be disproved by looking at the above post. It is a disgusting tactic to misquote someone to try to make yourself look better. We've gone away from any sort of technical discussion as to why you think the platform is "crippled" to a childish game.

Re:64-bit embedded possibilities...

[MarcQuadra]

OK here's an example... A professor opens up MATLAB and loads in all the stuff he wants to show the class, he gets the whole simulation ready to run, then 'sleeps' it. Then he changes the app image to 'template' mode and gets its URL on the campus network.

In class, he hands the URL out. Students who try to run it have computers that reach into the campus network, copy the app from whatever storage it's on, load any dependencies into RAM (including OS runtimes like posix.so, X11.so, or win32.so from the campus repository), starts a VM sandbox for the app, and the app runs on the student machine. When the student is done, they can save a 'running copy' of the app back to the professor or their own home folder. Once you 'quit' the app, though, it's gone forever and the files that were pulled for dependencies are moved to 'empty space' on the local drive, which is used as cache for that sort of thing. The app ran on the student's machine, but the student never really 'installed' it, and the University MATLAB license allows free distribution of that kind of app.

The 64-bit address space can be used to simplify things by unifying an entire organization's storage into one flat field, it's like Microsoft's Distributed File System but for more than files sitting on different servers. It facilitates the commoditization of -all- storage, RAM, SSD, tape, spinning media.

I'm talking about 'Star Trek' stuff here. You don't think they were installing applications, opening them up, saving data files, and then emailing them to each other, do you? I want to go to there.

Re:64-bit embedded possibilities...

[MarcQuadra]

Yes! And a lot of pie-int-the-sky stuff that MULTICS brought was later merged into the way we do things now (shared libraries and memory, the 'ring' security architecture).

Things could have kept going the MULTICS way if there weren't such limited resources, though. I think we're at a point where the resources aren't limited, and we can make major changes in that direction again.

I want some sort of system that intelligently says 'you know what, it's silly to run this VM on your PC, with puny spinning media. I have room on an SSD array and a rack of free CPUs over here in the data center, I'll just move the app over and keep the window on the client machine'. With an institution-wide 64-bit address space, the 'app' could be migrated over to that faster place and my machine could be informed to attach to the GUI output coming from a memory address over in the data center instead of my own PC.*

(I am not a computer scientist)

Re:64-bit embedded possibilities...

[MarcQuadra]

During MacWorld '84, I believe, there were guys walking around outside selling 256K SIMMs for $380, and that was a steal.

My first computer had 1K of RAM, and my dad had to save up to buy me the 16K expansion pack, if that's any idea of how far we've come.

Re:64-bit embedded possibilities...

[AdamHaun]

The embedded space is very cost-sensitive. It's not like PCs where you can dazzle end users with specs and convince them to pay more. Every gate on the die adds manufacturing cost (and cuts profit), so there has to be a compelling technical reason to add more functionality. Engineers aren't allowed to add features for the sake of features -- it tends to upset their managers. Only marketing people can do that. :-)

Also, keep in mind that embedded systems are totally different from large software and network systems. There isn't going to be some kind of crunch where suddenly we need 64-bit CPUs. We're not going to run out of bits. People still use 16-bit and 8-bit microcontrollers all the time. 64-bit CPUs will be used where their advantages justify the cost, and 32-bit CPUs will still be around afterward.

Collision course or not.

[elsJake]

It has to be cheap , power efficient , dense (performance per rack unit ) and most of all _stable_ if they want to use it for servers.
If they can manage those details it would be an instant hit , x86 servers are mighty expensive for small businesses , at least around where i live.
Either way some competition would be welcome and is sure to drive costs down.
The other essential problem is getting motherboards to meet the same criteria.

Re:Collision course or not.

[Anonymous Coward]

It has to be cheap , power efficient , dense (performance per rack unit ) and most of all _stable_ if they want to use it for servers.

ARM is already in use in medical equipment and industrial motor control. Those are two places where bugs have the potential to actually kill people.
What exactly do you mean when you say that it has to be _stable_ for server usage? Except for desktops and hobby projects servers have the least need for stability compared to all other uses.

What about time_t 64-bit?

[Anonymous Coward]

Consider something more important like having time_t up to 64-bit to have dates beyond 2038... among others.

Re:What about time_t 64-bit?

[petermgreen]

64-bit time doesn't require a 64-bit CPU. It would be a painful transition for an existing architecture since any time-dependent apps would need recompiling but it could be eased by allowing the OS to support both systems like was done for large file support.

lol

[Anonymous Coward]

... years after 64 bit computing is already available, ARM thinks they're going to be innovative and do the same... how about some forward thinking and better planning, like moving forward further to 128 bit.

P.S. I'm not looking for some technical analysis based on today's limitations saying 'oh that requires too much power' or whatever; the point of innovation is to change what is possible.

Re:lol

[WrongSizeGlass]

I don't think this is about 'innovation', it's about 'improvement' - 'improvement' measured in reduction. Chips that are more efficient and smaller mean more can be packed into a single blade while producing more 'right sized' CPU horsepower, less heat and lower power consumption (for the CPU's as well as the cooling). This 'improvement' is very measurable in resource consumption and cost, making them 'greener' with a faster return on investment. Another big plus is the CPU's are cheaper, and is if one inner board fails it is cheaper to repair/replace.

Re:lol

[Anonymous Coward]

I realize its not about innovation; that was my point.

Re:lol

[Hackeron]

For example AMD64 which actually has a practical 48-bit address space allows 65,000 times the address space of 32-bit at a small processing overhead. An address space of 128bit is significantly bigger than all the data stored on earth. There is nothing innovative about getting an address space that big, it's just plain pointless at this point in time.

ARM are not trying to be the fastest or most forward thinking, they are trying to be cost effective and power efficient and a 64-bit version of their chip would free developers from the 4GB address space limit of 32-bit - to one over 65,000 times larger.

I can't stress this enough, this isn't a factor of 2x or a factor of 10x or even 1000x larger, this is a factor of 65,000x times larger...

Re:lol

[del_diablo]

Sorry to break it, but 32-bit is access to roughly 4 gigabytes of data.
33 bit is roughly access to 8 gigabytes of data.
64-bit is roughly access to a data amount that is completely and utterly insane, unlike before we don't have a actual need for it, in contrast to when the 4 gig roof was annoying in supercomputers.
65-bit is twice of that again.
I think 128b-bit is a ridicules dream for the next century, maybe 80-bit or 94-bit or something else will hit instead on supercomputing?
x86-64 is currently limited to measly 52-bits also, which is far far away from entire 64-bit, so ARM would innovate yes.

Re:lol

[shogarth]

One of the more amusing blog entries from Sun engineers was a discussion of the amount of energy needed to completely fill a ZFS file system. A 128-bit address space isn't just optimistically big, it's "freaking huge!"
http://blogs.sun.com/bonwick/entry/128_bit_storage_are_you

Re:lol

[ChipMonk]

The address width and the data width are not dependent on each other. On AMD64, the data width (via REX.x prefixes) is 64 bits, although the maximum address bus width is 12 bits shorter.

It is entirely possible, today, to have natural 128-bit registers, accessing a 48-bit address space.

Re:lol

[del_diablo]

Yeah, but unless x86 happens all over again: A revision which is bumped from 64-bits to whatever the next step is, is a better step than halfassed implention today and all legacy support from 30 year old tech.

Re:lol

[dreamchaser]

I realize its not about innovation; that was my point.

And nobody claimed it was, so I fail to see your point. It just is an evolution of the ARM architecture that could open up some more potential applications for said architecture.

Re:lol

[TheRaven64]

128-bit is not unfeasible, it's just not useful. With a 64-bit program, every pointer is 8 bytes. With a 32-bit program, it's only 4 bytes. 32 bits is enough to address 4GB of RAM, so if everything else in the architecture is the same, you get better performance by using 32-bit pointers because you use less data cache. This isn't just a matter of 'it's too expensive' - no matter how much cache you can afford to add, the 32-bit code will use less of it so will run faster (note: x86-64 adds lots of other architectural enhancements, which offset this slowdown).

With 128-bit pointers, you'd gain absolutely no benefit unless your program needed to address more than 2^64 bytes of data. For reference, Wolphram Alpha claims that this is around 4x10^21 times as much data as is on the web, in total, today. Even if you had all of the information on the Internet in your address space, you wouldn't be filling a 64-bit address space. You'd just be loading and storing 8 bytes of zeroes with every single load and store operation, doubling the data cache and RAM usage for no benefit.

Unless you're talking about 128-bit arithmetic. In which case, you should be aware that most recent vector units support both 128-bit integer and floating point types, filling a complete register (or half a register on the ones that use 256-bit vectors).

ARM cores to take the place of the x86 dominion?

[moxsam]

Would be the most exciting revolution to watch. Since it has a totally different design it changes the parameters of how hardware end products can be built.

As ARM cores are so simple and ARM Holding does not have their own fabs, anyone could come up with their own optimized ARM-compatible CPUs. It's one of those moments when the right economics and the right technology could fuse together and change stuff.

Re:ARM cores to take the place of the x86 dominion

[0123456]

As ARM cores are so simple and ARM Holding does not have their own fabs, anyone could come up with their own optimized ARM-compatible CPUs. It's one of those moments when the right economics and the right technology could fuse together and change stuff.

The problem is... Windows. More precisely, proprietary closed-source software which can't just be recompiled for a new architecture.

The huge amount of installed Windows software out there won't run on ARM, so it won't change the mainstream laptop/desktop market any time soon.

Re:ARM cores to take the place of the x86 dominion

[del_diablo]

Well, considering that somewhere between 60-90% of the desktop marked in reality does not care what their computer is running, so long their got access to a browser and facebook and in worst case a office suit on the side for minor work, it would not really have mattered.
The only real problem is not Windows, it is getting the computers into the mainstream stores to be sold alongsides the Macbooks and the various normal Windows OEM solutions. Just getting it there would mean instant markedshare over night, because only a minority is application bound in reality.

Re:ARM cores to take the place of the x86 dominion

[TheRaven64]

The problem is... Windows. More precisely, proprietary closed-source software which can't just be recompiled for a new architecture.

Much less of a problem than it used to be. Aside from games, how many closed-source software packages do you run that are CPU-limited? In typical usage, the CPU monitor on my laptop rarely goes over 20%. Even emulating everything, it wouldn't be too slow to use. Modern emulators don't emulate everything though, they thunk out to native libraries for things like drawing. That's how Rosetta works on OS X, for example; OS X ships with stub versions of all of the native frameworks for PowerPC, which call the x86 versions outside of the emulator. When you call a library function from an emulated program, you're calling native code. Even if the emulator only runs at 20% of native speed, the apps typically run at over 50% of native speed, meaning that they use 10% of the CPU instead of 5%. You wouldn't want to run all of your code this way, but for the one or two apps that you can't get native versions of, it's acceptable.

Lots of hype.

[Anonymous Coward]

Wake me up when ARM has the performance part of the package at least partially addressed. If we want low cost, low power, low performance servers, we already have Atom and Nano, both of which offer x86 binary compatibility and can run the latest releases of WIndows and any Linux flavor of the month, and both of which deliver superior performance (to ARM). Anyone thinking that they are heading on a collision course with Intel any time in the next decade... I want some of what you are smoking.

So where is my ARM desktop yet?

[Anonymous Coward]

I guess it is nice that they are contemplating servers and thousand dollar cellphones for overpaid yuppies, but where are the hundred buck low power good enough for surfing ARM desktops or "nettops"? That's what I am really interested in, cheap, good enough, cool running, electron sipping can run linux and not x86 machines.

Re:So where is my ARM desktop yet?

[Tapewolf]

http://en.wikipedia.org/wiki/Acorn_Archimedes

Re:So where is my ARM desktop yet?

[Anonymous Coward]

Well, that is interesting and all, just wondering about something a bit more modern. We have 1 ghz ARM in cellphones now,and larger coming, etc, which is enough with sufficient RAM to work as a modern desktop for most uses. I currently still run an old slow single core, works fine, but if I could get comparable performance at only 1/10th the electricity use and eliminate all the fans...see what I mean? Way back in 2008 canonical announced serious ARM support and so on, but still no machines to buy from anyplace. I contemplated using a high end cellphone, but none of them have full keyboard and mice support and are beastly expensive and you can't get any with at least two gigs of RAM, which is defacto about the tipping point for a desktop today between "works" and "tear your hair out".

I mean really, the chips themselves are wicked cheap compared to intel or amd, so where is a plain vanilla ARM based normal form factor desktop, ATX or miniITX or like that? Seems like they could be making a good enough desktop for some serious cost reductions and hit the niche that fits. Now I have an old VIA miniITX board but dang they require super expensive RAM (via specific, generic pc133 stuff do NOT work) just to get it to one full gig, and the 256 megs that I have, just don't cut it. "Good enough" quiet, cheap to run and cheap is what I am after and it sure seems like an ARM solution would fit, just I can't find one, and I have looked now for two years off and on. I don't want a teeny netbook, I want a bog standard desktop cheap machine, just with ARM instead of AMD or Intel.

Re:So where is my ARM desktop yet?

[h4rr4r]

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:So where is my ARM desktop yet?

[Anonymous Coward]

I have a teeny ARM netbook and I agree with you. It is cool and all, but I can't bear using it for long. Too small and once any component dies, it's all over. Eight of them would easily fit inside a desktop case. Almost no heat generation nor power consumption and fast enough for most uses if the load was shared between the cores. No need for expensive embedded components either. Eight cores and what, 3 Gb of RAM would give you a competitive desktop out of already available tech.
I think the OS is what's holding the investors back. They can't ship Windows nor MacOS and let's face it, a netbook with Ubuntu is one thing, but a full desktop...

Re:So where is my ARM desktop yet?

[TheRaven64]

The BeagleBoard is $100 and can drive a DVI monitor, connect to a USB keyboard and mouse, and so on. Desktops are an increasingly irrelevant niche, however. They are now under 40% of new computer sales, meaning that laptop components now have the economies of scale that desktops once enjoyed. Between the server and the laptop, there's not much space left for the desktop.

Re:So where is my ARM desktop yet?

[olau]

Ergonomics of laptops suck compared to a dedicated desktop with a big monitor. On the other hand, maybe we'll see more Mac mini like desktops with laptop components. That would be neat.

Re:So where is my ARM desktop yet?

[TheRaven64]

There's nothing stopping you from plugging the laptop into an external monitor and keyboard / mouse.

The App-Store revolution will change that

[rsborg]

Apple, Google and Canonical have seen the writing on the wall: Make the apps independent of the ISA, and your platform can go anywhere.

Best way to do this is to provide the storefront, and handle distribution integrated with the OS.

I think the App Store is the biggest software revolution from the 00's ... and it's yet to play out completely.

Re:The App-Store revolution will change that

[h4rr4r]

I think you have no idea what a repository is, otherwise app stores would not impress you at all.

Re:ARM cores to take the place of the x86 dominion

[cbhacking]

I was going to mention a few, but then I realized that almost all of them are .NET based. MS already has a .NET implementation on ARM (for their mobile devices) and I believe Mono also works on ARM.

The remaining ones are MS Office (ported to x64 and PPC), Visual Studio (partially .NET and hopefully somewhat portable), Opera (portable), Foxit (there are other PDF apps even if it's not portable), and probably a few more.

Of course, you can't just ignore games. Relatively few of those are portable, and I happen to care about them quite a bit.

Power and cooling costs

[xswl0931]

In large datacenters, power and cooling costs have become a significant part of the TCO. For smaller server rooms x86 compatibility is probably more important.

more multi-core action

[ChipMonk]

Imagine these scenarios:

Building a Linux kernel on a dual-core AMD64: "make -j3 bzImage"

Building a Linux kernel on a quad-core or 8-core ARM: "make -j5 bzImage" or "make -j9 bzImage"

Any bets on which one will finish sooner? The smaller ARM die means the same wafer can hold more ARM cores than any current Intel x86 or AMD cores. The term "embarrassingly parallel" comes to mind.

Re:more multi-core action

[Anonymous Coward]

One of my professors was talking about a person he knows who is currently working on multi-layer chips for ARM, I'm not an EE, but AIUI, the idea was that if you put the cache on top of the CPU itself, you can significantly reduce the latency in signalling. I think he hoped that in future they might be able to reduce the chip density slightly, but put a third layer on top, containing a second CPU, so you get two cores with a shared cache and a tiny communication latency, but still have heat issues which re no worse than a high-end intel chip.

I think the big problem was in the added complexity of figuring out the cross-talk between the lines since you are adding more tracks in close proximity, and obviously you have to ensure there is no interference. Fabbing the chips would obviously be more expensive, but if the idea works, it could be a major improvement in performance.

Say it isn't so...!!

[Anonymous Coward]

No! Not the dreaded, "collision course." Can you imagine the energy that will be release when these 2 behemoths collide!

Quick, call the Intel bunnies and tell them to don their purple Nikes! Phone the folks at the LHC and let them know so they can accelerate their schedules before it's too late and we all die without knowing if the Big Bang really abhors vacuuming or Newton only thought he saw stars after being hit on the head with an apple.

We are all on a one way train to marketing=speak Valhalla, and we're never getting off~!

Seriously, should burn Rupert Murdoch's style book.

ARM is very behind

[Anonymous Coward]

Low Power - High Performance ... that is already occupied by Cavium, Tilera and others ...

However in the MOBILE space this will have some applications ...

Re:ARM is very behind

[the linux geek]

Tilera is still niche in a lot of ways. Limited memory and I/O bandwidth, as well as lack of an FPU until the TileGX, holds them back.

NetLogic and Cavium are both higher-performance for general server applications - I'd be interested in the potential for a server based on the new NetLogic XLP chip.

64-bit pointers considered harmful

[jensend]

This isn't like the 16->32 bit transition where it quickly became apparent that the benefits were large enough and the costs both small enough and rapidly decreasing that all but the smallest microcontrollers could benefit from both the switch and the economies of scale. 64-bit pointers help only in select situations, they come at a large cost, and as fabs start reaching the atomic scale we're much less confident that Moore's Law will decrease those costs to the level of irrelevance anytime soon.

Most uses don't need >4 gigabytes of RAM, and it takes extra memory to compensate for huge pointers. Cache pressure increases, causing a performance drop. Sure, often x86-64 code beats 32-bit x86 code, but that's mostly because x86-64 adds registers on a very register-constrained architecture and partly because of wider integer and FP units. 64-bit addressing is usually a drag, and it's the addressing that makes a CPU "64-bit". ARM doesn't have a similar register constraint problem, and the cost of 64-bit pointers would be especially obvious in the mobile space, where cache is more constrained- one of the most important things ARM has done to increase performance in recent years was Thumb mode i.e. 16-bit instructions, decreasing cache pressure.

Most of those who do need more than 4GB don't need more than 4G of virtual address space for a single process, in which case having the OS use 64-bit addressing while apps use 32-bit pointers is a performance boon. The ideal for x86 (which nobody seems to have tried) would be to have x86-64 instructions and registers available to programs but have the programs use 32-bit pointers, as noted by no less than Don Knuth:

It is absolutely idiotic to have 64-bit pointers when I compile a program that uses less than 4 gigabytes of RAM. When such pointer values appear inside a struct, they not only waste half the memory, they effectively throw away half of the cache.

The gcc manpage advertises an option "-mlong32" that sounds like what I want. Namely, I think it would compile code for my x86-64 architecture, taking advantage of the extra registers etc., but it would also know that my program is going to live inside a 32-bit virtual address space.

Unfortunately, the -mlong32 option was introduced only for MIPS computers, years ago. Nobody has yet adopted such conventions for today's most popular architecture. Probably that happens because programs compiled with this convention will need to be loaded with a special version of libc.

Please, somebody, make that possible.

It's funny to continually hear people clamoring for native 64-bit versions of their applications when that often will just slow things down. One notable instance: Sun/Oracle have told people all along not to use a 64-bit JVM unless they really need a single JVM instance to use more than 4GB of memory, and the pointer compression scheme they use for the 64-bit JVM is vital to keeping a reasonable level of performance with today's systems.

Re:64-bit pointers considered harmful

[gman003]

Several points here:

• There actually is a method for using 32-bit addresses in programs, but letting the OS address 52-bit space. It's called PAE, and it's been around since the Pentium Pro. It's almost always enabled on Linux and Mac OS X, but isn't available for non-server versions of Windows. So it's been tried, but isn't well-known or used.
• Currently, 64-bit processors only use a 48-bit address space, precisely for some of the reasons you listed. The architecture is designed to scale up to full 64-bit addresses, but the processors internally use 48-bit addresses, to save on cache, bus width, etc.
• While most programs don't use more than 4gb of memory, there is one rather significant market segment that does: gaming. Most games released over the past few years can benefit greatly from using significant amounts of RAM. 4gb of RAM is actually considered the minimum needed for modern gaming - many gamers will use 8gb or even 16gb of RAM. That's just one market segment that would use 64-bit. Photo processing is another one - for some time, Hollywood was using Linux and the GIMP for editing, because it was the only way to work with films that used nearly a gigabyte per frame. 3d rendering/modeling/CAD is yet another. While Joe User might not really need 64-bit addressing, there's enough users that DO need it that every OS needs to support it, and it's just less of a headache to use 64-bit throughout than to have some set up as 32-bit, and others as 64-bit.

Re:64-bit pointers considered harmful

[jensend]

PAE _is_ frequently used- whenever an x86-64 processor is in long mode it's using PAE. PAE has been around for a lot longer than long mode but few people had much of a reason to use it before long mode came around- not because it didn't accomplish anything but because memory was too expensive and people had little reason to use that much. On a processor where long mode is available there's little reason to use PAE without long mode- long mode gives you all those extra registers etc.

What I and my homeboy Knuth are talking about for x86 has more to do with the ABI than with hardware. As Knuth says some of the first places work would need to be done are the compiler etc and the libc; some OS support would also be required.

Yes, current 64-bit processors can't use more than 40 bits of physical memory or 48 bits of virtual. But the pointers are still the full 64 bits wide, and at no point does the processor store them in anything less than 64 bits. Limiting things to only using 48 bits of address space just simplifies MMUs etc, it doesn't save space. Trying to store other things in the unused bits in a register holding a 48 bit pointer would be more hassle than anybody wants to deal with. I mean, sure, you can do a bunch of bit twiddling to try to put junk in those other bits when you're storing a pointer, but it's going to be more expensive than it's worth.

I don't think there's any game out there which uses more than 4GB of address space in a single process, regardless of the settings you're using. If you can find concrete evidence of one, let me know.

Even finding situations where games really benefit from more than 4GB of total system memory is rare. I haven't seen too much in the way of benchmarks comparing differing amounts of RAM for this year's DX11 games, but I know that practically no games released before this year benefit from more than 3GB of system memory (of the benchmarks I saw the one which really contested that was published by Corsair, and they can't be accused of being indifferent to how much memory people buy). For games that do appear to benefit at their very highest detail settings at extreme resolutions, I'd still like to see evidence that the visual quality is noticeably different from what you get when you bump the settings down a notch and save a gig of RAM.

It's true that people working on films in ridiculously high resolutions and some 3d modeling/rendering/CAD folks may want more than 4GB of RAM available to a single process. But those and the other uses for >4GB in one process are a tiny portion of the overall market and have nothing at all to do with ARM and mobile. And you've vastly overstated the effort it takes to be able to support smaller pointers and the simplifications available if you stick with 64-bit.

Re:64-bit pointers considered harmful

[Anonymous Coward]

If your data consists mainly of pointers and it's a performance issue, you're doing it wrong.

Re:64-bit pointers considered harmful

[Anonymous Coward]

That is rubbish, I'm sorry but users need lots of RAM. I work with clients that regularly have machines that have 24 or 32 GB or more of RAM.
It is exactly like the 16->32 transition and I fail to see why so many developers and IT people love hanging on to the old 32-bit systems ??
Pure 64-bit is the only way to go and the sooner the better.

Re:64-bit pointers considered harmful

[vadim_t]

Actually, you can't store anything in the extra pointer bits. If you try to do some bit twiddling, the CPU will raise an exception. This is to make sure that when more than 256TB of address space is needed, the CPU can be expanded without running into trouble with programs that "cleverly" decided to use the extra space.

Re:64-bit pointers considered harmful

[Anonymous Coward]

You've obviously never worked with a decent size database or large data sets. 32 bit is a massive strain on the system because you're having to go from fast RAM to very slow harddrives.

Re:64-bit pointers considered harmful

[amorsen]

Good luck with getting OS vendors to maintain 3 versions of all libraries instead of "just" 2.

Re:64-bit pointers considered harmful

[Rockoon]

If your data consists mainly of pointers and it's a performance issue, you're doing it wrong.

While true, in this case the trend is to continue to do it wrong and to buy faster silicon to make up for it.

While the alternatives to linked lists, tree's, and so forth are often a big efficiency win, they are not very good when it comes to maintaining the code base.

Problems boil down to "I need O(x) Insertion, O(y) Lookups, O(z) Deletes, and O(w) Sorted Enumeration" with x, y, z, and w being of varying importance... the alternatives to pointer-heavy methods are maintenance nightmares unless only 2 of the 4 needs to be equal or better than O(log n)

Re:64-bit pointers considered harmful

[Anonymous Coward]

i respectfully disagree with dek here. having lived through the
tortuous FAR and HUGE pointer mess in microsoft land when
they were trying to keep a segmented model (which is what
you will get if you insist on making some software 32-bit only),
i can tell you it's no fun and should be avoided.

Re:64-bit pointers considered harmful

[jensend]

I certainly wasn't saying that there aren't any use cases for >4GB. I'm saying that those uses are a minuscule fraction of all systems and zero percent of mobile systems. I'm also saying that the idea that it's inevitable that Moore's law and growing memory demands will soon make 64-bit pointers the best option for all kinds of uses, from the average user's desktop to microcontrollers, is mistaken.

Re:64-bit pointers considered harmful

[Anonymous Coward]

While true, in this case the trend is to continue to do it wrong and to buy faster silicon to make up for it.

That trend has been around for decades and it tends to eat all available silicon no matter what. The only thing that would affect it is the end of Moore's law.

the alternatives to pointer-heavy methods are maintenance nightmares unless only 2 of the 4 needs to be equal or better than O(log n)

So, I replace pointers with handles. How is it a maintenance nightmare?

Re:64-bit pointers considered harmful

[Lemming Mark]

In fact, on PPC it's normal to run a 32-bit userspace on a 64 kernel simply because there's no benefit (and some cost) to having lots of 32-bit userspace code lying around. For the kernel it makes more sense to use 64-bit addressing, I think, since it avoids the need to keep mapping and unmapping userspace data when it needs to be accessed.

Re:64-bit pointers considered harmful

[Rockoon]

How would you access the data associated with a handle? Perhaps via a pointer of some kind?

..in other words, why an extra abstraction? Does it offer any advantage? Before you answer, make sure that you know at least a little bit about assembly language.

Re:64-bit pointers considered harmful

[Anonymous Coward]

Is accessing 16-64 gigabytes of memory with 32 bits not enough for you?

#define HTOP(h) ((void*)((char*)bases[(h)>>24]+((h)&0xffffff)*ALIGNMENT))

mov eax, h
shr eax, 24
mov rax, [bases+rax*8]
mov ebx, eax
and ebx, 0xffffff
shl ebx, 2
add rax, rbx

Slower? The first instruction is redundant since the handle is already in the register, bases array is in the cache and the few last instructions can easily be integrated into the actual access in form of [rax+rbx*4].

Okay, still loses to direct pointer access, but if we're speaking about big fat objects you don't convert these around all the time, do you?

Re:64-bit pointers considered harmful

[Anonymous Coward]

A "clever" developer will just mask the bits out when dereferencing.

Re:64-bit pointers considered harmful

[Rockoon]

Sure, you can find less efficient methods that are not very annoying to maintain.

Its the more efficient methods that are annoying to maintain.

For example, there exists methods of implementing binary tree's without the need to have any node references (pointers/handles/doesnt matter) in the node structure. The problem is of course that its incredibly wasteful of memory for sparse tree's, and it is the solutions to that memory waste that are problematic to maintain.

This tree method is actually extensively used in most operating systems memory management, where the trees are always fully populated to a specific depth, nullifying the downsides of sparseness by simply being the exact opposite of sparse. The method is generally referred to as the Binary Heap.

Re:64-bit pointers considered harmful

[Anonymous Coward]

Heaps are nothing. See what CSA does to indexes.

Re:64-bit pointers considered harmful

[Tuoqui]

Except you overlook one thing...

ARM Processors are in Netbooks and soon will be in Laptops. These devices get huge gains in battery life from low wattage CPUs. Also the more 'green'/energy conscious among us have started using ARM processors in personal servers and even some desktop machines (at least those ones which are not required to play heavy 3d games and stuff). Thus coming out with devices that can addrses 64-bits is not necessarily counter productive as they are likely aiming for a bigger segment of the netbook/notebook/desktop market.

Re:ARM cores to take the place of the x86 dominion

[LWATCDR]

Not that big of an issue in the server space. Sparc and Power5 don't run Windows. And almost all the big server apps already run under Linux so those can recompile without much effort.

Re:ARM cores to take the place of the x86 dominion

[gman003]

Apple managed to make the switch from PowerPC to Intel almost seamlessly, thanks to a well-written emulator. Microsoft might be able to do the same.

Windows Mobile

[tepples]

The huge amount of installed Windows software out there won't run on ARM

All the software for Pocket PC aka Windows Mobile (based on Windows CE) already runs on ARM.

Re:Bullshit considered harmful

[Anonymous Coward]

It's funny to continually hear people clamoring for native 64-bit versions of their applications when that often will just slow things down.

Yet benchmarks consistently show that despite the overhead of 64 bit pointers, nearly every program is faster on AMD64.

• http://www.tuxradar.com/content/ubuntu-904-32-bit-vs-64-bit-benchmarks
• http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&num=1

Finally- My PDA will support 4+Gb Ram!

[gearloos]

So, now I can really get WinCE Jamming! lol J/K of course...

new debian platform

[Cyko_01]

oh god, not another architecture to maintain! This is going to set back the next release a few years for sure!

@mods: it was a joke, I'm not trolling.

Re:new debian platform

[h4rr4r]

Debian is already maintaining an arm branch, so pretty bad joke.

Performance per watt

[msobkow]

Performance per watt is what matters in the server room, and that's one area where ARM handily trumps x86.

Floating point?

[Nicolas MONNET]

No floating point is ever required for filesystems or encryption.

Re:Floating point?

[TheRaven64]

No, for those two applications the reduced register churn is the big improvement. For other benchmarks, it's usually the SSE. This doesn't make a difference on OS X, where the oldest supported x86 chips have SSE, but for Windows and *NIX there's a big difference between compiling for i686 (includes PPro and P2) and i686+SSE. It's really hard to generate good code for x87 (weird hybrid of stack and register architecture) and even if you're not using the vector capabilities of SSE you typically get a 20-50% speed boost in the floating point code paths. If you are, it can be even larger. For typical apps, this translates to a 5-20% overall improvement, which appears to come from 64-bit, but can also be achieved simply by dropping support for anything older than a P3.

Re:Floating point?

[Rockoon]

It's really hard to generate good code for x87 (weird hybrid of stack and register architecture)

Not exactly true.

The problem is that a compiler attempts to preserve the rounding-error integrity of the equations they are given as expressed based on the implied language rules (typically left-to-right for equal-precedent operations,) where its literally impossible to generate x87 code that doesnt have a lot of loads and stores for any non-trivial expression.

This is why even intermediate assembly language programmers have always run circles around compilers with regards to x87 code. A competent programmer will know where the rounding issues could meaningfully manifest, free to produce very efficient code everywhere they wont manifest.

Re:Floating point?

[smallfries]

How does increasing the number of registers reduce churn in encryption? The working-set is far too large to fit in the larger number of registers anyway so it has little effect. In AES there is a 256byte/4096byte lookup table (depending on the implementation) and accesses into it are randomly distributed. On the public key side even with a tiny 1024-bit key the working-set is a 16x16 word set of partial products and it needs to be computed in some order to minimise memory traffic.

The only real question:

[rickb928]

When will it run Android?

Re:ARM cores to take the place of the x86 dominion

[slapys]

The only real problem is not Windows, it is getting the computers into the mainstream stores to be sold alongsides the Macbooks

What makes you assume Apple won't switch to ARM sometime in the next couple years? They dumped PPC for X86 due to the more favorable power/performance ratio. It's only natural to assume that when high-powered ARM processors appear, Apple will switch to that architecture without a moment's hesitation.

Re:Bullshit considered harmful

[ld a,b]

To be fair, that doesn't counter his argument, amd64 has more registers than i386 and they do make a big difference. Repeat the tests with 32-bit pointers and 64 bit registers and then get back to us.

As of today, the method he mentions would probably provide a bit better performance, assuming the processor optimizations didn't break when their expectations weren't met.

However, I think it is very short-sighted to miss the fact that about the only thing increasing these days is memory and that apps tend to grab all the address space they can get. By 2050 I can see machines with 1TB ram, but I can't see apps keeping themselves under 0xFFFFFFFF.

Furthermore, thanks to ASLR, which is a feature available now on most OSes, address space fragmentation is a problem today even for programs well under the 4Gb mark. The future is 64:64. 32 bit architectures are already dead, they just haven't realized it yet.

Re:ARM cores to take the place of the x86 dominion

[toejam13]

You must not be aware of JIT style binary translators. I used to use x86 Windows binaries on my DEC Alpha running NT4 (and NT5 up till build 2000) under FX!32 all the time. Heck, I even ran Win32 games that used OpenGL. Nothing prevents somebody from doing the same with ARM. In fact, I'm waiting for somebody to do that for WINE.

I didn't really answer the question

[dbIII]

If it's cheaper, doesn't use much power and gets the little jobs done then it will have an advantage over Atom etc.

Knuth considered senile

[r00t]

He's ignoring at least two benefits that help no matter the architecture.

First, address space allocation is a hashing problem. Calls to malloc (mmap) need to find free space; this gets slow as the address space fills up.

Second, we care about security and we realize that programs may have bugs. ASLR benefits greatly from extra address space. This can be the difference between an attacker having a 1-in-256 chance or having about a 1-in-trillion chance.

He's also focusing on the cache-related downside while ignoring the cache-related upside. Unless you get rid of all 64-bit libraries, adding 32-bit stuff to the system will double the amount of code that the CPU has to cache. Context switching between 64-bit and 32-bit software causes one or the other to start getting thrown out of the cache.

Re:Bullshit considered harmful

[Anonymous Coward]

To be fair, that doesn't counter his argument, amd64 has more registers than i386

There was no attempt to counter the OPs argument, only a single point that is untrue for the steady transition from i386 to AMD64. While I can respect your fairness, the facts remain that people are asking for AMD64 apps because they exhibit better real world performance and because few can be bothered with multilib systems.

As of today, the method he mentions would probably provide a bit better performance,

Surely 32bits better for each pointer :P

Re:ARM cores to take the place of the x86 dominion

[TheRaven64]

A few years ago, Microsoft bought a company called Connectix. Their flagship product was called VirtualPC, and was an x86 emulator for PowerPC. Not only could they do it - they have the expertise in house to do it. I believe they used this code to run XBox games on the XBox 360 and if the people who wrote it haven't left they could almost certainly come up with an ARM version.

Or they could use it as an opportunity to push .NET - anything written with .NET will run in Windows on any CPU...

Google using ARM on server-side?

[Anonymous Coward]

Maybe Google is interested in using ARM on the server-side. 64-bits sounds logical over there and it would heavily reduce power consumption on applications that are optimized.

And when you answer with the example ...

[dbIII]

And when you answer with the example be sure to tell us why not being able to run that application effectively "is totally crippling" to the platform.
I'm not saying that having more memory would not be useful, simply pointing out how idiotic the argument is that the platform is "crippled" simply because it has less memory than many desktop machines.

Re:ARM cores to take the place of the x86 dominion

[Lennie]

You could argue they already have, they sell many, many times more ARM-based devices then they sell desktop-machines.

Bah

[Yvan256]

I've got eight 8-bit AVRs and duct tape right here. That's almost the same thing.

Re:Bah

[Pence128]

What's faster? an i7 or 500,000 3GHz 4004s?

Re:ARM cores to take the place of the x86 dominion

[benhattman]

Exactly. How could they pass it up?

Mac: I'm a Mac
PC: and I'm a PC
Mac: You're looking a little sluggish PC.
PC: Yeah, my Dr. says I should stop using this Intel processor, but I just can't quit.
Mac: That's too bad, because now that I use half the power I can run an entire day without recharging.
PC: Sure, but who would want ... [PC slumps over].
Mac: PC, are you OK?
PC: [picking back up] Sure, I'm just demonstrating how I can go a day without recharging by using sleep mode.
Mac: How much of the day will you be sleeping then?
PC: About 20 hours [PC slumps over again].

---------

If we reach a point where ARM chips are available that match x86 on two of price, performance, and power usage and beat x86 by say 20% on the other factor, you can bet that the only platforms which will remain using x86 are those that can't make the leap. And any platform that can't switch over will be obsoleted pretty soon.

portability bugs

[Anonymous Coward]

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.

And how many of use non-Linux users have had to put up with bash-ism when someone specified /bin/sh, Linux-ism syscalls, and GNU-isms on BSD or Solaris when it comes to CLI utilities in scripts?

Portability bugs can be found all over the place. That's one of the problems with Unix to a certain extent.

Troll mods

[Gary W. Longsine]

Why suddenly does it appear that somebody is following jcr around with a bucket of "Troll" mods? "Score 3, Troll" just cracks me the frack up.