for most intents and purposes

A Computer for Compilers

Intro

One of the cooler benefits offered by Efficient is a budget for buying your work machine, as opposed to everyone getting the same one. Not sure how long we'll keep doing this, but it does have pros and cons:

This post will primarily focus on that last con: knowing what kind of computer to buy or build for the job. In truth, I kinda fumbled when it came to choosing my work machine and am largely dissatisfied with it. I'd like to prevent others from making the same mistakes I did.

I won't focus too much on specific SKUs or products because the market changes every day and some new laptop or CPU is always dropping, so it would be quickly dated (the specs will probably also be dated in a few years but so it goes).

Where to Source Information

There are a lot of consumer electronics reviewers, but rarely do they go in-depth on programming workloads. I think this would be a phenomenal niche to fill, but I lack the time and disposable income. Someone else should definitely do it, though.

Some good sources I've found are:

Otherwise, general PC/laptop advice does apply to a dev machine: the more powerful the parts, the faster you can build code, run programs, etc. That said, the goal is to find the specs you need for your workload while not overspending.

My Machines

As a baseline and to help with further discussions, these are the two machines I use daily:

Personal Desktop: Custom Built PC

Specs:

I love this machine. Bought it first thing after graduation and have enjoyed every moment we've spent together. It's also in this really cute case. So good.

Work Laptop: 2025 Framework 13

Specs:

This is the machine I fumbled. I only optimized for the CPU and neglected RAM, which I'll get into later. The battery life and build quality also leave something to be desired. The screen is great, though: high resolution with an uncommon 3:2 aspect ratio that's nice for code. If it were up to me, I'd prefer a MacBook, but our compiler requires Linux at the moment.

This isn't an endorsement or recommendation for any of these specific products. It just gives us some concrete examples to refer to.

Selecting Form Factor

Laptop

If you:

Then it may be more advantageous to go with a laptop.

The tradeoff is performance for portability. You won't be able to lug a desktop around with you everywhere (although you might with the latest Mac Minis). Laptops offer the most flexibility because you can also dock them. Lots of companies also offer remote VMs or build clusters, so the laptop becomes more of a thin client. Expect to pay a price premium for the portability, though, especially as the machine gets more powerful. You're also limited to SKUs that companies offer, but with things like Framework you have a bit more influence over what goes in your laptop.

One thing to keep in mind: laptops have thermal and power constraints that desktops don't. A laptop CPU with the same core count as a desktop CPU will often clock lower under sustained load because there's only so much heat a thin chassis can dissipate. For short, bursty tasks this doesn't matter much, but for a 20-minute full build it can. Some laptops also solder their RAM, which means you're stuck with whatever you buy at the start. Check before you purchase.

Desktop

If you are:

Then you should consider getting a desktop.

In terms of price-to-performance, you cannot beat a custom desktop. You can source all the parts yourself and shop around for the best deals. Pre-builts are also viable, but you'll pay extra for the convenience and be limited to supported configs. The other big advantage is upgradeability: if RAM prices drop next year, you can just pop in more sticks. If a bigger NVMe comes out, you swap it in. With a laptop you're mostly locked in at the time of purchase.

Both?

This isn't as uncommon as it sounds. Plenty of people use a laptop for the office and meetings, then SSH into a beefier desktop at home for heavy builds. If your employer provides remote access to build machines or you have a personal desktop, a mid-range laptop paired with a powerful desktop can be the best of both worlds. You get portability when you need it and raw power when you don't.

At work, I shifted my main flow to using my laptop to SSH into our more powerful VM cluster. I want to try setting up my desktop as an SSH box as well.

Selecting Your Specs

This is probably the most challenging part of the process. There are a ton of products out there, each with their own laundry list of specs and terrible product line names. From my experience, the "big three" for a compiler development machine are CPU, RAM, and storage.

The CPU

CPUs can be tricky to buy. There are many different product lines, and variants within those lines with different features, that are generally hard to keep track of. I'll try to break this down into universal information you can use to pick a CPU that's right for you.

Cores vs Threads

Cores are physical processing units. Threads are logical execution contexts. Most modern CPUs support SMT (simultaneous multithreading): each core runs two threads at once, which is why you see specs like "16-core/32-thread." That second thread per core isn't a full 2x (more like 20-30% extra throughput), but for parallel workloads like compilation, it adds up.

