Jeg undersøkte litt låsing ordningen bruker semaphores. Å vurdere grunnleggende system fart kjører jeg en løkke til å få noen semaforen info og vise det:

mens:; gjøre. / semshow; gjort> res.txt

Jeg kjørte dette på 3 bokser - to lignende moderne HP Xeon bokser, en kjører SCO OpenServer 5, den andre er Fedora 2.6.9, og en gammel PIII boksen under moderne Linux (har ingen info).
Resultatene er svært counter intuitive:
H / W | OS | Gj.sn. antall kjører BER sec
---- | --- | -------------------------
Xeon | SCO | 1700
Xeon | Fedora | 500
PIII | Linux (siste distro, ukjent) | 900
Alle de tre maskinene var ganske mye inaktiv på test kjøring.

Jeg vil gjerne spørre, hva ville være faktorer som gjør gamle Unix til resultater moderne OSes også, hvordan komme PIII boksen enn moderne Xeon boksen under lignende OS. Eventuelle ponters ville være verdsatt.

Den semshow programmet er helt grunnleggende, se liste under:

 
#include <stdio.h>
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>
#include  <sys/timeb.h>
#include <time.h>
#include "semlib.h"
#define MODE_CREATE     0
#define MODE_REMOVE     1
key_t   IPCKEY;
main(int argc, char *argv[])
{
  int   sid, i;
  pid_t last_rpid, last_wpid;
  char  dbuf[80];
  union semun           arg;
  unsigned short        vals[NSEMS];
  struct timeb tb;
  struct tm *tp;
        if((IPCKEY = get_ipc_key()) == -1)
        {
                errexit("Can Not Obtain IPC Key");
        }
        if((sid = semget(IPCKEY, NSEMS, 0)) == -1)
        {
                errexit("Can Not Get Semaphore ID");
        }
        memset(vals, 0, sizeof(vals));
        arg.array = &vals[0];
        if(semctl(sid, NSEMS, GETALL, arg) == -1)
        {
                errexit("Can Not Get Semaphore Values");
        }
        if((last_rpid = semctl(sid, RDLOCK, GETPID)) == -1)
        {
                errexit("Can Not Get Semaphore R-Pid");
        }
        if((last_wpid = semctl(sid, WRLOCK, GETPID)) == -1)
        {
                errexit("Can Not Get Semaphore W-Pid");
        }
        ftime(&tb);
        tp = localtime(&tb.time);
        strftime(dbuf, sizeof(dbuf) - 1, "%T", tp);
        printf("%12li.%03i %s  RD:[%i]  WR:[%i] %i/%i\n",
                tb.time, tb.millitm, dbuf, 
                vals[RDLOCK], vals[WRLOCK],
                last_rpid, last_wpid);
        exit(0);
}

 
#define NSEMS   2
#define RDLOCK  0
#define WRLOCK  1
union   semun   {
        int             val;
        struct semid_ds *buf;
        unsigned short  *array;
};

Her er ett svar: tidssoneinnstillingen målingen er vognen. Ser man på ftime () under Linux:

The Fedora boksen har
/lib/tls/libc.so.6 -> libc-2.3.5.so
så jeg antar det versjon 2.3.5.

Men det er i tillegg til punktet.

Ren rekke ganger system kjørte programmet innen andre skulle tilsi totale systemets makt, så å si. Til min astonishment PIII under linux klarte å kjøre nesten dobbelt så mange sykluser withi et sekund enn Xeon 3.2GHz under linux. Deretter samme Xeon h / w under gamle SCO OSR løpe dobbelt så fort som PIII boksen.

Men Problem nr. 1 er at du måle dette på feil måte. Du har for mange avhengigheter på biblioteket samtaler som er irrelevant i forhold til hva du prøver å måle. Ta ut alle semaforen koden, re-test, og se hva tid du får. Eller kjøre en 10.000 x løkke rundt semaforen. Deretter skalere ned til nærmeste andre slik at microseconds mistimings ikke komme i lek.

Problem nr. 2 er at semaphores krever buss-tilgang og er relativt uavhengig av prosessorhastigheten.

Jeg erstattet ftime med gettimeofday og kjør, resultatene er de samme.

For å oppsummere igjen
samme t / m:
program under SCO kjører 3 ganger raskere enn under Linux,
samme OS:
Programmet kjøres 2 ganger raskere på gamle PIII enn på moderne Xeon

Noen grunner? noen ideer?

Jeg beklager, men du fortsatt ikke har eliminert alle "løs variabler". Men semaforen koden i en sløyfe på 1000 eller så og benken igjen.

Jeg forenklet min programmet til helt grunnleggende minimum, det blir IPC tasten, får semaforen id og leser verdier av semaphores og så utganger på linje (tid og semaforen verdier). Det er alt den gjør.

Da kjører jeg det på følgende måte:
$ Mens:; gjøre tstshow; gjort> x.txt
og jeg traff avbruddsordrelinje tasten etter å vente i noen tid.

utvalg av x.txt fil innhold:
1221785538 [1,99]
1221785538 [1,99]
1221785538 [1,99]


Så å se hvor mange ganger systemet var i stand til å kjøre det jeg gjør:
$ Cut-c-12 x.txt | Unike-c

eksempel på utdataene:
616 1221785538
615 1221785539
612 1221785540

Det tels meg systemet er i stand til å kjøre denne enkle prosessen bare omtrent 600 ganger per sekund.

For å være konsekvente ville jeg gjenta resultatene her:
PIII under Linux -- 900 ganger / sek
Xeon 3.2 Linux -- 600 ganger / sek
Xeon 3.2 SCO -- 1800 ganger / sek
Er inaktiv på tidspunktet for test.
Hvordan vil du forklare resultatene jeg fikk? Jeg prøver å finne en flaskehals på moderne h / w kjører Linux.

Se mine nye forenklet koden under:

 
#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[])
{
  int           sid;
  ushort        vals[NSEMS] = {0, 0};
        if((sid = semget(get_ipc_key(), NSEMS, 0)) == -1)
        {
                errexit("Can Not Get Semaphore ID");
        }
        if(semctl(sid, NSEMS, GETALL, vals) == -1)
        {
                errexit("Can Not Get Semaphore Values");
        }
        printf("%12li [%i,%i]\n", time(NULL), vals[0], vals[1]);
        exit(0);
}