Aangezien u niet lijken op te volgen, ik verwacht niet dat u voor het benchmarken van de volgende code. In geval u dit echter, en de resultaten zijn nog steeds op grote schaal onverwachte, kunt u een notitie maken van het hier.

#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 nadruk, uw resultaten omvatten de overhead van het starten van een groot aantal processen, en in elk van hen, het afdrukken van een regel tekst op een gebufferde blok apparaat en het verlaten van het proces. Knelpunten in een van deze operaties zijn veel meer kans om de resultaten op dan het ding dat je probeert om te testen.

Ik opgesteld en lopen de lus test code geplaatst door Otheus.

Xeon / SCO resultaten: 555.555,56 semop / s [0,0]
Xeon / Linux resultaten: 128.205,13 semop / s [0,0]

Ik heb geen toegang tot PIII vak rechts nu, maar als de resultaten zijn hetzelfde (proportioneel) als wat ik zag in mijn test Ik vind het niet belangrijk niet te hebben PIII resultaten hier.

Zoveel overhead genoemd door Era - Ik ben mij bewust van, omdat het lijkt op situatie dat ik de evaluatie, zodat zij een geldige test en geen toezicht.

Dus, heeft iemand enig idee wat het knelpunt zou kunnen zijn? of waar te zoeken? Ik waardeer uw geduld met mij en uw volharding in om naar de onderkant van het.

Toegang tot een semafoor - ervan uitgaande dat er geen impasse - het is een directe geheugentoegang operatie, het toevoegen van een hele pagina of een veelvoud te verwerken geheugen overhead. Het kan gepaard gaan met een dure call: brk (), indien er geen geheugen is al aanwezig.

Het hangt af van wat

size mycode

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

PS oproep utimes (struct TMS *) tot werkelijke tijden, plus granulariteit is CLK_TCK, meestal veel beter dan time ().

gettimeofday kan worden gebruikt om muur tijd nog nauwkeuriger worden. utimes () retourneert clock_t muur tijd.

Jim, utimes () niet doet wat je denkt dat het doet. Gettimeofday meer kloppen, maar de code is een beetje ingewikkelder. Microseconde verschillen niet de verschillen in prestaties is hij te zien.

Jim,
Ik heb nooit geprobeerd profilering voor, dus ik liep in sommige probleem hier:
$ Gcc-pg-o tstloop tstloop.c
$ Tstloop
128.205,13 semop / s [0,0]
$ Gprof tstloop
gprof: gmon.out bestand ontbreekt call-grafiek gegevens

Any ideas?

Wat het gebruik van de tijd versus gettimeofday (die in feite heb ik gebruik) is volkomen irrelevant, ik probeer om te zien hoe veel keer per seconde systeem is geschikt voor het maken van een proces dat zou alleen maar lezen van een semafoor.

Bedankt.