For compiler work, core/thread count is king. Build systems like ninja and make -j parallelize across as many threads as you give them, so more threads = faster builds (up to the point where you run out of RAM). I'd say 12 cores/24 threads is a solid baseline, and 16+ cores is ideal if your budget allows.

Clock Speed

You'll see two numbers: a base clock (sustained frequency under load) and a boost clock (what the CPU hits on a few cores for short bursts). For compilation, sustained all-core performance matters more than single-core boost since you're using all your cores during a build. That said, single-threaded performance still matters for linking, which is often bottlenecked on one thread (unless you use a linker like mold, which parallelizes the linking step).

One thing to watch out for: don't compare GHz across brands. A 4.5GHz AMD chip and a 4.5GHz Intel chip can perform quite differently due to IPC (instructions per clock) differences. Use benchmarks instead.

Caches

CPUs have three levels of cache: L1 (smallest, fastest, per-core), L2 (mid-tier, per-core or shared), and L3 (largest, shared across cores). They exist because RAM is slow relative to the CPU, so frequently accessed data gets kept closer.

For compiler workloads, L3 cache matters the most. Compilers chew through large data structures (ASTs, IR graphs, symbol tables) that benefit from more cache. AMD's X3D chips (like the 7950X3D in my desktop) pack extra L3 via 3D V-Cache and do noticeably well on compilation benchmarks. If you're choosing between two similar CPUs and one has more L3, lean toward that one.

RAM

I think this is where you should (and probably will) spend the most of your budget. Compiling large codebases is extremely RAM-intensive. It's probably the case that the compiler you're using for your project is multithreaded, and each thread will have its own memory allocated for its tasks. In my personal projects, I've seen an individual clang++ thread take anywhere between 200-400MB of RAM while compiling LLVM from scratch. But the compiler is not the worst culprit! I've seen a single ld process use a few GBs of RAM on its own!

You should definitely not skimp on RAM. If you do, you won't be able to fully utilize all the powerful cores you spent your hard-earned money on. On my work machine, I can only use about 10 of the 24 available threads to compile large projects, or else the linking steps OOM the computer :(

So how much RAM do you need? I'd follow the general power-user advice of purchasing at least 2GB of RAM for every thread your CPU has. Concretely, if your CPU is 12-core/24-thread, you should purchase at least 48GB of RAM. Of course, more is always better.

I won't go into specifics about RAM configurations, DDR generations, ECC, or clock speeds. I find that these details are noticeable but not nearly as impactful as the amount itself. The general rule of thumb is: more expensive / higher number / more features = better. Look at your budget and assess how much you're willing to spend on the latest and greatest after doing some research.

One important thing to note: desktops and laptops typically use different form factors for RAM. If you're buying for a desktop, you want DIMM. If you're buying for a laptop, you want SO-DIMM. When in doubt, check the compatibility information for your motherboard or laptop.

Storage

