Hacker News Reader

Comment by riffraff | Hacker News Reader

OT: is "make -j64" overkill unless you have dozens of cores or am I missing something?

You're right - but that was the point. The patch was trying to fix problems with the process scheduler, and "-j64" is going to make lots of processes that want to do work and need scheduling.

thanks, but then the "that is my tipical workload" thingy does not hold, as you rarely have >60 cpu bound processes running at the same time. Well, flash player in chrome notwithstanding ;)

It probably approximates Linus's typical workload, which I imagine involves constant compiling and testing while compiling. He's probably still CPU bound.

make?

If you're the head of the world's largest computer OS project, the root of the maintainer tree as it were, I would make no assumption about what his typical CPU workload is like. :)

The number of jobs to run for an optimal compile time can be quite confusing. If none of the files you are going to compile are cached it is alright to run a lot more jobs then usual as a lot of them are going to wait for the disk I/O. After that twice the jobs then you have cores is mostly appropriate.

According to Con Kolivas's benchmarks, with the BFS scheduler you just do make -j [numprocs] for best results. I can't recall if he was accounting for disk cache, though.

How many simultaneous threads will your next computer be able to run?

Chances are it already runs at least two, most probably four. It's not unreasonable to see 4 and 8-threads as the norm. Also keep in mind we are only considering x86s. SPARCs, IIRC, can do up to 64 on a single socket. ARM-based servers should follow a similar path.

BTW, a fully-comfigured MacPro does 12. A single-socket i7 machine can do 12. I never saw a dual-socket i7, but I have no reason to believe it's impossible.

Considering that, -j64 seems quite reasonable.

Dual-socket i7 is called Xeon.

There are dual-socket and even quad-socket 8-core hyperthreaded xeons (the Xeon L75xx series). A 1U Intel with 64 threads will set you back about $20k.

AMD has 12-core chips, so you can get 48 cores in 4 sockets there. (But I think they only have one thread per core)

So, -j64 seems quite reasonable, if you have $20K around... ;-)

Personally, I would spend a part of the money on 2048x2048 square LCD screens. They look really cool.

Gentoo recommends -jN+1 where N is the number of physical and virtual cores.

Say I have a quadcore with hyperthreading, does this mean 4 + 8 + 1? Or is it either the physical or the logical cores (whichever is higher)?

How do you get 4 + 8? But anyway, it's logical cores, not physical ones.

The kernel can multi-task processes, but each process still gets exclusive use of the CPU when it runs. So if it doesn't need an adder, that adder sits idle.

With hyperthreading you can run two processes at once and the CPU merges them at the instruction level making maximum use of the components on the CPU.

make -j$(2N + 1) is roughly where minimal compile times are.

Where N is the number of physical cores? I do not use hyper-threading (it tends to be bad for the floating point and bandwidth limited operations that I do), but usually find minimal compile times at N+1 jobs (but with little penalty for several more).

It depends on many factors what the optimal number of concurrent builds is, but the bottom line is that you want to maximize your CPU utilization and minimize context switching.

If you think that one extra concurrent job is enough to fill CPU utilization in the time that other jobs are blocking on iowait, then you are fine.

So, bottom line, factors to think about:

- your i/o throughput for writing the generated object files;

- the complexity of the code being compiled, - template-rich C++ code has a lot higher CPU usage versus i/o ratio

- the amount of cores in your system

I have 4 cores with hyperthreading enabled (so 8 "threads"), and find that -j10 is the fastest.

Out of curiosity, What types of applications are you running where HT hurts performance?

Sparse matrix kernels and finite element/volume integration. For bandwidth-limited operations, it is sometimes possible to get better performance by using less threads than physical cores because the bus is already saturated (for examples, see STREAM benchmarks). For dense kernels, I'm usually shooting for around 70 percent of peak flop/s, and any performance shortcomings are from required horizontal vector operations, data dependence, and multiply-add imbalance. These are not things that HT helps with.

Additionally, HT affects benchmark reproducibility which is already bad enough on multicore x86 with NUMA, virtual memory, and funky networks. (Compare to Blue Gene which is also multicore, but uses no TLB (virtual addresses are offset-mapped to physical addresses), has almost independent memory bandwidth per core, and a better network.)

> Where N is the number of physical cores?

Yes. Dunno about HT, never used a box with it.

Reply on news.ycombinator.com