Just thought that I’d expand on my earlier findings. I’m still using the same method and project to test different hardware configurations, but the project has grown so compile times are quite different now, and the majority of the tests are disabled as the app is being rewritten at the moment.

Here’s the latest tests:

$5 DigitalOcean droplet - 1 vCPU & 1GB RAM
The single thread spent all of it’s compile time pinned at 98-100%. RAM usage was variable but stayed around 280MB.
Compile time: 2min 06sec
Test time: 3.6sec

$15 DigitalOcean droplet - 2 vCPU & 2GB RAM
Both threads varied between 50 - 95% during compilation. Rarely was a single thread pinned at 100%. RAM usage was the same as above.
Compile time: 1min 10sec
Test time: 1.2sec

$40 DigitalOcean droplet - 4 vCPU & 8GB RAM
All threads varied between 30-80%. Never pinned at 100%. RAM same as above.
Compile time: 1min 01sec
Test time: 1.1sec

$40 CPU-optimised DigitalOcean droplet - 2 dedicated vCPU & 4GB RAM
Both threads varied between 50 - 95% during compilation.
Compile time: 51sec
Test time: 0.8sec

$320 DigitalOcean droplet - 16 vCPU & 64GB RAM
Often threads were left unused, but sometimes all used at peaking at ~40%. Spikes to 60% on individual threads, but infrequent and short. RAM usage was slightly higher.
Compile time: 52sec
Test time: 0.9sec
!~ Interestingly one of my tests started failing from here on in. Issue with isolation when running tests in parallel most likely.

$320 CPU-optimised DigitalOcean droplet - 16 dedicated vCPU & 32GB RAM
Very similar to regular $320 server. Spikes were at 50% instead and RAM use climbed further to around ~650MB.
Compile time: 38sec
Test time: 0.6sec

c1.xlarge.x86 - Xeon E5-2640 (2x), 16 core (32 thread) at 2.6GHz & 128GB RAM, 1.6TB NVMe drive. $1300 p/m
Work spread across all cores, with single threads pinned at 100% for brief moments. Usually around 10-30%.
Compile time: 48sec
Test time: 0.9sec

t1.small.x86 - Atom C2550, 4 core @ 2.4GHz & 8GB RAM, 80GB SSD.
Huge variability in thread usage. Occasionally a single thread will be pinned at 100% whilst the other three are doing nothing. Only server to display this behaviour.
Compile time: 1min 54sec
Test time: 3.2sec

I had wanted to try out their Cavium server with 96 cores @ 2.0Ghz, but I found getting the project setup on the ARM version of Ubuntu quite tricky, and unfortunately I didn’t have the spare time to go configuring an environment I wasn’t going to use again. Given the relatively small changes in performance between 2 threads and 32, I don’t foresee 96 cores doing much for compilation but I imagine it would rock as the production server!

Reference: DO standard clock speed is 1.8GHz and 2.6GHz according to a blog post they made in 2018.

Conclusion: For remote development, I think DO’s $15 droplet hits the sweet spot. Spending a bit more on either of the $40 might be justified, but there’s very little time-savings thereafter. I think this probably carries through to local dev too, where the point of diminishing returns comes quite quickly. I think if I were using the full test suite I’d see more dramatic improvements in test time as threads increased.

For Elixir development I think you’re in pretty good standing as long as you’ve got more than one thread (surely that’s everyone these days) and clock speeds around 2.5GHz and above just to help with NodeJS compilation. It’s very impressive just how fast the core team have managed to make working with this language. Realistically, most local environments are going to be constrained by RAM more than their processor due to browser tabs, music playing, etc.

So in short, for all of you out there thinking that an iMac Pro or even the new Mac Pro is justifiable because of the time-savings you’ll see, I’m afraid it’s probably not. The reality is that unless you do something else like photo or video editing with your computer, we really don’t need powerful hardware. We’re more likely to find time savings in learning our tools (editors, linters, test suites, etc) better. Guess I’ll have to start taking more photos to justify my hardware-lusting!

@AstonJ and everyone else here:

I’ve written up a wiki about working from an iPad / on a remote server so that this thread can remain focussed on the hardware choices that help with Elixir performance.

Unfortunately I don’t have anywhere that a full on rack could live (noise, space, heat) in my current property, so it would have to be a tower. Given those benchmarks above, I’d be inclined to go for a Threadripper 2950X over the Xeons, but there is still the issue of Zen 2 making any purchases at the moment unwise.

I may have to do these. Coconut battery puts it at 81% of original capacity which isn’t bad, but it feels worse than that.

@peerreynders & @Exadra37 I really wanted to avoid this discussion becoming a Mac vs. Linux vs. X pissing contest like so many threads have before (including this one). I wanted to discuss hardware in quite broad (but also specific terms) and OS is a part of that. Yes, some of us agree and some of us disagree, but I’m sure that we can all agree that this great holy OS war is dull now.

We all use the tools we want to use. We don’t all need to be told we’re wrong, just because our priorities and preferences differ from yours.