szemafor hozzáférés sebessége - Page 6

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

Köszi a kódot, amikor futott azt kaptam ezt:
2.6.9/Xeon/3.2 MHz
(3 fut)
129186,76 semop / s (8784700/68) [100]
129367,65 semop / s (8797000/68) [100]
129257,35 semop / s (8789500/68) [100]

SCO/Xeon/3.2 MHz
(3 fut)
527641,18 semop / s (8969900/17) [100]
564212,50 semop / s (9027400/16) [100]
535800,00 semop / s (9108600/17) [100]

Látom SCO képes ezt nagyjából 3-szor több semop / s, mint a Linux.

BTW, a H / W ugyanaz, azt hiszem, hogy a kiküldött ezen looong szálat.

A Linux, majd újra elküldeni ide s / w verziók:
Fedora 2.6.9
gcc - ver.3.4.3
ldd - ver. 2.3.5
glibc - Ver. 2.3.5

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

Ez egy kicsit off-topic, de attól félek, nem teljesen érti a kódot.

Saját megértése céljából a kezdeti hurok

Idézet:

Originally Posted by otheus

Kód:

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

van, hogy az egész mérési pont az a változás a második. Igaz?

Következő,
Van még két hurkokon: először fut 8750000 alkalommal, mivel a maxloop értéke 1000000,

Akkor futni hurok a 1250000-szer, ahol minden 100. iterációs is ellenőrzi az idő, és ha a második változás, hogy kitör

Idézet:

Originally Posted by otheus

Kód:

    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;

Mi ez a technika, mellyel ellenőrizhető minden n-edik iterációs for? Miért nem ellenőrzi idő minden iteráció? van, mert ez adjunk sok extra időt hívások és sáros a méréseket?

Ön tisztázása lenne méltányol.

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

Idézet:

Originally Posted by migurus

Ez egy kicsit off-topic, de attól félek, nem teljesen érti a kódot.

Ez elég ON téma és az egyik ok, I posted a kódot.

Idézet:

van, hogy az egész mérési pont az a változás a második. Igaz?

jobb.

Idézet:

Mi ez a technika, mellyel ellenőrizhető minden n-edik iterációs for? Miért nem ellenőrzi idő minden iteráció? van, mert ez adjunk sok extra időt hívások és sáros a méréseket?

Azt válaszolta meg. AFAIK minden alkalommal () hívás során a rendszer hívást. Azt hiszem van egy jobb út, a kezelés, de ez az első, hogy jutott eszébe.

Én becsüllek ellenőrzése a kódot. Hogy én vagyok hajlamos kudarc lehet egy szerény alulbecsléséhez.

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

Megnéztem a mag. Nem voltak jelentős változások 1995-ben (a 2.0-s verzió), 1998 (előtt változat 2,4), majd ismét az "O (1) scheduler" (nem biztos). Íme a kód - óta változatlan 2,4 -, hogy nem semctl (GETALL):

Kód:

        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;

Íme a kód 2.0:

Kód:

        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;

Ha szünetet le, az egyetlen különbség a semlock () hívás, ami szükséges a több CPU rendszerek. Lehetne SCO is hasonlóképpen korlátozott. Miért nem próbálja meg a linux 2,0 elosztás, mint a RedHat 5.2, amely felhasználja a Linux 2.0.36 (és ugyanazt a kódot sem, mint fent). Telepítse a benchmark, és ugyanazt a kódot. Ez lenne a nagy segítség, hogy mi mindannyian, azt hiszem.

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

Migurus,

Én e-mailben a fenntartók a kódot. Ezt a választ kaptam vissza Alan "Maddog" Cox (engedélyével utáni ide):

Idézet:

Talán hozzájárulhat ahhoz, hogy ezt a vitát (a SCO vs linux teljesítmény különbségek semget):

No de ha van egy jó próba alkalmazásával gettimeofday (), nem pedig időben
így lesz, nagy pontosságú idő adatfájl hiba bugzilla.kernel.org, mint én
képzelni, Ingo Molnar, és még néhány más is érdekel.

Nagy teljesítményű Linux-kódot használ futex zárak helyett sys5 locks, de
még így is örülök, hogy tudom, ha valóban olyan nagy különbség, és miért

Alan

