On 2011-05-14 20:12, Brad Roberts wrote: > On 5/14/2011 7:44 PM, Jonathan M Davis wrote: > > On 2011-05-14 19:09, Brad Roberts wrote: > >> On 5/14/2011 7:02 PM, David Simcha wrote: > >>> On 5/14/2011 8:28 PM, Sean Kelly wrote: > >>>> Technically, you want a free list per core. I don't know how practical > >>>> it is to figure that out though. > >>>> > >>>> Sent from my iPhone > >>> > >>>> On May 12, 2011, at 8:14 PM, David Simcha<[email protected]> wrote: > >>> The idea being that, if you have a free list per core, there will > >>> almost never be any contention in practice, even if you have way more > >>> threads than cores? > >> > >> Ideally neither contention nor cache swapping. It'd stay in the l1 or > >> l2 of the core directly involved with the allocations. By being thread > >> centric even if not contended it could still wander between cores and > >> thus the caches associated with them. > >> > >> A serious micro-optimization, but.. > > > > But we're always serious about our micro-optimizations! ;) > > > > Yes, anything which we can reasonably do to make the GC more efficient is > > a good thing. Java already gets enough flak for its GC (most > > undeservedly at this point), and it has an efficient one. We don't. So, > > anything we can reasonably do to improve how well the GC performs is > > definitely desirable. > > > > - Jonathan M Davis > > Macro before micro though.
Oh, definitely. But in this case, it sounds like we're talking about a fairly major design decision with regards to thread pools, and we do want to consider all of the various ramifications when making a decision about what best to do, and such micro-optimizations factor in, though obviously any macro optimizations which the decision affects take precedence. - Jonathan M Davis _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
