Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #139003

Re: Multithreading

Show all headers | View raw

On Sat, 22 Dec 2018 19:52:01 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:

>nobody@example.org (Scott) writes:
>>On 19 Dec 2018 23:17:07 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
>>wrote:
>
>>What I'm running into now is irritating. I added the thread management
>>bits, it works, it produces correct results, but the performance is
>>perverse - the more threads I run, the slower it gets. Based on clues
>>popping up while chasing other bugs, am I right in thinking that
>>multiple threads calling malloc and friends could be a source of pain?
>>If so, I think I have a remedy for that. If not...well, I'll be stuck
>>looking for some other excuse.
>>
>
>It generally doesn't make sense to have more _active_[*] threads than
>cores/hardware threads.

Indeed. For fun (after I fixed the malloc problem) I tried pushing the
thread count up and up. Once I had more threads than cores (6),
performance was pretty flat, and started to slow down again at around
400 threads. No surprises there.

>Certainly malloc/free must be thread-safe, which implies some level
>of serialization of those calls - which for performance reasons, one
>should disfavor.   Pool based allocators (using atomics to manage the
>lookaside list) may be less expensive, but you'll still be contending
>for the cache lines that hold the pool metadata; for that reason, per-thread
>pool allocators may be more efficent.
>
>Best case, you allocate everything you need up front.

I wish. Being a ray tracer, the complexity and therefore memory
demands vary wildly with the input data. My test data set, which isn't
even very complex, ends up causing over 17 million malloc calls. The
resulting performance looks like this:

threads	time
1	0:22
2	0:23
3	1:18
4	1:27
5	1:29
6	1:42

Easy to see where the threads start fighting each other.

But lacking pre-allocation, as you said, a per-thread allocator is the
next best thing here. I did that with some #defines to redirect the
threaded malloc calls into my own thread pool allocator. It's not very
elegant since it has to search a list to find the thread context for
every call, but this can be done without mutex locks and that already
saves a lot of overhead. Point is, by making this change I was able to
reduce the number of actual malloc calls from 17 million to four
thousand (!), and the new performance tests look like this:

threads	time
1	0:21
2	0:11
3	0:08
4	0:06
5	0:05
6	0:05

And that is exactly the kind of performance gains I expected to see
when I first began this exercise. In fact the diminishing returns with
more cores is a clear effect of my program getting washed out by
system overhead - time to load the initial data, time to write the
results, the fact that the computer has other jobs than mine to keep
running. But I'm pleased with these results.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Multithreading nobody@example.org (Scott) - 2018-12-16 21:48 +0000
  Re: Multithreading Joey Pabalinas <joeypabalinas@gmail.com> - 2018-12-16 17:11 -1000
  Re: Multithreading rbowman <bowman@montana.com> - 2018-12-16 21:00 -0700
  Re: Multithreading Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-17 22:19 +0000
    Re: Multithreading Joey Pabalinas <joeypabalinas@gmail.com> - 2018-12-17 12:45 -1000
    Re: Multithreading nobody@example.org (Scott) - 2018-12-19 19:48 +0000
      Re: Multithreading fir <profesor.fir@gmail.com> - 2018-12-19 11:58 -0800
      Re: Multithreading Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-19 23:17 +0000
        Re: Multithreading "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-19 15:31 -0800
          Re: Multithreading "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-19 15:34 -0800
        Re: Multithreading nobody@example.org (Scott) - 2018-12-22 10:43 +0000
          Re: Multithreading fir <profesor.fir@gmail.com> - 2018-12-22 03:41 -0800
            Re: Multithreading fir <profesor.fir@gmail.com> - 2018-12-22 03:46 -0800
          Re: Multithreading Thiago Adams <thiago.adams@gmail.com> - 2018-12-22 07:14 -0800
          Re: Multithreading rbowman <bowman@montana.com> - 2018-12-22 11:41 -0700
            Re: Multithreading "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-22 16:09 -0800
          Re: Multithreading scott@slp53.sl.home (Scott Lurndal) - 2018-12-22 19:52 +0000
            Re: Multithreading "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-22 16:10 -0800
            Re: Multithreading nobody@example.org (Scott) - 2018-12-23 23:11 +0000
              Re: Multithreading "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-23 15:24 -0800
                Re: Multithreading "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-23 15:25 -0800
                Re: Multithreading fir <profesor.fir@gmail.com> - 2018-12-24 02:05 -0800
              Re: Multithreading fir <profesor.fir@gmail.com> - 2018-12-24 02:08 -0800
  Re: Multithreading fir <profesor.fir@gmail.com> - 2018-12-18 07:18 -0800
    Re: Multithreading fir <profesor.fir@gmail.com> - 2018-12-18 07:51 -0800
      Re: Multithreading fir <profesor.fir@gmail.com> - 2018-12-19 09:24 -0800
        Re: Multithreading fir <profesor.fir@gmail.com> - 2018-12-19 09:55 -0800
          Re: Multithreading fir <profesor.fir@gmail.com> - 2018-12-19 11:02 -0800
            Re: Multithreading fir <profesor.fir@gmail.com> - 2018-12-19 11:16 -0800
              Re: Multithreading fir <profesor.fir@gmail.com> - 2018-12-19 11:25 -0800
          Re: Multithreading "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-19 15:37 -0800
            Re: Multithreading fir <profesor.fir@gmail.com> - 2018-12-19 16:03 -0800
              Re: Multithreading fir <profesor.fir@gmail.com> - 2018-12-20 08:02 -0800

csiph-web