A generous member of the wider curl community stepped up and donated an unused Mac mini m1 model to me to be used for curl development. Today it arrived at my home. An
8C CPU/16GB/1TB/8C GPU/1GbE model as per the sticker on the box.
Apple is not helping
Apple has shipped and used curl in their products for twenty years but they never assist, help or otherwise contribute to the development. They also don’t sponsor us in any way, like with hardware.
Yet, there are many curl users on the different Apple platforms and sometimes these users run into issues that are unique to those platforms and are challenging to address without direct access to such.
I decided to accept this gift as I believe it might help the project, but this is not a guarantee or promise that I will run around and become the mac support guy in the project. It will just allow me to sometimes get a better grip and ability to help out.
I will also offer other curl committers access to the machine in case of need. For development and debugging and whatnot. Talk to me about it.
A tiny speed comparison
My Intel-based development machine runs Linux, is ten years old and is equipped with an i7-3770K CPU at 3.5GHz. The source code is stored on an OCZ-VERTEX4 SSD on the Intel, the mac has SSD storage only.
Here’s a rough and not very scientific test of some of my most common build activities on the m1+macOS vs the old Intel+Linux machines. This is using the bleeding edge curl source code with roughly the same build config. Both used clang for compiling, a debug build.
|configure||19.8 s||18.5 s|
|make -sj||12.8 s||14.2 s|
|autoreconf -fi||7.9 s||12.8 s|
|make -sj (in ||19.1 s||33.9 s|
I expected the differences to be bigger.
The first line of curl -V for the two builds:
curl 7.87.1-DEV (aarch64-apple-darwin22.2.0) libcurl/7.87.1-DEV OpenSSL/3.0.7 zlib/1.2.11 brotli/1.0.9 zstd/1.5.2 c-ares/1.18.1 libidn2/2.3.4 libpsl/0.21.2 (+libicu/71.1) libssh2/1.10.0 nghttp2/1.51.0 libgsasl/2.2.0
curl 7.87.1-DEV (x86_64-pc-linux-gnu) libcurl/7.87.1-DEV OpenSSL/3.0.7 zlib/1.2.13 brotli/1.0.9 zstd/1.5.2 c-ares/1.17.0 libidn2/2.3.3 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.10.1_DEV nghttp2/1.50.0-DEV librtmp/2.3 libgsasl/2.2.0
Interestingly, there is no mention anywhere that I can find in the OS settings/config or in the box etc as to what CPU speed the m1 runs at.
This device was donated “to the cause” by “a member and supporter of the Network Time Foundation at nwtime.org” (real name withheld on request).
People mention that the Intel CPU uses much more power, runs at higher temperature and that the m1 is “just first generation” and all sorts of other excuses for the results presented above. Others insist that the Makefiles must be bad or that I’m not using the mac to its best advantage etc.
None of those excuses change the fact that my ten year old machine builds curl and related code at roughly the same speed as this m1 box while I expected it to be a more noticeable speed difference in the m1’s favor. Yes, it was probably bad expectations.
4 thoughts on “An m1 for curl”
Regarding CPU, it supposedly has 8 (4 – high-performance, 4 – high-efficiency) cores running at 3.2 GHz (high-performance) and 2.1 GHz (high-efficiency). Source Mactracker app.
The shiny case distracts you which leads to a 90% faster build time.
Here’s another data point on what the M1 has vs your Intel:
The maximum clock speeds for the M1 are 2064 MHz for the efficiency cores, and 3204 MHz for the performance cores. However, the run-time clock speeds of the CPU cores tend to vary quite a bit. If you want real-time details on that as well as the power usage, the `powermetrics` command provides extremely detailed information.
I’d typically expect a higher speed-up than what you’re observing, but this might be because the project is relatively small, so it ends up being more I/O than CPU bound. For a large project, the performance difference does end up being substantial, at least compared to those older Intel CPUs. That said, Intel has caught up with their 12th gen processors, at least when not considering power consumption.
Comments are closed.