Submitted by We all know (and love?) ARM as the company which focusses on licensing designs for power-efficient yet still powerful processors, mostly used in embedded devices. The Cambridge company has been looking to expand into the netbook market, and has now announced a new step in this process with a number of new multicore Cortex-A9 designs.
ARM has announced dual, quad, and eight core Cortex-A9 processors, with clock speeds as high as 2Ghz. They’re really aiming for Intel’s Atom here: performance-per-watt is up to eight times more efficient than Intel’s offerings, with the highest-performance designs delivering five times the performance of Intel’s Atom chip at the same power consumption levels.
“This is a huge departure from what we’ve done in the past,” Eric Schorn, vice president, marketing for ARM’s processor division, told ZDNet UK, “We really wanted to take off the handcuffs and see what could be done with performance, performance, performance.” The new designs come in two variants, optimised for either low power consumption or high performance.
“The sweet spot for most customers is dual-core,” Schorn said, “but the base design can go up to quad-core and some partners are already building those. Eight way is coming. Everyone’s high-end roadmap is putting down more cores, and we do that. We’re headed in the direction of Intel’s mainstream processors. We have other plans that surpass the current performance, and we’ll intercept Intel in a high-margin area, not just with Atom.”
Key to ARM’s low power requirements is the ability to turn off different parts of the chip. Parts of the cache, maths, media and general processing areas can be turned off when these parts are idle.
ARM licenses their designs out to countless manufacturers, known as ARM licensees. Interested parties can license the new designs now, with delivery of the finalised designs delivered in the last quarter of 2009. Palm also says they will have evaluation chips ready in the first quarter of 2010.
These new chips will make their way to all sorts of devices, but the most promising application (at least, for me) is the prospect of seeing chips like this in netbooks. Currently, netbooks powered by Intel’s Atom chip are slow and very power-hungry, mostly because Intel decided to pair the Atom chip to an old and power-inefficient chipset. Since innovation in the battery industry is slow, we have to rely on the rest of the hardware to become more efficient, and it seems like ARM is the one really pushing the envelope.
.. it will be interesting to see how FOSS fares against closed source in this area.
I think a lot of vendors are smart enough to try different options. Consumers on the other hand .. not so sure.
My ASUS 901 runs Ubuntu so for me, to see a netbook running one of these chips would be fantastic. I want raw performance AND power efficiency, I don’t see why I should settle for just one of the two.
I’m hoping that when it’s ready, they port Haiku to ARM as then I think all my netbook dreams would come true :-). Until then, Linux will do fine.
That said, does anybody know of a good mainstream disto release for the ARM architecture?
There already is work underway to port Haiku to ARM so don’t be surprised if there is something bootable in the next year or so.
Question: It is my understanding that BeOS/Haiku uses the ‘HALT’ instruction to lower power use when the CPU is idle and waiting for an interrupt, does the ARM have such an instruction/mode and if it does how much power is used compared to normal CPU needs?
I am thinking in term of a large number of cores when a number of them will sit idle when there is not a heavy load on the system.
There is a WFI (Wait For Interrupt) instruction that puts the cpu to idle mode. Currently supported by Linux on MPCore
From what I understand Haiku is based on the NewOS kernel which includes support inside it for multiplatformness.
The problem with Linux is the need to get rid of HAL and replace it with something that doesn’t depend on a constant cycle of polling. Once HAL is replaced you’ll find that battery life will improve considerably when combined with the improvements that are slated for 2.6.32.
Really? I’m running powertop at the moment, and HAL doesn’t even show.
Which distribution? I know that there have been several distributions that have wound back what HAL does these days with the advent of devicekit but there were something like 6-10 components which kept waking up the CPU. Even so, HAL is hardly an ideal situation given how horribly buggy and unreliable given my experience. GNOME 2.28 has been demarcated HAL to be removed and apparently by 2.30/3.0 it will be 100% removed and replaced with Devicekit, Devicekit-power and Devicekit-Storage.
If there is a slick version of Linux bundled with the ARM Netbook, people will purchase it; the problem has been so far is the half assed efforts by OEM vendors in making sure everything works reliably.
The replacement is called devicekit.
Ubuntu will be soon available for ARM (in fact there is a version that currently works)
Canonical are working on a version of Ubuntu for ARM.
Debian have had an ARM port for ages.
http://www.debian.org/ports/arm/
Ummm, Debian?
Has been for a while. ARM and ARM-EL since, like *FOREVER*…
If netbooks will benefit from additional power, (not just power efficiency) then it will be with Linux, as Microsoft says they won’t port to ARM, but the benefits of power on a netbook IMO, is for games and entertainment, which is still the realm of 3rd party Microsoft developers.
I think that the biggest boost that both Linux and ARM netbooks need is for Wine to be ported to ARM. I know Codeweavers says they aren’t interested, but if some ARM company realizes that Wine on ARM could be their strongest sales method, then I hope someone fronts the dough to do it. I doubt they would, but Google could really expand their “Chrome OS” by that approach.
Very unlikely to happen, as Wine is not an emulator. Perhaps you are thinking of full fledged virtual machine products.
It’ll be more interesting when software houses see compiling stuff for Linux/Arm as a way to differentiate against competition: even if they were overwhelmed by competition in the usual wintel market, a small company could carve an area for themselves on Linux / Linux+Arm platform as they become more popular.
Actually, you would be best of doing a hybrid solution.
The Wine server running native on ARM, and the Wine client running emulated.
So you want to emulate windows apps? What a waste of precious resources!
It just doesn’t make any sense.
So you want to emulate windows apps? What a waste of precious resources!
It just doesn’t make any sense.
Why do people want to run Windows apps under Linux, BSD or OSX? Simple; because they are either used to those apps, there are no alternatives, or the alternatives just don’t cut it. So of course it makes sense, atleast to those people can’t get by with alternatives. But I think they’d be better off using Windows then altogether.
So WHY should one use non-compatible hardware platform with alternative OS for sluggish emulation of x86+Windows?
Isn’t it simpler and more logical just to use Windows on x86?
Re-read the last sentence?
guys guys! I didn’t mean it was a good idea. I don’t want Windows apps. I’m only interested in the technical aspect, and I was just saying, if you did need it, the best way would be native Wine server, and emulated Wine clients. So the moment the emulated app hands work to Win32, the work is native. That beats full emulation, but it still won’t be near real x86. Even if the emulator is JIT’ed etc etc. If Windows compatability is required, a x86 is required. Perhaps you could have a second processor that is x86 (RiscPC style) that is only power up to run Wine client apps. All very interesting, but not in terms of usefulness. 😉
Actually, it is simpler and more logical, and faster, more secure and far cheaper, to just use Debian for ARM. If you need any functionality that you cannot find native in Debian (doubtful) then it would be easier to write a new FOSS Linux-native application that implemented such functionality than it would be to try to run x86 Windows binaries.
For example: Mono is by far an easier way to run .NET on ARM than any kind of Wine + x86 emulation. To create and process word-processing, presentation or spreadsheet files, run OpenOffice not MS office. Use Firefox not IE to surf the web. Use GIMP (wait for version 2.8 with a sane GUI, perhaps) not Photoshop. Run Moneydance not Quicken. And so on, and so on.
http://www.gimpusers.com/news/2009-09-19/single-window-mode-gimp-2-…
http://www.mmiworks.net/eng/publications/2009/09/gimp-single-mode.h…
For well over 90% of uses and users, this will be by far the easiest way to get whatever desktop functionality one might need on any desktop, notebook or netbook machine with an ARM Cortex A9 dual core, 2GHz CPU. As a bonus it will perform far better than any same-price machine with Windows 7, too.
PS: For decent 3D graphics but still low-power machines, perhaps a combination of ARM Cortex A9 dual-core 2GHz (topic of this thread), a low-power GPU (perhaps the ATI HD 4300 http://hothardware.com/News/ATI-Launches-the-4600-Series-Mobile-GPU… ), say 4GB RAM, and the Linux 2.6.32 Kernel:
http://www.phoronix.com/scan.php?page=news_item&px=NzU0Nw
There are no artificial constraints on how much “punch” and capability OEMs put into a Linux\ARM netbook.
Edited 2009-09-21 09:59 UTC
JustAroundTheCorner(tm).
The dual-core 2GHz ARM Cortex A9 chip is indeed just around the corner. The design is there, and it will probably become a physical reality not too long after software such as the Debian on ARM kernel 2.6.32 with ATI 3D drivers and applications such as GIMP 2.8 are available.
Meanwhile, here is the type of thing that can be achieved on power-hungry x86 laptops today:
http://www.youtube.com/watch?v=pTRsLW0eet0
and this:
http://www.go-oo.org/
http://www.go-oo.org/discover/
Edited 2009-09-21 10:29 UTC
The notion of an ARM-native version of Wine is not terribly far fetched. There is even a precedent for it, that being the (PowerPC) Darwine project.
Back in 2002 the Darwine project started out with the notion of marrying up the QEMU processor emulator with Wine. They got as far as porting Wine to Darwin-x86, and even had a patch that had PowerPC Windows binaries (rare beasts) running on Darwin-PPC. It seems that after Apple announced the shift to x86 work on the QEMU integration (which had been going slowly) ground to a halt.
The same approach that Darwine was taking would be perfectly valid for ARM platforms. If there is sufficient demand it could happen.
The reason Wine is so important on x86 is because there is a huge glut of apps that people think they can’t live without that they are used to using on x86 Windows. So Wine allows them to keep one foot in the old world.
But ARM is a whole new world. Anyone making the break to ARM probably has their mind a little more open toward making a clean break from the past.
So making Wine work on ARM, maybe by adding some emulation capability, would be counterproductive.
So making Wine work on ARM, maybe by adding some emulation capability,
It wouldn’t be possible to run x86 Windows apps on ARM without converting ALL x86 instructions to ARM instructions. So it would require a lot more than just some emulation. Running anything more complicated than Calc.exe that way on a low-power ARM would be a suicide.
Not necessarily. You might be able to get by with running the Wine DLLs / Wine server as native code and then having some sort of thunks into the emulator which runs the app code. I believe the ARM can run in little-endian mode, so you might not even need to change endianness.
You’d still be running all the application code in emulation, which would still run terribly slowly and would probably be highly error-prone. Which I think was the point.
Edited 2009-09-18 21:53 UTC
Not necessarily. You might be able to get by with running the Wine DLLs / Wine server as native code and then having some sort of thunks into the emulator which runs the app code. I believe the ARM can run in little-endian mode, so you might not even need to change endianness.
Of course Wine itself would be native code then, but all the application code, x86 DLLs and all that would have to be emulated real-time. Even simple translation of x86 code to ARM would require keeping track of all the registers, jump references and such, not to mention the actual translation. That would make Wine a really complicated piece of software, it would make it even more crash-prone, and the performance would not be stellar.
Dynamic recompiling, like Rosetta on Mac. The APIs are native (WINE), but the x86 binaries can be partially recompiled at launch time, and then emulated (and cached) on the fly for the page-table stuff &c.
If there was the demand for it, it could be done. Hopefully there won’t be the demand for it
Of course it could be done, but Wine is still very much a work-in-progress and adding such functionality to it would just slow things down even more. Still, who knows if they do eventually do that?
If there was the demand for it, it could be done. Hopefully there won’t be the demand for it
I do also hope it won’t be done. Why? For the simple reason that having no x86 software for ARM users to play with would most likely push people to develop open replacements for them. Or atleast work on an existing alternative. This would then in turn benefit ALL platforms where those alternatives are supported.
Wine itself doesn’t need to do that, however. Emulating APIs (what Wine does) and CPU emulation are two different things. Dynamic x86 recompilation for ARM has already been done, iirc, for DOSbox. You could basically run Wine on top of such an emulator.
I’m not sure in which world you live in (though if I would have to guess I’d say a pretty geeky one), but in reality, that would most likely stop people using ARM altogether (where ‘people’ is the ordinary user, not the geek). OS developers are never ‘pushed’ by market demands, they are pushed by what they themselves find interesting (unless there’s company backup).
JAL
Well good! It would be counterproductive to the advancement of free software anyway.
I would to buy quite ordinary motherboard with new ARM
I’m waiting for that too! anyone listening? we want regular ARM motherboards in standardized form factors!
Currently you can get this micro-atx form factor motherboard with Cortex-A9 or ARM11MPCore, but it will cost you:
http://www.arm.com/products/DevTools/PB11MPCore.html
Can’t find pricing info. How much is it?
You guys seen the beagleboard?
http://beagleboard.org/
I nearly wet myself when I saw it. Perfect media pc hub.
My wife has reasoned with my though. For now…… 😉
There is also the sheevaplug .
http://www.marvell.com/products/embedded_processors/developer/kirkw…
But that lack all the video out stuff.
Computers are getting interesting again. Once freed from Windows, you freed from x86. 🙂
Yes, beagleboard is very nice thing – but if one doesn’t need it to be so small, “regular” ATX-board will be more comfortable, with some slots available, no need to buy special add-ons just to connect keyboard and mouse (or to have serial port available).
I would like just to replace Intel-based ATX-mobo with ARM-based one. Unfortunately, it seems, there’s a need for a (little?) patience.
Yer it depends what you want. I’m just gobsmacked someone hasn’t put the beagleboard in a nice case, added ethernet/wireless and soled it as a quiet, cheap, media pc.
As Linux and free software rises, x86 doesn’t matter so much, ARM will rise, but so will other architectures. Some competition at last. New architecture? No prob, just compile a Linux distro and all it’s repository and release. The more architectures supported, the easier the next architecture is to support. Makes for better software too because bugs show up that would other wise remain hidden.
Only down side is tuning to a architecture, but that kind of stuff can abstracted into a lib which can be tuned for the major architectures. Which we kind of have now with the different types of x86 anyway.
If everything is open, it can all be open to change, so your don’t have to let everything get gummed up with legacy (which is a good argument why there isn’t a stable kernel interface).
x86 is an ugly ugly architecture, which personally, I blame for people running away from assembler and how computers actually work!
I don’t know what came first, running away from assembler or creating applications in a non-instructionset-specific language like C.
Because not having to depend on the instruction set made a lot of things possible, euh… did not leave a lot of old code/programs behind on older long forgotten platforms. Well, most of your post already mentions reasons why this is good.
Languages like C came first. And I am very far from saying everything should be written in assembler. That would be crazy. But the ugly instruction set keeps people from digging down. It keeps them ignorant. You should have some idea how your code is compiling and if you don’t, then don’t bother learning C++ or your make a terrible mess. I’m not sure x86 is to blame for assembler being regarded as a dark dirty art, but I’m sure it doesn’t help.
I’d like to see the prices on these … especially 8 core units…
Very cool they now mention 8 core units. Previous documents only showed A9 scaling to 4 cores.
Also the addition of out of order execution with the A9 will help a lot.
ARM’s always said that Cortex-A9 could scale past 4 cores, just that there could only be 4 grouped together in one MPCore set. (Think how Intel’s first dual cores were, where they were two individual processors on the same package. An 8-core Cortex-A9 would be two separate 4-core Cortex-A9s on the same die.)
Oh please tell me I’ll be able to get a 2Ghz Quad-core RISC OS box sometime soon!
There was a time that would have excited me. But come on, RISC OS is dead. Any life is due to zombification by die hards.
But your be able to run RpcEmu at super speeds because it because just virtualization instead of emulation.
But, I’m a Linux man now. (Even if ALSA pees me off because it’s moving towards Windows rather than Plan9. Which is why no other *nix has adopted it. And don’t get me started on Pulse Audio (see http://www.chaoticmind.net/~hcb/murx/xaudio/). OSSv4 looks like what we should have had……)
I’m not terrible impressed with Pulseaudio either, but things seem to be improving. I’m kind of surprised they could stretch it that far.
I agree maybe OSSv4 should be adopted by the Linux-kernel. If only for compatibility reasons with other Unix-like operating systems.
ALSA is ignoring the lessons of Unix from the last 40 years. Keep it simple stupid. Everything is a file.
As Pulseaudio, don’t have a separate network connection for sound than video! That’s just asking for sync issues. The audio over X plugin is a great idea because both audio and video can go over the same ssh connect. Less code, less processing. Better still, it create a OSS file, so applications don’t even recompiling.
Heart breaking isn’t it.
Delivered this quarter? Isn’t TexasInstruments already shipping their version of OMAP4 based on Cortex-A9?
And to all those naysayers who said OpenSolaris on ARM was pointless because ARM was underpowered…ha! 😛
Does anyone know if it would be fruitful to run these things in high density processing applications?
Yep if ARM has a better heat/proformace ratio the it could well be considered for datacenters since that would be a major breakthrough
A very sizable portion of an x86 die is devoted to translating the x86 instructions into some other instruction set. Apparently ARM doesn’t need to do this (for now).
What I’d be interested in would be a reallife test. Let someone do “common” tasks for different user groups (e.g. office users have different tasks than programmers) and see how far they will get, how long it takes etc.
I really think that ARM is on the right track, the energy-saving track. E.g. looking at my AMD cpu, it runs 90% of the time at the lowest frequence (800 Mhz), saving a lot of power and ARM’s technology would most likely be even more efficient.
Now if only graphic vendors followed that track …
And yet it is probably still sucking more power than ARM at its highest power level
The upcoming Ubuntu 9.10 in real life tests has just achieved a five second boot time on systems with SSDs.
http://arstechnica.com/open-source/reviews/2009/09/ubuntu-910-alpha…
There is no reason why a dual-core 2GHz ARM CPU system with an SSD couldn’t do at least as well as that type of performance.
That has almost everything to do with the SSDs, and tweaking the init scripts, not so much the CPU. The real tasks to be concerned with are the likes of handling documents, browsing the web, etc.. They boast about theoretical potential, but we need to see some actual tests.
That said, even if it performs at 1/4 the Atom for real use, it will be compelling for netbooks, since you could have days of battery life, and/or netbooks well under 1lb, since RAM and display would be the dominant power hogs.