I got mine last week, and I've been using it as my main machine since then.
I put on a small Debian-based chroot and installed Guacamole[1]*, so I can use my favourite editor and X11 programs within a Chrome tab.
Compiling large C/C++ programs takes a while, but the Go compilers (what I mostly use) work really well. And I can always SSH into beefier machines (Linode/University) if I ever need to.
This replaced a Thinkpad which cost 5 times as much and broke in less than 13 months. So far I'm not missing the Thinkpad. (Well, maybe the 3 button TrackPoint)
Ugh. I read this and cry inside. Perfectly brilliant idea that I didn't even think of.
Why? I just purchased a new ultra book burdened by Windows 8 pre-installed. If I switch to the legacy BIOS the machine won't boot up, period. The only way to get the machine to work is through Windows 8. No installing Linux, no changing firmware, no nothing. Wonderful little box that's magnificently useless for systems level programming...
Can you quantify the differences in compile speeds between Go and C++ on the device? In particular, I'm interested in using Go to replace some of my scripts.
The comparison to the Intel D525 is really unfortunate, as that's a 2.5 year old, 45nm Pine Trail box with a 13W TDP. The low power 22nm Ivy Bridge cores are only 14W, so I'd really wanted to have seen a comparison to a more recent CPU.
The Exynos wipes the floor on the parallel NAS tests. I'm not sure why exactly.
The Atom core has known issues with floating point relative to desktop CPUs, and the A9 was never particularly good at it. So the FFTE results showing the A15 about 50% faster than Atom and 2x faster than A9 are a surprise. It's almost what I'd expect to see from a desktop box at that.
On the other hand, the 7-zip and x264 tests are integer dominated and largely cache-bound, and the A15 doesn't show itself off particularly well here, mostly matching the A9 and Atom per-clock. Yawn. (This is an area where all these CPUs get toasted by Ivy Bridge, btw -- remember that 14W TDP?)
The "Smallpt Global Illumination Renderer" and "C-Ray" tests (which I don't know anything about per se) shows everyone about the same (and for Smallpt 2x as fast as PandaBoard). So I'm going to guess this means the tests are DRAM-bound, and thus infer that the A15 has a similar memory bandwidth to Atom (probably 2x 32 bit vs. the Pine Trail 1x 64 bit channels). That's not great, honestly, as it's still about half of what you can get with a desktop part. But then DRAM refresh draws power, so may not have been an option for the Chromebook .
7-zip and x264 make almost perfect use of additional cores, so it makes sense that a quadcore beats a dualcore. (aside: I rather wish that Phoronix actually mentioned how much a given test benefits from multiple threads, single-threaded tests are presented next to multithreaded tests when comparing chips with different architectures and core counts without any comment or recognition.)
Additionally, x264 is heavily optimized for x86 and nowhere near as much for ARM. 7-zip is probably similar.
For floating point, A15 has double the execution resources as A9 (two symmetric floating point pipelines each capable of a FMA per cycle) so that's no surprise to me.
14W TDP is still too high, when a dual core A15 gets 4W at most. I doubt the IVB you're talking about is more than 3x faster than A15. Intel also has an advantage in process right now, and I'm not sure they will have it in the future. I think 14nm will be delayed, while others will catch-up to Intel on 14nm, and they might launch 14nm chips in the same time with Intel's 14nm chips, around 2015. We'll see.
What's with the only 6.5 hour battery life? I would buy it if it had >=9.
Edit: it's a serious question :) I am really wondering why the Nexus 10 has 9 hours and this 6.5?
Please Google, add a 3rd 'chromebook without chrome os' which is a Nexus 10 (Android but hopefully soon Ubuntu hacked) with a click-on keyboard (with battery) for $350. Thanks!
Given the same volume, a tablet has more space for batteries than a laptop. A laptop has to use space for the hinge, keyboard, trackpad, peripheral ports, and display. Worse, you can't fit batteries behind a laptop display without ruining the balance. On the other hand, a tablet is practically a screen with a ton of batteries behind it.
Here's some real-world data: The 3rd gen iPad has a 42 watt-hour battery. The 11" Air has a 35 watt-hour battery. The Air is 25% larger in one dimension and over 50% heavier, but it still can't fit the same amount of batteries as the iPad.
And of course tablets typically have slower processors, less memory, and less flash than laptops. Their lower specs mean tablets draw less power.
With so much going against them, I'm surprised that some laptops manage to come close to tablets in battery life.
It only has a 4,000 mAh (15 Whr) battery, smaller even than Nexus 7's 4,300 mAh battery, and considering it also has a much larger 12" screen (more than twice screen area), the battery life would also be smaller than Nexus 7.
Nexus 10 has a 9,000 mAh battery, which is also used to compensate for the 2560x1600 resolution. iPad 3/4 has 11,500 mAh and it's pushing 1 million fewer pixels for comparison's sake.
But I agree, Google needs to rectify this in next year's ARM Chromebook. They need to use a battery large enough to hold for 10h (and hopefully maintain, or lower the price). If they use this big.Little chip from Samsung next year, it might be easier to achieve that:
Coming in even or slightly faster (in most benchmarks) than an Intel Atom D525 from over two years ago is "crazy fast"? I'm impressed with the Chromebook overall and I think it's a cool product but talk about a bait-and-switch title.
I think people are reporting this relative to expectations rather than absolutely: they assumed it woudl be slower due to the lower cost and lower power consumption but the results defied that expectaion.
>All my development happens in ssh and firefox. So performance is not an issue.
Does that really bear out? I like the idea of a low-powered netbook connecting to a high-powered server for development, but in my (very limited) experience it's a pain.
I have two machines, and old laptop with an AMD RM-70 and a Thinkpad X41 with a Pentium M 1.6 Ghz.
On both machines, using Firefox is a painful experience because the performance is so bad. Using chrome is pretty good.
I've been thinking about buying a newer netbook with better battery life, but the performance of newer low-powered mobile CPUs doesn't seem that much greater than the systems I already have.
I think performance is still an issue. currently there are no gpu accelerated drivers if I understand correctly for non-chromeos linux, so until someone puts the effort into making that work.
I am also starting to consider this for development, but I need more assurance that it is a viable option.
Does everything mostly work out of the box, or would there be a lot of tinkering / troubleshooting required, e.g. because of the somewhat non-standard nature of running ubuntu on ARM architecture? What about drivers, e.g. for wifi and trackpad?
One of the reasons the Android emulator is slow, it's because it has to emulate an arm chip to x86 instructions. So if I'm running an arm pc as my main dev pc... Would the emulator run magically fast? Like unicorns, rainbows and such?
My guess is they would have to make a version of the SDK for ARM, and they haven't yet. But they may soon enough as these ARM chips get closer to PC-like performance, and more people buy ARM machines.
The emulator is qemu-based, and so is kvm. And, luckily the Cortex-A15 feature list has "hardware virtualization". And,
quick googling shows there's ARM virtualization support for linux. And, this has already been done for android/x86. So all the major bits and pieces are there.
I guess you meant "was slow." As of now, the Android emulator ships with an Intel Atom image that uses Intel HAXM tech for native execution (and is much faster than using the ARM image/emulator) on an x86 machine.
Isn't the entire point of the JVM: "write once, deploy everywhere" ???
Emulating the architecture makes sense from the standpoint that you want your development and 'production' (ie, the devices/handsets) to be the same ... but the Android emulator is INCREDIBLY slow. The juice is not worth the squeeze.
Have you checked out the Android-x86 project [1]? I remember, they were able to deliver some nice performance gains using an x86 emulator vs the ARM based emulators.
I should be able to figure this out for myself, but I will ask anyway: is 16GB SSD really enough to support Ubuntu and a development environment?
At a minimum, I would need Ruby+JRuby+Clojure+editors an an IDE. I could probably live with just 4 or 5 extra GBs for project files and whatever my current writing project is.
However, it looks like it has an SD card socket as well as a USB 3.0 slot. That means you could put a 32GB SD card in there and have plenty of room for projects. If that ounce is too important, you could probably get away with an Xubuntu distribution that's fairly stripped down.
Does anybody know how well the Mali drivers work on vanilla Linux (non-Android, non-Chrome Linux)?
As a longtime Linux guy, these ARM machines (and the similar tablets) are enticing. I'm finding conflicting reports on the drivers, though. It appears they were closed-source, that there is a project to reverse engineer them, and also I found a website (malideveloper.com) where they appear to have source code officially available...
I don't know much but it's a bit of a mess. You're right that there's a reverse engineering effort but it's against the 400 GPU, not the 704 in the Exynos. Samsung has been under quite a bit of pressure to open up the GPU code, and they've acquiesced to two binary blobs. See the Arndaleboard in ref below.
ARM have released code but it requires the full DDK which is not for general use. It's only available to partners.
BTW, in this link is a full linux Jelly Bean android repository. Except for the blobs, which are binary.
Only the kernel code is available on malideveloper.com though you can probably obtain binaries for the userland stuff (EGL, GLESv2) easily enough. ChromeOS is close enough to normal Linux (normal libc, etc) that it should be possible without too much hackery.
Say, for office users is open office the predominant office application suite used by these books, or to they virtual machine m$ office? I ask because i am currently a student
I wonder how much more performance can we squeeze off from compiler. Since x86 had the advantage from years of tuning. But if a Ivy Bridge of upcoming Haswell was throw into the chart i guess ARM as a performance solution still has a long long way to go.
[+] [-] saljam|13 years ago|reply
I put on a small Debian-based chroot and installed Guacamole[1]*, so I can use my favourite editor and X11 programs within a Chrome tab.
Compiling large C/C++ programs takes a while, but the Go compilers (what I mostly use) work really well. And I can always SSH into beefier machines (Linode/University) if I ever need to.
This replaced a Thinkpad which cost 5 times as much and broke in less than 13 months. So far I'm not missing the Thinkpad. (Well, maybe the 3 button TrackPoint)
[1] http://guac-dev.org
[+] [-] wheaties|13 years ago|reply
Why? I just purchased a new ultra book burdened by Windows 8 pre-installed. If I switch to the legacy BIOS the machine won't boot up, period. The only way to get the machine to work is through Windows 8. No installing Linux, no changing firmware, no nothing. Wonderful little box that's magnificently useless for systems level programming...
[+] [-] melling|13 years ago|reply
[+] [-] iso-8859-1|13 years ago|reply
[+] [-] ajross|13 years ago|reply
The comparison to the Intel D525 is really unfortunate, as that's a 2.5 year old, 45nm Pine Trail box with a 13W TDP. The low power 22nm Ivy Bridge cores are only 14W, so I'd really wanted to have seen a comparison to a more recent CPU.
The Exynos wipes the floor on the parallel NAS tests. I'm not sure why exactly.
The Atom core has known issues with floating point relative to desktop CPUs, and the A9 was never particularly good at it. So the FFTE results showing the A15 about 50% faster than Atom and 2x faster than A9 are a surprise. It's almost what I'd expect to see from a desktop box at that.
On the other hand, the 7-zip and x264 tests are integer dominated and largely cache-bound, and the A15 doesn't show itself off particularly well here, mostly matching the A9 and Atom per-clock. Yawn. (This is an area where all these CPUs get toasted by Ivy Bridge, btw -- remember that 14W TDP?)
The "Smallpt Global Illumination Renderer" and "C-Ray" tests (which I don't know anything about per se) shows everyone about the same (and for Smallpt 2x as fast as PandaBoard). So I'm going to guess this means the tests are DRAM-bound, and thus infer that the A15 has a similar memory bandwidth to Atom (probably 2x 32 bit vs. the Pine Trail 1x 64 bit channels). That's not great, honestly, as it's still about half of what you can get with a desktop part. But then DRAM refresh draws power, so may not have been an option for the Chromebook .
[+] [-] brigade|13 years ago|reply
Additionally, x264 is heavily optimized for x86 and nowhere near as much for ARM. 7-zip is probably similar.
For floating point, A15 has double the execution resources as A9 (two symmetric floating point pipelines each capable of a FMA per cycle) so that's no surprise to me.
[+] [-] mtgx|13 years ago|reply
[+] [-] tluyben2|13 years ago|reply
Edit: it's a serious question :) I am really wondering why the Nexus 10 has 9 hours and this 6.5?
Please Google, add a 3rd 'chromebook without chrome os' which is a Nexus 10 (Android but hopefully soon Ubuntu hacked) with a click-on keyboard (with battery) for $350. Thanks!
[+] [-] AngryParsley|13 years ago|reply
Here's some real-world data: The 3rd gen iPad has a 42 watt-hour battery. The 11" Air has a 35 watt-hour battery. The Air is 25% larger in one dimension and over 50% heavier, but it still can't fit the same amount of batteries as the iPad.
And of course tablets typically have slower processors, less memory, and less flash than laptops. Their lower specs mean tablets draw less power.
With so much going against them, I'm surprised that some laptops manage to come close to tablets in battery life.
[+] [-] mtgx|13 years ago|reply
Nexus 10 has a 9,000 mAh battery, which is also used to compensate for the 2560x1600 resolution. iPad 3/4 has 11,500 mAh and it's pushing 1 million fewer pixels for comparison's sake.
But I agree, Google needs to rectify this in next year's ARM Chromebook. They need to use a battery large enough to hold for 10h (and hopefully maintain, or lower the price). If they use this big.Little chip from Samsung next year, it might be easier to achieve that:
http://androidheadlines.com/2012/11/samsung-8-core-big-littl...
[+] [-] drivebyacct2|13 years ago|reply
I would weep.
I would love to pay someone to design a chasis and a bluetooth keyboard holder for the Nexus 10 (say on something like Shapeways).
[+] [-] ivany|13 years ago|reply
[+] [-] dspillett|13 years ago|reply
[+] [-] davedx|13 years ago|reply
[+] [-] itry|13 years ago|reply
Is the A15 my future development machine? All my development happens in ssh and firefox. So performance is not an issue.
[+] [-] gabemart|13 years ago|reply
Does that really bear out? I like the idea of a low-powered netbook connecting to a high-powered server for development, but in my (very limited) experience it's a pain.
I have two machines, and old laptop with an AMD RM-70 and a Thinkpad X41 with a Pentium M 1.6 Ghz.
On both machines, using Firefox is a painful experience because the performance is so bad. Using chrome is pretty good.
I've been thinking about buying a newer netbook with better battery life, but the performance of newer low-powered mobile CPUs doesn't seem that much greater than the systems I already have.
[+] [-] etherealG|13 years ago|reply
[+] [-] crayola|13 years ago|reply
[+] [-] vibrunazo|13 years ago|reply
[+] [-] mtgx|13 years ago|reply
[+] [-] zurn|13 years ago|reply
[+] [-] aviraldg|13 years ago|reply
[+] [-] whalesalad|13 years ago|reply
Emulating the architecture makes sense from the standpoint that you want your development and 'production' (ie, the devices/handsets) to be the same ... but the Android emulator is INCREDIBLY slow. The juice is not worth the squeeze.
[+] [-] IgorPartola|13 years ago|reply
[1] http://www.android-x86.org/
[+] [-] mark_l_watson|13 years ago|reply
At a minimum, I would need Ruby+JRuby+Clojure+editors an an IDE. I could probably live with just 4 or 5 extra GBs for project files and whatever my current writing project is.
[+] [-] ebiester|13 years ago|reply
[+] [-] autotravis|13 years ago|reply
[+] [-] kzrdude|13 years ago|reply
[+] [-] codesuela|13 years ago|reply
[+] [-] naner|13 years ago|reply
As a longtime Linux guy, these ARM machines (and the similar tablets) are enticing. I'm finding conflicting reports on the drivers, though. It appears they were closed-source, that there is a project to reverse engineer them, and also I found a website (malideveloper.com) where they appear to have source code officially available...
[+] [-] gregsq|13 years ago|reply
ARM have released code but it requires the full DDK which is not for general use. It's only available to partners.
BTW, in this link is a full linux Jelly Bean android repository. Except for the blobs, which are binary.
http://www.arndaleboard.org/wiki/index.php/Main_Page
[+] [-] randallu|13 years ago|reply
[+] [-] Too|13 years ago|reply
[+] [-] Symmetry|13 years ago|reply
[+] [-] potkor|13 years ago|reply
[+] [-] k_bx|13 years ago|reply
[+] [-] somid3|13 years ago|reply
[+] [-] ksec|13 years ago|reply
[+] [-] silentmars|13 years ago|reply
[+] [-] kindalu|13 years ago|reply
http://liliputing.com/2012/10/benchmarking-the-249-samsung-c...
[+] [-] muyuu|13 years ago|reply
[+] [-] gsnedders|13 years ago|reply
[+] [-] orik|13 years ago|reply
[+] [-] autotravis|13 years ago|reply