x86 vs G5, Linux vs OSX

Tobb problemam is van a cikkel... Az egyik pl. az utasitasok sebessegenek osszehasonlitasanal. Aztmondja pl. hogy ugyannannyi es ugyanolyan utasitast teszteltek, es annak a sebesseget merik. Ezzel csak az a baj, hogy az architekturalis kulonbsegek miatt, ua. feladathoz PPC-n altalaban _kevesebb_ utasitas szukseges. Pl. mert 3 operandusosak az utasitasok, igy nem kell fel-ala kavargatni a regiszterek kozott, meg reloadolni folyton az ertekeket amivel dolgozol. Egy x86 core, barmennyire cache meg register renaming optimalizalt a dolog, a plusz utasitasok miatt mindenkeppen hatranyba kerul, az instruction dekodert megtoltik ezek az utasitasok, es maris kesz a jo kis pipeline stall.

Akkor a Lightwave tesztnel igy kisutik, hogy hat ez tokjo Intel optimalizalt, es nemtudjuk h. mennyire van Altivecre, de valoszinuleg semennyire. Ha pedig nem, vagy csak tessek-lassek van Altivec kod benne, akkor kb. ugyanaz van, amit a G4-em is csinal a maga kategoriajaban, hogy rendes optimalizalas nelkul, felkaru oriaskent tartja a lepest az SSE2-re meg mindenre optimalizalt x86 kodokkal.

Ja es az OS X lassu, ez teny. Nem szeretem a Macet, de ez nem a processzor hibaja, meg akkor sem, ha amugy tavolrol sem a G5 a kedvenc PPC procim... Egyebkent en biztos megismetelnem a teszteket PPC64-es Linuxszal is. Szoval kicsit nekem ilyen sokadik "akkoris bebizonyitjuk hogy az x86 a gyorsabb" c. probalkozasnak tunik, objektiv alarc moge rejtve. :) De nyilvan en is elfogult vagyok, valamilyen iranyban.

A teszt tenyleg hianypotlo, a napi humoradagomat tekintve pl. eletmento volt.

``This means that applications use slower user-level threads like in FreeBSD and not fast kernel threads like in Linux. It seems that FreeBSD 5.x has somewhat solved the performance problems that were typical for user-level threads, but we are not sure if Mac OS X has been able to take advantage of this.

In order to maintain binary compatibility, Apple might not have been able to implement some of the performance improvements found in the newer BSD kernels.''

Nem lenyeges, de a FreeBSD mar eleg regota egy hibrid user/kernel threading mixet alkalmaz (KSE), hasonlot ahhoz ami a regebbi Solarisokban volt. Az is reszletkerdes, hogy most melyik ``newer BSD kernel''-re gondol a csavo, mert ugye mind a haromban mas-mas threading van, pl az OpenBSD borzalmasan lassu es gany tisztan user-level threadinget alkalmaz. De hogy azt honnan vezeti le, hogy az OS X-ben user level threading van, arrol fogalmam sincs. Ebbol a szempontbol az OS X threadingje inkabb a Linuxeval rokon, gyakorlatilag a szabvanyos POSIX pthreads API, ami kernel threadinget hasznal (e kore persze megvannak a szokasos Carbon es Cocoa wrapperek, az NSThreads es tarsai, csak azt nem tudom, hogy jon ez a MySQL-hez). Mivel a threadinget a Machbol vette az az OS X, igy nem valoszinu, hogy a KSE-t valaha atemelik a FreeBSD-bol.

Az igazi hulyeseg mondjuk ezutan jon:

``As we increase the level of concurrency in our database test, many threads must be created. The Unix process/thread creation is called "forking" as a copy of the calling process is made.

lmbench "fork" measures simple process creation by creating a process and immediately exiting the child process. The parent process waits for the child process to exit. The benchmark is intended to measure the overhead for creating a new thread of control, so it includes the fork and the exit time.''

Tehat uj threadet ujabban fork()-kal hozunk letre. Valo igaz, OS X-en jelentos az overheadje egy uj processz letrehozasanak, de konyorgom mi koze ennek a threadinghez? A faszi legalabb az alapoknak utananezhetett volna, mielott ekkora orbitalis baromsagokat ir: megmeri mekkora overheadje van egy thread letrehozasanak/kilepesenek, mindezt a fork() overheadjen keresztul. Jaj.