On 07/08/09 1:36 AM, "Christian Anthon" <[email protected]> wrote:
> Hi Michael, > > thx for investigating this. My answer would have been along the lines > of "beyond our control". Jon coded most of the threading stuff and I > believe that the MAX_NUMTHREADS is indeed somewhat arbitrary. However > I believe there is a bit of memory consumption and possible also extra > cpu time involved in setting it higher. Hopefully Jon will pitch in. > You are right about overhead. There is the resource overhead (extra memory), runtime threading overhead, and as the cores increase on SMP system there is the contention overhead of all the memory requests coming from all the processors across the same bus (with current SMP/FSB architectures) Its going to be rather interesting to see performance numbers for GnuBG on systems with 32+ cores and Numa architectures (Nehalem/QPI for example). I think the shared memory design we use for every thread could still be a bottleneck for scalability. The question for me would be, at what point do additional extra cores provide little in the way of performance gains. Some day I think we might have to re-evaluate how we process data in a given thread, but likely we have some breathing room before someone here is running GnuBG on a 128 Core desktop system. The next 5-10 years could be interesting. Michael _______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
