V minulém článku jsem nakousl historii i specifika běhu Windows NT na počítačích s jinými procesory než Intel/AMD x86 a přiblížil pracovní stanici Bull Estrella z poloviny 90. let, která mi slouží pro testování. To byly takové ty obecnější informace, které v nějaké formě jsou na internetu všude možně. Tentokrát popíšu, jak se doopravdy žilo člověku, co si takový počítač koupil místo Pentia, co za problémy jsem řešil, co nefungovalo, co je vůbec dostupné za software a hlavně, jak rychlé to tedy bylo – jak při vykonávání nativního kódu, tak v emulaci x86.

Abych si mohl počítač řádně užít, musel jsem nejdřív vyřešit několik nedostatků – nefunkční zvuk a slabou grafickou kartu bez 3D akcelerace. Protože co bych to měl v roce 1996 za hi-end workstation, kdyby nebyla maximálně multimediální. Když tak nad tím přemýšlím, dnes už se to slovo nepoužívá, ale dřív bylo slovo multimédia takový buzzword jako dnes AI…

Trápení se zvukem

Když jsem počítač doma zapojil, fungoval v nainstalovaném systému veškerý hardware s jedinou výjimkou – zvukový čip. Systém zvukovku sám od sebe neviděl. Dlouho jsem si ani neuvědomoval, že tam je, ale na základní desce jsem si všiml čipu Crystal CS4231, který už jsem viděl v jiných počítačích (typicky ne PC). Znovu jsem otevřel brožurku z krabice Windows NT 4.0, abych ověřil, jaké zvukové čipy jsou podporované – a skutečně žádná zvukovka od Crystal Semiconductor tam nebyla. Jak je tedy možné, že samotný počítač Bull Estrella v podporovaných počítačích je, když pak nějaká komponenta nemá ovladač?

První neurčité hledání na googlu mi odpověď nedalo. Ono už o samotném počítači se nic moc najít nedá. Začal jsem hledat i ve starých USENETových diskuzích a postupně jsem se doklikal k nějakému oběžníku Microsoftu, kde bylo, že na CD s Windows NT 4.0 SP2 je v extra adresáři zvukový driver pro Crystal CS423x dohromady s driverem, který zpřístupňuje Plug-n-Play (PnP) funkcionalitu sběrnice ISA, na které je tento čip připojený. Znělo to nadějně, až tak, že jsem si text oběžníku nepřečetl celý. Takže jsem si stáhl potřebný adresář z CD a skutečně – oba ovladače měly verzi jak pro x86, tak pro PowerPC. To je znamení.

Instalace se však příliš nezdařila – ISA PnP ovladač šel nainstalovat, ale při zavedení hlásil chybu. Bez něj však není možné autodetekovat zvukový čip a jeho konfiguraci. Při ruční instalaci ovladače zvukovky je tedy uživatel dotázán na parametry adres, přerušení a DMA. Vyzkoušel jsem různé kombinace, ale bez šance. Pak jsem si znovu přečetl text oběžníku a zjistil, že ten ovladač vůbec není pro můj čip, protože mám CS4231 (non-PnP), zatímco ovladač s názvem CS423x je pro všechny čipy této řady… s výjimkou toho končícího jedničkou.

Takže zpátky na začátek. Stáhl jsem si datasheet pro daný zvukový čip – v něm stálo, že jde o 100% kompatibilní řešení se standardem Windows Sound System (WSS). Je to podobné jako se Sound Blasterem – nemusíte mít Sound Blaster, ale pokud máte zvukovku, která je s ním 100% kompatibilní, tak může fungovat s jeho ovladačem. Hle, WSS je certifikovaný v NT 4.0 i pro platformu PowerPC.

Zvolil jsem jej tedy a dostal jsem se opět do tradičního nastavení, kde si musím ručně zvolit parametry zvukovky. Výchozí nefungoval a různé smysluplné kombinace také ne. Už jsem si říkal, že si připojím osciloskop na nožičky čipu, které určují nastavení těchto parametrů (čip se jinde ještě nastavuje jumpery, ale na této desce žádné nejsou).

O několik večerů později jsem zkusil prohledat z jiného důvodu mailing listy vývojářů Linuxového jádra. Řešila se tam podpora mého konkrétního čipu a tvůrce ovladače psal, že bylo nutné na PowerPC použít nestandardní parametry, aby mu to fungovalo. Řekl jsem si, že jim dám šanci. Zapnul jsem počítač a při výběru zvukového ovladače jsem v seznamu mimoděk zahlédl „IBM Power PC Audio“. Celou dobu tam bylo něco takového před očima a já na to nezkusil kliknout. Variantu s nastavením ovladače WSS jsem na chvíli upozadil a přidal tento ovladač.

Hle, ovladač po zavedení rovnou našel můj zvukový čip, stačilo dát enter (volba „výchozí nastavení“), potvrdit restart a od té doby mám zvuk. Dokonce se Estrella ukázala jako skutečný profesionální počítač. Na to mám takovou poučku, že opravdový profi počítač se od nějaké trapné skládačky liší tím, že bez připojených reproduktorů umí přehrávat zvuk na svůj interní reproduktor. Pro tehdejší UNIXové stanice to byl relativně standard. Platilo to však i pro značková PC, která navíc měla obvykle i tu odlišnost, že oproti skládačkám nepotřebovala instalovat ovladače zvukové karty v DOSu (inicializaci PnP nastavení zvukového čipu zajistil BIOS).

Zas aby se to s tou profesionalitou nepřehnalo – integrovaný repráček sice umí pípat hlasitě, ale zvuk ze zvukového čipu do něj jde buď poměrně tichý, anebo při překročení určité hlasitosti zase zkreslený. Dobový Mac hraje z integrovaného reproduktoru daleko lépe. Navíc nepotřebuje takovou hlasitost, aby přeřval hluk chlazení.

Softwarová MIDI syntéza

Použitý zvukový čip je sice v mnohém schopný, ale nemá v sobě žádnou MIDI syntézu. Postupně tak od roku 2002 začala hardwarová MIDI syntéza ze zvukových čipů mizet plošně, ale to už tolik nevadilo, neboť Microsoft ve Windows XP ponechal pro tento případ licencovanou softwarovou wave-table syntézu GS od Rollandu.

V době Windows 95 a NT 4.0 však softwarová syntéza v operačním systému nebyla. Pokud ovladač zvukovky nezpřístupnil vlastní syntézu (typicky hardwarovou, ale už se objevovaly postupně i softwarové), systém neumožnil vůbec přehrávat MIDI soubory. To je případ i zde. Na strojích od IBM platilo, že pouze PowerPC notebooky (ThinkPady řady 8xx) používaly stejný čip CS4231. Ve stolních počítačích byl čip CS4232, který se dal spojit (a spojoval) s čipem pro FM syntézu, takže alespoň nějaká možnost přehrávání MIDI byla.

Zatímco ve standardních Windows NT 3.51 a 4.0 nic takového není, existuje speciální instalační medium NT 3.51 pro ThinkPad 850, které je dovybaveno řadou ovladačů včetně IBM SoftSynth pro wave-table MIDI syntézu. IBM se u ní chlubilo, že je taková syntéza možná jen díky nadstandardnímu výkonu procesorů PowerPC ve výpočtech s plovoucí řádovou čárkou. Jestli je opravdu tak dobrá, netuším. IBM ji opravdu nabízelo jen pro svoje počítače s PowerPC na systémech Windows NT, OS/2 a AIX.

Snažil jsem se vyextrahovat knihovny a ovladač syntézy z instalačního CD od ThinkPadu, ale nahrát ten ovladač do mých NT 4.0 se mi nepovedlo. Buď dělám něco špatně (nejvyšší pravděpodobnost), anebo je tam nějaká nekompatibilita mezi NT 3.51 a 4.0 (mám za to, že by neměla).

Přidáváme 3D/video akcelerátor

Mám na stole krásnou pracovní stanici z roku 1995, s RISC procesorem a spoustou RAM, je připojená do sítě, jak se u správné pracovní stanice sluší a patří, ale něco tomu ještě chybí. Správně, chtělo by to nějaký 3D akcelerátor a ideálně také z této doby.

Byl to jeden ze dvou důvodů, proč jsem si pracovní stanici půjčil. Sice pro ni prakticky nejsou ovladače od třetích stran, ale mezi podporovanými adaptéry Windows NT 4.0 pro všechny procesorové varianty je grafický akcelerátor Matrox Millennium MGA-2064W.

On je to takový zvláštní akcelerátor poplatný době. Umí akcelerovat přehrávání videa, ale hardwarové roztažení obrazu dělá bez vyhlazení. Umí akcelerovat i 3D zobrazení, ale neumí textury, ani poloprůhlednost. Na akceleraci 3D her tedy moc smysl sice bez textur nedává, ale velmi dobře dokáže akcelerovat rasterizační fázi vykreslování v profesionálních 3D modelovacích a CAD/CAE nástrojích, a to i v 32bit barvách, se Z-bufferem a ve vysokém rozlišení.

Je tu ovšem jeden konkrétní důvod, proč mě zajímá grafická karta zrovna s tímto konkrétním čipem. Ovladače dodávané s Windows totiž po desítky let v sobě nikdy neměly modul pro akceleraci OpenGL. Tato část vždy chyběla a uživatelé museli nainstalovat ovladače z disket/CD, anebo později s webových stránek výrobce. MGA-2064W je však výjimkou – Microsoft na tomto čipu prezentoval možnost hardwarové akcelerace OpenGL přes mini-client driver model (novinka v NT 4.0), o kterém mám celý článek na retroSwarm. A aby ukázal, jak se dělá takový ovladač, tak jej pro tento čip sám vytvořil a dal do svého Windows NT 4.0 DDK (driver development kit) včetně zdrojových kódů.

Finální ovladač včetně hardwarového OpenGL však mimo jiné integroval i přímo do Windows NT 4.0. Jde tedy o jediný grafický čip, se kterým máte 3D akceleraci bez nutnosti nainstalovat ovladač od výrobce. To se v případě stroje s procesorovou platformou, na kterou nikdo extra ovladače nedodával, mimořádně hodí, ne?

PCI/ISA karty z PC do RISC stanice

Tady bych měl zastavit a nejdřív vysvětlit, jak to vůbec je s rozšiřujícími kartami na alternativních platformách. PowerPC, MIPS a další RISC procesory používají ve výchozím obrácenou endianitu (než x86), tedy řazení bajtů uvnitř „slova“, se kterým pracují (typicky zde 32 bitů, resp. čtyři bajty). Když se podíváte do skoro libovolného datasheetu k čipům používaným v té době na rozšiřujících kartách v PC, nastavení endianity je často podporované, takže to není zas takový problém. V případě RISC počítačů určených pro běh Windows NT je to dokonce ještě jednodušší, protože většina těch RISC procesorů se umí z big-endian přepnout na režim little-endian (ala x86), což je jedním z požadavků Windows (nedivím se jim, že nechtěli řešit ještě tento typ rozdílu mezi platformami).

Takže zbývají už jen dvě nástrahy – ovladače pro daný operační systém a firmware. Ovladače jsou jasné – ty, které Microsoft přeložil a otestoval na PowerPC, jsou uvedené v příručce v krabici operačního systému (a nic moc dalšího od ostatních nejspíš neexistuje), ale jak je to s tím firmwarem? Část karet žádný firmware nemá a všechno je v režii ovladače – typicky zvuková karta, případně síťová karta (pokud nás nezajímá boot ze sítě, což tento počítač nejspíš vůbec nepodporuje).

Firmware bývá naopak vždy u grafických karet a mnohdy také diskových řadičů (SCSI). V případě Maců s PowerPC a PCI sběrnicí se musel použít jiný firmware, takže takové karty přímo z PC v Macu nefungovaly. Někteří výrobci (např. ATI) nabízeli speciální Macovskou verzi (samozřejmě dražší) s jiným firmware a mnohdy také větším flash ROM čipem (v případě Macu je firmware větší a obsahuje i základní ovladač do MacOS, aby karta aspoň neakcelerovaně fungovala hned po vložení v plném rozlišení / obnovovací frekvenci / barevné hloubce). Některým výrobcům (např. Matroxu) nestálo za to podporovat extra verzi pro tou dobou docela malý trh, takže pro uživatele Maců vydali akorát flashovací utilitu a firmware pro Mac si uživatel obvykle v jednoduchém nástroji na dvě kliknutí nahrál do obyčejné karty z PC sám.

I když měl v polovině 90. let Mac malý tržní podíl, pořád šlo o daleko víc počítačů než všechny ty RISC počítače s Windows NT dohromady. Mac byl totiž zavedený ekosystém, zatímco NT na něčem jiném než x86 byl segment, který teprve bojoval o svoje místo na trhu. Chtít po výrobcích extra firmware v takové situaci není možné. Řešením se stala emulace x86 procesorů ve firmware počítače. Počítač po spuštění při aktivaci karet použije svůj interní emulátor procesoru (486) a vykoná „option BIOS“ x86 kód vložených ISA a PCI karet. Ty se tedy zinicializují, aniž by poznaly, že neběží v obyčejném PC. Tím role emulátoru končí a dále se již ke kartě přistupuje pouze přímo, anebo přes nativní funkce firmware počítače. Tímto způsobem problém vyřešily nejen NT stanice s PowerPC, ale i s MIPS a Alpha.

Samozřejmě ne každé PCI/ISA zařízení se nutně inicializuje původním option BIOSem v emulovaném módu. Všechny PCI/ISA čipy na základní desce Estrelly mají samozřejmě inicializaci vestavěnou ve firmware počítače. Dokonce i některé rozšiřující karty do slotů lze inicializovat nativně, neboť firmware počítače má kód pro vybrané grafické karty přímo v sobě.

Zpět k Matroxu

Teorii jsme probrali, takže k samotnému vložení karty. Vzal jsem tedy Matrox Millennium MGA-2064W, strčil ji do počítače, přepojil do ní kabel monitoru původně vedoucí k integrované grafice a zapnul. Bez jakéhokoli nastavování firmware počítače deaktivoval interní grafiku a od začátku zobrazoval na Matroxu. Problém byl, že hned po proběhnutí úvodní fáze NT zavaděče došlo při spouštění kernelu okamžitě k BSOD (modré obrazovce smrti s výpisem registrů procesoru).

Zkoušel jsem všechno možné, ale pořád to nefungovalo. Tak jsem vzal ISA grafickou kartu Tseng ET4000, která je v podporovaných pro firmware Estrelly, ale nepodporovaná ve Windows NT. Tam jsem vyzkoušel, že i nepodporovaná karta na Windows NT stále běží (stejně jako na PC) alespoň v režimu VGA 640×480 16 barev. Vyzkoušel jsem pak ještě novější PCI S3 ViRGE/VX, která na rozdíl od Tsengu a Matroxu není podporovaná firmwarem Estrelly – poprvé jsem tedy viděl, že po zapnutí počítače se nejdříve v textovém režimu zobrazil inicializační výpis BIOSu grafického čipu a až pak to celé naskočilo do grafiky firmware počítače. Opět Windows fungoval a opět jen ve VGA režimu kvůli absenci ovladačů.

Nakonec po týdnech dělání jiných věcí jsem na to přišel. V mém Matroxu po konverzích PC->Mac a zpět jsem měl nejnovější video BIOS verze 3.x. Zkusil jsem najít nějakou verzi 2.x, jestli bude něco jinak. A skutečně bylo. Proběhl zavaděč NT a místo BSOD při načítání kernelu zůstala černá obrazovka a blikající kurzor textového režimu. Po náhodném mačkání různých kláves na klávesnici (včetně CTRL+ATL+Delete) najednou karta vypsala inicializační text video BIOSu, ale dál zůstala zaseklá.

Nevadí – teorie se potvrdila. Verze video BIOSu (byť jde o kód pro x86) ovlivňuje projev závady, takže jsem se jal sehnat ještě starší BIOS z doby, kdy kartu pro NT 4.0 mohli testovat. Našel jsem nějakou verzi 1.x a s ní Windows okamžitě najel. Před zavedením kernelu problikne výpis video BIOSu grafiky, ale pak už se objeví informace kernelu a systém se zavede. K mému překvapení se rovnou zavedl s ovladačem Matroxu a rozlišením původně použitým s integrovanou grafikou. Ani nebylo nutné ovladač vybrat a ani se nezobrazila žádná notifikace, že mám nový hardware.

3D i lepší video

Akcelerace od Matroxu je poněkud nenápadná. Není totiž poznat vizuálně – pouze výkonem. V tom je její zádrhel, protože když někdo dnes zkoumá tuto kartu, dojde chybně k závěru, že žádnou akceleraci nemá. V případě videa je to tím, že roztažení přehrávaného videa do okna prohlížeče dělá bez nějakého vyhlazovacího filtru. Jen se některé pixely zdvojí/ztrojí v daném směru. Vizuálně se to tedy neliší od toho, jak to staré přehrávače řeší, když akcelerace není dostupná.

Rozdíl je tak pouze v rychlejším vykreslování (což moderní badatel nepozná, pokud strčí kartu do počítače s příliš rychlým procesorem). Na 66MHz procesoru je rozdíl výrazný. Pro mě byla vždy pracovní stanice o obřím monitoru s nadstandardním rozlišením. Neakcelerované roztažení typicky znamená, že procesor vykreslí maximálně nižší jednotky snímků za sekundu. Stačí už rozlišení 1024×768 a není šance na plynulé roztažené video – jediné řešení pak je nechat přehrávání v okně 1:1 (tak to dělá dobový Mac).

Interní karta od Cirrus Logic má jednoduchou akceleraci videa. Také nevyhlazuje a už při roztažení na 800×600 bylo u testovacího videa znát, jak se snížila snímková frekvence (pomohlo by rozšíření paměti na 2 MB?). O tom, že je roztažení řešené grafickým čipem, vypovídal kurzor myši, který se překresloval stejnou trhaností jako snímky videa (při softwarovém přehrávání se nic takového ve Windows NT neděje). Proti tomu s Matrox Millennium lze přehrávat video roztažené klidně na rozlišení 1600×1200 bez snížení snímkové frekvence. Líbí se mi, že ta karta byla opravdu navržená pro vysoká rozlišení ve všech ohledech.

OpenGL 3D je akcelerace ještě nenápadnější, protože mini-client driver (MCD) model, který je zde použit, je vlastně jen napojením na Microsoftí softwarové vykreslování. Je to zjednodušení pro výrobce hardware – vezme hotové zobrazení (přes CPU) a do něj pouze modulem přidá napojení na akceleraci grafické karty u těch vykreslovacích funkcí, které karta podporuje. Tedy pouze polygony, které využívají funkce akcelerovatelné kartou, jsou s její pomocí vykresleny. Polygony s nepodporovanými funkcemi se vykreslí softwarově přes CPU.

Čip MGA-2064W umí netexturované polygony s vertexovým osvětlením, čáry (wireframe) a efekt mlhy. Tím výčet končí – žádné textury, žádná poloprůhlednost. Karta mířila na CAD a VRML scény, kde fungovala překvapivě dobře. Sice nic moc neumí, ale to, co umí, vykresluje s velkou rychlostí.

Softwarově je na tomto počítači v OpenGL možné při 16bitové barevné hloubce kreslit jen 5,1 miliónů stínovaných pixelů bez textur a poloprůhlednosti (5,1 Mpix/s). V případě použití Z-Bufferu (tedy ověřování vzdálenosti pixelu) je to dokonce 2,0 Mpix/s. S Matroxem se hodnoty zvýší na 26,3 Mpix/s bez a 25,8 Mpix/s se Z-Bufferem (měřeno naším benchmarkem GPUbench).

V praxi v demonstračních programech 3D Labs pro Windows NT 3.51 umožnil Matrox 3-5x vyšší snímkové frekvence než softwarové vykreslování, což už je opravdu hodně znát. S výkonnějším procesorem by byl rozdíl nejspíš ještě o něco větší. Problém je, že mini-client driver (ale vlastně i karta samotná) neumí akcelerovat přípravu geometrie, ani výpočet parametrů pro trojúhelníky (triangle setup) – tyto operace jdou stále přes procesor, který se s nimi evidentně trápí (v ideálním případě lze s tímto procesorem dosáhnout na 74 tisíc trojúhelníků za sekundu; tj. pro 20 fps není možné mít ve scéně více než cca 3000 polygonů). V hodně malém okně tedy rozdíl v rychlosti s akcelerací a bez není moc velký. Jakmile už je ale okno roztažené třeba na 640×480 pixelů, je akcelerovaná verze násobně rychlejší.

Moje karta má pouze 4 MB vlastní paměti. Existuje rozšiřující modul až na 8 MB, ale ten bohužel nemám. V případě 3D je problém, že potřebuje více paměti v kartě. Takže zatímco pro 2D zobrazení a video můžu pracovat klidně s rozlišením 1600×1200 při 65 tisících barev (3,66 MB), kdybych chtěl ve stejném rozlišení pracovat s 3D, potřebuju stejné množství paměti pro druhý obrazový buffer (do jednoho se připravuje scéna, z druhého se kreslí na monitor; při dalším snímku se role prohodí) a pak ještě pro Z-Buffer, kde je každému pixelu přiřazena hodnota vzdálenosti (10,99 MB).

U mojí karty lze tedy akcelerovat 3D při tisících barvách (a Z-Bufferu) do rozlišení 800×600, anebo v miliónech barev do 640×480. Pro vizualizace simulací ve 3D to však stačilo a v roce 1995, kdy karta vyšla, bylo pro 3D i takové rozlišení bráno jako vysoké.

Nativní výkon

Už jsem tu psal, že Windows NT 4.0 lítá na Estrelle jak z praku, a netipnul bych, že je uvnitř procesor na pouhých 66 MHz. Pomáhá tomu samozřejmě rychlejší SCSI disk, dostatek paměti a po upgradu i grafický akcelerátor od Matroxu. Cokoli jsem z toho mála spustil v nativní verzi, mělo okamžité reakce. Za výpočetně náročnější lze považovat asi jen Excel 5.0 (specificky na FPU kvůli práci s čísly s plovoucí řádovou čárkou). Exaktní měření jsem příliš neprožíval (vzal jsem si stopky), ale nechal jsem si přepočítat list plný Fourierových transformací a časově to sedělo k nějakému Pentiu na 75 MHz, s odřenýma ušima možná 90 MHz.

Tedy procesor je na takt rychlejší. Na druhou stranu samozřejmě za ty peníze nebyl problém koupit si PC s Pentiem, co má úměrně vyšší takt. Rozhodně se nekonal zásadní rozdíl, kvůli kterému by byla celá platforma x86 považována automaticky za beznadějně zastaralou.

V případě měření výkonu procesoru mimo FPU jsem použil náš Sieve Benchmark, který jsem pro tu potřebu konečně naportoval i pro Windows. Doteď sice existovala verze pro různé UNIXy, Amigu, DOS, MacOS a dokonce i Windows CE, ale verze pro klasický Windows chyběla. Nyní je to napraveno. Na počítači totiž bylo již nainstalované Visual C++ 4.0a RISC Edition, kterým bylo možné kompilovat nativní kód. Do svého Windows 11 on ARM jsem tedy nainstaloval obyčejné Visual C++ 4.0 pro x86, zmodifikoval direktivy kompilátoru a změnil jeden řádek kódu. Když jsem zjistil, že jsem schopný program zkompilovat, přetáhl jsem projekt do Estrelly a zkompiloval nativní verzi bez jediné další změny. Je jen mrzuté, že Microsoft sice vydal Visual C++ 4.0 pro všechny možné platformy (x86, MIPS, PowerPC, Alpha), ale kompilovat bylo možné vždy jen pro tu platformu, jejíž verzi Visual C++ máte zrovna nainstalovanou. Až v době vývojových nástrojů pro Windows CE už tohle neplatilo a daly se vyprodukovat jedním krokem binárky pro všechny platformy.

Sieve Benchmark (hledání prvočísel vysoce optimalizovanou metodou Eratosthenova síta) generuje pro procesor zátěž, kde rychlost bývá podobná kompilaci, indexování, práci s textem a podobným činnostem, takže hodně napoví k výkonu procesoru. Místo jednoho výsledku program zkouší hledat pro různé velikosti síta, čímž se mění velikost dat, a tedy i schopnost procesoru udržet je v různých úrovních cache. Díky tomu je možné vidět, že v závislosti na velikosti dat může vyjít jako rychlejší pokaždé jiný procesor.

Podívejme se na porovnání PowerPC 603 (66/66MHz; vnitřní takt / paměťová sběrnice) v Bull Estrella s PowerPC 601 (75/38MHz) v Power Macintosh 7200/75 a Pentium MMX (133/66MHz, resp. 66/33MHz při low-power režimu) v notebooku Toshiba Satellite 440CDT. Kopečky v grafech jsou situace, kdy jednotlivé procesory vypadávají z L1, případně L2 cache:

