what's more important when it comes to compiling (hardware)

[mightysilentsaint]

i've been using linux environments as my daily driver for the last 6 years starting with ubuntu when i was 14, moved to mint and used mint for 2 years then moved to arch and been using it ever since until i moved to gentoo 3 months ago.

i currently am using a g3258 overclocked to 4.2ghz core and 4ghz uncore, it has 2 cores and no ht/smt. it scores 4600 single and 7700 multi core on geekbench. it takes me 14 hours to completely install/compile my gentoo system, the entirety of it with every bit of software i need. i don't use firefox/chromium or libreoffice so it doesn't take a lot of time compared to the ones where said programs get compiled.

fx-6300 has 3 modules and each module contains 2 cores with every core having their individual l1 cache but l2 and l3 cache is shared. as bulldozer/vishera has really low ipc, it scores less than a 6-core chip on benchmarks, has really low single core score but has 6 threads. it scores around 2200 single and 7-8k multi-threaded on geekbench4, similar to my g3258 at 4.2/4ghz.

my question starts here, will it be beneficial to my compiling time if i were to change my setup to an fx-6300? it has 6 threads (4 threads more) but scores similar to my dual core chip. is thread count really important compared to overall multi-threaded performance? i don't have any multitasking problems with my dual core system as linux/unix-like environments aren't hard on system resources unlike windows, i rarely use more than 2.5 gigs of ddr3 so ram is not the issue here.

so, 6 threads with low-ipc cores with dumbed down cache and same multi core performance or 2 threads with high-ipc?

[Marcih]

A short answer to your very long-winded question would be: We don't know.

A slightly longer answer would be:
There's simply no way for us to tell which one will be faster. Forget the synthetic benchmarks, forget the details, they are often not very telling of real-world performance beacuse so many variables come into play here (I/O speeds, how much free memory you have/amount of swapping done during compilation, the packages themselves that are being compiled, the alignment of the planets etc.) that even knowing what the world set compile time is for somebody else using the same processor is not much of an indicator.
My gut feeling would be that being able to run more jobs, accounting for the decrease of single-core performance, would be a benefit.

Here is my advice though: If you have access to both processors, set them up in a test machine with all the components the exact same (having an abundance of memory so you can write files during compile time to tmpfs would be a good idea to try and minimize potential I/O bottlenecks), install a very minimal installation of Gentoo (no X, the simplest Portage profile etc. Also, having the installs unique to the hardware by rebuiling the world set, or at least the toolchain, with march=native instead of using the generic binaries may make a difference) and test for yourself; either by rebuilding the entire world set or picking a large-ish package to measure its compile time. I've done tests like this with glibc, measured the time with genlop, I don't know whether there is a more common, "accepted" way to benchmark compile times.
_________________

[joanandk]

[NeddySeagoon]

mightysilentsaint,

Some things, like ./configure, are single threaded so the more cores you have the more waiting you have between configure steps when all but one core is idle.
That makes it appear bleaker that it is in reality, since emerge can run several jobs in parallel, dependencies permitting.

So much for cores, now RAM.
C++ can use over 1G RAM per thread, so to run eight C++ instances, you want >8G RAM.
You should also have /var/tmp/portage in tmpfs. There are lots of different ways to get 8 make jobs in parallel and the what's fastest will vary depending on what is possible.

With more cores working hard, you need more RAM, as being pushed into swapping and disk I/O in general wall slow you down, even if its an SSD.
Moving data around does not contribute to the end result.

The cache question is harder to answer. Cache thrashing, because not everything fits in the CPU cache certainly leads to slowdowns.
So do all the workarounds for meltdown and spectre, which effectively turn off the affected processor features, some of which helped with cache prefetch.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[szatox]

[msst]