Programming

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.

Code:

#include <stdio.h>
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>
#include <time.h>
#define NSEMS   2
main(int argc, char *argv[])
{
    time_t start,stop;
    long int i;
    int sid;
    key_t key;
    ushort vals[NSEMS] = { 0, 0 };

    key = ftok("/tmp",99);
    start=time(NULL);
    for (i = 0; i < 5000000; i++) {
      if ((sid = semget(key, NSEMS, IPC_CREAT | 0777)) == -1) {
          perror("Can Not Get Semaphore ID");
      }
      if (semctl(sid, NSEMS, GETALL, vals) == -1) {
          perror("Can Not Get Semaphore Values");
      }
    }
    stop=time(NULL);
    printf("%.2f semop/s [%i,%i]\n", (double)i/(stop-start), vals[0], vals[1]);
}

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

Code:

size mycode

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:

Code:

gcc -p -g -o otherus otheus.c
otheus.c
grpof otheus

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.

------