Mi versión de la viga no tiene bandera-c, o de cualquier otra bandera similar a la que he usado con traza en Linux.


En Linux:
$ / Sbin / sysctl-a | grep shm
... <snip error msgs>
vm.hugetlb_shm_group \u003d 0
kernel.shmmni \u003d 4096
kernel.shmall \u003d 2097152
kernel.shmmax \u003d 33554432

Q: ¿Por qué parámetros SHM semáforo afectar el rendimiento?

Además, sólo en este caso me encontré
$ / Sbin / sysctl-a | grep sem
<snip error msgs>
kernel.sem \u003d 250 32000 32 128

* * Es posible que debido al número de página de los cuadros y estructuras necesarios para hacer uso de toda esa memoria. Podría dar lugar a cada op requieren de dos a tres pierde caché por llamada. Si no hay memoria caché extraña, porque es menos shmem, entonces tal vez toma 3 veces más rápido. Jim?

Me gustaría pedir a los gurúes que más puedo publicar mi pregunta. ¿Recomendaría usted me cualquier otro grupo o foro?
Sus sugerencias serán apreciados.

Como he sugerido anteriormente: LinuxQuestions.org.

Desde el cuello de botella parece estar dentro de la llamada al sistema, le sugiero ver también relacionados con el núcleo del BB (KernelTrap.org es buena).

Gracias Otheus y Jim, tengo bastante detallada respuesta aquí:
semáforo de la velocidad de acceso | KernelTrap

Así, el núcleo 2.6.9 no es la mejor para la moderna h / w.

Agradezco everebodys tiempo!

Felicidades a ustedes por su tenacidad! Sin embargo, no creo que este es el final de la misma.

Hice un poco de investigación sobre la respuesta de strcmp. 2.6.9 fue liberado en 2004 y es el estándar con RHEL 4, que se incluye con glibc 2.3.4. Pentium 3 a la edad fueron en 2004. RHEL 5 buques con el kernel 2.6.18 y 2.5.12 glibc.

Así que hice algunos puntos de referencia.

He seguido la sugerencia del strcmp y utilizó "una caída de temporizador" método, cuando el bucle se inicia y termina después de la hora () toma nota de llamada de un cambio en cuestión de segundos. Hay de 10 a 100 ms diferencia a ambos lados de la caída, por lo que tuvo un promedio de varias carreras. Luego divida la ops / s por el número de la velocidad de la CPU (ciclos / s) para obtener "los tics por op".

• 2.6.18 / P3 / 800 MHz: 548300 / s (promedio de 19 carreras) \u003d 1459 tics / op
• 2.6.18 / AMD Opteron 285 / 2,6 GHz: 1689138 (promedio 6 carreras) \u003d 1539 tics / op
• 2.6.18 / AMD Opteron 270 / 1,0 GHz: 974228 (promedio 7 carreras) \u003d 1026 tics / op
• 2.6.9 / Xeon / 3,6 GHz: 917196 (promedio de 4 carreras) \u003d 3925 tics / op
• 2.6.9 / P3 / 1.25 GHz: 733927 (promedio de 5 carreras) \u003d 1703 tics / op
• 2.6.9 / Xeon / 2,3 GHz: 1127894 (promedio de 10 carreras) \u003d 2608 tics / op

Para los tics / op, menor es mejor. Por lo tanto, el núcleo 2.6.18 es más rápido que los núcleos 2.6.9. El Xeon es mucho lento. Presumiblemente, los granos fueron compiladas por un mínimo común denominador. Optimización de las banderas no fueron activadas, pero había una diferencia de compiladores: el gcc 2.6.9 acoge utilizado 3.4.6, mientras que las más recientes fueron con gcc 4.1.1. Asimismo, cabe señalar que no tenemos un AMD corriendo 2.6.9 ni un Xeon corriendo 2.6.18.

Es muy posible que el problema es que estos núcleos no fueron compilados óptima de las distintas arquitecturas. ¿Por qué la Xeons son mucho más lenta es bastante sorprendente, dado su uso como característica HPC componentes.

A pesar de todo, ninguno de estos resultados parecen explicar la cuestión fundamental: ¿Por qué es tanto más rápido de SCO?

Aquí está mi código:

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

/* change this per CPU to run between 8 and 12 s*/
const static int maxloop = 10000000; 

main(int argc, char *argv[])
{
    time_t start,last,stop;
    long int i;
    int estimate = 100;
    int sid;
    key_t key;
    ushort vals[NSEMS] = { 0, 0 };

    key = ftok("/tmp",99);
    last=start=time(NULL);
    for (i = 0; i < 1000; ++i) {
        usleep(10);
        last=time(NULL);
        if (last > start) break;
    }
    start=last;
    last = 0;

    for (i = maxloop/8; i < maxloop; 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");
      }
    }

/* do the last 1/8th until the second changes.
    If your processor reaches the maxloop before that,
    change the maxloop or the divisor or the "estimate" */

    stop=time(NULL);
    for (i = maxloop - maxloop/8; i < maxloop; ++i) {
      if ( !(i % estimate) ) {
        last=time(NULL);
        if (last > stop) break;
        stop=last;
      }

      /* repeat semaphore opts */
      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=last;

    printf("%.2f semop/s (%i/%i) [%d]\n", (double)i/(stop-start), i, stop-start, estimate);
}