Čo ešte stále neviete o Mac OS X Snow Leopard: Architektúra a technológia detailne

Hneď po uvedení systému Mac OS X Snow Leopard na trh ste si na MacBlog.sk mohli prečítať recenziu Alexandra Mravčáka, ktorá sa venovala všetkému, čo vám prinesie tento systém prevažne z užívateľského hľadiska. Zaujímalo vás ale niekedy aj hlbšie, prečo je systém svižnejší a čo všetko sa udialo pod povrchom?Mac OS X čelil od svojho uvedenia mnohým problémom so stabilitou, nedostatkom funkcií, bezpečnosťou, nekompatibilitou a všetkým zlovestnostiam, na ktoré si spomeniete. Preto bolo až do nedávna cieľom Apple liečiť tie najzávažnejšie nedostatky a Leopard bol zavŕšením tejto snahy – po všetkých stránkach dospelý operačný systém, ktorý vám dal minimum priestoru na kritiku.

~~Poznámka: Pre lepšie porozumenie článku odporúčam prečítať si moje staršie zhrnutie celkovej architektúry Mac OS X a tiež evolučný vývoj Mac OS X

Namiesto pridávania funkcií sa však Snow Leopard vydal smerom k dolaďovaniu a optimalizáciam. Apple si pri vývoji uvedomil prednostne niekoľko základných faktov:

• Menej je niekedy viac,
• úzke hrdlo počítača je pevný disk,
• veľa potencionálneho výkonu je nevyužitého, alebo nepovšimnutého.

Keď vložíte inštalačné DVD Snow Leoparda, určite budete myslieť na tvrdenie Applu, že inštalácia je takmer o polovicu rýchlejšia, než tomu bolo doposiaľ. Ako ale presuniete operačný systém z pomalého optického média na váš pevný disk tak rýchlo, pričom výsledný systém vyzerá a funguje skoro rovnako ako predchodca?

Menej je viac

Ľahko na to prídete, keď sa inštalácia skončí. Snow Leopard na disku zaberá výrazne menej miesta (menej dát na kopírovanie z DVD) a prvotná indexácia disku Spotlightom trvá sotva tretinový čas oproti minulosti. Otázka, ktorá nás zaujíma prednostne však je, kam zmizli tie kedysi nevyhnutné gigabajty dát? Časť odpovede, ktorá je každému známa sa skrýva vo vypustení kódu pre PowerPC. V minulosti obsahoval Leopard spustiteľný kód pre PowerPC vo verzii 32 aj 64-bit, Snow Leopard už PowerPC kód neobsahuje. Ostal kód len pre x86 (32-bit Intel) a x86_64 (64-bit Intel). Ak si uvedomíme, že prechod na Intel bol oznámený v teplý pondelňajší podvečer 6. júna 2005, teda len pred 4-mi rokmi, môže to trochu zamrzieť, ale jedná sa o nevyhnutný evolučný krok.

Ďalšia časť odpovede sa skrýva vo vylúčení prebytočných ovládačov. Je to síce rozumné, ale limituje to možnosti bootovať z jedného systémového disku viac rôznych počítačov s rôznym interným hardvérom. Rovnako sa môžete vyhnúť inštalácii prebytočných ovládačov pre rôzne tlačiarne výberom len tých najznámejších, a taktiež bola zo štandardu vyčiarknutá Rosseta. Aj keď si ju môžte pred inštaláciou ručne zaškrtnúť a nainštalovať, je to známka definitívneho konca a začiatku ignorancie architektúry PowerPC.

Ubudlo aj množstvo drobností, ktoré si možno ani nevšimnete. Radikálne boli preriedené templaty v základnej inštalácií XCode pre vývojárov v Carbone (všetky, takže nový Carbon project už nezačnete), Ruby a Python. Bola zrušená možnosť AppleTalk tlače, zápis na HFS (nemýliť si s aktuálnym HFS+ z roku 1998), ODBC Administrator, verzie Java 1.4 a 1.5, podpora pre pluginy v kontextových menu 64-bit aplikácií, vypustenie 32-bit screensaverov na 64-bit Intel CPU a množstvo ďalších drobností.

Kompresia ako ju nepoznáme

U Snow Leoparda sa taktiež začala používať hromadná komprimácia. Veľká časť systémových komponentov sú jednoduché dáta obsahujúce obrázky, zvuky alebo nastavenia. Tieto dáta sú odteraz komprimované. Obrázky sú prevažne ukladané ako JPEG alebo PNG, ozvučenie systému je prevažne v kodeku AAC, úvodné a ďalšie animácie sú uložené vo formáte MPEG-4/H.264. Dokonca aj súbory s nastaveniami (.plist) sa zmenšili vďaka použitiu kompaktnejšieho binárneho formátu miesto štruktúrovaného XML. Väčšina spustiteľných súborov je taktiež komprimovaná, ale keďže neexistuje nič ako komprimovaný formát pre spustiteľný kód, Apple si vymyslel vlastný trik. Zapracoval ho do svojho súborového systému HFS+ a jedná sa o transparentný spôsob kompresie, kedy prakticky nemáte ako priamo zistiť, či je, alebo nie je daný súbor komprimovaný.

Ukážme si najskôr, že nehovoríme o abstraktných pojmoch a použitie tejto kompresie je masívne. Ak si chcete nasledujúce postupy overiť doma, stiahnite si HFSDebug a afsctool . Prvý nástroj pochádza od známeho autora Amita Singha, ktorý sa preslávil predovšetkým knihou Mac OS X Internals. Možnosti programu sú široké a nájdete ich v dokumentácií. Nás však bude zaujímať jeho schopnosť identifikovať HFS kompresiu. Keď si program stiahnete, otvorte si Terminál a zadajte napríklad nasledujúci príkaz pre zistenie informácií o Chess.app:

sudo hfsdebug /Applications/Ches­s.app/Contents/Ma­cOS/Chess

Ak vám Terminál vrátil command not found, dôvodom bude, že sa nenachádzate v rovnakej pracovnej zložke ako program. Povedzme, že ste si uložili HFSDebug na plochu, napíšte jednoducho:

sudo /Users/Uzivatel/Des­ktop/hfsdebug /Applications/Ches­s.app/Contents/Ma­cOS/Chess

Nezabudnite samozrejme nahradiť časť ~~Uzivatel~~ vašim vlastným krátkym užívateľským menom. Ak ste uspeli, uvidíte dlhý výpis, z ktorého nás ale bude zaujímať posledná časť:

Tá je relatívne drobná a možno nezaujímavá, ale v skutočnosti odhalila všetko podstatné. Bližší význam prostredného riadku výpisu objasníme neskôr, teraz si ukážme, koľko miesta sa ušetrilo komprimáciou najlepšej hry na svete. Na to použijeme druhý nástroj, zadáme preto:

afsctool -v /Applications/Ches­s.app

Následný výpis nám zobrazí komprimovanú veľkosť súboru (ak nie, použijeme rovnaký postup úpravy príkazu s cestou k nástroju ako pri HFSDebug), nekomprimovanú veľkosť a vypočíta nám v percentách zisk ušetreného miesta:

Dosiahnutý kompresný pomer je 66,8%, čo je výborný výsledok a v našom prípade to znamenalo takmer 2,5 MB miesta, ktoré môžme využiť po svojom. Ale vo väčšom merítku, ktoré použil Apple sú úspory markantnejšie. Vyskúšajte si napríklad vhodiť do programu na analýzu priečinok System:

afsctool -v /System

Po chvíli čakania vás uvíta výsledok, že bolo ušetrených vyše 40 % miesta, čo pre vás znamená nie len zopár megabajtov, ale ušetrené gigabajty navyše. Ako tento zázrak ale funguje a ako je možné, že tieto komprimované súbory sú viditeľné aj zo starších systémov, ktoré o tomto spôsobe kompresie ani nechýrovali? Tieto súbory v skutočnosti čitateľné sú, ale nie úplne. Ak sa pozriete na náš Šach, zistíte zaujímavé veci. Znovu vyžijeme Terminal.app a tentokrát príkazy:

cd /; cd Applications/Ches­s.app/Contents/Ma­cOS; ls -l

Bude nasledovať výpis práv a hlavne veľkosti priečinka, kde je uložený strojový kód aplikácie Šach. Pokiaľ máte Snow Leopard, neprekvapí vás dnes už videná hodnota veľkosti. Ak máte starší OS, uvidíte nulu. V praxi to znamená, že skomprimovaný systémový súbor staršie systémy vidieť budú, ale priamo skomprimované súčasti zostanú skryté. Význam tohto počinu je v tom, že staršie systémy tieto súbory nebudú môcť poškodiť nevhodným zápisom, budú jednoducho preskočené. Kompresia sa vždy týka len resource forkov, ktoré slúžili pôvodne pre ukladanie štruktúrovaných dát, poväčšine tvar okna aplikácií, definície menu v menu bare a podobne. Každý súbor môže mať resource fork, ale je používaný majoritne aplikáciami. V praxi to teda znamená, že užívateľom tvorené súbory, ako napríklad text, zostanú kompresiou nedotknuté a čitateľné všetkými systémami Mac OS X. Systémové súbory, ktoré si nepotrebujete otvárať na iných počítačoch/sys­témoch sú skomprimované. Kompresiu ale môžte aplikovať globálne aj na celý priečinok, ak chcete. Pre vás je dostupná v podobe atribútu pre aplikáciu ditto, ktorý sa používa nasledovne:

ditto –hfsCompression [zdrojovy_subor] [cielovy_subor]

Keď to však budete robiť, spomeňte si aj na nasledujúci úryvok z manuálu pre príkaz ditto:

–hfsCompression
When copying files or extracting content from an archive,
if the destination is an HFS+ volume that supports compression,
all the content will be compressed if appropriate.
This is only supported on Mac OS X 10.6 or later, and is
only intended to be used in installation and backup scenarios
that involve system files. Since files using HFS+ compression
are not readable on versions of Mac OS X earlier
than 10.6, this flag should not be used when dealing with
non-system files or other user-generated content.

Kompresia a dopad na rýchlosť

Čo ale znamená táto kompresia okrem úspory miesta? Kompresia prináša aj rýchlosť, drží sa výroku na začiatku článku, že úzke hrdlo počítača je pevný disk. Mohlo by sa zdať, že načítať súbor do pamäti, dekomprimovať a až potom exekuovať musí byť zdĺhavý proces, ale v skutočnosti je to rýchlejšie, než načítať súbor v plnej veľkosti a potom ho bezstarostne spustiť. Príčinou je priepastný rozdiel vo výkone CPU a disku. Predpokladajme, že máme pevný disk, ktorý načíta súbor o veľkosti 1 MB za jednu sekundu, a procesor následne jeho spustením z RAM nestratí nič. Celkový čas je teda 1 sekunda.

Teraz si predstavme, že rovnaký disk načíta rovnaký súbor, ale už v komprimovanej podobe s veľkosťou 0,5 MB za pol sekundy. Následne CPU stratí 200 milisekúnd dekompresiou a až potom ho spustí. Celkový čas je teda 0,7 sekundy. Je to typický príklad výmeny cyklov CPU za operácie disku. Samozrejme, v reálnom svete treba zarátať mnoho ďalších premenných, ako je seek disku, jeho nekonštantná rýchlosť pri načítavaní blokov rôznej veľkosti a tak ďalej, čiže zisky môžu byť rôzne, no aj naozaj veľké. Procesor sa síce napracuje viac, ale to je nepodstatné, keďže procesor bežnéhu užívateľa je vyťažený väčšinu času na najviac 5 % a v budúcnosti s nárastom jadier to bude teoreticky ešte horšie (nižšie priemerné zaťaženie).