Tehát itt van egy újabb verzió használatával gettimeofday (). Ne fáradj hozzászólás a referenciaértékeket ide, kivéve, ha azok jelentősen eltérőek. De felkészítik őket a bugzilla:

Kód:

#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, soha nem foglalkozott jelentéstételt bugzilla, úgy tűnik, ti meg nem nagyon minősülhet, és attól félek, nem fogják elküldeni valamit helyénvalók, hogy ha megállapodnak abban, hogy csináld magad, itt vannak az eredmények a 2. verziója te gettimeofday-alapú "kód, amit újra futni 4-szer akkora, mint hogy átlagosan:

SCO
$ Tmx2
575108,94 semop / s (5000000/8694005)
$ Tmx2
575215,00 semop / s (5000000/8692402)
$ Tmx2
575183,63 semop / s (5000000/8692876)
$ Tmx2
559832,49 semop / s (5000000/8931243)

Linux:
$ ./tmx2
129363,77 semop / s (5000000/38650699)
$ ./tmx2
129428,22 semop / s (5000000/38631452)
$ ./tmx2
129601,55 semop / s (5000000/38579786)
$ ./tmx2
129511,76 semop / s (5000000/38606534)

Amint látod, nincs különbség a korábbi vizsgálatok.

Csak az én egyértelműsítés: valahogy az embereket, akik részt vettek ezen a vitát unix.com megfogal valamint kerneltrap és más helyeken is nagyon aggasztja, 2 dolgot, hogy az én szempontból lényegtelen, hogy az érintett e téma: idő mérésének pontosságát és részvétel A futó folyamatok többszörös / shells etc, hogy sáros az eredményeket. Én teljes mértékben egyetértek, hogy ha a SCO kontra Linux eredmények összehasonlíthatók legyenek. De nem ez a helyzet itt. SCO háromszor gyorsabb, nem számít, mi az én használt módszer vagy gettimeofday nagyon pontos módszer. Minden felülről is nagyjából hasonló, azt hiszem, mi voltunk a fajta dobogó körül a bokrot, amikor megpróbálták elérni, hogy a mérési pontosság (ami nem fáj, a cource!), Hanem arról, hogy a szál duzzadt.

Ismét csak köszönet Otheus meg javaslatokat, hogy ebben a pontban a kernel kódot tűhegy azt mutatja, hogy a több CPU képesség hozzáteszi réteggel összetettsége, és nem segíti a sebesség. Ön és strcmp's (kerneltrap fórum) recomendations frissíteni a Linux kernel jól venni.
migurus

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

Csak ellentétben a modern SMP Intel processzorral futó Linux 2.6.18 jutok tovább
mint egy millió művelet / mp.
Ennek alapján nem hiszem, ez minősíti a hibát .. egyre több fájdalom.
Linux mindig is a projekt előre mozgást. Vagy felzárkózni, vagy szenvednek.
Linus a rövid apologies ehhez a típushoz, hogy láttam.

Kód:

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

A FreeBSD 6,0 gép (uniprocessor) a Érdekes ...
Intel (R) Celeron (R) CPU 2.00GHz (1999,94-MHz 686-class CPU)

Kód:

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

Több, UNIX és Linux fórum témák Ön által talált Hasznos
Szál	Thread Starter	Fórum	Válaszok	Utolsó hozzászólás
szemafor	raguramtgr	A UNIX a dummies Kérdések és válaszok	7	06-15-2009 10:39 AM
Szemafor	Jaken	Shell programozás és Scripting	2	04-04-2009 06:10 PM
dmidecode, RAM sebesség \u003d "Jelenlegi sebesség: Ismeretlen"	Santi	Fájlrendszerek, lemez és memória	0	02-16-2006 06:16 AM
Szemafor	vjsony	A UNIX a dummies Kérdések és válaszok	3	04-07-2003 03:06 PM
szemafor	yls177	A UNIX a dummies Kérdések és válaszok	1	10-09-2002 12:18 AM

Téma eszközök	Keresés a téma
Show Nyomtatható verzió Küldés e-mailben	Keresés a téma: Részletes keresés
Megjelenítési módok	Rate this thread
Váltás Linear Mode Hibrid üzemmód Switch to Threaded Mode	Rate this thread: