4 ms·

My advice is to find the bottleneck first. Watch performance counters. How do your cache hit and miss rates vary at the levels at different CPU counts? For exam

My advice is to find the bottleneck first. Watch performance counters. How do your cache hit and miss rates vary at the levels at different CPU counts? For example, poorly designed GCs don't scale well on multiple processors. You could very well be paying for a single shared allocator lock or have a young generation shared across multiple packages. When are your threads idle? Can you produce log events for when your threads block on locks to see how often your threads are live versus sitting around? Do you have bad thread migration? Even if your GC is careful and you only allocate thread-local data, if the OS keeps moving your threads between packages every timeslice, you'll pay a huge hit. Analyzing performance data for multi-core program execution is hard, particularly in a virtual machine environment. It's even worse with some of the latest 4 and 6 core processors, where even measuring cache miss rates can have a noticeable impact on performance. (shameless plug: these issues and parallel language features are what our research group works on -- http://manticore.cs.uchicago.edu http://manticore.cs.uchicago.edu)

runT1ME 16y ago
>For example, poorly designed GCs don't scale well on multiple processors. You could very well be paying for a single shared allocator lock or have a young generation shared across multiple packages. Java's GC is anything but poorly designed, and it definitely scales to spades. >When are your threads idle? Can you produce log events for when your threads block on locks to see how often your threads are live versus sitting around? A good profiler should be able to show this. I've had a lot of luck with Yourkit, but others may work just as well.
- larsberg 16y ago
  Poorly designed was a harsh choice of words. A better way of putting it would be "not yet optimized for single program execution processor counts > 6 or so." The allocation wall (http://portal.acm.org/citation.cfm?id=1639949.1640116 http://portal.acm.org/citation.cfm?id=1639949.1640116) is something a lot of folks are seeing in practice across a variety of virtual machine-based languages (including Java) when scaling to about 8 cores.
  - runT1ME 16y ago
    Hrm, interesting. I would have thought the way allocation is done with threadlocal variables negate a lot of the scaling for allocs, but I could be wrong. Do you have a direct link to the PDF, or mind putting it somewhere? I don't have an ACM login.
    - larsberg 16y ago
      Sorry, but unfortunately I can't. The authors are permitted to put it online (where scholar.google and CiteSeerX usually immediately find them) but in this case they don't appear to have done so.
fhars 16y ago
I think the bottleneck is the problem he is trying to solve: forward messages from one producer to one consumer in order. This is an inherently sequential problem, all it requires is a FIFO and a select on two file descriptors. The only thing that changes if you introduce treads is that they must continuously coordinate to find out who should send the next message. "I'm only dangerous with synchronized blocks", indeed.

runT1ME 16y ago

>For example, poorly designed GCs don't scale well on multiple processors. You could very well be paying for a single shared allocator lock or have a young generation shared across multiple packages. Java's GC is anything but poorly designed, and it definitely scales to spades. >When are your threads idle? Can you produce log events for when your threads block on locks to see how often your threads are live versus sitting around? A good profiler should be able to show this. I've had a lot of luck with Yourkit, but others may work just as well.

larsberg 16y ago
Poorly designed was a harsh choice of words. A better way of putting it would be "not yet optimized for single program execution processor counts > 6 or so." The allocation wall (http://portal.acm.org/citation.cfm?id=1639949.1640116 http://portal.acm.org/citation.cfm?id=1639949.1640116) is something a lot of folks are seeing in practice across a variety of virtual machine-based languages (including Java) when scaling to about 8 cores.
- runT1ME 16y ago
  Hrm, interesting. I would have thought the way allocation is done with threadlocal variables negate a lot of the scaling for allocs, but I could be wrong. Do you have a direct link to the PDF, or mind putting it somewhere? I don't have an ACM login.
  - larsberg 16y ago
    Sorry, but unfortunately I can't. The authors are permitted to put it online (where scholar.google and CiteSeerX usually immediately find them) but in this case they don't appear to have done so.

fhars 16y ago

I think the bottleneck is the problem he is trying to solve: forward messages from one producer to one consumer in order. This is an inherently sequential problem, all it requires is a FIFO and a select on two file descriptors. The only thing that changes if you introduce treads is that they must continuously coordinate to find out who should send the next message. "I'm only dangerous with synchronized blocks", indeed.