Threadripper 3990X: The Quest To Compile 1B Lines Of C++ On 64 Cores

Fun experiment.<p>The more pedestrian 5950X or the now bargain 3950X are great for anyone doing a lot of compiling. With the right motherboard they even have ECC RAM support. Game changer for workstations in the $1000–$2000 range.<p>The more expensive Threadripper parts really shine when memory bandwidth becomes a bottleneck. In my experience, compiling code hasn’t been very memory bandwidth limited. However, some of my simulation tools don’t benefit much going from 8 to 16 cores with regular Ryzen CPUs because they’re memory constrained. Threadripper has much higher memory bandwidth.

&gt;C++Builder with TwineCompile is a powerful productivity solution for multi-core machines compiling 1 million lines of code very quickly and can work better than the MAKE&#x2F;GCC parallel compilation Jobs feature due to it’s deep IDE integration<p>You&#x27;re claiming this plugin has deeper IDE integration than `make`? I find that really, really difficult to believe. And if it&#x27;s true, it seems like the solution is to either use a better IDE, or improve IDE support for the de facto standard tools that already exist, as opposed to writing a plugin for the -j flag.

[Not &quot;real&quot; C++ code, benchmark is for compiling 14492754 copies of a fairly simple C function]

That article mentioned Delphi and Object Pascal, and it brought back many fond memories. I absolutely LOVED Delphi and Object Pascal back in the day. So clean and so fun to program in. If Borland hadn&#x27;t f-ed it up and had stayed around until now, I&#x27;d be the biggest Delphi fanboy.<p>Alas, that was not to be. Modern languages are fun and all, but not Delphi-back-in-the-day level fun :-).

After liking this article, I wanted to check out others on the site, and am shocked at the terrible usability of their front page. I can&#x27;t finish reading the titles of their articles before the page just keeps moving things around on me. It is so frustrating, which is unfortunate because I would otherwise have been interested to see more of their content. Experience completely ruined by awful design judgment.

This seems to be a little bit related to this quest for fast compilation:<p>The &quot;mold&quot; linker:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;rui314&#x2F;mold" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rui314&#x2F;mold</a><p>&gt;&quot;Concretely speaking, I wanted to use the linker to link a Chromium executable with full debug info (~2 GiB in size) <i>just in 1 second</i>. LLVM&#x27;s lld, the fastest open-source linker which I originally created a few years ago, takes about 12 seconds to link Chromium on my machine. So the goal is 12x performance bump over lld. Compared to GNU gold, it&#x27;s more than 50x.&quot;

Lucky sons of gun. We are stuck with Xeons. Have to wait 3 hours for our 20M C&#x2F;C++ on the 2x14cores Xeon machine after a pull&#x2F;rebase. Ryzen&#x2F;TR would probably be faster 2-3x times for the same money, yet it is a BigCo, so no such luck (and our product is certified only for Xeons, so our customers can&#x27;t run AMD too - thus we&#x27;re de-facto part of the Great Enterprise Wall blocking AMD from on-premise datacenter).

there&#x27;s something much easier to bring 64 cores to its knees - chromium takes a loooong time to compile.

This shows that if you are making a not-very-fast compiler (most compilers these days), then the much maligned C compilation model has some serious advantages on modern and future hardware, due to its embarrassingly parallell nature.

Great read. I wonder if the make -j modification wasn’t scaling things across all cores because it was using the physical core count (number of cores) versus the logical core count (number of core threads).<p>Or perhaps the code wasn’t modified to spread the work across all processor core groups (a Windows thing to support more than 64 logical cores).<p><a href="https:&#x2F;&#x2F;bitsum.com&#x2F;general&#x2F;the-64-core-threshold-processor-groups-and-windows&#x2F;" rel="nofollow">https:&#x2F;&#x2F;bitsum.com&#x2F;general&#x2F;the-64-core-threshold-processor-g...</a>

They finally got around to reusing mainframe model numbers.

Does anyone have reviews of this on their JS test suite. The quicker the tests run the better my life, I have around 2000 quite slow tests... 76s MacBook 15” 2016, 30s M1 Apple Silicon Mac Mini, what should I expect with loads more cores like this?

The images remind me of &quot;Bad Apple!&quot; as displayed on a CPU load graph of a 896 core machine:<p><a href="https:&#x2F;&#x2F;youtu.be&#x2F;RY5_gutA_Vw" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;RY5_gutA_Vw</a>

Embarcadero? Are they still around?

Just try to compile LLVM - maybe not 1b of LoC, but that&#x27;s definitely going to be challenging

Great article but for the love of god don&#x27;t use Passmark. They are extremely bad on AMD scores. Now this is luckily two CPU&#x27;s from AMD so it isn&#x27;t bad but it is a bad comparison site as they heavily favour Intel.

On Linux I would just use Bazel. It can burn through 1B lines of code on all cores.

Hahaha, fuck me, CPUs are <i>fast</i>. That&#x27;s wicked. 15 mins. A billion lines of C. Insane. Wonder if there&#x27;s some IO speed to be gained from ramdisking the inputs.

Interesting. It would be cool to compare this against Visual Studio + Incredibuild, in my experience the most solid distributed C++ compilation tool.

In my experience multi-core compilation does not work.<p>make -j&gt;3 just locks the process and fails.

It is a good thing that Embarcadero is keeping alive this technology to create desktop apps from the early 2000s that was abandoned by MS and other large companies in favor of complex Web-based apps.

&gt; 1B Lines of C++<p>Seems like our code is inflating quite rapidly. I remember when 1M was the biggest project. &#x2F;snark

How many times are they going to repeat the search phrases like &quot;one billion lines&quot;? It&#x27;s reached the point where SEO obstructs human readability. It was cool that Object Pascal (maybe a descendant of Turbo Pascal) compiled 1e9 lines of Pascal in 5 minutes on the 64 core box. Scrolling way through the article, it looks like they had enough trouble setting up their parallel Windows C++ build environment on 64 cores that they ended up running 4 instances on 16 cores each, and splitting the source files among the instances. The build then took about 15 minutes on 64 cores, which is faster than I&#x27;d have expected.<p>This all seems kind of pointless since distributed C++ compilation has been a thing for decades, so they could have used a cluster of Ryzens instead of &quot;zowie look at our huge expensive single box&quot;.

1B Lines? And this is just from a &quot;rails new&quot; command. Had to for some levity.

A Billion lines, eh?<p><pre><code> int main () { &#x2F;* _______ _ _ _ _ |__ __| | (_) (_) | | | | | |__ _ ___ _ ___ __ _ | | ___ _ __ __ _ _ __ _ __ ___ __ _ _ __ __ _ _ __ ___ | | | &#x27;_ \| &#x2F; __| | &#x2F; __| &#x2F; _` | | |&#x2F; _ \| &#x27;_ \ &#x2F; _` | | &#x27;_ \| &#x27;__&#x2F; _ \ &#x2F; _` | &#x27;__&#x2F; _` | &#x27;_ ` _ \ | | | | | | \__ \ | \__ \ | (_| | | | (_) | | | | (_| | | |_) | | | (_) | (_| | | | (_| | | | | | | |_| |_| |_|_|___&#x2F; |_|___&#x2F; \__,_| |_|\___&#x2F;|_| |_|\__, | | .__&#x2F;|_| \___&#x2F; \__, |_| \__,_|_| |_| |_| __&#x2F; | | | __&#x2F; | |___&#x2F; |_| |___&#x2F; *&#x2F; return 0; }</code></pre>