Shifting Apps To ARM Chips Could Save Laptop Batteries 326
An anonymous reader writes "When is an Intel PC not an Intel PC? When it moves applications such as Internet browsing and email on to an ARM processor because it can get longer battery life. And according to a story at EE Times, this hybrid Intel-ARM processor approach is being taken by PC makers as prominent as Dell. The problem for Intel: Why would you switch out of 'all-day' mode and use the Intel processor? The problem for ARM: lacking support from Microsoft for Windows; the applications it runs for the PC have to do so under Linux."
Re:Good but.. (Score:5, Informative)
Re:Not a problem (Score:5, Informative)
WINE is just Win32 for POSIXy platforms. It's not able to rewrite x86 binary for ARM. You could perhaps take Windows software compiled for an ARM processor and run it, but that kind of defeats the point of using Linux for portability in the first place. KVM/Xen also do not rewrite binary for other architectures. QEMU could do it, but performance and battery life would drop dramatically.
Re:Good but.. (Score:5, Informative)
Then put your name down for one of these [engadget.com].
ARM licensed Java from Sun years ago, and include hardware acceleration for Java apps via Jazelle. In addition, Adobe have said they will have a version Flash 10 for ARM sometime this year. So get your wallet out.
At $199, these netbooks won't cost you and arm and a leg...
Re:Apple / BSD (Score:4, Informative)
Re:Good but.. (Score:2, Informative)
Java works on ARM, kind of. Sun and ARM both seem to want to charge for ARM-based Java implementations.
Sun's KVM (used on many phones, can only handle J2ME, very slow) is proprietary, and only available for large-scale embedded use. Some ARM CPUs can actually execute Java bytecode directly, but they won't disclose any information about how to actually write a JVM that uses it. JVMs that use this feature cost an arm and a leg. Sun had a full J2SE JVM for ARM at some point, but again it was targetted at embedded developers, and the only reference I could find was for an evaluation version.
The icedtea VM apparently made some progress towards a CPU-independent version (the zero assembly port). Not as fast as a native port, but at least it should work. Since everything else is open source, you could at least get a fully working (if a bit slow) JVM running on ARM Linux.
I don't know about JavaFX though.
Mono supports ARM. It even has a working JIT. So a Moonlight port isn't out of the question. I guess you could probably even use IKVM to run Java on ARM Linux, but I doubt that'd get you JavaFX either. It doesn't even get you a working version of AWT or Swing.
Shame about Flash though. That's not likely to ever be available on ARM Linux.
Re:Options (Score:3, Informative)
Of the operating systems I've used and administrated (Windows, Linux, FreeBSD, MacOS), I've had to spend more time administrating Linux than the others (FreeBSD might take more administration time, but short of mergebastard 'administrating' it involves me typing a make or portupgrade command, and leaving it along for a couple hours, or at least not performing a relatively small set of tasks).
Starting in 02 or whenever I first tried it, I had to deal with the usual dependency hell. I found out about yum later, but it didn't fix the issues.
I moved from Fedora to Ubuntu as some people suggested. Performance on the two machines I used was lackluster (6.x and 7.x versions) compared to Windows and FreeBSD. It managed to prevent X from starting after a recommended update of KDE. I had a few other issues with the updater breaking itself or other apps, and gave up after a week or two each time (no other OS took that much time to get functional - I have limited patience). Also it usually crashed on shutdown. Not a big deal, but EXT2/EXT3 takes forever to check. It also crashed when I tried to play Boson.
I then tried Gentoo. It worked mostly well, but I couldn't get open office installed, an app I really needed. So eventually, after some effort in that area, I gave up.
Recently I went to try Arch. After installing and then installing X, it no longer wanted to boot from my HDD (SATA), it complained about not being able to start/initialize/mount (forgot the proper term) the root partition. It suggested I add rootdelay=8 to the kernel params in Grub. I did, and it didn't fix the issue, I tried rootdelay=30, but still no fix.
I went to KUbuntu, the installer froze on me each time I tried to install (same spot each time, right after accepting the choice for the default keyboard).
XUbuntu was next, XFCE is ok too. It installs, but it won't boot, with the same issue as Arch-Linux.
Typically, each time, I spend a few days working on the issue, and if I can't find the resources to get it solved, I give up for a while, and go back to other OSes that suit my purposes sufficiently, namely Windows and FreeBSD. I'd like to give Linux a good shot, and use it - it's got better hardware support than FreeBSD, and a few apps that aren't properly ported that I'd like. As for Windows, it's not had any issues short of bad hardware, since Win2000 (note: Linux and FreeBSD refused to use the bad hardware, I guess they were smarter than windows on that machine).
Re:Not a problem (Score:4, Informative)
yep, Pandora fills this niche. 0.3kg, ARM, 10h battery, runs ubuntu just normally. But it's very small, only a 4.3" screen 800x480. About the size of DS. http://openpandora.org/ [openpandora.org]
It's just a startup now, people did preorders (by preordering it means that you are trusting them ;) and it will be delivered about March or April. I expect that by the end of the year they will be selling it in online shops in a usual way.
It's a perfect UMPC for me, a really "mobile" PC, smaller than my wallet, actually.
ARM Cortex A8 netbooks Real Soon Now (Score:3, Informative)
Freescale and Pegatron showed a prototype at CES:
http://jkkmobile.blogspot.com/2009/01/meet-pegatron-199-arm-based-netbook.html [blogspot.com]
Re:I like it (Score:2, Informative)
The trouble with most modern laptops, is that even when completely unattended, doing no work that the user expects any results of anytime, just by being 'on', these seldom consume below 5 Watts of power, and in their factory config about usually 15 (nobody bothers with configuring power management). I am talking about a laptop that is lid-closed, radios (wifi, bluetooth) off, not doing ANYTHING for you.
Re:Does it matter still ? (Score:2, Informative)
Are you sure? Have you compared a 33Mhz ARM to a 33Mhz x86 chip? Is the performance that different?
Clock frequency is a horrible comparison statistic. Note that AMD chips for years have had similar performance with increased clock cycle lengths. It's not so much about MHz, it's about what you actually get done during that cycle.
There is no way to do an apples-to-apples comparison here, because I don't think anyone makes x86 chips that are as slow as ARM chips. The instruction set doesn't have that much bearing on performance.
I don't want to be rude, but you're obviously just an arm-chair commentator on the subject. While it's true, the fastest ARM based processor doesn't run any faster than 1 GHz (Cortex based ARMs, or the ARM being used in Qualcomm's SnapDragon platform) you can make direct comparisons against Intel's Atom processors, which do run at those frequencies. The power comparison is bad for Intel, very bad. Especially when you consider how much power the ancillary hardware required for Atom uses. I'm not saying that MIPS/W is a great benchmark either, but it makes a lot of sense in small devices.
Instruction set makes a huge difference on performance. Otherwise, we'd still be using CISC instruction sets. Heck, even Intel converts CISC x86 instructions to RISC versions under the hood. This has a huge impact on power. ARM has conditional execution of just about every instruction, reducing the need for branching. This has two main benefits: less required additional hardware (branch predictors, speculative execution) to deal with a potential pipeline stall (and Intel's pipelines are very long) which saves considerable power.
But power use goes up according to the square of the voltage, and voltage increases when clock speed increases -- so it is all about the megahertz.
You're forgetting something that comes with that power equation that you're using. You're assuming that both processor have similar effective resistance. It's a poor assumption to make, and only works when you're taking the same processor and increasing the clock frequency.
In any case, what I'm trying to impress upon you is that instruction set matters (and x86 has been both a blessing and a curse to Intel over the years), and that clock speed isn't a good measure of performance or power consumption.
Re:The CPU is not the biggest consumer (Score:2, Informative)
I am afraid I do not completely agree with you. I do not deny that the screen is the main source of energy consumption in a laptop but I claim that the energy consumption of the processor should not be diminish. Consider the following log obtained on my Intel dual core laptop:
root@mandan:~# acpi
Battery 0: Discharging, 98%, 00:04:22 remaining
root@mandan:~# cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Veuillez rapportez les erreurs et les bogues à linux@brodo.de, s'il vous plait.
analyse du CPU 0 :
pilote : acpi-cpufreq
CPUs qui doivent changer de fréquences en mÃme temps : 0
limitation matérielle : 1000 MHz - 1.83 GHz
plage de fréquence : 1.83 GHz, 1.33 GHz, 1000 MHz
régulateurs disponibles : userspace, powersave, ondemand, conservative, performance
tactique actuelle : la fréquence doit Ãtre comprise entre 1000 MHz et 1.83 GHz.
Le régulateur "userspace" est libre de choisir la vitesse
dans cette plage de fréquences.
la fréquence actuelle de ce CPU est 1000 MHz (vérifié par un appel direct du matériel).
analyse du CPU 1 :
pilote : acpi-cpufreq
CPUs qui doivent changer de fréquences en mÃme temps : 1
limitation matérielle : 1000 MHz - 1.83 GHz
plage de fréquence : 1.83 GHz, 1.33 GHz, 1000 MHz
régulateurs disponibles : userspace, powersave, ondemand, conservative, performance
tactique actuelle : la fréquence doit Ãtre comprise entre 1000 MHz et 1.83 GHz.
Le régulateur "userspace" est libre de choisir la vitesse
dans cette plage de fréquences.
la fréquence actuelle de ce CPU est 1000 MHz (vérifié par un appel direct du matériel).
root@mandan:~# acpi
Battery 0: Discharging, 98%, 00:04:23 remaining
root@mandan:~# cpufreq-set -c 0 -f 1.83GHz
root@mandan:~# cpufreq-set -c 1 -f 1.83GHz
root@mandan:~# sleep 20
root@mandan:~# acpi
Battery 0: Discharging, 97%, 00:03:22 remaining
root@mandan:~# cpufreq-set -c 1 -f 1.00GHz
root@mandan:~# cpufreq-set -c 0 -f 1.00GHz
root@mandan:~# sleep 20
root@mandan:~# acpi
Battery 0: Discharging, 97%, 00:04:19 remaining
Setting the CPU frequency to the highest speed reduces the battery life from 4 hour 20 to 3 hour 20, which is 22% less. My point is that CPU energy consumption should not be neglected. Of course, my processor is not the most energy efficient one and using acpi is a very simple test. But if I can use an extra processor instead of changing the CPU frequency, we could be able to cut some part of the energy consumption.
Moreover, the energy efficient processor are known to have low computation power. Adding heterogeneity by adding a processor could cover the gap.
Darwine already does this (Score:5, Informative)
WINE is just Win32 for POSIXy platforms. It's not able to rewrite x86 binary for ARM.
Indeed, *wine* doesn't do it itself. But nothing prevents you from running a separate layer to do the translation.
QEMU has a Linux-on-Linux mode, where it doesn't emulate a full blown virtual PC, it only runs the application targeting a foreign architectures inside the emulator and passes along the calls to the actual native OS and libraries.
Darwine has been doing exactly this to run x86 Win32 application on PPC Mac OS X using a combination of Wine and QEMU. It should be possible to build a similar stack to run x86 Win32 application on ARM Linux.
But don't expect much performance from it on an ARM netbook. It will probably OK to run a couple of simple tools. It won't probably work with games or other more resource intensive application.
But gamers aren't the machine's main audience anyway, the ARM netbooks are targetted at people who just want Web, Email & Chat, with the longest possible battery life.
Although, you probably could get better Win32 performance (at the cost of battery life) with dual-chip machine (like DELL Lattitude ON) or using accelerator boards if the ARM netbooks has some standard connector (like Xpress card).
Re:Does it matter still ? (Score:3, Informative)
Unfortunately this translator takes up most of the power and silicon real estate on the chip.
That is false. It actually takes up a few percentage points of power and silicon real estate. If it took up most of the power and silicon real estate, then they would not do it.
The Pentium Pro was the first Intel chip to have a translator, and to run RISC instructions internally. At the time, several techie magazines (Byte?) had articles on the architecture. Intel claimed something like 5% overhead from doing that. They even posited that they might be able to create a Pentium that could run any arbitrary instruction set, just by modifying the microcode in that 5%.
Since that time, all Intel chips (and most clones) include such a translator because it is so effective.