CPU info

[leguan]

Ahojte, mozno to spada do HW, ale je to take aj tam/aj tam.

Mam biely MacBook, trosku ma zarazilo, ked v MenuMeters (ale aj inde, napr. v MySQL adminovi) pozriem info o CPU, vidim:
2x i386 (80486) 2000.0 MHz, 2.0 GB RAM

Tu i386 neviem, preco pise (je darwin kernel buildnuty bez optimalizacie!?). A tu 486 uz vobec netusim…

sysctl -a hw
…….
hw.optional.mmx: 1
hw.optional.sse: 1
hw.optional.sse2: 1
hw.optional.sse3: 1
hw.optional.x86_64: 1
hw.optional.supplementalsse3: 1
hw.machine = i386
hw.model = MacBook2,1
hw.ncpu = 2
…….

Co to znamena? Ide o optimalizaciu kernelu? Alebo o nieco ine? Ma zmysel sa tym zapodievat? Pise vam to iste?

[DoNaLd]

Zajtra ti dam vediet

[Dominik Balogh]

Mne pise to iste… kernelu velmi nerozumiem, takze viac neviem povedat :)

[toxygen]

Par info: Tiger nie je plne 64-bitovy. niektore casti operacneho systemu (ako napriklad graficke prostredie) su nativne 32-bitove aplikacie. Plna 64-bitova “nativnost” systemu (cize system bude kompletne 64bitovy) ma prist az v Leopardovi (ak nahodou nezmenili plany :).

kernel v tigerovi je tiez 32-bitovy. to si lahko mozes overit prikazom uname -m
(aj napriek tomu, mam pocit, ze darwin (kernel) uz ma 64bitove pointre, ale to z neho hned nerobi nativne 64-bitove jadro)
v tigrovi je 32bitovych veci popravde velmi vela (pocnuc bashom a konciac xargs).

no, aby som to nejak zhrnul: tiger je aj nie je 64bitovy – jadro je skompilovane v 32 bitovom mode, ale ma podporu 64-bitovych pointerov. na druhu stranu, su vsak v systeme aj plne 64bitove kniznice (hlavne pre programy co bezia z command line + nejake dalsie serverove veci)

a to zdesenie, ze to “nie je” optimalizovane na i386 myslim tiez nema velke opodstatnenie. nie som sice ziaden expert, ale myslim si (cize som si nie isty), ze apple pouziva sice oznacenie platformy i386, ale ich modifikacie gcc v podstate optimalizuju aplikacie na aktualne procesory, cize i386 nemusi byt to iste, co pri klasickom (nie apple upravovanom) gcc. (len co budem mat trochu casu, ponorim sa do toho hlbsie).

ak by ta zaujimali nejake clanky:

http://www.osnews.com/story.php/9220/64-bit-Support-in-Tiger-Is-Only-for-Server-Processes
http://www.itjungle.com/tug/tug041405-story03.html

a to ze mas 32bitove mysql ti tiez nemusi kazit naladu.
donedavna platilo pravidlo, ze pri prechode 32bit -> 64bit databazy stracali vykon.
to vsak zmenil amd, ktory celkom slusnou logistikou pri opterone dosiahol, ze v 64bitovom mode bezali databazy rychlejsie.
kazdopadne, jeden velmi stary benchmark mas tu:
http://www.anandtech.com/IT/showdoc.aspx?i=2447&p=5

dneska je realita trosku ina (hlavne prichodom core 2 duo a vylepseniami – napr. znizenie memory latency) a databazy uz podavaju lepsi vykon v 64bitovom mode aj na inteloch (mozem potvrdit z vlastnej skusenosti).

no a dneska to vyzera asi takto,
citujem:
“Two weeks ago I ran many benchmarks on my new server comparing various installs & configs on 32 & 64 bit, using CentOS 4.4 (basically the same as RHEL).

I found two main benefits of 64bit:
– 64bit OS recognized all avail RAM (8gigs), (32bit only had approx 7.5 gigs avail to the OS)
– MySQL 5 was 44% faster on 64bit”
datum: Mar 26th 2007

aj ked to znie velmi lakavo, bohuzial 64-bitova verzia pre Intelacke Macy neexistuje a tak si moc nepomozes.

