Since you don't seem to follow instructions, I don't expect you to benchmark the following code. In case you do, however, and your results are still widely unexpected, please make a note of it here.

Just for emphasis, your results include the overhead of starting a large number of processes, and in each of them, printing a line of text to a buffered block device, and exiting the process. Bottlenecks in any of these operations are much more likely to explain the results than the thing you are trying to test.

I compiled and run the loop test code posted by Otheus.

Xeon/SCO results: 555555.56 semop/s [0,0]
Xeon/Linux results: 128205.13 semop/s [0,0]

I don't have access to PIII box right now, but as results are same (proportionally) as what I saw in my test I think it is not crucial not to have PIII results here.

As far as overhead mentioned by Era - I am aware of it, as it is closely resembles situation that I am evaluating, so it a valid test and not an oversight.

So, does anyone have any idea what the bottleneck could be? or where to look? I really appreciate your patience with me and your persistence in getting to the bottom of it.

Accessing a semaphore - assuming there is no deadlock - it is a direct memory access operation, adding a whole page or multiples to process memory has overhead. It can involve an expensive call: brk(), if no memory is already there.

It depends on what
says in total, rounded up to a minimum of the PAGE_SIZE (mutiple) boundary (stack frame boundary usually), which can leave extra multiple pages of memory. Look at what is show to be allocated to heap. As a start. You can call sbrk(0) to find the end of process memory.

shmget allocates from heap in most implementations: /proc/sys/kernel/sh* proc directories have shared memory information. kernel settings control shared memory operations.

try this:
That will display cum time spent + # calls for each of the function calls. You can see if/where there is a problem. If there is one with semaphores then semget will be your most likely problem - allocating pages of memory.

PS call utimes(struct tms *) to actual times, plus granularity is CLK_TCK, usually way better than time().

gettimeofday can be used to get wall time even more accurately as well. utimes() returns clock_t wall time.

Jim,
I never tried profiling before, so I ran into some problem here:
$ gcc -pg -o tstloop tstloop.c
$ tstloop
128205.13 semop/s [0,0]
$ gprof tstloop
gprof: gmon.out file is missing call-graph data

Any ideas?

As far as use of time vs. gettimeofday (which, in fact I did use) is quite irrelevant, I am trying to see how many times per second system is capable of creating a process which would simply read a semaphore.

Thanks.

------