Cesty k súborom

Kým sa ešte venujeme súborovým systémom, môžme nepriamo nadviazať aj na iné vylepšenie. Je ním unifikovaná sada API pre prácu so súbormi. Cieľom tohto počinu je upratať a zrýchliť reprezentáciu umiestnenia súborov na disku. Poznáme totiž niekoľko spôsobov, ako pracovať s cestou k súboru. Prvým je stará dobrá plná cesta k súboru od koreňového adresára až po cieľový súbor. Jeho nevýhoda z hľadiska aplikácií je, že pokiaľ premiestnime aplikáciu, pôvodné cesty k súborom nebudú fungovať. Jednoduchý príklad, ktorý môžete preskočiť, ak problematike rozumiete:

~~Predstavme si aplikáciu uloženú v priečinku „Program“ v koreňovom adresári. Bude sa skladať zo súboru Program.app a jednoduchého súboru s nastaveniami zvaného Nastavenia.xml. Cesta k tomuto súboru je teda „/Program/Nas­tavenia.xml“ a presne týmto spôsobom je zapísaná v programe. Ak však zoberieme priečinok „Program“, ktorý obidva súbory obsahuje a premiestnime si ho napr. do Dokumentov, cesta k nastaveniam sa zmení „/Dokumenty/Pro­gram/Nastaveni­a.xml“. Náš program sa však vždy odrazí od koreňového adresára a hľadá cestou dole, čo sa mu nepodarí a tak vytvorí nový súbor s prázdnymi nastaveniami na starej adrese. Pokiaľ sa však bude program odkazovať rozumnejšie pomocou relatívnej adresy od seba samého, nebude mu zmena umiestnenia prekážať~~

Druhý spôsob, ako pracovať s cestou k súboru je vyhľadať ho nezávisle na jeho aktuálnom umiestnený pomocou unikátnych ID, čo sa v OS X dá dosiahnuť pomocou dátového typu zvaného FSRef. Posledným tretím spôsobom je každému známe URL, ktoré môžu odkazovať aj na súbor na vzdialenom počítači.

Pokiaľ teda aplikácia chce vykonať operáciu, strávi výrazný čas iba transláciou týchto adries na iné a späť. Ak potrebuje zložitejšiu informáciu o súbore, musí sa obrátiť zase na inú službu. To je však už minulosť. Snow Leopard všetky adresy zlúčil na jednotný dátový typ URL a pribalil k nemu aj všetky podstatné atribúty, ku ktorým aplikácie budú mať prístup. Do budúcnosti je to najlepšie riešenie, keďže vďaka tomu existuje možnosť neobmedzene pridávať ďalšie vlastnosti, podporu cachovania a metadát.

Pribudli aj bookmarky na súbory uložené na disku, ktoré nahrádzajú pôvodné Mac OS aliasy. Sú lepšie uspôsobené na odkazovanie súborov cez sieť a môžu obsahovať ďalšie metadáta pre aplikácie. Vďaka tomu si budú môcť aplikácie udržiavať vždy funkčný zoznam súborov, napríklad posledných upravovaných a pritom sa nezaujímať, že mohli byť premiestňované užívateľom. Tieto funkčnosti sa však najskôr musia zapracovať do nových aplikácií, aby sme z nich mali priamy úžitok.

QuickTime X, kým vlastne je?

Modrá ikona a prehrávač, hovoríte si, ale ten je len povestnou špičkou ľadovca. QuickTime je veľmi komplexná vrstva, bez ktorej by ste si neotvorili ani obyčajný obrázok, neprehrali žiadne audio alebo video. Poskytuje multimediálne služby aplikáciam a podobne. Vekmi veľmi narástol, prispôsoboval sa novým možnostiam systému (zažil všetko od Sytem 7 cez Mac OS 9 až po OS X), a taktiež výpočtovému výkonu moderných strojov, kedže pri jeho uvedení vládla svetu ešte Motorola 68030 s taktom do 33 MHz. Aj z hľadiska bezpečnosti uz však bola situácia neúnosná a QuickTime potreboval radikálnu zmenu, ktorej sa ale Apple bál kvôli spätnej kompatibilite.

A tak sa začala nová kapitola nie len pre modrú ikonku a prehrávač, ale prakticky pre tretinu operačného systému. Možno poznáte ten legendami opradený príbeh, keď si vývojári iPhonu v Apple uvedomili, že aby dohnali toto zariadenie k prehrávaniu videa, vtedajší QuickTime 7 im bol k ničomu. Bol príliš komplexný, neohrabaný a so slabšími vnútornosťami iPhonu nebol schopný práve zázrakov. Dalo to za vznik tomu, čo poháňa iPhony a najnovšie aj Macy a nesie názov QuickTime X. Priniesol nám podporu pre akceleráciu H.264 videa pomocou GPU (momentálne len na nVidia 9400) a celkovo dobrú rýchlosť aj na veľmi slabom HW pri prehrávaní náročných kodekov. Taktiež svojim spôsobom prestal QuickTime robiť viac, než bolo potrebné. Staršie verzie QuickTime pri otvorení súboru na prehrávanie najskôr analyzovali celý súbor bit za bitom, aby ho mohli parsovať a nájsť v ňom všetky stopy a ďalšie informácie potrebné k prípadnému editovaniu. Úpravy však nie sú tak častá požiadavka užívateľa, namiesto toho si skôr želáte, aby sa začal súbor prehrávať tak skoro, ako to je možné. API QuickTimu X to teda robí po novom a miesto analyzovania začne hneď prehrávať. Až keď si užívateľ vyžiada operáciu mimo rozsahu prehrávania, vyvolá sa výnimka programu a začne s prácou, ktorú API pre QT 7 robil hneď na začiatku. Práve vďaka týmto možnostiam API (API je interface, cez ktorý aplikácie môžu ovládať funkcie, ktoré im primárne nepatria, v tomto prípade funkcie QT X) je aplikáciam umožnené ku QT X pristupovať iba a jedine takto, nie priamo. Je tu však háčik, o ktorom sme ešte nehovorili. Čo bude svet robiť bez komplexnosti QuickTimu 7?

Odpoveď je jednoduchá. Apple totiž systém vybavil vrstvou QTKit, ktorá za sebou schováva ako pôvodný QuickTime 7, tak aj QuickTime X a vyberie ktorý z nich má volať. Bude tomu tak asi až do doby, než QuickTIme X dospeje a plne nahradí všetku funkčnosť, ktorú na seba zatiaľ preberá sedmička, teda všetko okrem prehrávania, nahrávania a exportu. Pokročilejšie úpravy videa a tiež prehrávania starších typov videa, extrakcia audio a video stôp, strih a podobne sú dostupné len pre QuickTime 7. Obstaróžnejšie (podľa Applu všetky, ktoré nejdú prehrať na iPhone) typy videa by šli určite nahradiť plug-inmi a nemalo by to dlho trvať, ale QT X nepodporuje zatiaľ ani plug-iny.

Apple vyriešil dokonca aj problém, ktorý by mohol nastať kvôli tomu, že zatiaľčo nový QT X je plne 64-bitová aplikácia, pôvodný QT 7 zostal stáť na 32-bitoch. QTKit je sám o sebe tiež 64-bitový, a tak pokiaľ aplikácia potrebuje službu QT X, všetko je v poriadku. Ak ale potrebuje službu 32-bitového QT 7, spustí sa samostatný 32-bitový proces inicializovaný pomocou QTKit zvaný QTKitServer, ktorý sa postará o obsluhu QT 7. Keď prestane byť potrebný, ukončí sa.

Tento proces je možno trochu zložitejší, ale všetko sa deje bez starostí zo strany programátorov aplikácií, či nebodaj užívateľa. Je pravdepodobné, že tomu tak bude až do doby, než QT X bude poskytovať všetku potrebnú funkčnosť na poli editácie videa a podpory plug-inov. To zrejme potrvá ešte nejaký čas, keďže Apple musí nahradiť QT vyvíjaný spolu 18 rokov. Priniesť všetko naraz by sa možno dalo, ale vybralo by si to určite krutú daň v množstve chýb a dier, takže namiesto toho Apple spustil pozvoľný a neviditeľný prechod, čo mu ide tradične na jedničku. Nemusíme sa ale báť, že by to trvalo príliš dlho, lebo Final Cut Studio okrem prepisu z Carbonu taktiež čaká na príchod 64-bitového prostredia podobného tomu, ktoré poskytuje QT 7 so všetkými funkčnosťami, teda na dokončenie QT X.

Využitie viacerých procesorových jadier

Pri uvedení prvých dvojjadrových procesorov sa svet začal pomaly pripravovať na to, ako ich vlastne využiť. Avšak pri uvedení prvých dvojjadrových procesorov mal Apple už za sebou dlhé roky praxe s tvorením viacprocesorových počítačov (pre zaujímavosť, prvý Dual CPU stroj Apple bol z roku 1996, PowerMacintosh 9500, 2× 180 MHz PowerPC 604) a tento náskok s uvedením Snow Leoparda ďalej prehĺbil a prišiel s ním na pomoc vývojárom.

Ikona LLVM

Prvý krok je ale aj tak na strane vývojára, ktorému dal do ruky Apple zbraň zvanú LLVM kompilátor (Low Level Virtual Machine). Tento relatívne mladý kompilátor vznikol v roku 2000 a od roku 2005 Apple prispieval do tohto projektu. Prvé ovocie tejto stratégie bolo pretavené už v minulosti, keď sa v Leopardovi použil na interpretáciu niektorých grafických úkonov spojených s OpenGL, pokiaľ ich nezvládali integrované grafické čipy. Jeho špecifickou vlastnosťou bolo totiž tvorenie veľmi rýchleho kódu, ktorý môže navýšiť výkon aplikácie až o 20 %. Jeho využitie v Leopardovi však bolo minimálne a sotva mohlo predznamenať to, čo prišlo. Doteraz sa používal ako základný kompilátor oveľa starší, ale spoľahlivý a overený GCC s počiatkami existencie kdesi v 80-tych rokoch. Projekt na nahradenie GCC novým, ale s GCC kompatibilným kompilátorom zvaný Clang (C-language) priniesol svoje ovocie. Programátor si teda môže vybrať z tejto ponuky kompilátorov: GCC 4.2 (najstarší, doteraz používaný, predvolený), LLVM-GCC 4.2 (medzikrok) a Clang (najnovší prírastok do rodiny, Applom odporúčaný).

Oba novšie kompilátory majú všetko, čo sa od moderného produktu čaká, teda oveľa kratšie časy kompilácie (teda menej čakania zo strany programátora na jeho počítač) a o v priemere 5 až 25 % rýchlejšie aplikácie v porovnaní s GCC. Samozrejme, je o čosi viac priateľskejší voči užívateľovi a poskytuje uľahčenú a vylepšenú podporu pre tvorbu viacerých programových vlákien, ktoré môžu paralelne bežať na viacerých jadrách/proce­soroch. Skrátka, tvorí ideálny základ pre tvorbu aplikácii, ktoré si budú rozumieť s Grand Central Dispatch, ktorému uľahčia zisťovanie, na koľko samostatných vlákien sa môže problém, ktorý aktuálne aplikácia rieši, rozdeliť. Grand Central Dispatch (ďalej len GCD) určí, na koľko vlákien rozdeliť problém v skutočnosti má. Ako to myslím?

Ikona Grand Central Dispatch

Bežný programátor musí myslieť na to, ako rozdeliť problém na čo najväčšie množstvo nezávisle vykonateľných úloh a následne sa rozhodnúť, v akom množstve programových vlákien sa budú problémy riešiť, povedzme že identifikuje 128 úloh nezávislých na sebe. Ak zvolí príliš málo vlákien, povedzme dve (teda jedno bude za sebou riešiť napríklad 64 úloh), na 8-jadrovom Macu Pro sa bude 6 jadier nudiť. Pokiaľ bude myslieť na budúcnosť a zvolí 128 (1 úloha na vlákno), na dvojjadrovom iMacu sa nebude diať nič iné, iba sa budú vlákna neustále prehadzovať na dvoch jadrách, čo zaberie veľa času a nastane dramatické spomalenie. GCD tento problém rieši. Neočakáva vlákna, ale zbierku samostatne vykonateľných úloh, ktoré si usporiada do pamäti. Z nich potom na základe dostupných systémových prostriedkov upradie optimálny počet vlákien. Optimum neráta len na základe toho, koľko jadier je v počítači, ale hľadí aj na to, do akej miery je ktoré z nich vyťažené. Pokiaľ teda na dvojjadrovom iMacu beží jedno jadro naplno, úlohy aplikácie dočasne zoradí do jedného vlákna a v momente, keď sa druhé jadro uvoľní, prehodnotí svoj prvotný záver a zvyšné úlohy bude rozdeľovať do dvoch vlákien. Z hľadiska budúcnosti je to výborný krok, pretože programátor nebude musieť aplikáciu ďalej upravovať, keď Intel uvedie povedzme 16-jadrový procesor. Hneď na začiatku jednoducho identifikuje toľko možných úloh, koľko vie (napríklad aj 1000) a výkon bude rásť automaticky. Praktické tiež je, že GCD je ľahko dostupná jednoduchá C knižnica v samotných základoch systému, takže prístup k nej nie je zložitý a netreba robiť veľké úpravy aplikácií. Čo však GCD nerieši, je samotná identifikácia nezávislých úloh, táto najťažšia časť `ostáva stále na programátorovi.

Využitie nie len grafickej karty

Už od úsvitu OS X sa snaží Apple preniesť čo najviac úloh z ramien samotného CPU. Doposiaľ to bolo preto, aby sa zvýšila responzívnosť a nezaťažoval sa CPU drobnými úlohami spojenými s grafickým rozhraním. Neskôr pribudla snaha preniesť problémy s prehrávaním HD videa na slabších procesoroch. Snow Leopard ale už nechce využívať grafickú kartu len ako prípadnú pomoc, ale zapojiť ju ako serióznu výpočtovú jednotku na úrovni CPU. Veď prečo by aj nie, vývoj grafických kariet sa ubral smerom k masívnej paralelizácii a špecializácii na určité úlohy, v ktorých je hrubý výkon na úplne inej úrovni než u všestranných CPU. V hrubých číslach, výkon nVidie 9400M je 54 GFlops (floating point operations/sec), výkon 8600 GT je 113 GFlops a u ATI (dnes AMD) HD 4870 dodávanému k Macu Pro za príplatok je prelomená hranica 1 TFlops. Pre porovnanie, priemerný CPU osadený v notebooku dosahuje okolo 20 GFlops a aktuálna špička Intelu sa pohybuje na úrovni 50 GFLops.

Čo s takým masívnym výkonom robiť? Na to Apple odpovedal technológiou OpenCL. Vrcholovou (neskôr uvidíte, že doslova vrcholovou) snahou Applu je využiť každý milimeter štvorcový kremíku v počítači. OpenCL sa často predstavuje ako cesta k behu bežných aplikácií na grafických kartách, čo je pravda, ale je to iba časť pravdy. Zoberme to ale poporiadku.

GPU je výkonná súčiastka počítača, avšak vďaka vysokej špecializácii. V minulosti neboli grafické karty schopné vôbec žiadneho programovania a všetky jej možnosti boli fixné. Z tohto sa postupne začali vyvíjať moderné grafické čipy, ktoré už bolo možné programovať, ale iba veľmi obmedzeným spôsobom v hraniciach grafického segmentu v striktne grafických programovacích jazykoch. Neexistoval žiadny všeobecný programovací jazyk, a to hlavne kvôli veľkým rozdielom v architektúrach jednotlivých grafických čipov. Na poli bežných CPU je nutnosť, aby obyčajný program bol schopný bežať na procesore AMD K7 z roku 1999 rovnako, ako na poslednom procesore Intel, pretože obaja výrobcovia sa držia istých štandardov. To ale u GPU vôbec neplatilo, čo grafika, to iný typ a množstvo výpočtových jednotiek s rôznymi inštrukčnými sadami. Programátor ale nie je ochotný sa týmto rozdielom vystavovať, komu by sa chcelo myslieť na všetky riziká s tým spojené, keď vlastne aj CPU nebeží až tak pomaly? Lepšia je situácia, keď programátor napíše kód, ktorý nejakým zázrakom pobeží na akomkoľvek GPU. Ak náhodou nie, tak nech súčasť OS (ktorú nepotrebuje poznať) zariadi, aby operáciu vyrátal CPU. Skrátka, aby existoval nejaký medzičlánok, ktorý programový kód posunie grafickej karte a odtieni programátora od toho, aké limity a možnosti daná grafika poskytuje. Vo svete hier a 3D grafiky také niečo spĺňa OpenGL. Vo svete viacúčelového počítania si túto úlohu na seba zobral OpenCL. Tak ako OpenGL, aj OpenCL je už oficiálny štandard a bude výrobcami časom implementovaný do každej novej grafickej karty.

Pri vývoji OpenCL spolupracoval Apple s nVidiou, takže v ňom nájdeme veľa spoločného s technológiou tejto spoločnosti zvanou nVidia CUDA*. Vďaka tomu je OpenCL podporované na mnohých už existujúcich kartách a čaká sa teda len na to, až ho začnú objavovať tvorcovia vašich programov. Jedná sa vlastne o jazyk podobný obyčajnému jazyku C s doplnkami pre vektorové výpočty. V zásade niečo podobné, ako niekdajšie pokusy zo strany výrobcov CPU ako SSE2 až 4 alebo MMX. OpenCL muselo na seba ale vziať aj spomenutú zodpovednosť za staršie grafické čipy, ktoré nič ako CUDA nepoznali a tým pádom nepodporujú OpenCL (napr. v Macoch populárna Intel GMA X3100 alebo GMA 950). Taktiež preberá zodpovednosť za to, že niektoré programy proste bežia rýchlejšie na CPU (čo počítač, to iný rozdiel výkonu CPU a GPU). OpenCL hľadí na všetky tieto faktory, vie komu má priradiť dotyčnú úlohu a na koľko vlákien ju rozdeliť, tak ako Grand Central Dispatch. V podstate, OpenCL je nadstavba Grand Central Dispatch, ktorá ale už presahuje rámec CPU a hľadí na *všetky prostriedky v počítači ako na celok. Dokáže dve vlákna nechať rátať grafickou kartou a jedno posunúť procesoru alebo naopak. Programátor teda nemusí riešiť optimalizáciu pre nové generácie HW, o všetko je v budúcnosti postarané. Dokonca aj hybridné riešenia pre integráciu grafických kariet do procesorov, alebo nastupujúcu grafiku zloženú zo zmenšených a patrične upravených Pentií Pro z dielne Intelu zvanú Larabee má Apple týmto spôsobom pokrytú.

6 + 4 = 64-bit

Výraznou zmenou v architektúre Snow Leoparda je prestavba jeho komponentov na 64-bit. Praktické zisky z použitia 64-bit inštrukcií sú na pováženie, keďže reálne potrebné boli 64-bitové aplikácie len vo vysoko presných matematických aplikáciach, veľkých databázových programoch a podobne. V bežných situáciach docielite prevažne jedine mierny nárast spotreby operačnej pamäte. Na nových procesoroch je však už počítanie v 64-bit preferované a sú v ňom predsalen o čosi efektívnejšie. Hlavne marketing však presvedčil masy, že číslo 32 je na modernú dobu primalé, a tak sa Apple prispôsobil a pripravil sa aj na budúcnosť.

Prierez vrstvami verzií Mac OS Tiger, Leopard a Snow Leopard. Prebraté z Arstechnica.com

Snow Leopard disponuje 64-bitovou verziou všetkých kľúčových zložiek, teda od kernelu, kernel extensions, základných driverov, cez všetky vrstvy systému až po Cocoa a systémom bundlované aplikácie ako Finder, Dock a podobne. Ostal prítomný 32-bit Carbon, ktorý ako je známe, už nebude prestavaný na 64-bit verziu a je odsúdený na pomalý zánik. Obsiahnutý je samozrejme aj 32-bit Cococa, pre podporu veľkej časti dnes používaných 32-bit aplikácií. Znie to ako dokonané dielo, ale v skutočnosti je tu stále ešte malý háčik.

Na všetkých počítačoch pre bežných zákazníkov okrem serverového segmentu, Snow Leopard primárne štartuje s 32-bit kernelom. Otázka znie prečo, keď váš CPU podporuje 64-bit? Problém 64-bit kernelu je v tom, že si vyžaduje aj 64-bit ovládače a kernel extensions. Tie sa však momentálne nevyskytujú v dostatočne hojnom počte. To tiež vysvetľuje, prečo 64-bit kernel bootuje štandardne len na Xservoch, kde je menšia potreba pripájania externých periférií a veľa HW radičov už svoju 64-bit verziu má. Apple tiež vzal do úvahy fakt, že užívatelia radi štartujú z jedného disku viac počítačov a nie všetky musia byť kompatibilné.

Čo vlastne znamená kompatibilný? Aj keď váš Mac štandardne neštartuje do 64-bit kernelu, stále s ním môže byť kompatibilný a systém sa s trochou snahy nechá presvedčiť k štartu v tomto móde. Jediné, čo k tomu potrebujete je 64-bit verzia EFI (obdoba BIOS-u známeho z PC, základný SW počítača na zavádzanie OS) a 64-bit CPU. Ako zistíte že máte túto verziu EFI? Buď sa spoľahnete na to, že Macy s dátumom výroby po roku 2008 ho obsahujú, alebo použijete tento príkaz:

ioreg -l -p IODeviceTree | grep firmware-abi

Následný výpis v okne Terminálu vám dá jasnú odpoveď. Ďalej musíte vedieť, či je váš CPU 64-bitový, to si zistíte tak, že v kliknete na jablko v Menu Bare a zvolíte „About this Mac“. Pokiaľ si v položke Processor nájdete, že vlastníte Intel Core Duo, je to 32-bit, pokiaľ tam bude Intel Core 2 Duo alebo Xeon, ste za vodou. S výnimkou úplne prvých generácií iMacov, Macov mini a MacBookov Pro z roku 2006 bolo ale všetko vybavené 64-bit CPU. Posledná podmienka je nebyť na čiernej listine Snow Leoparda, kde sa nachádzajú Mac mini a MacBook. Ak na nej nie ste, smelo môžete bootovať aj 64-bit kernel, ale má to vôbec zmysel?

Všetky výhody 64-bitovosti máte k dispozícii aj s 32-bit kernelom. Mac-a si môžte osadiť viac než 4 GB RAM (aj staršie verzie OS X zvádnu do 32 GB RAM cez 32-bit obdobu PAE) a aplikácie ju využijú bez problémov až do dnes nepredstaviteľnej veľkosti 16 EB (Exabyte). Pred príchodom Snow Leoparda mohla každá separátna 32-bit aplikácia využiť najviac 4 GB RAM. Avšak 32-bit kernel ako taký v súčasnosti bez problémov uskromní svoje nároky pod 4 GB adresného priestoru. Pre bežného užívateľa teda nemá žiadny zmysel usilovať o bootovanie 64-bit kernelu. Pre koho ale áno a prečo?

Opäť sa jedná hlavne o poistku do budúcna, kedy bude kapacita operačnej pamäte rásť do dnes zrejme len ťažko predstaviteľných hodnôt. Už dnes nie je nevídané postaviť korporátny server s 64 GB RAM. Povedali sme síce, že aplikácie nebudú mať problém využiť také množstvo RAM, ale jednou z úloh kernelu je mapovať použitie operačnej pamäte a na každý 4 KB segment si musí vytvoriť 64-bajtovú štruktúru. To znamená, že je v tomto konkrétnom prípade potrebné 1 GB priestoru vyhradiť len na mapovanie RAM, takže na samotné úlohy kernelu ostávajú 3 GB, čo nie je ideálny stav. Čo ak sa ale postaví server s 256 GB RAM? Nabootuje sa 64-bit kernel a je po probléme, a to je jediný signifikantný rozdiel. Samozrejme, už dnes je tento 64-bit kernel o čosi rýchlejší, keďže procesory sú na počítanie v 64-bit móde optimalizované a tiež sa ním odstraňujú niektoré prekážky výkonu v špecifických serverových aplikáciach. Pri domácom použití počítača však nemožno zbadať rozdiel. Pokiaľ neveríte a chcete nulovo viditeľný rozdiel vyskúšať, nech sa páči:

sudo nvram boot-args=”arch=x86_64″

Nezabudnite, že časť „sudo“ vynucuje root práva pre príkaz za ňou, k čomu samozrejme musíte zadať administrátorské heslo. Pokiaľ si chcete 64-bitovosť vychutnať iba jednorázovo, držte pri štarte počítača klávesy „6“ a „4“ naraz. Pri najbližšom reštarte sa všetko vráti do pôvodného stavu. Overiť si, či bežíte naozaj v 64-bitovom kerneli môžte nasledovným príkazom:

uname -v

Ten vám vo výpise vráti riadok informácií, kde na konci uvidíte buď úspech, alebo text obsahujúci i386. Ak zistíte, že vám nejaká aplikácia alebo ovládač robí problémy a budete sa chcieť vrátiť k pôvodnému kernelu, držte klávesy „3“ a „2“, alebo použite príkaz:

sudo nvram boot-args=”arch=i386″

Menšie zmeny s veľkým dopadom

V tejto časti sa budeme venovať drobnostiam, ktoré však stoja za zmienku, pozrieme sa na zmeny väzieb medzi aplikáciami a súbormi, ktoré tvoria, odhalíme pravdu o antivíruse údajne zabudovanom v Snow Leopardovi a povieme si prečo aplikácie štartujú rýchlejšie než v minulosti.

Linkovanie aplikácie a súboru

Vypĺňanie kódu tvorcu v prostredí REALbasic

Keď vytvoríte súbor s textom, ako pri jeho otvorení Finder opätovne zistí aká aplikácia ho vytvorila a akú má spustiť? Podľa koncovky. Ale nie je to tak celkom pravda. V skutočnosti dominuje rozpoznávanie súborov podľa metadát. Ak vytvoríte obrázok s príponou .JPG, zároveň doň bude pridaná informácia o type súboru (JPEG), a tiež kód tvorcu súboru s dĺžkou štyroch znakov (v prípade Photoshopu je to 8BIM). Kód tvorcu je vždy unikátny a poctivo sa registroval, pokiaľ by programátor použil už iný používaný kód tvorcu, spadol by naň traktor. Máme tak tri nezávislé informácie a aj keď súbor a jeho koncovku premenujeme, otvorí sa v správnej aplikácii. Ak si to ale vyskúšate na systéme 10.4 a novšom, pohoríte, pretože u nich sa používa UTI (Uniform Type Identifiers). Ten sa ale mení podľa koncovky, takže ponuka aplikácií na otvorenie v kontextovom menu Findera sa určuje práve podľa nej, default-ná aplikácia sa však odvodzuje podľa kódu tvorcu. Ak si to ale vyskúšate v Snow Leopardovi, znovu pohoríte. Ten už totiž kód tvorcu vôbec neuznáva. Čo to v praxi znamená? Ak si v staršom systéme (Tiger, Leopard) uložíte JPEG obrázok pomocou Photoshopu, Finder pri dvojkliku naň spustí Photoshop, aj keď default-ne otvára súbory .JPG cez Preview. Snow Leopard však už tieto metadáta nepoužíva a riadi sa len koncovkou, takže nami vytvorený súbor v Photoshope otvorí pri najbližšej príležitosti cez Preview, alebo inú aplikáciu, ktorú si užívateľ môže nadefinovať globálne pre daný typ. Pre programátora to môže znamenať drobné komplikácie, ale pre väčšinu z nich to znamená len to, že nebudú vypĺňať jedno políčko v Builder Settings (ako na obrázku z nastavení mojej aplikácie).

Trochu bezpečnosti navyše

Apple aktuálne nemusí riešiť problémy, ako je stotisíc nových malwarov ročne, ale snaží sa udržať si svoj náskok pred tvorcami škodlivého kódu. Tým sa momentálne príliš neoplatí tvoriť vírusy pre Mac, keďže zatiaľ neexistuje spôsob, ako na tom zarobiť, kdežto botnet z Windows PC má hodnotu zlata. Aby sa to nezmenilo, okrem bežných bezpečnostných záplat sa v Leopardovi zaviedli metadáta stiahnutých programov, ktoré pri prvom spustení uviedli svoj pôvod a dátum stiahnutia. V Snow Leopardovi sa zaviedol aktualizovateľný blacklist malwaru a pri otváraní napríklad obrazov disku so známymi vírusmi budete upozornený.

Nie je to však antivírus, iba vás systém upozorní, že sa jedná o škodlivý kód. V súčasnosti vás ale prakticky nemá na čo upozorňovať, výnimkou môže byť napríklad nelegálne šírený iWork s trojanom. Mohlo by to vyzerať tak, že vás systém upozorní, ale trojan sa už rozšíri, avšak napríklad tento potrebuje spustiť inštaláciu a zadať do nej administrátorské heslo. Rovnako je to aj s ostatnými pokusmi o vírusy pre Mac – zatiaľ nie je taký, ktorý by nepotreboval súčinnosť užívateľa. Všetky takto fungujúce nebezpečenstvá z minulosti sú na čerstvo aktualizovaných systémoch už nefunkčné. Rovnako aj Safari vás upozorní, ak sa chystáte navštíviť stránky známe šírením nebezpečného softwaru. Pokiaľ máte aj tak strach, existujú antivírusy pre Macy, ale tie zbytočne obsadzujú prostriedky a hlásia vírusy pre Windows, ktoré vám neublížia. Paradoxne, antivírusy pre Macy sa svojou potrebou širokých prístupových práv stávajú potencionálnym zdrojom chýb a bezpečnostných dier. Jediná možná výhoda takého SW pre Mac OS X je v tom, ak nechcete nechtiac vášmu šéfovi poslať vírus pre Windows v neznámom .DOC dokumente, či iných podobných scenároch.

Rýchlosť, tentokrát pri spustení aplikácie

Štart aplikácie a čas, ktorý na to potrebuje je často predmetom benchmarkov a z hľadiska užívateľa je to dôležité kritérium pre hodnotenie responzívnosti počítača. Preto Apple trochu popracoval aj tu a upravil knižnicu DYLD (Dynamic Loader for Darwin), ktorá slúži na dynamický loading všetkých frameworkov, plug-inov a dynamických knižníc, ktoré bude spustený proces potrebovať. Keď sa tieto operácie ukončia, až vtedy sa spustí hlavný kód aplikácie. V praxi je však potrebné načítavať často rovnaké knižnice a preto si ich DYLD nahráva do cache. Tá je zdieľaná a obsahuje kópie hlavných knižníc systému, pri ktorých už DYLD urobil v minulosti prípravy pre priame použitie s aplikáciami a ich previazania (prebindings). Ľubovoľný proces si ich môže z tejto cache prebrať a ušetriť tak čas. Ďalšími optimalizáciami sa dosiahla tiež úspora pamäte v rozsahu pár stoviek kilobajtov na proces.

Zhrnutie

Najviac asi upúta celková zmena ponímania počítača a jeho výpočtového výkonu, keď vďaka spojeniu OpenCL a Grand Central Dispatch nie je potrebné premýšľať z akých komponentov sa počítač skladá a ako ich využiť. O všetko sa operačný systém postará sám a vyťaží hardware pokiaľ možno na maximum. Prvý krok však musia učiniť developeri a osvojiť si prácu s novým kompilátorom na báze LLVM, ktorý umožní optimálne fungovanie aplikácií so spomenutým OpenCL a GCD. V snahe využitia potenciálu počítačov sa vyvíjala aj HFS kompresia, vďaka ktorej sú systémové súbory menšie a rýchlejšie sa tak načítajú do pamäti, kde sa dekomprimujú a použijú, čo je nie len úsporné, ale aj rýchle. Počas doby, než by sa nekomprimované dáta načítali z pevného disku, je možné ich v skomprimovanej podobe načítať aj rozbaliť a získať aj nejaký čas navyše.

Nesporne racionálnou voľbou je aj pripraviť sa v predstihu na nárast možností hardware a prepísať všetko na 64-bit. Apple sa však narozdiel od konkurencie neunáhlil a default-ne ponechal kernel 32-bitový s možnosťou prepínania. Prechod je vďaka tomu čistý a na dlhú dobu dopredu je tak Snow Leopard bez zmeny schopný využiť plný potenciál prakticky akokoľvek veľkej RAM a neobmedzuje potrebou mať všetky ovládače a doplnky v 64-bit verziách. Vo vzdialenejšej budúcnosti Applu bude stačiť predvoliť štart plne 64-bitového kernelu, na ktorý už dnes môžu vývojári upraviť svoje doplnky a prepísať ovládače. Aplikácie ako také pokojne môžu ťažiť zo všetkých výhod 64-bitov.

Snow Leopard sa okrem prípravy na budúcnosť a celkové zrýchľovanie sústredil aj na pretrhnutie okov minulosti a spätnej kompatibility. Mnohé nepoužívané a zastaralé schopnosti systému, ako napríklad zápis do HFS, tlač cez AppleTalk a podobne, zmizli. Prišiel na rad aj takmer dve dekády starý QuickTime, ktorý je plynulo a postupne nahrádzaný moderným QuickTimom X. Nejaký čas budú tieto technológie koexistovať a Apple sa pomocou QTKit (ktorý slúži ako komunikačná vrstva aplikácie a samotného QuickTimu) postaral o to, aby programátori nemuseli túto zmenu vnímať.

Snow Leopard je všetko to, čo nám Apple sľuboval, je vyladený, modernizovaný a dospelejší. Ale pridáva aj mnoho nového a po mnohých stránkach bez preháňania aj revolučného, na čo si u konkurencie zrejme pár rokov počkáme.

Zdroje a námety na ďalšie čítanie:

• Arstechnica.com: Výborná recenzia OSX 10.6 od Johna Siracusu
• AppleInsider.com: 64-bitov podrobne od Daniela Diligera
• AppleInsider.com: Ochrana pred malware od Daniela Diligera
• Apple.com: Prehľadne a  jednoducho rozpísané funkcie a novinky Snow Leoparda
• Aktuality.fir­stnet.cz: Prehľadný rozpis vyškrtnutých vecí zo Snow Leoparda, na stránke je aj mnoho ďalších informácií o architektúre OS X v CZ jazyku
• TidBITS.com: Podrobnejšie o konci kódov tvorcov v súborch
• Sealiessoftwa­re.com: Podrobný pohľad na problematiku zmien v DYLD
• Developer.apple­.com: Release notes k DYLD v OSX 10.6