Bonjour et bienvenu par les États-Unis à la UNIX et Linux Forums! Merci de votre visite et vous joindre à notre communauté mondiale.
|
Bonjour et bienvenu par les États-Unis à la UNIX et Linux Forums! Merci de votre visite et vous joindre à notre communauté mondiale.
|
|
google unix.com
|
|||||||
| Forums | S'inscrire | Forum Rules | Liens | Albums | FAQ | Liste des membres | Calendrier | Recherche | Aujourd'hui, les postes | Marquer les forums comme lus |
 |
| High Level Programming Posez vos questions à propos de C, C + +, Java, SQL, et d'autres langages de programmation ici. |
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 09:39 AM |
| Sémaphore | Jaken | De programmation et de script Shell | 2 | 04-04-2009 05: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 02:06 PM |
| sémaphore | yls177 | UNIX pour les nuls Questions et réponses | 1 | 10-08-2002 11:18 PM |
 |
Powered by 
|
|
|
LinkBack | Thread Tools | Recherche sur ce Thread |
Rating: 
|
Modes d'affichage |
|
|
09-24-2008
|
||||
|
||||
|
Ma version de treillis ne dispose pas de c-drapeau, ou tout autre drapeau similaire à celle que j'ai utilisée avec trace sous Linux.
Sur Linux: $ / Sbin / sysctl-a | grep shm ... <snip erreur msgs> vm.hugetlb_shm_group \u003d 0 kernel.shmmni \u003d 4096 kernel.shmall \u003d 2097152 kernel.shmmax \u003d 33554432 Q: Pourquoi SHM sémaphore paramètres affectent la performance? Aussi, au cas où j'ai rencontré ce $ / Sbin / sysctl-a | grep sem <snip erreur msgs> kernel.sem \u003d 250 32000 32 128 Dernière édition par migurus; au 09.24.2008 07:55 PM.. Motif: ajout d'info |
|
09-25-2008
|
|||||
|
|||||
|
Citation:
|
|
09-30-2008
|
|||||
|
|||||
|
Comme je l'ai suggéré précédemment: LinuxQuestions.org.
Depuis le goulot d'étranglement, semble être à l'intérieur du système d'appel, je vous suggère de regarder aussi le noyau liée à BB (KernelTrap.org est bonne). |
|
09-30-2008
|
||||
|
||||
|
Merci Otheus et Jim, je me suis assez détaillée réponse ici:
sémaphore la vitesse d'accès | KernelTrap Ainsi, le noyau 2.6.9, n'est pas la meilleure moderne h / w. J'apprécie everebodys temps! |
|
10-01-2008
|
|||||
|
|||||
Bravo à vous pour votre ténacité! Cependant, je pense que ce n'est pas la fin de celui-ci.
J'ai fait un peu de recherche sur la réponse de strcmp. 2.6.9 a été publié en 2004 et est standard avec RHEL 4, livré avec la glibc 2.3.4. Pentium 3 étaient âgées en 2004. RHEL 5 est fourni avec le noyau 2.6.18 et glibc 2.5.12. Donc j'ai fait quelques points de repère. J'ai suivi la suggestion de strcmp et utilisé une chute timer "méthode, où la boucle commence et se termine après le moment () appel a pris note d'un changement en quelques secondes. Il ya de 10 à 100 ms variance de chaque côté de la chute, donc j'ai pris une moyenne de plusieurs pistes. Ensuite, je divise la ops / s par le numéro de la vitesse du processeur (cycles / s) pour obtenir des "tics par op.
Pour les tics / op, les petits, c'est mieux. Ainsi, le noyau 2.6.18 est en effet plus vite que les noyaux 2.6.9. Le Xeon est beaucoup plus lent. Vraisemblablement, les noyaux ont été compilées par un plus petit dénominateur commun. N Optimisation des drapeaux ont été activé, mais il y avait une différence dans les compilateurs: la 2.6.9, gcc 3.4.6 hôtes utilisés, tandis que les plus récents ont été avec gcc 4.1.1. Aussi, il convient de noter que nous n'avons pas un AMD exécutant 2.6.9, ni un fonctionnement Xeon 2.6.18. Mai, il est très bien que le problème est que ces noyaux ne sont pas compilées optimale pour les différentes architectures. Pourquoi les Xeons sont beaucoup plus lent est assez surprenant, compte tenu de leur utilisation en tant que caractéristique HPC composants. Néanmoins, aucun de ces résultats semblent expliquer la question fondamentale: Pourquoi est-SCO tellement plus rapide? Dernière édition par otheus; au 10.08.2008 05:57 AM.. Motif: j'ai dit que le Xeon est beaucoup plus rapide quand il a été beaucoup plus lente. |
|
10-01-2008
|
|||||
|
|||||
|
Voici mon code:
Code:
#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);
}
|
|
| Bookmarks |
| Thread Tools | Recherche sur ce Thread |
| Modes d'affichage | Rate this thread |
|
|
Mode Hybrid
