Tak for den kode, når jeg kørte det, jeg fik i denne:
2.6.9/Xeon/3.2 MHz
(3 kører)
129.186,76 semop / s (8784700/68) [100]
129.367,65 semop / s (8797000/68) [100]
129.257,35 semop / s (8789500/68) [100]

SCO/Xeon/3.2 MHz
(3 kører)
527.641,18 semop / s (8969900/17) [100]
564.212,50 semop / s (9027400/16) [100]
535.800,00 semop / s (9108600/17) [100]

Jeg ser SCO er i stand til at gøre omkring 3 gange mere semop / s end Linux.

BTW, H / w er identisk med, jeg tror jeg har det indsendt i denne looong tråd.

Til Linux, vil jeg igen-post her s / w versioner:
Fedora 2.6.9
gcc - ver.3.4.3
ldd - ver. 2.3.5
glibc - ver 2.3.5

Dette er en smule off-topic, men jeg er bange for, at jeg ikke helt forstår koden.

Min forståelse af formålet med den oprindelige loop
er til at starte hele måling på det punkt for forandring af den anden. Right?

Næste,
vi har to sløjfer: first run 8750000 gange, da de maxloop værdi 1000000,

Så vi kører loop op til 1250000 gange, hvor hver 100 iterationsprocedure vi kontrollerer for tiden, og hvis anden ændret, vi bryder ud
Hvad er denne teknik for at kontrollere hver Nth iteration til? hvorfor ikke tjekke tidspunkt hver iteration? Er det, fordi dette vil tilføje, at mange ekstra tid opkald og mudret målingerne?

Deres præcisering vil blive værdsat.

Det er helt til emnet og en grund, jeg indsendt koden.

højre.

De besvarede det. AFAIK hver gang () kalder indebærer et system opkald. Jeg tror, der er en bedre måde at håndtere dette, men dette er den første, der kom til at tænke på.

Jeg værdsætter du kontrollere kode. At jeg er tilbøjelig til at slå fejl kan være en beskeden underdrivelse.

Jeg kontrolleret kerner. Der var større ændringer i 1995 (før version 2.0), 1998 (før version 2.4), og derefter igen med indførelsen af "O (1) Scheduler" (ikke sikker). Her er den kode - uændret siden 2.4 - det betyder semctl (GETALL):

        sma = sem_lock(semid);
