sémaphore la vitesse d'accès - Page 2

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

Puisque vous ne semblent pas suivre les instructions, je ne vous attendez pas à vous de comparer le code ci-dessous. Dans le cas où vous le faites, toutefois, et les résultats sont encore largement inattendue, s'il vous plaît prendre note de cela ici.

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

ère · #2 (**permalink**) 09-19-2008

Juste pour attirer l'attention, les résultats comprennent les frais de démarrage d'un grand nombre de procédés, et dans chacun d'eux, l'impression d'une ligne de texte à un périphérique bloc en mémoire tampon, et la sortie du processus. Les goulets d'étranglement dans l'une de ces opérations sont beaucoup plus susceptibles d'expliquer les résultats que la chose que vous essayez d'essai.

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

J'ai compilé et exécuter le code de la boucle d'essai envoyé par Otheus.

Xeon / SCO résultats: 555.555,56 semop / s [0,0]
Xeon / Linux résultats: 128.205,13 semop / s [0,0]

Je n'ai pas accès à la boîte de PIII maintenant, mais que les résultats sont identiques (en proportion), comme ce que j'ai vu dans mon test, je pense qu'il est crucial de ne pas de ne pas avoir PIII résultats ici.

En ce qui concerne les frais généraux mentionnés par Era - Je suis conscient, comme il est près à la situation que je suis d'évaluation, si un test valide et non pas un oubli.

Alors, est-ce que quelqu'un a une idée de ce que pourrait être le goulot d'étranglement? ou où chercher? Je vous remercie de votre patience avec moi et votre ténacité à aller au fond de celui-ci.

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

Accéder à un sémaphore - en supposant qu'il y ait pas de blocage - il s'agit d'un accès direct à la mémoire opération, l'ajout d'une page entière ou des multiples processus de la mémoire a des frais généraux. Elle peut impliquer une activité coûteuse appel: brk (), si pas de mémoire est déjà là.

Cela dépend de ce que

Code:

size mycode

dit en total, arrondi à un minimum de PAGE_SIZE (mutiple) frontière (stack frame limite habituellement), ce qui peut laisser plusieurs pages supplémentaires de la mémoire. Regardez ce qui se montrent à allouer aux tas. Dans un premier temps. Vous pouvez appeler sbrk (0) pour trouver la fin du processus de la mémoire.

shmget alloue de tas dans la plupart des implémentations: / proc / sys / kernel / sh * proc répertoires ont la mémoire partagée information. paramètres du noyau de contrôle des opérations de mémoire partagée.

essayez ceci:

Code:

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

Qui permettra d'afficher le temps passé cum + # demande pour chacun des appels de fonction. Vous pouvez voir si / où il ya un problème. S'il ya un message avec des sémaphores alors semget sera votre problème le plus probable - l'attribution de pages de mémoire.

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

PS appel utimes (struct tms *) à temps réel, plus la granularité est CLK_TCK, généralement bien meilleur que le temps ().

gettimeofday peut être utilisé pour obtenir mur du temps, même avec plus de précision ainsi. utimes () retourne clock_t mur du temps.

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

Citation:

Posté par jim McNamara

PS appel utimes (struct tms *) à temps réel, plus la granularité est CLK_TCK, généralement bien meilleur que le temps ().

gettimeofday peut être utilisé pour obtenir mur du temps, même avec plus de précision ainsi. utimes () retourne clock_t mur du temps.

Jim, utimes () ne fait pas ce que vous pensez qu'il fait. Gettimeofday est plus juste, mais le code est un peu plus compliqué. Microseconde différences ne produira pas les disparités dans les performances, il est à voir.

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

Jim,
Je n'ai jamais essayé de profilage avant, j'ai donc rencontré un problème ici:
$ Gcc-pg-o tstloop tstloop.c
$ Tstloop
128.205,13 semop / s [0,0]
$ Gprof tstloop
gprof: gmon.out fichier est manquant appel graphique des données

Des idées?

En ce qui concerne l'utilisation du temps par rapport à gettimeofday (qui, en fait je ne l'ai utilisé) est très pertinente, je suis en train de voir combien de fois par seconde système est capable de créer un processus qui serait tout simplement lire un sémaphore.

Merci.

Plus d'UNIX et Linux Forum Sujets Vous trouverez peut-être utile
Fil	Thread Starter	Forum	Réponses	Last Post
sémaphore	raguramtgr	UNIX pour les nuls Questions et réponses	7	06-15-2009 10:39 AM
Sémaphore	Jaken	De programmation et de script Shell	2	04-04-2009 06:10 PM
dmidecode, RAM vitesse \u003d "Current Speed: Unknown"	Santi	Systèmes de fichiers, disques et mémoire	0	02-16-2006 06:16 AM
Sémaphore	vjsony	UNIX pour les nuls Questions et réponses	3	04-07-2003 03:06 PM
sémaphore	yls177	UNIX pour les nuls Questions et réponses	1	10-09-2002 12:18 AM

Thread Tools	Recherche sur ce Thread
Voir la version imprimable Envoyer cette page	Recherche sur ce Thread: Recherche avancée
Modes d'affichage	Rate this thread
Switch to Linear Mode Mode Hybrid Switch to Threaded Mode	Rate this thread: