Re: [Gc] parallel speedup
Bruce Hoult <[email protected]> Wed, 25 Jun 2014 12:48:14 +1200
| Newsgroups | gmane.comp.programming.garbage-collection.boehmgc |
|---|---|
| Message-ID | <CAMU+EkwB-_Z5n+aXkid5U=6YNAzar4X_8+yaxrtwATa7-FDANQ@mail.gmail.com> |
Hi Daniel, Unfortunately you haven't given us much to go on. We don't know how you've built the GC, and we don't know how you are using it. Are you spending your time in allocation, or in marking? Have you read http://www.hboehm.info/gc/scale.html ? What from there have you done? As you can see, the information there is not very recent. I'm not aware of any serious work carried out with regard to scalability on modern 6 or 8 or 12 core CPUs. The thread local allocation stuff *should* take care of lock contention, even with quite a few CPU cores. Marking is a more difficult problem. If the structures allocated by different cores have pointers into structures allocated by other cores (or it's just generally one big ball of mud) then marking will inevitably cause a lot of cross-CPU cache traffic. If the different threads' data structures are mostly disjoint then parallel marking *could* work very well. *Could*. I really don't know in practice as I've never tried it. On another track .. are your objects mostly pointers or mostly data? If you have, for example, big arrays filled with numbers, are you using GC_malloc_atomic() so that the GC knows they don't need to be scanned? On Wed, Jun 25, 2014 at 11:46 AM, Daniel R. Grayson < [email protected]> wrote: > In our application that uses libgc (see http://macaulay2.com/) I observe > no > speedup when running tasks in parallel, if the tasks allocate memory using > libgc. Perhaps I'm doing something wrong. Are there any commonly observed > situations where no speedup occurs? > > A glance at the source code shows that mutex locks lock down the world on > almost every occasion, so it's hard to see why there would ever be any > speedup > when using threads. > > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. > _______________________________________________ > bdwgc mailing list > [email protected] > https://lists.opendylan.org/mailman/listinfo/bdwgc > _______________________________________________ bdwgc mailing list [email protected] https://lists.opendylan.org/mailman/listinfo/bdwgc