0

Can Parallelism in threads benefit processes in a single CPU system as well? I know they can help in other systems but I was confused if they can actually benefit single CPU systems as well.

Jason Mason
  • 1
  • 3
  • 5
    Your question is too broad, this I guess will depend on the Operating system and other factors. Even today a single CPU has multiple cores. And benefit by what mean ? – Tony Tannous Oct 17 '17 at 06:25
  • There are a *lot* of different concurrent/asynchronous/parallel programming paradigms. Besides - what single CPU? Most CPUs are multicore and support hyperthreading. – Panagiotis Kanavos Oct 17 '17 at 07:17
  • BTW your machine doesn't block while you type because the OS is multithreaded. Your applications don't block when they perform heavy processing because they do it on a background thread (that's concurrency). Or they may be using a separate thread to read/write files. Or they may not even be using threads to read files, they use asynchronous IO to let the OS handle it and call back when it finishes. That's asynchronous IO processing. – Panagiotis Kanavos Oct 17 '17 at 07:19
  • 1
    The same with the web browser - it doesn't freeze while waiting for a web site response (ok, not always). It uses both async IO *and* background threads to handle multiple requests. – Panagiotis Kanavos Oct 17 '17 at 07:21
  • Data Parallelism is when you want to process a lot of data. You can split it into chunks and have each thread process it. In a single-core machine, you can't have multiple threads running at the same time. *BUT* hyperthreading can still help. Or you can separate IO from CPU processing so you can process data while waiting to read from the disk or network – Panagiotis Kanavos Oct 17 '17 at 07:23
  • Finally, SIMD operations, when available through libraries, can give you a 4x speedup from even a single core. These are CPU instructions that allow the same operation (eg addition) to be performed to up to 4 different values. Many vector/math libraries include optimized implementations of vector algorithms so you don't have to rewrite them using SIMD operations. – Panagiotis Kanavos Oct 17 '17 at 07:26
  • 3
    Possible duplicate of [Single- vs. multi-threaded programming on a single core processor](https://stackoverflow.com/questions/20476638/single-vs-multi-threaded-programming-on-a-single-core-processor) – Ravindra babu Oct 17 '17 at 11:23

2 Answers2

1

Without using threads, you have something of a painful problem. Suppose you're doing something that might block, but probably won't. You can find some asynchronous way to do it, but that can make the programming much more complex, and if it only rarely blocks, the payoff isn't great. But if you do it synchronously, then in the rare cases where it does block, your entire process makes no forward progress.

Page faults are a good example. Consider if a server encounters an error and has to run code to log that error. This code might not be in memory and it might take a disk operation to read that code in. Do you want the whole server to make no forward progress until that disk operation completes?

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
0

You can use threads as a mechanism for async I/O, e.g. to keep multiple disc and network loads in flight, and this works even on a uniprocessor system.

Most OSes have async or non-blocking IO APIs that let you do the same thing from a single-threaded process, but that might be less convenient for some applications.

See What is the status of POSIX asynchronous I/O (AIO)? for some discussion: e.g. event based, non-blocking I/O is usually much better than the "billions of blocking threads" where you have a separate thread for each I/O operation you're waiting on concurrently.

So anyway, yes, you can usefully use threads on a single-core (without hyperthreading or other SMT) system, for things other than number-crunching throughput. (But other ways to get I/O concurrency or parallelism or whatever you want to call it are usually even better.)

There are other use-cases, like a game where one thread runs the GUI and another runs the simulation. Letting the OS schedule them may be simpler than inserting "is it time to update the GUI yet" checks or in the simulation thread.

(Or really anything with a GUI + computation, since you don't want to run the GUI from signal handlers for timers.)

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
  • 1
    Asynchronous IO isn't the same as parallelism. In fact, async IO means you *don't* need to use a thread to wait for the blocking operation – Panagiotis Kanavos Oct 17 '17 at 07:13
  • @PanagiotisKanavos: I'm answering the question I think the OP *meant* to ask, which is "are threads useful for anything on a UP system?". I avoided the term "parallelism" in my answer :P – Peter Cordes Oct 17 '17 at 07:15
  • 1
    If you use async IO you don't *need* threads. You need threads to wait for *synchronous*, ie blocking IO. Not that you can't use a different thread to process the results. – Panagiotis Kanavos Oct 17 '17 at 07:16
  • @PanagiotisKanavos: Thanks, my last paragraph made it sound like threads were still useful with async IO. Fixed, and added another use case. Heh, I just expanded comments on the question, and I see you made the same point of computation + GUI. – Peter Cordes Oct 17 '17 at 07:21