Gracias por el código, cuando me encontré que me presente:
2.6.9/Xeon/3.2 MHz
(3 carreras)
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 carreras)
527.641,18 semop / s (8969900/17) [100]
564.212,50 semop / s (9027400/16) [100]
535.800,00 semop / s (9108600/17) [100]

Veo que la OCS es capaz de hacer aproximadamente 3 veces más semop / s de Linux.

BTW, el H / W es idéntica, creo que he publicado en este looong hilo.

Para Linux, voy a volver a publicar, s / w versiones:
Fedora 2.6.9
gcc - ver.3.4.3
ldd - ver. 2.3.5
glibc - versión 2.3.5

Esto es un poco off-topic, pero me temo que no entienden completamente el código.

Mi comprensión de los efectos de la inicial de bucle
es para iniciar el conjunto de mediciones en el punto de cambio de la segunda. ¿Verdad?

Siguiente,
tenemos dos bucles: en primer lugar ejecutar 8750000 veces, dada la maxloop valor de 1000000,

Entonces corremos bucle hasta 1250000 veces que cada iteración nos 100a para comprobar si el tiempo y segundo cambiado, salimos
¿Qué es esta técnica de control para cada enésima iteración? ¿por qué no comprobar la hora cada iteración? es porque ello agregar tiempo extra a muchas llamadas y barroso las mediciones?

Su aclaración se agradece.

Eso es bastante sobre el tema y una razón por la que envió el código.

derecho.

Usted contestó ella. AFAIK cada vez () implica un sistema de llamada de llamada. Creo que hay una mejor manera de manejar esto, pero esta es la primera que vino a la mente.

Yo apreciamos que el código de control. Que soy propenso al fracaso puede ser un modesto eufemismo.

Revisé los granos. Hubo cambios importantes en 1995 (antes de la versión 2.0), 1998 (antes de la versión 2.4) y, a continuación, de nuevo con la introducción de la "O (1) programador (no seguro). Este es el código - que no ha cambiado desde 2.4 - que no 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,

Yo por correo electrónico los mantenedores del código. Esta es una respuesta que obtuve de vuelta de Alan "maddog" Cox (con el permiso para publicar aquí):
Así que aquí es otra versión utilizando gettimeofday (). No se molestan en publicar los puntos de referencia, a menos que sean significativamente diferentes. Sin embargo, prepararse para 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, yo nunca he tratado con la presentación de informes sobre bugzilla, parece ti me hago muy alejada y me temo que voy a publicar algo que no es pertinente, por lo que si estaría de acuerdo en hacerlo por sí solo, aquí están los resultados de la 2 ª versión de su 'gettimeofday basada en código, que volver a ejecutar 4 veces a la media:

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)


Como puede ver, no hay diferencia de la antigua pruebas.

Sólo para mi aclaración: de alguna manera las personas que participaron en este debate sobre la formulación unix.com así como en otros lugares kerneltrap y están muy preocupados con 2 cosas, que en mi punto de vista no son pertinentes al tema de este hilo: la medición del tiempo de la precisión y la participación funcionamiento de múltiples procesos, depósitos, etc, que los resultados barroso. Yo totalmente de acuerdo con que si SCO vs Linux resultados eran comparables. Pero este no es el caso aquí. SCO es tres veces más rápido, no importa que mi método utilizado o gettimeofday método muy preciso. Con todos los gastos generales está más o menos similares, me parece que se tipo de golpes con rodeos cuando se trata de lograr tener exactitud en la medición (que no duele, de cource!), Pero hizo que el hilo hinchado.

Una vez más, gracias a Otheus de sus sugerencias, en este punto el núcleo de código que muestra señalar que la capacidad de multi-CPU añade una capa de complejidad y no ayuda a la velocidad. Y de su strcmp (kerneltrap foro) recomendaciones para la actualización del núcleo de Linux están bien tomadas.
migurus

Sólo por el contraste en un moderno procesador Intel SMP ejecutando Linux 2.6.18 obtener más
a más de un millón de operaciones por segundo.
Sobre esa base, no creo que esto califica como un error .. más de un creciente dolor.
Linux siempre ha sido un proyecto en marcha avante. O a ponerse al día o sufren.
Linus es corto en disculpas por este modelo que he visto.

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)