Linux – ny way to squeeze more performance out of a vintage Itronix GD8000 laptop PC

laptoplinux-mintperformanceruggedwindows 10

Shorter question:

I am attempting to use an Itronix GD8000 laptop with 4GB of its 8G RAM given to a Mint 17.2 guest OS under Windows 10 host for an open-source Django development environment, but performance on this kind of setup seems sluggish. What—if anything—can I do to squeeze some more performance out of this setup so I can better use it as a daily development environment.

Longer question:

Once I had gotten everything installed and in place for an Itronix GD8000 laptop with 4G of its 8G RAM given to a Mint 17.2 guest OS under Windows 10 host, I got to work and slowly acknowledged to myself how much my wonderful development environment was bogged down. It was bogged down enough to shift me from expecting to do open source software development on the back porch thanks to using a laptop, to staying inside on my desktop Mac setup.

I was trying to make minor changes to my JSX source for a Django application, and I was overlooking multi-second delays when swapping windows, as well as getting Vim to register keystrokes, and it consistently seemed a really long time to get webpages to load (served by the Django development server). Even taking into account that the hard drive is old and very slow, I don’t see why one should need 5+ seconds to alt+tab.

Now if the issue is virtualization, I may be able to get a little closer to Windows by running Cygwin; I also don’t know if there are some VMware Player vs. Workstation issues. But there were long stretches of my attempted migration from a MacBook Pro to an Itronix GD8000 where performance was easily an order of magnitude less than it should be. I would normally consider a possibility that it was constantly swapping, but there was no particularly great hard drive noise, the things I was doing shouldn’t have been demanding on any resources, and certain old things I remember for swapping weren’t there.

Years back on a Debian machine when I crossed the threshold into disk swapping, and switched into a workspace that placed me in swapping territory, the appearing or disappearing window was slowly painted or unpainted regarding the background, stripe by stripe, appearing or disappearing. This was as slow as swapping, but any effect was sudden after its delay. This included swapping between windows, getting a new browser window to load, getting a response from the editor in terms of a terminal window, and so on.

So all that said, what can I do—in software or hardware—so that my Itronix GD8000 will exhibit normal performance behavior in response to development activity that should not be particularly demanding?

  • Is there some sort of software tune-up I should be making?
  • Should I swap guest and host?
  • Are there ways to ask Windows 10 and Linux Mint 17.2 to be thriftier in resource use?
  • Should I try something I haven’t thought of yet?

I’m sure something would improve in my performance if I shelled out $1,000 for a 256G SSD, but that’s on a financial back burner.

Best Answer

Short Answer

It's your graphics processor. I know that sounds like a bold claim, but to me it's completely obvious, having dealt with similar problems on similarly ancient systems before. You can't upgrade your graphics processor, so you will need to "downgrade" your software so that it isn't using such graphically-intensive methods to render the desktop, both on the Windows (host) side, and the Linux (guest) side. The exact methods to do this are worth entire questions on their own, but I suggest you start with Googling "disable dwm Windows 10" and "disable compositing Linux Mint".

Long Answer

Terminology

  • GPU: Graphics Processing Unit. Basically, this is a special integrated circuit whose design is such that it is optimized to perform efficient operations on graphics data. The number of transistors and power required to perform most graphics calculations is lower for a GPU than a Central Processing Unit (CPU) because of the embarrassingly parallel design of graphics data, which is reflected in the design of GPUs by their having many, extremely simple processing cores. Your CPU may have 2 or 4 cores, but a GPU can have thousands of much simpler, less-capable cores, which can perform the same math on a lot of data at once in an extremely short time. This design differs from the CPU because the CPU is designed to perform lots of different types of operations (not necessarily all the same operation) on different data.

  • IGP: Integrated Graphics Processor. Sometimes abbreviated iGPU. Modern IGPs are built directly into the CPU package, and sometimes on the CPU die itself. Older ones are built into the motherboard and interface closely with the CPU. IGPs are slower than dGPUs of a similar generation, but they can be quite serviceable for running most contemporaneous software, except for games. Only very recently have the highest-end iGPUs started supporting dedicated Video RAM (VRAM), but even they depend primarily on System RAM for storing data. Older or lower-end iGPUs depend exclusively on System RAM.

  • dGPU: Discrete Graphics Processing Unit. These are different than IGPs because they have their own, dedicated PCI Express lanes, and are never built into the CPU. They may sometimes be soldered onto a motherboard, but in all cases a dGPU also has dedicated VRAM readily accessible, which is much faster than having the GPU depend on System RAM like an iGPU does.

  • OpenGL: A graphics Application Programming Interface (API) that has evolved over time to support new capabilities on GPUs as they have been very rapidly advancing in sophistication over the years. That's about all you need to know about it. In broad brush strokes, the OpenGL major versions 1, 2, 3, and 4 roughly delineate the various "industry generations" of progressively evolving GPUs, which were originally "fixed-function" devices that could only perform very specific operations, and are now (in the OpenGL 4.x era) fully programmable and capable of general-purpose computation (GPGPU).

  • WDDM: Windows Display Driver Model. A low-level graphics API and device driver framework by Microsoft that forms the low level of interface and hardware abstraction between graphics hardware and a Windows operating system (including in VMware guests, if the guest runs Windows). Extremely old GPUs are considered "pre-WDDM" because their hardware does not support the basic requirements for Windows to run a WDDM 1.0 device driver with that hardware underneath. Older GPUs support WDDM 1.0, 1.1, or 1.2, depending on just how old they are, while the latest GPUs on Windows 10 support WDDM 2.0. Newer versions of WDDM expose better performance across the board, better task scheduling (sharing of GPU resources across processes), and lower power consumption.

  • vmwgfx: A graphics architecture made available by VMware in their Player and Workstation products (for at least the past handful of releases), which exposes your physical GPU's capabilities to the guest operating system via the Direct Rendering Manager (DRM) and OpenGL (on Linux guests) or WDDM/OpenGL/Direct3D (on Windows guests).

  • EPT: Extended Page Tables. An instruction set addition to Intel processors starting with the Nehalem microarchitecture, which is the one immediately following the "Core" microarchitecture that your "Core 2 Duo" processor is using. You can recognize Nehalem parts with names like "Core i7 920" and similar. EPT improves Virtual Machine performance across the board by 50% - 100% (roughly) compared to running without it. VMware makes full use of EPT if it's available, but falls back to a slower method of memory management if not.

  • Compositing Window Manager: Also known as a compositor. A general term that refers to a component of modern desktop environments that uses the 3D graphics stack (which ultimately, one hopes, is backed by 3d graphics hardware such as a modern GPU) to perform basic rendering of the desktop graphical interface and everything on it. Compositing window managers have been around since the mid-2000s, but they became the default (and are sometimes always enabled, even if the GPU hardware drivers can't be initialized, by emulating the rendering (slowly) in software) somewhere around 2011, give or take a few years depending on the OS. Modern GNU/Linux desktops such as GNOME Shell always do compositing, even if it's on the CPU (also known as "in software", to distinguish it from "in (GPU) hardware".) To contrast, operating systems such as Red Hat Enterprise Linux 5.x and Windows XP did not use a compositing window manager by default.

The Raw Numbers - It's Slow, Jim!

First, click here to compared your graphics chipset, which is variously known as "945GM", "GM945" or "4500MHD", to the latest-generation, mid-grade Intel IGP and Nvidia dedicated GPU. Look at the numbers for the G3D benchmark, and then let that sink in for a while. The 4500MHD has a score of 5. F-i-v-e. Compare that to the Intel HD 5500, which has a score over 100 times higher. And the HD 5500 is, by today's standards, a pretty weak GPU.

Your Hardware and What It Can't Do

(based on what I could glean from the link to the review you showed me)

  • Your processor is a Core 2 Duo. This means the following statements are true:
    • Your CPU does not support EPT.
    • Since you're running a Core 2 Duo, that means your motherboard can only socket CPUs that are from before the Nehalem generation of CPUs. These CPUs are still reasonable on the CPU performance for simple development tasks like you described, but they're definitely not reasonable in terms of what their graphics can do. But you can't upgrade to a newer IGP because you can't slot in a newer processor. You could try swapping out the motherboard with a newer-generation one, but that is very unlikely to fit within the chassis and map cleanly to all the ports, connect to the display and keyboard, etc. Basically it's not worth the effort, and would be very expensive even if you pulled it off.
  • Your graphics chipset is an IGP called Intel GMA 4500MHD, which is both ancient and very slow even for its day. It can barely even be considered a 3d accelerator, and is slower for some operations than some of the first 3d accelerators that ever existed...! Now, IGPs are usually slow, but modern IGPs are much, much, much faster than this one.
  • You're running Windows 10 (a modern OS), with Mint 17.2 (another modern OS) in a virtual machine, on VMware. This means the following statements are true:
    • Your native Windows 10 environment might support WDDM 1.0 if you're lucky. Or it might even be in software fallback mode! It's worth looking, though, by running dxdiag and checking Device Manager. If you don't have any hardware accelerated graphics at all, expect a lot of pain, both on the native Windows side, and inside the guest. This is distinct from (and at a lower level than) Direct3D, so this isn't about gaming.
    • Your copy of VMware Player/Workstation is probably trying to use a virtual graphics driver called vmwgfx. However, vmwgfx only works well when you're using a modern graphics chipset (roughly speaking, from the past 4 years or so) that supports a lot of recent OpenGL features on the host side. I suspect you have very little, if any OpenGL support from your hardware on Windows 10, and even on an older OS like Vista you'd probably not be getting very good OpenGL support because this chipset is so old. Maybe OpenGL 2.1 or 3.1 at best. For reference, we're up to OpenGL 4.5.
    • Both Windows 10 and your Linux Mint guest are running some kind of compositor, simultaneously. Windows 10 does this through its Desktop Window Manager (dwm.exe) and Linux Mint through its compositing manager (which varies depending on how you've installed it and what desktop manager you're using). This works fine on a modern, capable GPU, but is likely to be killing your GPU in terms of the demands it's making on the hardware. OR, alternatively (and I'm not sure which case is true because I can't see inside your computer, and it'd require a lot of back and forth to tell you to run commands so I could find out), your Linux Mint install may not be using hardware acceleration at all, and is actually executing graphics draw commands that should normally be hardware-accelerated (via a compositing manager) in software, on the CPU. Now, if your CPU were a current-gen Core i7 4790K or similar, it would probably have enough horsepower to simply "crunch through" these graphics operations, and you'd barely notice, even if they ran entirely in software. But in your case, running a compositor in software is going to require exactly that sort of 5 second delay that you have been experiencing.

