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

71–80 of 187 posts

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

#71

Post by yread »

frizkie wrote: post #64
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.

They do but it's really large. The Tech Report did an endurance test on SSDs 5-6 years ago [0]. The tests took 18 months before all 6 SSDs were dead. Generally you're looking at hundreds of terabytes, if not more than a petabyte in total write capacity before the drive is unusable. This is for older drives (~6 years old as I said), and I don't know enough about storage technology and where it's come since then to say…

> things probably have not gotten worse.

I am afraid they did, consumer SSDs moved from MLC (2 bits per cell) to TLC (3) or QLC (4). Durability changed from multiple petabytes to low hundreds of terabytes. Still a lot, but I suspect the test would be a lot shorter now.

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

#72

Post by Sesse__ »

trhway wrote: post #61
Retric wrote: post #51

Earlier quoted context omitted.

If your SSD would be at 100% utilization it’s going to take a lot of HDD to reach that kind of bandwidth. To the point where for high bandwidth loads SSD’s actually cost less even if you have to replace them regularly. 100% utilization and 30x the bandwidth = 30x as many HDD. Alternatively, if HDD’s are an option you’re a long way from 100% utilization.

SSD have hard time sustaining 200-400Mb/s write where is 4 HDD do is easily. Our case isn't that much about IOPS. Anyway, reasonably available SSDs have up to [1000 x SSD size] total write limit, so doing couple of 400G builds/day would use up the 1TB drive in 3 years. At worst times we had to develop&maintain 5 releases in parallel instead of regular 2-3.

Urm what? A modern NVMe drive will sustain ~2 GB/sec write.

(See e.g. https://cdn.mos.cms.futurecdn.net/Ko5Grx7WzFZAXk6do4SSf8-128..., from Tom's Hardware)

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

#73

Post by bjoli »

titzer wrote: post #27
renewiltord wrote: post #15

Hahaha, fuck me, CPUs are fast . That's wicked. 15 mins. A billion lines of C. Insane. Wonder if there's some IO speed to be gained from ramdisking the inputs.

17,300 lines/sec per core. That's embarrassingly slow IMHO.

That depends completely on what optimizations are being done.

But alas, I have said for some time that a fast compiler should be able to compile about 1MLOC/S with some basic optimization work.

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

#74

Post by dekhn »

fctorial wrote: post #53
ska wrote: post #18

Earlier quoted context omitted.

I suspect the biggest (build time) benefit to most c++ workflows and toolchains was the move to ubiquitous SSD. Prior to that in my experience excepting expensive RAID array dedicated build machines, it was really easy to build a system that would always be IO bound on builds. There of course were tricks to improve things but you still tended to hit that wall unless your CPUs were really under spec. edit: to be clear…

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

I've swapped hundreds of terabytes to a terabyte SSD (off the shelf cheapie) with no recognizable problems (the gigapixel panoramas look fine).

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

#75

Post by bluedino »

fctorial wrote: post #53
ska wrote: post #18

Earlier quoted context omitted.

I suspect the biggest (build time) benefit to most c++ workflows and toolchains was the move to ubiquitous SSD. Prior to that in my experience excepting expensive RAID array dedicated build machines, it was really easy to build a system that would always be IO bound on builds. There of course were tricks to improve things but you still tended to hit that wall unless your CPUs were really under spec. edit: to be clear…

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.

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

#76

Post by hedora »

klodolph wrote: post #36
StillBored wrote: post #20

Earlier quoted context omitted.

I might be misunderstanding something, but the common gnumake does no such thing. https://www.gnu.org/software/make/manual/html_node/Job-Slots...

I didn’t go into great detail of the reasons, but the jobserver doesn’t address the problem except for the most trivial cases—the core problem is that you can’t cross to a recursive make invocation via multiple edges. This is fairly common in larger projects, so you end up having to do some hackery to manually sequence make invocations if you want to use recursive make (which is pretty awful). Honestly, for large pro…

> 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 found every alternative to make that I’ve used to be inferior, and they almost always advertise a “killer feature” that’s a bad idea, or already handled better by make. It’s surprising how many people reimplemented make because they didn’t want to RTFM.

Anyway, the next build system on my list to check out is bazel. Some people that I’ve seen make good use of make say it’s actually an improvement.

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

#77

Post by ahepp »

zajio1am wrote: post #57
klodolph wrote: post #17

Earlier quoted context omitted.

Make forces you to choose between being able to do full parallel builds or using recursive make, you can’t do both.

Why would you do recursive make? That is setup discouraged for decades ...

(for reference: "Recursive Make Considered Harmful", https://accu.org/journals/overload/14/71/miller_2004/)

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

#79

Post by 55873445216111 »

bmurphy1976 wrote: post #65
PragmaticPulp wrote: post #13

Fun experiment. 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. 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…

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....

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

#80

Post by klodolph »

StillBored wrote: post #46
klodolph wrote: post #36

Earlier quoted context omitted.

I didn’t go into great detail of the reasons, but the jobserver doesn’t address the problem except for the most trivial cases—the core problem is that you can’t cross to a recursive make invocation via multiple edges. This is fairly common in larger projects, so you end up having to do some hackery to manually sequence make invocations if you want to use recursive make (which is pretty awful). Honestly, for large pro…

Make isn't great, but if you look at the opensource world the vast majority of the large projects are make based. The backbone of your average distro is a thin layer on top of what is mostly automake/autoconf in the individual projects. That is because while I can create a toy project that builds with make in a half dozen lines, big projects can extend it to cover those odd edge cases that break a lot of other "bette…

> …I'm really tired of people pissing on solutions (c also comes to mind) that have been working for decades because of edge cases or problems of their own creation because they don't understand the tool.

You would have to be extraordinarily cynical to think that there’s been no progress in making better build software in the past forty years or so.

Yes, there are definitely plenty of build systems out there that were built from scratch to “fix” make without a sufficient understanding of the underlying problem. I’m not going to name any; use your imagination. But make was never that good at handling large projects to begin with, and it was never especially good at ensuring builds are correct. This is not “pissing on make”, for Chris’s sake, make is from 1976 and it’s damn amazing that it’s still useful. This is just recognizing make’s limitations, and one of those limitations is the ability for make to handle large projects well in general, specific cases notwithstanding. Part of that is performance issues, and these are tied to correctness. As projects which use make grow larger, it becomes more likely that they run into problems which either interfere with the ability to run make recursively or the ability to run make incrementally.

The “poor craftsman who blames his tools” aphorism is a nice way to summarize your thoughts about these kind of problems sometimes, and it does apply to using tools like make and C, but it’s also a poor craftsman who chooses tools poorly suited to the task.

Post reply on HN