3

I just got an account on a 24 core VPS (according to UnixBench there are 24 CPUs).

  1. In general terms, how can I make good use of all these cores for general purpose shell computing in Debian?
  2. Do I need to type something special when I issue long-running apps from the shell in order to make each process run on a separate core if one is available? Or does Debian just handle all of that, invisible to me?
Gilles 'SO- stop being evil'
  • 829,060
themirror
  • 6,988
  • One thing that comes to mind is that Debian uses a single-threaded gzip and bzip. You can replace them by pigz and pbzip. It's more about the applications using the cores, the OS already does a pretty good job at it. – Marco Sep 26 '13 at 21:21
  • @Marco so if I start 24 different non-interactive apps from the shell via 24 panes in tmux, and each app is written to only use one core, will the time it takes them to finish be less than just running all 24 in a sequence in one tmux pane on 1 CPU? In other words, in this scenario will Debian magically divvy-up my apps across my CPUs? – themirror Sep 26 '13 at 21:24
  • If each application spins one process than the operating system will assign those processes to the individual CPU cores and they run in parallel. Depending on your applications you might then be IO bound, so it's not always faster. And you can run them all in the same tmux pane if you use xargs -P, GNU parallel or just run them in the background. – Marco Sep 26 '13 at 21:44

2 Answers2

5

You don't need to do anything special: it's the kernel's job to decide which thread goes on which CPU, and it does a far better job than a human could.

However, there is no point of having 24 CPUs if you don't have at least 24 concurrent threads to run. Programs won't magically go faster if more CPUs are available: only programs that are coded to have multiple parallel threads will benefit, and many programs won't benefit, not because they are written in an inferior way, but because what they do is inherently not parallelizable.

A program with N concurrent computation threads will benefit from up to N CPUs (though it might not go N times faster, because synchronization between the threads takes time). Running M different programs that don't interact much if at all similarly takes advantage of M CPUs (or more than that if the programs are multi-threaded).

There are a few cases where manual intervention is necessary to take advantage of parallelism. If you're starting multiple data processing tasks, take care that they're spawned in parallel (with slightly over one task per CPU) rather than one after the other. For example, when building software, pass the -j option to make. See a few other examples and explanations:

If you're running a web server, all web servers designed for heavy loads are good at exploiting parallelism. Apache is used as a test case when evaluating the performance of optimizations in the Linux kernel. Beware however that parallelism in the CPU only helps if there is no other bottleneck, such as contention due to database access or input-output bandwidth.

Community
  • 1
Gilles 'SO- stop being evil'
  • 829,060
2

Making use of many cores to speed up performance depends heavily on your application. Some applications need to be run step-by-step: there's just no way to split the computation in parallel among many cores because to compute a certain step, one needs to know the results of the previous steps. If that's the case, then using 24 cores is as good as using only one.

In other cases, where the application needs to do many things that don't depend on each other, having many cores can speed things up considerably. As a pertinent example, if you're compiling a project with many source files, you can compile each source file independently before linking the different files. In such a case, you can have the compiler compile each file on a separate core. Applications that can make use of several CPU cores usually have a switch for you to request this. For example, when compiling a project using GNU make, you can pass it the -j switch followed by a number. This number specifies the number of jobs make should start simultaneously (read: on different cores).

Joseph R.
  • 39,549