Subj : Re: A multithreading benchmark
To   : comp.programming.threads
From : chris noonan
Date : Sun Jun 12 2005 02:06 pm

Thank you all for your comments. I will address some of the
points raised:

Torsten Robitzki wrote:
>I fail to get what you want to benchmark. Initial it where "various heap
>managers", but how would that connect to a "thread-per-connection
>basis", where you for sure spend more time waiting for a complete IO
>then to allocate memory. Do I miss some connection?

In classic multiprocessing style, when one thread pauses for I/O,
the operating system schedules another thread to perform
computation (including heap operations). You ramp up the number
of threads until the CPU is saturated.

David Schwartz wrote:
>>2. The program will take the server role of a
>>client-server system, and will run on a thread-
>>per-connection basis.
>Since this architecture is almost never used by programmers looking for
>performance, why use it as a benchmark?

The shallow answer is that only with thread-per-connection can
the program be coded in a natural style.

The deeper answer is my belief that thread-pooling solutions
do not in principle improve performance, though they may do
so in practice on specific, mutex-ridden operating systems.
That is best elaborated in a separate topic.

Doug wrote:
>Wierd, I can't see my posts...  Nevermind.
It's OK, I can see them.

The many comments on network issues have given
me pause for thought. When dreaming up the benchmark
I wanted it to be typical in some sense of a multithreaded,
real-world, performance-sapping application. Client-server
software such as web servers, database servers, seems
to fit the bill. The utility of the benchmark would lie in the
ability to substitute operating system routines in the areas
of memory management, file system etc., and see what
difference that made to performance under conditions of
high thread count and activity. Following that line of thought,
the performance of networking code (e.g. protocol stack
traversal) would fall within the ambit of the benchmark,
but the performance of the network itself would not.

Thanks again,
Chris

.