Semaforens adgang hastighed - Side 2

otheus · #1 (**permalink**) 09-18-2008

Da du ikke synes at følge instruktionerne, jeg forventer ikke, at De benchmark følgende kode. Hvis du gør, og dine resultater er generelt meget uventet, skal du gøre et notat om det her.

Code:

#include <stdio.h>
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>
#include <time.h>
#define NSEMS   2
main(int argc, char *argv[])
{
    time_t start,stop;
    long int i;
    int sid;
    key_t key;
    ushort vals[NSEMS] = { 0, 0 };

    key = ftok("/tmp",99);
    start=time(NULL);
    for (i = 0; i < 5000000; 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");
      }
    }
    stop=time(NULL);
    printf("%.2f semop/s [%i,%i]\n", (double)i/(stop-start), vals[0], vals[1]);
}

epoke · #2 (**permalink**) 09-19-2008

Bare for vægt, dine resultater omfatter overhead ved at oprette en lang række processer, og i hver af dem, trykning en linje med tekst til en bufferfunktion blok enhed, og udsejlingsdato processen. Flaskehalse i nogen af disse operationer er meget mere tilbøjelige til at forklare de resultater, end de ting, du forsøger at teste.

migurus · #3 (**permalink**) 09-19-2008

Jeg kompileret og køre loop afprøvningsregler Indsendt af Otheus.

Xeon / SCO resultater: 555.555,56 semop / s [0,0]
Xeon / Linux resultater: 128.205,13 semop / s [0,0]

Jeg har ikke adgang til PIII kassen lige nu, men da resultaterne er samme (proportionalberegning) som det, jeg så i min test Jeg tror det ikke er afgørende ikke at have PIII resultater her.

Så vidt overhead nævnt af Era - Jeg er klar over det, da den er tæt ligner situationen, at jeg evaluering, så det en gyldig test og ikke en forglemmelse.

Så Er der nogen har en idé om, hvad den flaskehals, kan være? eller hvor kan man se? Jeg virkelig sætter pris på din tålmodighed med mig og din vedholdenhed med at komme til bunds i det.

jim McNamara · #4 (**permalink**) 09-19-2008

Adgang til en Semaforens - hvis der ikke er nogen dødvande - det er en Direct Memory Access operation, der tilføjer en hel side eller multipla at behandle hukommelse har overhead. Det kan medføre en dyrere opkald: brk (), hvis ingen hukommelse er der allerede.

Det afhænger af, hvad

Code:

size mycode

siger i alt, der rundes op til et minimum af PAGE_SIZE (mutiple) grænseforholdene (stack frame grænseforholdene normalt), som kan efterlade ekstra flere sider i hukommelsen. Ser på, hvad der viser, der skal afsættes til bunke. Som en begyndelse. Du kan ringe sbrk (0) at finde i slutningen af processen hukommelse.

shmget tildeler fra bunke i de fleste implementeringer: / proc / sys / kernel / sh * proc abonnentfortegnelser har delt hukommelse oplysninger. kerne-indstillinger kontrol delt hukommelse operationer.

prøv dette:

Code:

gcc -p -g -o otherus otheus.c
otheus.c
grpof otheus

Det vil vise cum tid + # opfordrer til hver af funktionen opkald. Du kan se, om / hvor der er et problem. Hvis der er ét med semaforer derefter semget bliver dit mest sandsynlige problem - tildeling af sider i hukommelsen.

jim McNamara · #5 (**permalink**) 09-19-2008

PS opkald utimes (struct TMS *) til de faktiske tidspunkter, plus granularitetskravene er CLK_TCK, normalt måde bedre end tid ().

gettimeofday kan bruges til at få væggen tid endnu mere præcist som godt. utimes () returnerer clock_t væg tid.

otheus · #6 (**permalink**) 09-20-2008

Citat:

Oprindeligt Indsendt af jim McNamara

PS opkald utimes (struct TMS *) til de faktiske tidspunkter, plus granularitetskravene er CLK_TCK, normalt måde bedre end tid ().

gettimeofday kan bruges til at få væggen tid endnu mere præcist som godt. utimes () returnerer clock_t væg tid.

Jim, utimes () ikke gør, hvad du tror, at det gør. Gettimeofday er mere korrekt, men derefter koden er en smule mere kompliceret. Microsecond forskelle vil ikke producere forskelle i resultater, han ser.

migurus · #7 (**permalink**) 09-19-2008

Jim,
Jeg har aldrig prøvet profilering før, så jeg løb ind i nogle problemer her:
$ Gcc-pg-o tstloop tstloop.c
$ Tstloop
128.205,13 semop / s [0,0]
$ Gprof tstloop
gprof: gmon.out fil mangler call-graf data

Nogen idéer?

Hvad angår brugen af tid vs gettimeofday (som i virkeligheden jeg gjorde brug) er helt irrelevant, jeg forsøger at se, hvor mange gange i sekundet system er i stand til at skabe en proces, som blot ville læse en Semaforens.

Tak.

Mere UNIX og Linux Forum Emner du måske kan finde Helpful
Tråd	Thread Starter	Forum	Svar	Last Post
Semaforens	raguramtgr	UNIX for dummyer Spørgsmål & svar	7	06-15-2009 09:39 AM
Semaforens	Jaken	Shell Programmering og Scripting	2	04-04-2009 05:10 PM
dmidecode, RAM hastighed \u003d "Nuværende Hastighed: Ukendt"	Santi	Filsystemer, disketter og Hukommelse	0	02-16-2006 06:16 AM
Semaforens	vjsony	UNIX for dummyer Spørgsmål & svar	3	04-07-2003 02:06 PM
Semaforens	yls177	UNIX for dummyer Spørgsmål & svar	1	10-08-2002 11:18 PM

Thread Tools	Søg denne tråd
Vis Printvenlig Version Email denne side	Søg denne tråd: Avanceret søgning
Display Modes	Bedøm denne tråd
Switch to Linear Mode Hybridtilstand Switch to Tråd Mode	Bedøm denne tråd: