Merci pour le code, alors j'ai couru, j'ai eu ceci:
2.6.9/Xeon/3.2 MHz
(3 pistes)
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 pistes)
527.641,18 semop / s (8969900/17) [100]
564.212,50 semop / s (9027400/16) [100]
535.800,00 semop / s (9108600/17) [100]

Je vois SCO est capable de faire à peu près 3 fois plus semop / s que Linux.

BTW, les h / w est identique, je crois que je l'ai posté dans ce looong fil.

Pour Linux, je vais re-poster ici, s / w versions:
Fedora 2.6.9
gcc - ver.3.4.3
ldd - ver. 2.3.5
glibc - version 2.3.5

C'est un peu hors-sujet, mais je crains de ne pas comprendre le code.

Ma compréhension de l'objet de la première boucle
est de commencer à l'ensemble de mesure au point de changement de la seconde. Right?

Suivant,
nous avons deux boucles: première exécution 8750000 fois, étant donné la maxloop valeur de 1000000,

Ensuite, nous courons à la boucle 1250000 fois où chaque itération 100e nous pour vérifier la deuxième fois et, si changé, nous distinguons
Qu'est-ce que cette technique de vérification de chaque itération de Nième? pourquoi ne pas le temps de vérifier chaque itération? est-ce parce que ce serait ajouter un délai supplémentaire pour de nombreux appels et les mesures de boue?

Votre précisions seraient les bienvenues.

C'est tout à fait sur ce sujet et d'une raison que j'ai posté le code.

droit.

Vous avez répondu. AFAIK chaque fois () appelle à un appel système. Je pense qu'il ya une meilleure façon de traiter cela, mais c'est la première qui m'est venu à l'esprit.

Je ne vous remercions d'avoir le contrôle du code. Que je suis enclin à l'échec mai être une modeste euphémisme.

J'ai vérifié les amandes. Il ya eu des changements majeurs en 1995 (avant la version 2.0), 1998 (avant la version 2.4), puis de nouveau avec l'introduction de la "O (1) scheduler" (pas sûr). Voici le code - inchangée depuis 2.4 - qui ne 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,

J'ai envoyé par e-mail aux développeurs du code. Il s'agit d'une réponse je suis rentré d'Alan "Maddog" Cox (avec la permission de poster ici):
Donc, voici encore une autre version en utilisant gettimeofday (). Ne pas la peine de poster ici les critères de référence, sauf si elles sont sensiblement différentes. Mais de les préparer à 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, je n'ai jamais traité avec les rapports sur bugzilla, il semble ti moi je ne suis pas tout à fait admissible et je crains de ne pas envoyer quelque chose de pertinent, si vous acceptez de le faire vous-même, voici les résultats de la 2ème version du votre gettimeofday basée sur le code, que je re-courir 4 fois plus pour obtenir la moyenne:

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)


Comme vous pouvez le voir, aucune différence de l'ex-tests.

Juste pour mon clarification: en quelque sorte les gens qui ont participé à ce débat sur la formulation unix.com ainsi que sur kerneltrap et d'autres lieux ont été très préoccupés par 2 choses, que, dans mon point de vue ne sont pas pertinentes à l'objet de ce fil de discussion: la mesure du temps de la précision et la participation de l'exécution de plusieurs processus / etc obus qui brouiller les résultats. Je voudrais tout à fait d'accord pour que les SI SCO vs Linux résultats étaient comparables. Mais ce n'est pas le cas ici. SCO est trois fois plus rapide, peu importe, nous avons utilisé ma méthode ou gettimeofday très précis. Avec tous les frais généraux sont à peu près similaires, je pense que nous avons été de nature tourner autour du pot pendant que nous tentions de parvenir à avoir la précision de mesure (qui ne fait pas de mal, bien sûr!), Mais il fait le fil ballonné.

Encore une fois, grâce à Otheus pour vos suggestions, à ce point le code du noyau, je vous identifier montre que les multi-cpu capacité ajoute une couche de complexité, et il ne contribue pas à la vitesse. Votre et l'strcmp (kerneltrap forum) recommandations pour améliorer le noyau Linux sont bien prises.
migurus

Juste pour le contraste sur un processeur moderne intel SMP marche linux 2.6.18-je obtenir plus
plus d'un million d'opérations / sec.
Sur cette base, je ne crois pas que cela comme un bug .. de plus en plus de la douleur.
Linux a toujours été un projet en marche avant. Soit vous rattraper ou de souffrir.
Linus est à court d'excuses pour ce modèle que j'ai vu.

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)