Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blogs.embarcadero.com

Post reply on HN
Print view View original

171–180 of 187 posts

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

#171

Post by daemin »

nh2 wrote: post #137
ska wrote: post #50

Earlier quoted context omitted.

Hmm. Maybe the tradeoff has changed since I last tested this (to be fair, a few years ago). But I'm also not focused on build servers especially, it's always been possible to make those reasonably fast. Unless you have a very specific sort of workflow anyway, your devs are doing way more local builds than on the server and that sped up a ton moving to SSD, in my experience anyway. YMMV of course.

Last time I benchmarked C++ compilation on SSDs vs HDDS (compiling the PCL project on Linux which took around 45 minutes), SSD didn't help in a noticeable fashion. I believe that this makes sense: In a typical C++ project like that which use template libraries like CGAL, compilation of a single file takes up to 30 seconds of CPU-only time. Even though each file (thanks to lack of sensible module system) churns throug…

Back in 2012 at a previous job we tested compilation performance on spinning disks versus solid state. On Linux it made almost no difference what so ever, on Windows however it was a game changer. The builds were an order of magnitude faster so it was well worth it making the switch.

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

#172

Post by daemin »

bluedino wrote: post #75
fctorial wrote: post #53

Earlier quoted context omitted.

Don't SSDs have a finite TBW? 50GB of writes everyday (possible on large projects) will consume that in a couple of months.

Something like the Samsung EVO 960 (typical mid-range SSD) will take 400TB of writes in it's lifetime. So that's 8,000 days of 50GB writes.

At my current job I do at least 150-200GB of writes per day. 50GB for code temporary files, 70+ GB for data files, x2 that for packing them, and then also deleting some of those to make some room to do it again.

Also the disk that it's on is over 50% full so that also degrades it faster as there's fewer blocks to wear level with.

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

#173

Post by account42 »

bombcar wrote: post #163
biglost wrote: post #145

Earlier quoted context omitted.

With gentoo i use tmpfs and it works really well

Do you have details on how to enable this?

Just mount a ramdisk over your portage TMPDIR (default /var/tmp/portage). You will need a decent amount of ram though for larger packages like LLVM. Disabling debug symbols will reduce the required space a bit.

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

#174

Post by account42 »

55873445216111 wrote: post #79
bmurphy1976 wrote: post #65

Earlier quoted context omitted.

Where can you get decent ECC ram for a reasonable price? I was on the hunt recently for ECC RAM for my new desktop and I gave up and pulled the trigger on low latency non-ECC RAM. Availability seems to be pretty terrible at the moment.

You can get ECC UDIMMs from Supermicro. They are rebranded Micron DIMMs. ECC memory is not going to go as high of frequencies as you might be looking for. They will only go up to the officially validated speed of the CPUs. https://store.supermicro.com/16gb-ddr4-mem-dr416l-cv02-eu26....

> They will only go up to the officially validated speed of the CPUs.

You won't be able to buy ECC ram marketed for speeds beyond JEDEC standards but that does not mean that you cannot clock them higher.

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

#175

Post by account42 »

jandrese wrote: post #6
formerly_proven wrote: post #4

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

Seems like he tried more complex examples too, but ran into roadblocks like a 2GB limit on executables and running into a commandline length limit restriction that dates back to early DOS days which made it impossible to link. Both of those problems seemed solvable if he was willing to chunk up his application into libraries, maybe 1024 files per library then linked to the main application.

> a commandline length limit restriction that dates back to early DOS days which made it impossible to link.

MinGW's linker supports passing the list of objects as a file for this reason and CMake will use that by default.

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

#176

Post by hedora »

klodolph wrote: post #89
hedora wrote: post #76

Earlier quoted context omitted.

> the core problem is that you can’t cross to a recursive make invocation via multiple edges. I’ve never had that issue, and used to heavily use recursive make. I carefully benchmarked those make files, and am sure this wasn’t an issue. I suggest reading the paper “Recursive Make Considered Harmful” before attempting to use make for a large project. It describes a lot of anti-patterns, and better alternatives. I’ve f…

> I’ve never had that issue, and used to heavily use recursive make. I carefully benchmarked those make files, and am sure this wasn’t an issue. So, you’ve never had two different targets that depend on something in a subdirectory? If you’ve just solved this by building subdirectories in a specific order, or building entire subdirectories rather than the specific targets you need, what you’re really doing is making a…

If there’s a requirement to use an intermediate target from a subdirectory, and that’s not expressible in the parents or siblings, you could run into issues. I thought you meant it failed to parallelize multiple unrelated targets because they are in multiple subdirectories.

Anyway, the solution to that specific problem is written up in “Recursive make considered harmful”. Make handles it elegantly.

The title is kind of a spoiler, but if you’re using recursive make and care about fine grained dependencies across makefiles, you’re doing something wrong.

As an aside, I wonder if recursive make misuse is why people claim ninja is faster than make. I’ve benchmarked projects before and after, and before, make was generally using Afterwards, ninja was exploiting the same underlying parallelism in the dependency graph as make was. Thanks to Amdahl’s Law, there was no measurable speedup. The only thing I can figure is there’s some perceived lack of expressivity in make’s dependency language, or there are an absurd number of dependencies with trivial “build” steps.

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

#177

Post by tomc1985 »

rbanffy wrote: post #167
tomc1985 wrote: post #160

Earlier quoted context omitted.

As a counterpoint, I burn-tested several random M.2 NVME drives over a period of a month of 24/7 writes and reads and all but one model failed before the month was up

Heat dissipation can be an issue. Writing continuously generates a lot of heat.

Part of the purpose of a burn test is to see how it handles temperature under load. We didn't have the option of adding cooling, many of the product installations took place in a hot climate, and nobody wanted to pay for a hardened part...

Anyway, my point is that SSD drive reliability varies wildly

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

#178

Post by rbanffy »

viktorcode wrote: post #56
bserge wrote: post #48

Earlier quoted context omitted.

What can perform better?

Other languages do perform better

Besides being fast, I imagine that one could implement every application ever developed in 1 billion lines of APL.

I'll show myself out.

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

#179

Post by rbanffy »

pirocks wrote: post #130
bullen wrote: post #47

Earlier quoted context omitted.

Aha, I only compile on ARM so I got no room to increase RAM... Is it the same with g++? I have 4GB so I should be able to compile with 4 cores, but the processes only fill 2-3 cores even when I try make -j8 on a 8 core machine and then locks the entire OS until it craps out?! Something is fishy...

This is just a low end/uncommon hardware problem. I typically do make -j16 on a 4 core x86 system and it just works. You are probably running out of ram and the swapping resulting in that instability.

Ideally compilation is CPU intensive. Unless you are constrained on IO, it won't improve your compilation much.

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

#180

Post by m463 »

heelix wrote: post #148
m463 wrote: post #70

Earlier quoted context omitted.

same for everything. 5950? where would you even get one? wait - seems you can get one, just pay 2x list price.

I picked one up at the Minneapolis Microcenter about a week ago at near (or less) than MSRP. I'd been looking for any stock since launch, and that was the first one I'd seen show up in stock and queued up for it. (Same day as a bunch of video cards showed up, so a bit less competition.) They have an online checkin app that they use to order the queue. You see it show up in stock, add yourself to the queue, and get an…

After you buy a chip with that many cores, your future problem will be heat, not cold. :)
Post reply on HN