[Updated, June 14, 2018]
I finally decided to replace my almost-a-decade-old laptop with a Dell Inspiron 5370. I’ll be using this post to keep running notes of my impressions of the machine and the issues that come up when running Linux on it.
The laptop has a 8th-generation quad-core i5-8250U processor, 8 GB DDR4-2400 RAM (expandable to 32 GB), 256 GB SATA SSD and a full-HD IPS screen. There is a fingerprint sensor and a Type-C port that supports the DisplayPort standard. It weighs around 1.4 kg.
The laptop is light and sleek, designed in the general metallic ultraportable style. The outer shell is aluminium but the inner surfaces are plastic.
Keyboard and touchpad
The keyboard is a backlit, chiclet-style keyboard which is comfortable to type on. However, you cannot rest your hands on the laptop for long while typing since the front edge is sharp enough to bite uncomfortably into your wrists if you do so.
The touchpad has a roughened surface. It is multitouch enabled. At least on Linux, while one and two-finger actions work perfectly, three- and four-finger gestures are sometimes recognized and sometimes not.
Both the keyboard and the touchpad have a little bit of mechanical give that you would not find on, say, a Macbook.
The display is sharp and has good viewing angles.
It is a matte display. Which has its good and bad parts. Reflections are not a problem at all. A light fixture right opposite my table which would bother me no end with my old laptop does not throw any visible reflection on this machine’s display.
But perhaps because of the anti-reflective treatment the contrast is low even at maximum brightness. Also, the color balance is towards the warm side. Being used to reflective bluish displays, whites on this screen look somewhat muddy to me. I’m sure part of this is a matter of habit. But I wish Dell had made the display a little brighter.
In going from the 7th to the 8th generation Intel doubled the number of cores for its mobile processors. Each 8th generation core has however more or less the same architecture as its 7th generation counterpart, thus carrying out about the same amount of computing per clock cycle. Thus doubling the number of cores would double computing power only if the processor frequency does not change.
However for modern CPUs the processor frequency is not a constant but changes according to the CPU’s operating conditions. Intel quotes a base frequency at which the heat generated by the processor will stay withing its advertised Thermal Design Power (TDP). Given the additional heat generated by twice the number of cores, the base frequency of the 8250U has come down to 1.6 GHz from the 2.5 GHz base frequency of its predecessor, the 7200U.
However, if sufficient power and cooling are available the CPU can ramp up its frequency, a technology called Turbo Boost by Intel. For the 8250U the top frequency is 3.4 Ghz, more than double the base frequency.
So hypothetically there is a factor of two performance gap possible between two systems with the same processor depending on cooling and power supply. So system design matters, particularly for the ultraportable form factor.
To see how the CPU runs under full load on the Inspiron 5370, I ran the benchmarks bundled with Intel’s Math Kernel Library. For the High Performance Linpack benchmark which measures floating-point performance the machine can achieve a steady performance of around 100 GFLOPS/s (for double precision, using four threads).
When running the Linpack benchmark the CPU frequency climbs to around 3 GHz for twenty odd seconds (from a cold start), but then throttles back and levels off at a frequency of around 2 GHz. This happens at a CPU temperature of around 60°C even though the maximum temperature for this processor 100°C so it is some other component which turns out to be the limiting factor.
While one would have wanted the 3 GHz speeds to go on forever, at the end of the day the processor performance is pretty good. 100 GFLOPS/s would have earned this machine a place among the top 100 supercomputers of the world in the late 90s. In real world usage, doing moderate data analysis and numeric work, I hardly ever have to noticeably wait for the machine to respond. Most workloads are not going to be as well-parallelisable, vectorisable and floating-point heavy as the Linpack benchmark, and would therefore give the system more headroom to sustain higher frequencies for longer.
HPCG and STREAM
With the gap between processor speeds and memory speeds widening, the performance of many real-world workloads depends on how fast data can be moved to and from memory. Intel MKL provides a tuned implementation of the High Performance Conjugate Gradient benchmark which stresses both floating-point performance and memory bandwidth. On this machine we get around 3 GFLOP/s for this benchmark.
The STREAM memory benchmark achieves a sustained memory bandwidth of around 12 GB/s when runnning four threads.
This is quite lower than the numbers of around 20 GB/s I have seen for the Dell XPS 13 and Acer Swift 3 which use the same processor. This is possibly because the memory on those machines is in a dual-channel configuration while the Inspiron 5370 in the configuration I bought has a single 8 GB memory module.
Building LLVM: RAM is a bottleneck
As an example of a demanding real-world task I built LLVM from scratch with all options (Clang, lld, and various tools and libraries).
The laptop does this in 48 minutes.
However, it took me two days to actually find the right way to get the job done.
The reason is that the compilation of LLVM goes through two phases. In the initial part of the build small files are compiled with the compilation of each requiring small amounts of RAM. We want to run as many of these small compiles in parallel as possible. On the other hand, in the later part of the build the files are linked together into libraries and executables. Each of these link commands needs multiple GBs of RAM and runnning many of them in parallel leads to the system getting stuck swapping. We must limit the amount of parallelism here.
The build system provides no direct way to separate out these two phases.
The recipe which finally worked for me is this.
cmake -G Ninja \ -DLLVM_PARALLEL_COMPILE_JOBS=6 \ -DLLVM_PARALLEL_LINK_JOBS=1 \ -DLLVM_ENABLE_LLD=ON \ -DCMAKE_C_COMPILER=clang \ -DCMAKE_CXX_COMPILER=clang++ \ ../llvm ninja -l8
The values of the
LLVM_PARALLEL_LINK_JOBS variables ensure that while upto 6 compile jobs can be launched in parallel, only one RAM-hungry link job is run at any time. The other variables specify that the
clang compiler and
lld linker (both installed from the standard Debian repository) be used for the compile. Finally the
-l8 option tells the Ninja build tool to stop lauching new jobs if the system load average goes above 8.
This experience of compiling LLVM brings out an important fact about the processor/memory balance of this laptop. Counting hyperthreading the processor supports 8 parallel threads. But if each of these threads were to run an independent task, as happens when compiling LLVM, each thread gets only 1 GB of RAM. When this turns out to be too little for the task at hand, the amount of RAM becomes a bottleneck on the parallelism that can be achieved.
By the way, the LLVM debug compile generates 55 GB of build products. So if you plan to work on large software projects, the SSD capacity may also turn out to be a bottleneck.
Here are the results of running Geekbench on my machine.
To contrast, here are the results from a XPS 13 9360 which has only marginally better scores on the single-core benchmarks (XPS: 4264, Inspiron: 4243) but does noticeably better on the multi-core benchmark (XPS: 14868, Inspiron: 13584) very likely due to the higher memory bandwidth.
The SSD is a Hynix SC311. This is a SATA rather than a PCIe SSD. Casual measurement with
dd gives read speeds of around 460 MB/s and write speeds of 400 MB/s.
Apart from faster booting, there are two places where I have already found the SSD making a big differnce.
One is typessetting documents with LaTeX. For documents of a couple of pages typesetting is practically instantaneous. This takes away a big friction from my workday.
The other is situations where some program uses up all physical RAM, goes into swap and the system locks up thrashing. With Linux and a HDD I could never recover from this situation and would have to reboot. With SSD I had the pleasant experience of taking a long play break with my daughter and coming back to find my task done and my machine usable again.
The battery is rated at 32WHr. At maximum brightness with a few browser tabs open the power draw is around 6W. Turning the brightness to half reduces this by 1W. Installing TLP reduces it by a further 1W to around 4W.
At the other end, Linpack at its peak uses around 23W.
Consistent with the above numbers I got a battery time of around 4 hours on my usual mix of work with the screen at maximum brightness and TLP not installed.
I finally choose to not to install TLP. Even with TLP I would not be able to take the machine to work without carrying a charger. And four hours is more than sufficient to cover my commute. So it seemed safer to not have something like TLP which touches setting all across the system.
Linux hardware support
I installed Debian Stable on the system but then updated it to Testing (currently Buster) with a 4.14 kernel.
The Wi-Fi module is an Atheros QCA9377 that requires non-free firmware (provided by the package
firmware-atheros) to be installed. Once this is done Wi-Fi works.
I’ve not tried setting up the fingerprint sensor.
Suspend to RAM and hibernate work.
Connecting an external display over the USB-C port (using an Amazon Basics USB-C to VGA adapter) works out of the box.
Everying else works perfectly as well.
Linux setup tips
Currently the Debian installer cannot run under Secure Boot. Disable it in the BIOS before beginning installation.
firmware-atheros needs to be installed for the Wi-Fi to work.
Swap and limiting runaway memory use
The Debian installer’s automatic partitioning creates a swap as large as RAM to allow suspend to disk.
The downside is that a runaway process can grow to 16 GB of memory use and lock up the system because of swapping before it is killed by the OS. I have chosen to protect against this by limiting the address space that any single user process can use to 8 GB. To do this, edit the file
/etc/systemd/user.conf to uncomment the line with
DefaultLimitAS and set it to
Here the 8G is the ‘soft limit’ on address space that any process will have as a default and infinity is the ‘hard limit’ to which processes can raise the bound. This way if there is a process which actually needs a larger address space, it can be accomodated by temporarily raising the limit by, say, the
ulimit command in Bash.
With the display running at its native resolution fonts are too small. By default GNOME allows the screen to be scaled only in integer multiples and scaling by 2 leaves too little space on this screen. Recently GNOME has added experimental support for fractional screen scaling but when I tried it the fonts were fuzzy in many applications including Emacs. For now I have settled for the following compromise. I’ve installed
gnome-tweaks and used it to set font scaling to 1.7. In Firefox configuration (available by vising
about:config in the URL bar) I’ve set
layout.css.devPixelsPerPx to 1.5. This gives reasonably sized fonts in most places, though icons still remain small.
gnome-tweaks can also be used to turn on tap-to-click on the touchpad.
libinput driver used for the touchpad by default does not give a right click, mapping all single-finger clicks to the primary mouse button. Instead, two-finger clicks are mapped to right-clicks and three-finger clicks are mapped to middle-clicks. It is possible to change that, but I found the current setting fine.
I had been waiting long for a laptop with adequate SSD storage and a FHD IPS screen that does not cost an arm and a leg. Now in 2018 such machines are finally becoming available. And despite a somewhat short battery life and dull screen, mine is still a great pleasure to use.