Rychlost průchodu vnitřního cyklu programu v milisekundách. Čím kratší, tím lepší.

Výsledky přepočítané na počet cyklů procesoru pro porovnání, jak by si proti sobě procesory vedly, kdyby běžely všechny na stejné frekvenci.

Jak je vidět, Visual C++ zkompilovalo kód tak, že dokud běží čistě v L1 cache procesoru, je podobně rychlý na PowerPC 603 i Pentiu na stejném taktu. Kompilátoru pro Mac se podařilo udělat průchod vnitřním cyklem na menší počet taktů procesoru. V případě Macu se však projevuje klasický problém celé řady (vyjma drahých PowerPC 604 a později G3), kdy Apple používal pomalé vnější sběrnice. To se ještě umocnilo tím, že ranné PowerPC nemělo samo o sobě práci s pamětí nejrychlejší.

Zatímco práce s malými daty, která se vejdou do cache, je rychlá, pro velká data začne Power Macintosh 7200 rychle ztrácet dech a dostává se pomalu na úroveň notebooku s podtaktovaným Pentiem, kde vnější sběrnice v tu chvíli běží na pouhých 33 MHz. Proti tomu Bull Estrella má paměť rychlou a jako správná pracovní stanice si stále drží slušný výkon. 133MHz Pentium MMX je sice stále rychlejší, ale je vidět, že to není dvakrát, jak by naznačoval takt. Pentium na 100 MHz by bylo výkonem hodně podobné Estelle.

Vyšší výkon tedy nejde PowerPC upřít, ale opět to není tak zásadní, aby mělo smysl pro uživatele přecházet z x86. Tím, že pracovní stanice s PowerPC nebyly zas tak levné, bylo jednodušší koupit výše taktované Pentium, anebo s ohledem na tehdejší obecně rychlý vývoj procesorů počkat půl roku a koupit si ještě více výkonu za méně peněz.

Výkon emulace x86: DOS

Hlavní průšvih je, že na rozdíl od Windows NT na x86 zde není možné nechat DOSové programy přímo přistupovat ke grafickému čipu pro plný výkon. Na všech ne-x86 platformách se emuluje grafická karta VGA a vše se vykresluje v okně, kde to logicky znamená spousty práce navíc. Zatímco Doom na 133MHz Pentiu MMX běží (celoobrazovkově) pod NT úplně plynule a při snížení taktu na 66 MHz není problém dosáhnout na 20 fps, v případě 66MHz PowerPC 603 se vykresloval každý snímek přibližně sekundu. Při snížení rozlišení v Doomu (F5) se zvedla snímková frekvence někam na 3 fps. O hratelnosti tedy nemůže být řeč.

Superscape 3D Benchmark dal na notebooku s Pentiem MMX 90,9 fps, zatímco polovičně taktované PowerPC 603 zvládlo jen 3,6 fps. Z toho je vidět, že cokoli tehdy náročnějšího, co bylo závislé na rychlém kreslení, bylo pod emulovaným DOSem nepoužitelné a zcela jistě by situace nebyla únosná ani s mnohem rychlejším procesorem PowerPC 604, který se vyskytoval v dražších pracovních stanicích a který představoval konkurenci spíše pro Pentium Pro.

Smyslem emulace DOSu zde primárně byla možnost spustit starší business aplikace, účetní programy a podobně. Prostě takové ty věci, co mohou běžet na čemkoli, takže je nikomu nestálo za to přepsat na Windows. V těchto případech to funguje dobře (včetně tisku na reálnou tiskárnu). Většinou jsou totiž v textovém režimu a grafiku využívají spíše pro statické vykreslení výstupu, kde nevadí její řádově pomalejší vykreslování.

Rychlost emulace jsem opět zkoumal pomocí Sieve Benchmark, a to spuštěním DOS/x86 verze. Vyšla na úrovni 16-20MHz 486SX (tj. cca 33-40MHz 386DX), což sice znamená 5-8x menší výkon, než procesor umí dodat v nativně zkompilované verzi, ale pro spoustu DOSových programů to s přehledem stačí.

Výkon emulace x86: Windows / 16bit

Že Windows NT 4.0 ve výchozím stavu emulují pouze 16bitové x86 aplikace pod Windows, jsem již psal v prvním díle. Jde o jiný emulátor – ten pro DOS napsala Insignia (používala ho v produktech SoftPC pro další platformy; zde je jen emulátor více integrovaný do systému), ale ten pro Windows si napsal Microsoft sám. To rozhodnutí přišlo už u prvních Windows NT (3.1), protože se Microsoft bál, že Insignia by nestihla Win16 emulaci napsat (tou dobou ještě ani neemulovala procesor 386).

Emulátor „Windows on Windows“ řešil emulované vykonávání programů pro x86 a zároveň napojení všech volání API na nativní verze knihoven. V podstatě kromě toho, že v některých 16bitových instalátorech aplikací (paradoxně zrovna těch od Microsoftu) dojde k vytížení procesoru na 100 % a všechno se ještě řádově zpomalí, i když se reálně jen čeká na vstup uživatele, je kompatibilita velmi slušná. 16bit programy jdou spustit a jejich jedinou nevýhodou je, že je to pomalé. Mírně pod úrovní emulátoru DOSu.

Zkoušel jsem nějaké primitivní hry pro Windows 3.1 a programy jako Visual Basic 3.0. To všechno bylo použitelné. Jen to neodpovídalo nárokům na výkon u lidí, kteří si v té době kupovali drahou pracovní stanici. Nicméně Visual Basic 3.0 byl dostatečně responsivní, aby se v něm takto dalo vyvíjet. Dokonce i Word 6.0a šlape použitelně při překreslování během procházení dokumentů v rozlišení 1024×768.

Až 16bitová verze SimCity 2000 už byla na počítač příliš náročná a nehratelná – u plně zastavěné mapy trvalo překreslení po zoomu nebo změny místa k zobrazení tři sekundy.

Výkon emulace x86: Windows / 32bit

Byť emulace Win32 programů pro x86 v základu chybí, Microsoft záhy nabídl modul, který tuto funkcionalitu přidává. Bylo to logické, protože Windows 95 se ukázal jako velmi úspěšný a s tím přišla intenzivní snaha ostatních vývojářů nabídnout nové 32bitové verze svých programů. Kdyby Windows NT na ne-x86 strojích emuloval jen 16bitové programy, bylo by to značné omezení.

Jde o situaci, která nastala i s ARMem. Windows 10 on ARM měly emulaci pouze 32bitových x86 programů, ale 64bitové x86 spustit nešlo. Kdyby se na ARM rychle přecházelo, bylo by to jedno, ale k takovému ovlivnění trhu ve světě PC nemá nikdo dost síly. Takže je potřeba nabídnout i do budoucna schopnou emulaci pro nejnovější programy výrobců, kteří na alternativní platformy zatím kašlou. Microsoft to nakonec (stejně jako s Windows NT) pochopil a Windows 11 on ARM má emulaci x86 i x86-64.

Modul do Windows NT 4.0 (předchozí verze nejsou podporovány) se jmenuje Wx86, existuje pro PowerPC, MIPS i Alpha a Microsoft ho jako „technology preview“ umístil v roce 1996 zdarma na svoje FTP (a po neúspěchu RISC verzí NT zase tiše smazal).

Nevýhoda Wx86 je v jeho extrémní pomalosti. 32bitové programy spustit jdou, ale zejména na tomto 66MHz PowerPC 603 (tedy nejslabší verzi pracovní stanice) nesnesitelně pomalu. Člověk by čekal, že emulace Win32 bude rychlejší, protože se nebude muset blbnout se segmenty a offsety při skládání adres v paměti, ale realita je, že Wx86 je navzdory tomu polovičně rychlý než 16bitový emulátor, takže pokud má program obě verze, je vždy lepší použít tu 16bitovou.

Výkon pro Wx86 není na tomto počítači dostatečný na pohodlné používání ani pro dobovou 32bit verzi webového prohlížeče Netscape.

Výkon emulace x86: SoftWindows 32

Motorola si problém pomalé emulace s Wx86 uvědomovala a domluvila se s Insignií ještě v roce 1996 na vytvoření produktu SoftWindows 32, který byl distribuován na samostatném CD-ROM. Šlo o rychlejší emulátor 32bitových x86 programů pro Windows a základ napojení na operační systém vycházel přímo z Wx86. Od něj se odlišoval vlastně jen náhradou modulu CPU emulátoru (WX86CPU.DLL) za optimalizovanější verzi.

Hodně mě zajímalo, jak se projeví rychlost emulace v našem benchmarku. Oproti Wx86 je výkon dvojnásobný a Win32 verze s ním překonává dokonce i emulaci 32bitové verze pro DOS. Je někde na úrovni 25MHz 486.

Výkonový nárůst v násobcích proti emulaci DOSové x86 verze (fialová). Pro velikost síta nad 10 KB vychází výkon emulace SoftWindows32 na úroveň nativního vykonávání kódu 25MHz procesorem 486SX (oranžová).

Dvojnásobný výkon ve Win32 programech je znatelný. SimCity 2000 už jde tak tak hrát v 32bit verzi, takže mnohem silnější 133MHz procesory PowerPC 604 v lepších pracovních stanicích už musely nabídnout přijatelný komfort pro emulované běžné programy té doby (nakonec vyzkoušeno, výkon v emulaci je téměř 3x vyšší). Velký zázrak se však stejně nekonal. Nešlo o tak pokročilou emulaci, jakou měl Digital pro svoje počítače s procesory Alpha běžící na Windows NT (ale zase byla stabilnější). V praxi, pokud měl program 16 i 32bitovou verzi, bylo stran výkonu emulace obvykle téměř jedno, kterou z nich člověk použil.

Že nějaký program běží pod 16bitovým emulátorem lze poznat velmi snadno. Ve Správci úloh se takový program zobrazuje vnořený pod procesem ntvdm.exe. Emulaci těchto programů Wx86, ani SoftWindows32 nijak neovlivňují.

