First, why would I ever do this? My old laptop is many times better. I had some use for it, which I will explain in another article, but once I got the Acer Chromebook 311 11H, I decided to use it as a personal laptop for a short time just out of curiosity. I don’t think I will spoil anything if I say it was bad. But it surprisingly wasn’t bad at some things.
The specs
All components were somewhere between the cheapest and even cheaper:
- Mediatek MT8183 processor (a cheap ARM CPU for tablets, with 4 performance cores and 4 power efficient ones)
- 4 GB RAM
- 64 GB eMMC disk
- 11.6 inch HD LCD display
- ChromeOS
- WiFi 5
- USB-C with charging and DisplayPort support (but its GPU can’t render QHD or more)
- USB 2.0 port
- 3.5 mm jack
- 36 Wh battery (advertised battery life of 15 hours, seems to be closer to 13)
Its adverts seem to focus on battery life, good keyboard, ChromeOS’ simplicity of use and good WiFi and Bluetooth. Turned out the battery life was really great, it seemed to last for around 13 hours under regular use, with no effort to save power (no wonder when it has a tablet CPU). The keyboard was okay, but that was mainly because the laptop’s designers weren’t even trying to make it thin, leaving enough space for the keyboard. WiFi seemed about as fast as the WiFi of my other, far more expensive laptop (but downloads were bottlenecked by the CPU at about 7 MB/s). So, no lies there, only a little embellishment.
The overall power consumption was between 2 and 3 watts when idle, and could go up roughly to 7 watts when loaded.
The disk size seemed like the most limiting part. You have only 64 GB for everything, out of which around 51 GB is available to the user. Google Drive is seamlessly integrated into its file manager to compensate for it in some scenarios. I suppose it can be worked around by sticking a small USB flash drive into the USB 2.0 port and keeping it there permanently. Small ones that don’t reach much outside of the USB port and thus aren’t mechanically obstructive have capacities up to 256 GB. Of course, with the USB 2.0 port occupied, a Bluetooth mouse is necessary (or using only the touchpad, which is actually quite good).
The mechanical build
When I first held it in my hand, it felt like a toy. Light (weighs 1 kg), small, made of weak plastic that bends easily. The whole laptop isn’t thin, it has similar thickness than a Dell XPS 15. Hinges were okay, opening reveals a small display with wide margins, a keyboard of regular laptop size covering all of its width and multitouch touchpad.
The overall size allows it to fit into the tablet room of small bags, but it’s thicker than a tablet.
ChromeOS
ChromeOS is Google’s Linux distribution with its own desktop environment and its own application installer. Obviously, the Chrome browser is its integral part, but it has many other utility apps. It can also run Android apps from Play Store.
I expected it to be a platform designed for casual users similar to MacOS, with more focus on the browser. This was somewhat true, but it turned out to be more about simplification than thinking different. Its control was similar to Windows or Ubuntu, shortcuts were fairly usual, window buttons were as one expected them, mouse worked as expected. I was delighted to learn that it used the programmer keyboard layout, at least for Czech and Slovak. A few things were different but configurable, I could disable mouse acceleration, set focus to follow mouse, set functional buttons to work as F1-F10 buttons. The only thing I could not change was that Start button was moved to the place of Caps Lock and there was no button in its place, but I didn’t miss Caps Lock. On the other hand, its command line, called crosh, was completely basic (seemed mostly for diagnostics), nothing like Mac’s terminal. Just like Mac, it missed a physical Delete button.
I bought it with the idea of installing Ubuntu over the ChromeOS, but it turned out to be a problem. Booting from a USB stick requires patching BIOS, but it’s not an option on ARM Chromebooks. The method that gets the most search results is Crouton, but it’s unmaintained and doesn’t support newer versions of Linux distros. However, the team stopped maintaining it because Google has decided to add a setting to enable Linux, which installs a container named Crostini that runs Debian. It appears as a Terminal app, with fairly regular shortcuts and capabilities. Using apt allows installing Debian packages. Installed GUI apps are searchable as regular ChromeOS apps, with proper window decoration and a normal interaction. Any folders, including external devices, can be made available in /mnt/ by clicking on a share option in ChromeOS’ file manager (which felt similar to Windows Explorer overall). There are some drawbacks, the mounted folders are unchangeably owned by the main user with access rights 744 and the container doesn’t not start on startup and has to be manually launched.
After installing a lot of Linux apps in Crostini and using mostly just these apps, it felt like a normal Linux distro. The fact that I was mostly inside a container wasn’t very apparent, some might even argue that it’s good to containerise development away from documents. I also missed the few Ubuntu-specific goodies that weren’t on Debian, like the context menu in Nautilus to open a folder in Terminal. On the other hand, it suspended flawlessly, had a good multitouch touchpad with good support of gestures and a functioning palm rejection and swapped with a good strategy, which are things I am not used to seeing when using Linux.
Benchmarks
I was expecting the chromebook to be slow, but the question was, how slow. ChromeOS did a good job of loading stuff asynchronously to avoid UI freezes, though some mild frame drops did occur. The system compensated for its low RAM with swapping, but it manifested as stuttering rather than visible freezes.
Its slowness fully manifested when I started using Linux and saw how long were the usual operations taking. Installing apps and compilation were around 5 times slower than I was used to.
Naturally, my expectations are based on the performance of my main laptop, Dell XPS 15. It has a i7-9750H 6-core/12-thread processor with turboboost disabled (it could not sustain turboboost, ended up throttling and had less performance in the long run). So if don’t explicitly mention what am I comparing the Chromebook to, I am comparing it to this laptop.
So when I set up the usual development tools, I started running my own benchmarks (I didn’t bother running generic benchmarks that can be looked up, Geekbench says it’s 5 times slower both in singlethreaded and multithreaded mode, similar to Raspberry Pi 4). The benchmarks I was running have found that the results greatly depended on the application, with the Chromebook usually in the range between twice and ten times slower.
Because I like optimising code, I usually design code to have good memory locality (that is, group data in a way that allows it to stay in the processor cache together, reducing the number of high latency RAM roundtrips). In C++, this also greatly reduces the chance of making memory corruption errors. Code written this way was usually roughly twice slower on the Chromebook than on the laptop, sometimes even less.
It got worse for tasks including a lot of non-local accesses. Adding a few syscalls into the process (I think it spent most of the time in the syscalls) increased the difference a lot, it became 5 times or even 7 times slower.
One benchmark where I was positively surprised as that it could parse an HTTP request and write a response to it in 3 microseconds. Of course, I couldn’t process a million realistic requests per second on all threads combined because there was no encryption, the requests came in unrealistic 32 kB TCP packets and were simply asking for a small resource that was in memory.
I also run a stock browser-based benchmark with a multithreaded raytracing algorithm, mainly because I expected it to have bad memory locality (raytracing algorithms don’t have good memory locality). And it’s also easy to set up. The Chromebook achieved score 2107 (amount of computation done per time, in arbitrary units), my main laptop scored 20835. Because of the ease of setting it up, I benchmarked a lot of other devices as well. For whatever reasons, running the test in Firefox instead of WebKit-based browsers made the results far worse, the better the CPU, the greater the difference.
| CPU | WebKit | Firefox |
|---|---|---|
| MediaTek MT8183 | 2107 | 450 |
| Apple A-15 | 13331 | ? |
| Intel i7-9750H | 20835 | 1298 |
| Ryzen 7 2700X | 24240 | 1381 |
| Apple M1 (Ubuntu) | 19625 | 1801 |
| Apple M1 (MacOS) | 23218 | 2577 |
| Intel i7-1370P | 49089 | 1144 |
| Ryzen 7 7800X3D | 98173 | 2509 |
I will be speculating a little now. I interpret the results as the Chromebook’s CPU computing power per core is about a half of the laptop’s one. The clock frequencies are similar, so the improved vectorisation, out of order execution and speculative parallelism are already doing wonders. Much of the difference lies in CPU cache, both have 64 kB of L1 cache for each core, 256 kB of L2 cache for each core, but MT8183 has 2 MB of L3 cache shared between cores while i7-9750H has 12 MB of L3 cache shared between cores. The desktop CPU I tried to use for the raytracing has 64 kB of L1 cache, 1 MB of L2 cache and 96 MB of L3 cache, which is massively better. The iPhone approached the laptop’s performance at the raytracing task despite having only 2 performance cores because Apple’s CPUs have large caches and also contain the RAM as part of the chip. Running the raytracing in Firefox seemed to be bound on instructions rather than cache and followed similar ratios to tasks with good memory locality (maybe it was interpreting some code that WebKit could JIT).
I tried running SIMD operations on the Chromebook too. With 128 bit SIMD operations, it was about half as fast as the laptop. I was surprised that it supports also 256 bit SIMD operations, but they took twice as much time as the 128 bit ones (the laptop did 256 bit ones equally fast as the 128 bit ones). They didn’t really allow optimising anything, it seems like they are supported for compatibility with future binaries. For reference, Apple’s M3 processor supports only 128 bit SIMD.
Summary
There’s no way a laptop for 200€ could be good, but it’s surprisingly usable with the low specs it has. It doesn’t obstruct any activities as long they are not demanding on hardware. And its battery life is great. So if you need a laptop for some purpose that doesn’t require any hardware capacities or running any Windows-only software, you have an option that won’t cost you much.
It can be used for software development, as long as you don’t need any heavy libraries or frameworks. It’s possible to squeeze decent performance from it, but it requires writing the code and optimising it for memory locality, which often isn’t an option. Compilation will be slow, about five times slower than on a good laptop, and that is a factor that can’t be handwaved.