AMD64 - kdo doda HW?

Pátek Listopad 21 09:38:01 CET 2003

	Dobry den po ranu,

	predem dekuji za nastineni aktualniho stavu, vyvoj pokracuje milovymi kroky a clovek nestiha sledovat...:-). Rad bych odpovedel na nektere konkretni dotazy, zaroven se omlouvam za pozdnejsi odpoved, nedostal jsem se k tomu.

> -----Original Message-----
> From: Jan Derfinak [mailto:ja na mail.upjs.sk] 
> Je tak daleko, ze si mozete kupit 64-bitove distribucie pre 
> Intel, AMD.
> PPC64 alebo S390.
> V distribuciach sa nachadzaju 64-bitove aplikacie. Tiez existuju
> 64-bitove komercne aplikacie (nedavno som instaloval DB2 na 
> AMD a Intel). 

	Prvni na cem bych se rad zastavil je to, co je vlastne 64-bitova aplikace. Vetsina aplikaci, ktere jsem mel tu cest videt (zejmena z oblasti GNU - a to ted nemyslim stare "core" veci, ale spise vyvoj rekneme v poslednich 5-ti letech) je napsana tak, ze:

a) pouziva int (CPU/architecture depend)
b) vubec nezjistuje, zda-li bezi na "vetsi" (64-bit) platforme

	Na jednu stranu to usnadnuje vyvoj na stranu druhou to zaroven znamena, ze vse, co aplikace dela je "implementovano" do 32 bitu, coz naprosto zbtecne zdrzuje, uz jen z duvodu, ze 64-bitovy prefetch v CPU proste zpracovava sice 64-bitovy kod, ale se spoustou vaty, protoze programator pouzil pouze 32-bit funkce/volani...

	Popisu konkretni situaci, na ktere to IMHO musi byt silne videt. Je znamo kolik se vejde do int v 32-bitovem rezimu. Je to nekde v radu GB dat. Proto mame v Linuxu klasickou funkci fseek, fseeko, lseek, llseek. fseek nam nepomuze, protoze ma offset jako long (=> vzdy 32-bit = je to pravda? - vychazim z tohoto: "On many architectures  both  off_t  and  long  are  32-bit types, but compilation with #define _FILE_OFFSET_BITS 64 will turn off_t into a 64-bit type" - o long ani zminka, ze by se "zvetsoval"). fseeko ma offset jiz jako off_t, jenze ten je 64-bitovy pouze v pripade #define _FILE_OFFSET_BITS 64 - kolik aplikaci (source) to ma detekovano a nastavovano? lseek sice pouziva offset jako off_t, ale situace je podobna jako v fseeko - kolik aplikaci ma nastaveno patricne makro. llseek je kapitola sama pro sebe, protoze sice ma "lo" a "hi" cast, ale kompilatoru na 64-bit platforme nezbyde nic jineho nez do "ulong" udelat padding => CPU musi v datove casti precist dvojnasobne mnozstvi dat, nez bylo treba.

	Takze zaver - za 64-bitovou aplikaci nepovazuji takovou, ktera byla navrzena a odladena pro 32-bitovy rezim a byly pouze source vzaty a prekompilovany 64-bit kompilatorem. Aplikace musi proste aktivne s 64-bit platformou pracovat.

	On skutecne veskerou praci neni dneska schopen odvest kompilator, stejne jako piplava optimalizace pro SSE, SSE2, 3DNow! je jednak zalezitost pro kompilator (panove od Intelu to fakt umi), ale rovnez pro mozky - a vysledek je na snade.

	O strastech prechodu muze pojednavat i kurzivou sazena poznamka zde http://www.linuxzone.cz/index.phtml?ids=3&idc=908 .

	Z tohoto pohledu se domnivam, ze Linux ceka jeste velmi dlouha cesta, nez se bude moci nejaka distribuce oznacit za 64-bitovou (vyjma marketingove nalepky). Stejne tak MS trvalo hodne dlouho nez byly 64-bitova okna pro Alpha CPU (jiz davno zastaven vyvoj) - taky se neprepsal jen architekture depend kus kodu... MS Windows pro IA64 pripadne Opterony nejsou a jen tak realitou nebudou (mylim se?).

> Pokial sa nemylim, tak Tru64 bezi nativne na Alphach a tato 
> procesorova
> platforma uz nebude pokracovat vo vyvoji. A ako vyvojar 

	No ono to je trochu slozitejsi, nicmene pokud se divate na horizont let 2010-2015 mate pravdu, kde v te dobe bude Linux, si prognozovat netroufnu, do te doby vyvoj pokracovat bude, protoze je to smluvne podporeno... (a nevim o tom, ze by tuto ochranu investic si dovolil jak Intel, tak Compaq zrusit - obe firmy si puvodni DEC Alpha vyvoj a poznatky rozkouskovaly mezi sebe..)

> perspektivy. Napokon mam pocit, ze 64-bitovy linux na Alphach 
> uz niejaku tu
> dobu bezi.

	O tom se nepru - pidim se vsak po realne efektivite tohoto procesu/provozu...

> -----Original Message-----
> From: Jan Kasprzak [mailto:kas na informatics.muni.cz] 
> 	Linux neni prece ani 32-bitovy ani 64-bitovy OS - dnes 
> uz je jadro
> napsane pomerne neutralne z pohledu architektury.

	O tom neni sporu rovnez, i kdyz si nejsem jist, nakolik je navrzena architektura jadra skutecne tak odstinena od jednotlivych CPU architektur - ja jsem naopak z komentaru na abclinuxu.cz, puvodne linuxworld.cz panem Literakem  nabyl dojmu, ze navrh, ktery byl puvodne 32-bit x86 je nekdy dooost slozite prizpusobit diametralne odlisnym architekturam - udelat to opravdu optimalne zrejme nejde vzdy... Navic operacni system dneska uz zdaleka neni jen kernel v pravem slova smyslu - je to cely system.

> 	BTW, cim jinym chcete dosahnout behuschopnosti na vice 
> architekturach
> nez #ifdefy v hlavickovych souborech? Co je spatneho na #ifdefu?

	No pri soucasnem navrhu to jinak zrejme nejde, ono jde spise o to, ze ty vnitrnosti musi mit take dohodnute API (linux kernel prece nekomunikuje pomoci front zprav) a co vyhovuje x86 CISC nemusi vyhovovat z hlediska optimalniho behu a vykonu RISCu ci jinym apod.

> 	??? A co napriklad? Pokud treba uvazujeme x86_64. Co z moznosti
> teto architektury Linux umi "docela malo" (na rozdil od 
> jinych OS na teze
> architekture)?

	Dostavam se na tenky led, tady nejsem schopen (a priznavam to rovnou) archumentovat technologiemi apod., ale z pohledu realneho behu rekneme back office pro 600 uzivatelu (z toho 400 soucasne pracujicich) je treba Informix na PowerPC a AIXu (cele v podani IBM) vykonem trochu dost jinde nez na stejnem zeleze Linux a stejny SW. To je fakt, ktery vim, jeho priciny vidim zejmena v nesladenosti cele "Linux" architektury - mozna je na vine i "slaba" portace Informixu na Linuxu, nevim, realny vysledek je zatim takovy, ze v podobnych nasazenich Linux prohrava z hlediska vykonu - zda-li prohrava i celkove je spise otazka preferenci a sily dotycneho subjektu.

> 	Chapu ze Linux neumi vsechno (a Tru64 nebo Solaris taky neumi
> vsechno co umi Linux - treba vic routovacich tabulek, device mapper,
> _rozumne_ raw device, vyber z vice algoritmu schedulovani 
> diskovych operaci,
> atd.). 

	Samozrejme, ze jsou technologie, kterymi Linux oplyva a znacne prevysuje celou svoji konkurenci. Vyslovim vsak tezi, ze nelze mit nejlepsi OS, ktery bude jak pro aplikacni nasazeni, tak pro routery/smerovace. I Novell je velmi dobry a rock stable OS, ale jeho vykon v oblasti aplikacni moc dobre znaji ti, kdo ho pouzivaji. IOS v CISCU je velmi dobry OS, pridavat mu aplikacni funkcionalitu zrejme nikoho nenapadne. Bohuzel Linux je takovy system ala pejsek s kocickou varili dort, lidi to maji radi, zamlouva se jim to, ale obliba prece nesouvisi s tim, ze tento OS je nejlepsi ve vsem kde je nasazen...

> Ale neprijde mi, ze by zrovna "64-bitovost" byla 
> necim, v cem Linux
> nejak vyrazne zaostava.

	Mozna ne a muzete mit pravdu, realny vykon celeho systemu (jako ostatne kazdeho je limitovan nejslabsim clankem) je nizsi nez u jinych reseni. Mozna tim nejslabsim clankem je neco jineho nez kernel, to vsak zakaznika bude tezko zajimat, ten chce dodavku, system, je mu jedno co to je, pokud to bude splnovat nebo jeste lepe prevysovat jeho pozadavky ci predstavy.

> 	Treba jste chtel rict neco jineho - kdyztak zkuste
> preformulovat.

	Pokusil jsem se vyse, druha cast, zejmena odpoved na Vami polozene dotazy uz v nekterych smerech trochu odbihaji od puvodni nite, jsem si toho vedom. Vemte prosim za bernou minci zejmena prvni cast prispevku, kde jsem popsal co do "64-bitovosti" pocitam rovnez a co prave v Linuxu (ne nutne pouze kernelu) pomerne silne postradam.

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------