semáforo acesso velocidade - Página 6

migurus · #1 (**permalink**) 10-01-2008

Graças ao código, quando eu corria que eu tenho este:
2.6.9/Xeon/3.2 MHz
(3 execuções)
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 execuções)
527.641,18 semop / s (8969900/17) [100]
564.212,50 semop / s (9027400/16) [100]
535.800,00 semop / s (9108600/17) [100]

Vejo SCO é capaz de fazer cerca de 3 vezes mais semop / s do que o Linux.

BTW, o H / W é idêntica, penso tê-lo postado nesta looong discussão.

Para o Linux, vou voltar a postar aqui s / w versões:
Fedora 2.6.9
gcc - ver.3.4.3
ldd - ver. 2.3.5
glibc - versão 2.3.5

migurus · #2 (**permalink**) 10-01-2008

Isto é um pouco off-topic, mas estou com medo eu não compreendo perfeitamente o código.

O meu entendimento da finalidade inicial do loop

Citação:

Originally Posted by otheus

Código:

    for (i = 0; i < 1000; ++i) {
        usleep(10);
        last=time(NULL);
        if (last > start) break;
    }

é dar início a toda a medição no ponto de mudança do segundo. Certo?

Próximo,
temos duas alças: primeiro execute 8750000 vezes, dada a maxloop valor de 1000000,

Então, corremos loop até 1250000 vezes em que cada iteração 100. Nós para verificar se segundo tempo e mudou, não sair

Citação:

Originally Posted by otheus

Código:

    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;

O que é esta técnica de controlo de cada iteração de Nth? por que não verificar vez a cada iteração? é porque isso iria adicionar ao tempo extra muitas chamadas e turvar as medições?

Seu esclarecimento seria apreciada.

otheus · #3 (**permalink**) 10-01-2008

Citação:

Originally Posted by migurus

Isto é um pouco off-topic, mas estou com medo eu não compreendo perfeitamente o código.

Isso é bastante SOBRE tópico e uma razão que me postou o código.

Citação:

é dar início a toda a medição no ponto de mudança do segundo. Certo?

direito.

Citação:

O que é esta técnica de controlo de cada iteração de Nth? por que não verificar vez a cada iteração? é porque isso iria adicionar ao tempo extra muitas chamadas e turvar as medições?

Você respondeu ela. AFAIK cada tempo () chamada envolve um sistema de chamada. Penso que há uma maneira melhor de lidar com isto, mas esta é a primeira que veio à mente.

Eu aprecio você verificar o código. Que estou propenso a falha pode ser um modesto subavaliação.

otheus · #4 (**permalink**) 10-06-2008

Eu chequei o miolo. Não houve grandes mudanças em 1995 (antes da versão 2.0), 1998 (antes da versão 2.4) e, em seguida, novamente com a introdução do Ó (1) scheduler "(não sei). Aqui está o código - inalterada desde 2/4 - que faz semctl (GETALL):

Código:

        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;

Aqui está o código a partir de 2.0:

Código:

        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;

Quando você quebra-la, a única diferença está no semlock () chamada, que é necessária em sistemas multi-processador central. Poderia ser SCO também é similarmente limitado. Porque não tentar uma distribuição Linux 2.0, como o RedHat 5.2, que utiliza Linux 2.0.36 (e usa o mesmo sem o código como acima). Instale-o e aferir o mesmo código. Isso seria uma grande ajuda para todos nós, eu acho.

otheus · #5 (**permalink**) 10-06-2008

Migurus,

I emailed os mantenedores do código. Esta é uma resposta eu tenho de volta de Alan "Maddog" Cox (com permissão para postar aqui):

Citação:

Talvez você possa contribuir para essa discussão (relativo SCO vs linux desempenho diferenças com semget):

Não, mas se você tem um bom teste caso, utilizando gettimeofday () ao invés de tempo
Assim, obtém alta precisão tempo um erro no arquivo de dados bugzilla.kernel.org como eu
Imagino Ingo Molnar e alguns outros possam estar interessados.

Alto desempenho código usa Linux futex fechaduras, em vez de fechaduras sys5 mas
ainda assim seria bom saber se há realmente uma grande diferença é essa e por que razão

Alan

Então aqui vai mais uma versão usando gettimeofday (). Não se preocupe em postar aqui os valores de referência, a não ser que sejam significativamente diferentes. No entanto, prepará-los para bugzilla:

Código:

#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);
}

migurus · #6 (**permalink**) 10-06-2008

Otheus, nunca tratou com informação sobre bugzilla, parece-me ti eu não beneficiar bastante e eu temo que vou postar algo não pertinente, por isso, se você concordaria que fazer você mesmo, aqui estão os resultados da versão 2. o seu 'gettimeofday baseado em «código, que re-executar 4 vezes mais para obter média:

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 você vê, não houve diferença entre os antigos testes.

Só para o meu esclarecimento: de alguma maneira as pessoas que participaram neste debate sobre unix.com formulação, bem como sobre kerneltrap e outros lugares foram muito preocupada com 2 coisas, que na minha perspectiva são irrelevantes para o tema da presente discussão: medir o tempo precisão e envolvimento de funcionamento dos vários processos / conchas etc enlameada que os resultados. Gostaria sinceramente que, se concordar com SCO vs Linux resultados foram comparáveis. Mas este não é o caso aqui. SCO é três vezes mais rápido, não importa que o meu método utilizado ou gettimeofday método muito preciso. Com todo o overhead sendo aproximadamente semelhantes, eu acho que nós estávamos tipo de espancamento no arbusto quando estávamos a tentar conseguir ter precisão na medição (que não se machucar, de cource!), Mas ele fez a discussão inchado.

Mais uma vez, graças a Otheus para suas sugestões, neste momento eu o código do kernel que você indique que mostra multi-cpu capacidade acrescenta uma camada de complexidade e que não ajudam a velocidade. Seu e strcmp's (kerneltrap fórum) recomendations de atualizar kernel do Linux são bem tomadas.
migurus

ramen_noodle · #7 (**permalink**) 10-06-2008

Só por contraste, em um moderno processador Intel PMS executando Linux 2.6.18 eu recebo mais
superior a um milhão de operações / seg.
Com base nisso eu não acredito que isto pode ser considerada um erro .. mais de uma crescente dor.
Linux sempre foi um projecto em marcha em frente. Você quer apanhar ou sofrer.
Linus é curto em desculpas para este modelo que eu tenha visto.

Código:

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

Em uma máquina FreeBSD 6.0 (uniprocessador), o tempo é interessante ...
Intel (R) Celeron (R) CPU 2.00GHz (1999,94-MHz 686-class CPU)

Código:

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

Mais UNIX e Linux Fórum Tópicos Você pode achar Helpfull
Fio	Thread Starter	Fórum	Respostas	Última postagem
semáforo	raguramtgr	UNIX para Dummies Perguntas & Respostas	7	06-15-2009 10:39
Semáforo	Jaken	Programação Shell Script e	2	04-04-2009 06:10
dmidecode, RAM velocidade \u003d "Actual Speed: Desconhecido"	Santi	Filesystems, Discos e Memória	0	02-16-2006 06:16
Semáforo	vjsony	UNIX para Dummies Perguntas & Respostas	3	04-07-2003 03:06
semáforo	yls177	UNIX para Dummies Perguntas & Respostas	1	10-09-2002 12:18

Thread Tools	Pesquisar este Thread
Show Printable Version Enviar esta página	Pesquisar este Thread: Pesquisa Avançada
Display Modes	Esta taxa Thread
Mude para o Modo Linear Hybrid Mode Switch to Threaded Mode	Esta taxa Thread: