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

111–120 of 187 posts

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

#111

Post by dekhn »

nine_k wrote: post #100
dekhn wrote: post #74

Earlier quoted context omitted.

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

SSDs avoid catastrophic write failures by retiring damaged blocks. Check the reported capacity; it may have shrunk :) Before you ever see bad blocks, the drive will expend spare blocks; this means that a new drive you buy has 10% more capacity than advertised, and this capacity will be spent to replace blocks worn by writes.

Now I'm curious how the kernel responds to having swap partitions resized under it.

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

#112

Post by [deleted] »

com2kid wrote: post #26
simcop2387 wrote: post #16

Earlier quoted context omitted.

I believe this is one of the reasons for object libraries (or archives, the foo.a files on linux/unix), you can then link in all of the object files from one of those at link time without having to list them all at once. That won't get past the 2GB limit on executables but it will get past the command line length.

This is correct, a .lib file on Windows has a bunch of .obj files in it that you can then link together. You can also use command files[1] to pass options in instead of using the command line. [1] https://docs.microsoft.com/en-us/cpp/build/reference/linking... to pass

[deleted]

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

#113

Post by [deleted] »

PragmaticPulp wrote: post #49
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…

SSDs help, but nothing beats core count X clock speed when compiling. Source code files are relatively small and modern OSes are very good at caching. I ran out of SSD on my build server a while ago and had to use a mechanical HDD. To my surprise, it didn’t impact build times as much as I thought it would.

[deleted]

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

#114

Post by nevi-me »

andy_ppp wrote: post #105

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?

How parallel do the tests run? The Threadrippers have massive number of cores, but their per-core performance is lower than say a Ryzen 9.

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

#115

Post by archi42 »

ChuckMcM wrote: post #41
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...

It may be a Windows thing. I too started reading the post and was thinking, why not -j128 or -j64 depending on if HT was on and then realized that the author's system wasn't one that had been tuned for decades to build software as quickly as possible :-). It would be an interesting academic exercise to create a setup on Linux that did the same thing but using the extant build tools, and then to do a deep dive into ho…

We're running our builds and tests on both Windows 10 and Linux. At least for Windows 7, the compiler start up time had a huge impact on total run time. I think back then we had 2500 tests, each compiled, then linked, and then dwarfdumped and then some more tools (we build a compiler). We moved some stuff to Linux (eg dwarfdump) and saved a few program executions by compiling & linking single c file tests in one step (yeah, the driver still calls everything, but the driver is called once less). I was under the impression Windows 10 improved on that (we didn't benchmark in detail since then, since it's still far enough), but on Linux I don't have to bat an eye on eg make -j32.

BTW, the author messed up anyway. Make -j does schedule everything at once. How do I know? Only way I got my private 128GB build host to oom...

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

#116

Post by moonchild »

josephg wrote: post #110
moonchild wrote: post #106

Earlier quoted context omitted.

V8 is a JIT compiler, which has a baseline interpreter and progressive optimization. It's not surprising that interpreters have fast startup time. (Hotspot is the primary exception in this case, but a big part of its slowdown comes from the fact that it verifies bytecode before loading it.)

I wonder if it’d be possible / useful to implement a rust or C compiler that worked that way. Basically instant startup time after a code change is a delightful feature.

I've been bandying around ideas lately for an extremely fast c compiler that, among other things, caches machine code for individual function declarations. You wouldn't realistically be able to get to the level of speed as js, though, because js is a dynamic language. With a statically typed language like c or rust, any time you change a declaration, you have to re-typecheck everything that depends on that declaration. (Though you can frequently avoid generating new code, if you implement structs using hashtable semantics.) Both languages also have a concept of compile-time evaluation, and rust in particular has to deal with template expansion (which is not trivial, I hear they use an SMT solver for it now).

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

#117

Post by reitzensteinm »

spullara wrote: post #81
bluedino wrote: post #75

Earlier quoted context omitted.

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.

Hmmm. Looks like I need to move my temp dir for GeForce instant replay off of my SSD. It records about 1.6GB/5min which is 460GB per day. RAM disk would probably be the best option.

I'm pretty sure it doesn't record the desktop with instant unless you have specifically set that up, so you'd only be writing to the drive while you're in game.

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

#118

Post by titzer »

moonchild wrote: post #106
josephg wrote: post #82

Earlier quoted context omitted.

Go, Jai, V8 (weirdly), some hobbyist C compilers.

V8 is a JIT compiler, which has a baseline interpreter and progressive optimization. It's not surprising that interpreters have fast startup time. (Hotspot is the primary exception in this case, but a big part of its slowdown comes from the fact that it verifies bytecode before loading it.)

Bytecode verification is not a large part of compilation time for Java. For HotSpot server, verification is dwarfed by building the IR, repeatedly walking and transforming it, generating code, and register allocation. Keep in mind that HotSpot will very likely inline a ton of methods, making the compilation unit large. Many passes are at least slightly superlinear, so that makes compilation time explode.

That said, I ported C1 (the client compiler) to Java back in my Maxine VM days, about 2009. At that time on typical x86 processors it was easily hitting 1.8MB/s (of bytecode) compilation time. You can work backward to how many lines of code a second that is (and sure, you aren't paying the cost of the frontend), but yeah, that is in the ballpark for 1MLOC/s I think. And that's with an optimizing compiler with IR and regalloc!

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

#119

Post by mhh__ »

bserge wrote: post #48
titzer wrote: post #27

Earlier quoted context omitted.

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

What can perform better?

I can build the D compiler (500k lines?) Warts and all in a second in my machine - and that's code that's not particularly complicated, but not at all optimized for compile times realistically.

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

#120

Post by mng2 »

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.

Kingston has some, I got a couple of KSM32ED8/16HD recently. They are 3200 CL22, though they probably have some room to tighten up timings.
Post reply on HN