You may not actively perceive or realize it, but both Windows 10 and Linux Mint, out of the box, unless you configure them differently, are applying very subtle and not always noticeable graphics effects whenever you do even the simplest operations. For instance, text is anti-aliased; there are drop shadows on window borders; there are hardware-accelerated (or should be hardware-accelerated) animations for minimizing, maximizing and restoring windows and alt-tabbing; and so on and so forth. These graphics operations actually require a lot of computation to do accurately, and they can only be done efficiently on a modern GPU.

An Intel GMA 4500MHD is not a modern GPU, and it was very, very low-end even on the day that it was released to the market.

If you have no internal expansion slots such as a PCIe slot that you could put a discrete GPU into (and I'd be astonished if that were true), you're not going to get any faster or newer graphics chipset on this laptop, and you're just going to have to resign yourself to that fact.

So, what to do instead? Well, simple:

Don't run desktop environments that require access to a modern, advanced, hardware-accelerated graphics chipset for good performance. Basically, stop using desktops that run a compositor, or figure out how to disable the compositor(s).

Specifically:

  • On the host side, see if there's any way to turn off the Desktop Window Manager in Windows 10. I know it was possible up til Windows 7, but I don't know if that is supported anymore on Windows 8 or later.
  • On the guest side, install a desktop environment like Mate (a fork of Gnome 2, which can run fine without a compositor), or LXDE, and make sure the 3d-accelerated compositing is disabled. The method of disabling the compositing will be DE-specific, so you'll have to google it. It would depend on what window manager you're running, and whether the window manager depends on a separate compositing manager (e.g. compiz) or does its own compositing (e.g. KDE plasma or GNOME Shell). GNOME 3 and Cinnamon both ship out of the box with a compositing manager, and even if you don't have any 3d graphics support in the guest at all, it will fall back to a CPU-driven OpenGL renderer with no hardware acceleration at all.

It's also possible that you might not even be using vmwgfx in the guest because it's not installed, in which case simply compiling it and enabling it in the graphics stack (mesa, the Xorg DDX, et al.) might improve performance by allowing the compositing window manager to tap into your graphics hardware through VMware. Again, to determine that, I'd have to look more closely at your configuration. However, I believe (and someone can correct me on this if I'm wrong) that Linux Mint should ship the fully open source vmwgfx as part of its open source graphics stack, which means that if your VMware hypervisor could enable 3d acceleration from the host side (meaning: supported GPU, supported 3d stack on the host side, etc.), then you would have vmwgfx enabled in the guest.

But, with my experience using vwmgfx in a similar configuration on VMware Workstation 12 Pro (the latest release of VMware Workstation) on a Sandy Bridge processor (which is two generations newer than the one you have, and supports Extended Page Tables and a much more powerful IGP), I can tell you that even with vmwgfx fully functional and enabled, it's still quite slow on an IGP compared to "native" performance. Faster than 5 seconds waiting for alt-tab, but still markedly slower than working directly on the host.

Summary: Your hardware is old, in particular your graphics processing unit, which is an Intel IGP from about 2007. Windows 10 and Linux Mint 17.2 are both modern operating systems, whose desktop environments, out of the box, assume a much more capable graphics processor (in terms of feature-set, and performance) than you have in your computer. One of two things is happening: either it's trying to use your IGP and it's just too slow, or it can't even try to use your IGP because its feature-set is lacking (or due to bad software configuration), so it's falling back all of those heavy rendering tasks to the CPU, which is abysmally slow.

Unless you run an older desktop environment that doesn't depend on having modern 3d rendering capabilities, both on the host and guest side, you are not going to have acceptable performance. And the primary culprit is the graphics chip, not the CPU, RAM, or disk. 8 GB of RAM is actually more than sufficient, and allocating 4 GB of it to the guest is awesome. If you had that much RAM and a modern IGP from 2011 or newer, you'd have a great experience.

If all this talk about IGPs and vmwgfx confuses you, just remember this old adage: old hardware runs best on old software. If you can't avoid running old hardware, then you better be running old software on it. This is more true for GPUs than you can imagine, since GPU performance has about doubled year over year for the past decade or more (some years it increased even more rapidly than that, though in the last 2-3 years it's kinda slowed down).

Of course, you don't literally have to install Windows XP and an 8 year old Linux distribution in VMware to get acceptable performance. It should be possible on reasonably modern OSes to just tell it to disable all the accelerated graphics "effects" and compositing, which will greatly improve performance on an old GPU.

Related Question