kedze nemozes nic zmenit, tak pre teba teraz nema zmysel sa tym zaoberat.
a ano, aj ja mam taky isty vystup zo sysctl, ako mas aj ty.

ono, pravda je taka, ze pokial nerenderujes veci, alebo nepouzivas aplikacie, ktore potrebuju niekedy namapovat viac ako 8gb pamate, tak pre teba 64bitov nema skoro ziadne vyhody. nejake 2-3% vykonu su zenedbatelne a tiez by som chcel poznamenat, ze ked bude graficke rozhranie skompilovane s -mcpu=x86_64, tak bude bezat pomalsie) – cize pre teba 64bitov moze znamenat casto aj nevyhody. takze zatial mozme byt spokojny, ze mame 32bitove kernely, 64bitove procaky a operacny system 32bitovy s podporou 64bitovych aplikacii :)

[leguan]

dik za 32vs64bit info. Napada ma otazka – kedze vacsinu narocnejsich casti GUI aj tak riesi procak na grafickej karte, ak ten nie je 64bitovy, pomoze 64bit procak ako core2 duo tomu nejako?

ja som ale mal namysly (aj ked na 99%) zbytocne obavy s chybajucej optimalizacie pre core2 duo. samozrejme vzhladom na detekciu sse3, etc.., v jadre uplne zbytocne. Len som sa cudoval, ze dalo i386 a nie i686 alebo tak.

[Dominik Balogh]

toxygen: kolko teda moze v Tigrovi vyuzit maximalne jedna aplikacia spolu RAM? Bol som v tom ze 3GB. Plati to pre vsetky 32bit systemy. Odkial mas 8GB?

[Dominik Balogh]

Mimochodom, pamatovy radic vo vsetkych Macoch je zatial (okrem Mac Pro) len 32 bitovy.

[toxygen]

no pamatovy radic (ak mas namysli hw suciastku) tak ani nema zmysel, aby bol vacsi na inych macoch, lebo do nich viac ako 4gb ram asi nenapchas :)

“aplikacie, ktore potrebuju niekedy namapovat viac ako 8gb ”
tu som sa pomylil, malo tam byt 4gb (pretoze to je adresovatelne velkost v 32 bitovom mode)

Ten “limit” 3gb (v linuxe s jadrom skompilovanym s CONFIG_NOHIGHMEM=off; ak skompilujes s bud =4GB alebo =64GB /podla toho kolko mas fyzicky ram ak >4gb tak davas 64GB ak menej tak davas 4GB/ tak mas adresovatelnu vsetku ramku aj v 32bitovom mode (aj viac ako 4gb)), resp. 4gb(macosx) pre jednu aplikaciu platil iba po panthera. V tigrovi, uz ako som spominal, su pointre aj niektore kniznice 64bitove. (ale aj to sa dalo obist vsemoznymi workaroundami, ako napriklad mmap() a namapovat miesto z disku, ale o tom inokedy :) )

“Tiger takes Mac OS X another small step in the 64-bit direction by allowing any process to see a 64-bit address space. Such a process must use 64-bit pointers in its code, of course, and that means that any libraries it uses must also be compiled to use 64-bit pointers.”

http://arstechnica.com/reviews/os/macosx-10.4.ars/4

aplikacia skompilovane voci 64bitovym knizniciam budu mat v tigrovi teda k dispozicii 64 bitovy adresny priestor (16 exbibytov – neviem, ci je to slovensky spravny vyraz)

leguan – aj napriek tomu, ze dneska su vsetky (urcite sa najdu aj vynimky :) ) GPU 32-bitove, maju ovela vacsi vykon v grafickych vypoctoch oproti core 2 duo. je to vec specializacie, boli stavane robit len urcity druh vypoctov a ten im ide. GPU su radovo desatnasobne a viac rychlejsie ako dneskajsie najvykonnejsie procesory v grafickych vypoctoch. takze odpoved znie nie, core 2 duo nijak tomu nepomoze (mimochodom, keby bol core 2 duo 32 bitovy, tak by bol o trosku lepsi v grafickych vypoctoch, ako ked je 64bitovy)

to, ze ta architektura je i386 a nie i686 trosku prekvapilo aj mna (uz davnejsie :) ), ale uz som napisal, ako si to vysvetlujem ja. nie je i386 ako i386 :)

[Autor]

Príspevky