32bitové programy emulované pomocí Wx86 (resp. SoftWindows32) není možné ze Správce úloh odlišit od nativních.

Pentium Pro a konec procesorových válek

Tvrdou ránu dostala RISCová konkurence ucházející se o místo nástupce x86 v druhé polovině roku 1995. Všechno to nadšení pro RISC procesory a obavy, že x86 procesory už není možné dále zrychlovat, které roztleskávaly redakce magazínů jako Byte, se pomalu začaly rozplývat, když vyšly oficiální výsledky industry standard procesorových testů SPECint a SPECfp pro úplně nový procesor Pentium Pro. Ty výsledky totiž rozbily celý ten narativ, že x86 už nemá kam růst, když je tu najednou nový x86 procesor, který sice míří na servery a výkonné stanice (a je tedy úměrně naceněn), ale v integerové (celočíselné) matematice, která je pro takovou tu běžnou práci a velké množství úloh (včetně serverových) zásadní, překonal svou RISC konkurenci (i tu s vyššími takty). Matematika s plovoucí řádovou čárkou potřebná pro vědecké výpočty, práci s grafikou a podobné činnosti sice stále zaostávala za procesory jako DEC Alpha, jenže počítač s Pentiem Pro byl také úměrně levnější.

Od tohoto bodu už tvrzení, že x86 končí, přestalo jakkoli fungovat. Tím pádem to u zákazníků z řad firem zabilo takový ten argument, že jestli něco nakonec stejně brzo končí, bude lepší přejít už teď. Ochota zákazníků k přechodu na jinou procesorovou architekturu byla rázem na bodu mrazu, což postupně vyústilo v utlumování snah výrobců nabízet takovou konkurenci k běžným x86 PC.

První to vzdal MIPS, který alespoň v první polovině 90. let měl nějaký úspěch s Windows NT, kde jej používaly některé firmy na distribuovaný rendering (počítače byly dražší, ale poměr cena/výkon byl stále příznivější než získat stejné množství výkonu větším množstvím x86 PC, typicky s procesory 486). Proti tomu PowerPC se nechytlo s Windows NT nikde (byť snaha byla u databází), takže jeho podpora byla ukončena jen o pár service packů Windows NT 4.0 později.

Nejdéle se držely procesory DEC Alpha, které nabízely více výkonu než MIPS i PowerPC (takže zákazníci Windows NT, kteří se byli ochotni vzdát x86 kompatibility, přecházely právě sem). S jejich podporou se vyvíjel i Windows 2000, a kdyby Digital/Compaq ukončil podporu jen o trochu později, dostala by se verze pro Alphu i do finálního CD Windows 2000 (a ne jen „release candidate“). O tom si ale můžeme napsat někdy příště, protože celá Alpha je také zajímavý příběh.

Windows NT vznikl jako naprosto multiplatformí systém, primárně vyvíjený na MIPSu, aby nehrozila přílišná svázanost s x86. Už NT 3.1 existovalo ve verzích MIPS, x86 a Alpha. NT 3.51 a 4.0 měly navíc k této trojici ještě PowerPC, ale Windows 2000 nakonec vyšel pouze pro x86. Podpora jiné platformy se vrátila až u Windows XP, ale tam byla oddělena do samotné verze Windows XP 64-Bit Edition for Itanium. O tom ale můžu napsat také někdy jindy (Itanium také mám).

Závěrem

Bull Estrella přišla moc pozdě. Byl to klasický případ „too little, too late“, pokud jde o nasazení s Windows NT, protože nenabízela ani nic navíc proti strojům s x86 za stejnou cenu. Varianta s PowerPC 604 měla lepší výkon než klasické Pentium, ale zas kdo půl roku počkal, ten si pořídil stejný výkon, aniž by musel řešit přechod na jinou platformu a obměnu aplikací (anebo se trápit s emulací). Tato varianta s PowerPC 603 ani nebyla zásadně rychlejší než klasické Pentium a sloužila nejspíš jen jako levnější vývojářská alternativa k větším PowerPC mašinám.

Na druhou stranu až na hlučnost jde o příjemný počítač, na kterém je ironické, že jeho procesor je tak úsporný, že se moc nezahřeje, i když na něm není heatsink. Fakticky by se tedy dal udělat tišší než průměrné tehdejší PC. Ale holt nebyl ze strany výrobce zájem. Zároveň to, co z něj dělá na používání Windows NT příjemný stroj – tedy hodně RAM a rychlý SCSI disk – byly věci, které člověk stejně tak mohl nacpat i do počítače s procesorem od Intelu.

Pod čarou

Nedalo mi to a půjčil jsem si počítač Motorola PowerStack E, který je také kompatibilní s Windows NT (a IBM AIX) a má v sobě rovnou 128 MB RAM a 133MHz procesor PowerPC 604, což by mělo znamenat mnohem více výkonu. Zjistil jsem, že asi potřebuji zažít, zda pak už emulace byla dostatečně rychlá a použitelná, anebo to na mě neudělá dojem. Ještě o tom nejspíš napíšu alespoň kratší článek.