/* check condition omitted */
        nsems = sma->sem_nsems;
        err=-EIDRM;
        if (sem_checkid(sma,semid)) goto out_unlock;
        err = -EACCES;
        if (ipcperms (&sma->sem_perm, (cmd==SETVAL||cmd==SETALL)?S_IWUGO:S_IRUGO))
                goto out_unlock;

	case GETALL:	{
		ushort __user *array = arg.array;
		int i;

		if(nsems > SEMMSL_FAST) {
/* omitted code -- relevant only when nsems > 256 */
		}

		for (i = 0; i < sma->sem_nsems; i++)
			sem_io[i] = sma->sem_base[i].semval;
		sem_unlock(sma);
		err = 0;
		if(copy_to_user(array, sem_io, nsems*sizeof(ushort)))
			err = -EFAULT;
		goto out_free;

        case GETALL:
                if (ipcperms (ipcp, S_IRUGO)) return -EACCES;
                switch (cmd) {
/* ommitted irrelevant code */
                case GETALL:
                        array = arg.array;
                        i = verify_area (VERIFY_WRITE, array, nsems*sizeof(ushort));
                        if (i)
                                return i;
                }
                break;
/* skipping case statements */

        if (semary[id] == IPC_UNUSED || semary[id] == IPC_NOID)
                return -EIDRM;
/* the next line provides the sem_checkid() call from 2.4/2.6 code */
        if (sma->sem_perm.seq != (unsigned int) semid / SEMMNI)
                return -EIDRM;

        switch (cmd) {
        case GETALL:
                if (ipcperms (ipcp, S_IRUGO))
                        return -EACCES;
                for (i = 0; i < sma->sem_nsems; i++)
                        sem_io[i] = sma->sem_base[i].semval;
                memcpy_tofs (array, sem_io, nsems*sizeof(ushort));
                break;

Migurus,

Jeg e-mailede de vedligeholdere af koden. Dette er et svar, jeg fik tilbage fra Alan "Maddog" Cox (med tilladelse til at sende indlæg her):
Så her er endnu en version bruger gettimeofday (). Må ikke gider at udgive en benchmarks her, medmindre de er væsentligt anderledes. Men forberede dem til bugzilla:

#include <stdio.h>
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>
#include <time.h>
#define NSEMS   2

const static long maxseconds = 1000;
main(int argc, char *argv[])
{
    struct timeval tod_start,tod_stop;
    long int start,stop;
    long int maxloop = 5000000;
    long int i;
    int sid;
    key_t key;
    ushort vals[NSEMS] = { 0, 0 };

    if (argc > 1)
      maxloop = atol(argv[1]);
    i = maxloop;

    key = ftok("/tmp",99);

    gettimeofday(&tod_start, NULL);
    while (--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");
      }
    }
    gettimeofday(&tod_stop,NULL);

    start = 1000*1000*(tod_start.tv_sec - maxseconds) + tod_start.tv_usec;
    stop  = 1000*1000*(tod_stop.tv_sec  - maxseconds) + tod_stop.tv_usec;

    printf("%.2f semop/s (%ld/%ld)\n",
      (double)maxloop/(stop-start)*1000*1000, maxloop, stop-start);
}

Otheus, jeg aldrig behandlet med rapportering om bugzilla, synes det TI mig Jeg er ikke helt berettiget, og jeg er bange for, at jeg vil sende noget ikke er relevant, så hvis du vil være enig i at gøre det selv, her er resultaterne fra 2. udgave af Deres' gettimeofday-baseret "kode, som jeg igen køre 4 gange så at få gennemsnit:

SCO
$ Tmx2
575.108,94 semop / s (5000000/8694005)
$ Tmx2
575.215,00 semop / s (5000000/8692402)
$ Tmx2
575.183,63 semop / s (5000000/8692876)
$ Tmx2
559.832,49 semop / s (5000000/8931243)

Linux:
$ ./tmx2
129.363,77 semop / s (5000000/38650699)
$ ./tmx2
129.428,22 semop / s (5000000/38631452)
$ ./tmx2
129.601,55 semop / s (5000000/38579786)
$ ./tmx2
129.511,76 semop / s (5000000/38606534)


Som du ser, ingen forskel fra det tidligere forsøg.

Bare for min præcisering: anden mennesker, der deltog i denne diskussion om unix.com formule samt om kerneltrap og andre steder var meget bekymret med 2 ting, at i mit perspektiv er irrelevant for emnet for denne tråd: tid målenøjagtighed og inddragelse af kører flere processer / tanke etc at ville mudret resultaterne. Jeg vil helt enig til, at hvis SCO vs Linux resultaterne var sammenlignelige. Men dette er ikke tilfældet her. SCO er tre gange hurtigere, uanset vi brugte min metode eller gettimeofday meget præcis metode. Med alle de generalomkostninger, der nogenlunde tilsvarende, ville jeg synes, vi var slags prygl omkring bush da vi forsøgte at nå have nøjagtighed i målingen (som ikke gør ondt, for cource!), Men det gjorde tråd oppustet.

Igen, tak til Otheus for dine forslag på dette punkt, jeg kernel code du lokalisere viser, at multi-CPU kapacitet tilføjer et lag af kompleksitet og hjælper det ikke den hastighed. Din og strcmp's (kerneltrap forum) recomendations at opgradere Linuxkernen er gennemtænkte.
migurus

Bare for kontrasten på en moderne Intel SMP-processor, der kører Linux 2.6.18 jeg få mere
end en million operationer / sek.
På denne baggrund tror jeg ikke, dette kan betragtes som en fejl .. mere af en voksende smerte.
Linux har altid været et projekt i frem bevægelse. Du enten indhente eller lider.
Linus er kort på undskyldninger for denne model, som jeg har set.

1402465.14 semop/s (5000000/3565151)
1409187.85 semop/s (5000000/3548143)
1448182.72 semop/s (5000000/3452603)

501281.02 semop/s (5000000/9974445)
500868.00 semop/s (5000000/9982670)
450727.95 semop/s (5000000/11093166)