This one is actually pretty easy. If this is a machine specifically for work (i.e., you won't be storing lots of unrelated media on it), I'd just go 1-2TB. My development setup is pretty light, so I opted for 1TB. You might use more tools, containers, IDEs, packages, etc. that require more. If that's the case, go bigger. Definitely go with an SSD. I don't think anyone should really be in the business of buying an HDD in the year of our lord 2026. If you can swing it, upgrade to an NVMe. You'll definitely notice the speed difference reading and writing files in your day-to-day.

Many people advise putting your OS partition on a separate drive from your working drive. It isn't strictly required, but it does prevent a single point of failure where corrupting your work drive borks your OS. Although if your OS drive fails, you're still SoL. I've personally only ever had an HDD fail, and have never had an issue with an SSD or NVMe drive.

Other Nice to Haves

A list of other features you might want in a computer for compiler dev:

Should I Care About the GPU?

Short answer: no.

More nuanced answer: if your work depends on it, yes.

If you're employed as a GPU-centric compiler engineer, I'd assume you have access to the GPUs you need through your employer. Use those.

If this is a personal machine, then you'd need to purchase a GPU for the platform you're targeting (NVIDIA/CUDA, AMD/ROCm, Apple/Metal). It's tricky to make specific recommendations because GPUs aren't actually involved in the compilation process itself; your choice depends on the performance needs of your application. Using CUDA as an example: if you just want to get your feet wet, do some casual experiments, generally low-powered stuff, just get a low-end RTX card like the 5050. If you need maximal power, consider one of their workstation GPUs. The main thing to look at when buying a GPU for compiler dev is the compatibility matrix for the software you're using. Continuing the NVIDIA example, they publish a list of CUDA versions along with the GPUs that support them. Consult a similar list for your platform of choice.

The OS Question

Choosing an OS is a personal decision that many people go to war over. Personally, I dislike them all for different reasons. I currently run Linux on both my personal and work machines. It's basically required at work because our compiler only supports Linux natively at the moment. I run Ubuntu at home because I got used to it at my last job and it's the most vanilla distro that supports Linux gaming (I have retired from the distro-hopping game).

So, does OS choice matter? Unfortunately, quite a bit. Your choice of OS directly impacts the tools, packages, and libraries available to you. For example, Windows has some of the best tooling for software development in my opinion (Visual Studio, RemedyBG, RAD Debugger, etc.). Linux is appallingly behind in this regard. On the flip side, if you're an LLVM developer, Linux is nice because you can easily swap out the compiler toolchain. Good luck wrestling with Apple-clang on macOS.

My quick (subjective) take on each:

macOS

If you're targeting macOS or Metal in any capacity, you just have to use a Mac. Otherwise, if you appreciate high-quality hardware and best-in-class battery life, it's also a solid option. Macs have a lot of good native apps and dev tools, and most libraries and packages are well-supported because Macs are some of the most commonly requested machines by developers. The Apple Silicon chips are genuinely impressive for the power-to-watt ratio, which matters if you're building on battery. They've also gotten more affordable with the latest M5 Neo and Air entries.

The main downsides for compiler work: you're stuck with Apple-clang unless you install your own toolchain, Xcode's debugger is a bit finicky, and if you need to test against Linux-specific behavior (glibc, ELF, etc.) you have to use a VM or container.

Windows

Windows is a decent choice. You get access to some of the best debugging and profiling tools out there, and WSL has matured a lot over the years. For a lot of compiler work, WSL2 is genuinely good enough that you can do your Linux development without dual-booting. The Visual Studio debugger and profiler are still unmatched for certain workflows.

The downsides: WSL still has some rough edges (filesystem performance across the Windows/Linux boundary, USB passthrough, etc.). And of course, hope you enjoy involuntary updates and ads on the computer you paid for.

Linux

Linux is much better than it used to be. It's easier to install and daily drive without too many issues. It's free. Easier to understand than the other two and offers the most customization. It's generally the default when it comes to package and toolchain support: you can install any version of GCC, Clang, or any other compiler with minimal friction. Most open-source projects assume Linux as the primary development platform, so you'll run into fewer "works on my machine" issues. It really stays out of your way.

But the tooling quality is rough. Debugging options are basically GDB and LLDB, both of which are command-line tools that haven't had a meaningful UX improvement in years. Profiling tools exist but are scattered and inconsistent. GUI-based dev tools on Linux are mostly Electron apps or ports that feel like afterthoughts. You can absolutely get work done, but you will miss the polish of Windows and macOS tooling at times.

At the end of the day, you can probably make any OS choice work. Choose one that you're comfortable and proficient with while still being able to do your job. If your employer mandates a specific OS for compatibility reasons, that makes the decision for you.

Some Proposed Configurations

These are not gospel. They're just configurations I would personally consider at different budget levels, based on everything above. Prices fluctuate constantly, so do your own shopping around.

My Ideal Dev Machine

This is the dream config. 48 threads with 128GB of RAM means you can ninja -j48 a full LLVM build and still have headroom for whatever else you've got running. Definitely overkill for most people, but if your workload genuinely demands it and the budget is there, this is what I'd go for.

Desktop (~$3,500-$5,000)

Laptop (~$2,500-$3,500)

Middle-end Dev Machine

This is the sweet spot for most people. You get enough threads to parallelize builds effectively, and 48-64GB of RAM keeps you well above the 2GB-per-thread guideline. If I could go back and redo my work machine, this is roughly what I'd aim for.

Desktop (~$1,500-$2,200)

Laptop (~$1,500-$2,000)

Low-end Dev Machine

Totally viable for compiler work, especially if you have access to remote build machines. You won't be doing full LLVM builds at max parallelism on 32GB of RAM, but for smaller projects or if you're just getting your feet wet, this gets the job done without emptying your wallet.

Desktop (~$800-$1,200)

Laptop (~$900-$1,300)

Conclusion

I love this stuff. I love researching parts, reading reviews, watching videos for products I have zero intention of buying. But I understand that big purchases, especially ones with this many variables, can be daunting. Hopefully some of the advice here makes your process less stressful. Some closing remarks:

#compilers #devtools #hardware