[Shootout-list] Re: Integer overflow, massivly parallell

[Brandon J. Van Every]

Bengt Kleberg wrote:
>
> the original question was if we should create a few threads several
> times, or many threads once. (i thnk the latter is more
> difficult, and therefore better)
>
> how would it be easier for a language to implement few
> threads several times?

Well, they are definitely different tests.  Different expected case
uses.  What app are you trying to model?  I think it would be perfectly
reasonable to model most 3D games with a few threads.  Moreover, each
thread would have qualitatively very different functionality.  In
contrast, some concurrent apps would use tons of highly similar threads.
I really think for those apps, you should have a hardware testbed
appropriate for them.  I don't think slicing a single CPU over and over
again is all that meaningful, if it would never actually be used that
way.  You need a multiple CPU or multiple machine configuration.  I
admit I'm not up on the Intel 'hyperthreading' marketing mumbo jumbo.

Have either of you gone to comp.benchmarks and asked about extant
concurrency benchmarks?  Not that it will necessarily help you, as I
didn't get any answer about garbage collection benchmarks.  I suppose
there's always digging through the archives though.

At some point you guys will have to decide if concurrency testing is
really within the scope of the Shootout, or if a more specialized
benchmark needs to be devised / used for that.  I've stayed out of that
discussion because threading isn't one of my personal concerns.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur