Vyznam dual core

[miho]

Bohužel tomu vše nasvědčuje. Nebo ty vidíš za poslední řekněme čtyři roky nějaký dramatický zvrat? Fyzika se začíná projevovat.

Mozna, ze se na to divame ze spatneho uhlu. Fyzika se projevuje a bude se projevovat stale vice. Zadny prulom neni v tomto smeru videt. Hlad po vykonu tady ale stale je. Mozna je tedy na case poohlednout se nekde jinde po kostlivcich, kteri nase problemy zpusobuji.

1) Prokleti 8086. Kdo najde odvahu zbavit se toho balastu a do nekonecna a ledabyle nabalovani novych funkci? Tento proces uz bezi 28 let. Tak jsem se tesil, ze to s potrebou prejit na 64bit procesory skonci... bohuzel AMD zase prislo s bastlem Jak moc bychom si vykonnostne a redukci poctu tranzistoru pomohli, kdybychom zacali na zelene louce? Procesor bez balastu zpetne kompatibility, od zacatku 64bitovy, s peclive navrzenou homogenni instrukcni sadou od zacatku pocitajici se SIMD, navrzen pro podporu vice jader/procesoru, procesor od zakladu navrzen pro virtualizaci. Je to do jiste miry utopie ale nastesti se najdou i inovativni projekty jako napr. Cell.

2) Programovaci paradigmata. V roce 1967 vznikl objektove orientovany jazyk Simula s garbage collectorem. Pak v 1980 Smalltalk prinesl spoustu novych myslenek, ktere jsou dodnes vetsine programatoru nezname (objektove programovani bez trid resp. kdy trida je objektem, jazyk, kde neni prikaz pro cyklus ani pro podminku pripada mnohym jako z Marsu ale uz si neuvedomi, ze to jsou konstrukce proceduralniho programovani, ktere v objektovem pristupu nemaji co delat). Posledni zmenu, ktera stoji za zminku- vyjimky popravde nevim, kde se vyskytly prvne. V Cfront 1983 uz ale byly. Deklarativni a funkcionalni jazyky stoji zcela stranou pozornosti. Tady bohuzel nemuzu navrhnout reseni. Nevim jak z toho ven a popravde ani kterym smerem. V kazdem pripade to je odvetvi, ve kterem nedoslo uz pres 20 let k zadne zasadni zmene v tak dynamicky se menicim prostredi.

[Eagle]

Mozna, ze se na to divame ze spatneho uhlu. Fyzika se projevuje a bude se projevovat stale vice. Zadny prulom neni v tomto smeru videt. Hlad po vykonu tady ale stale je. Mozna je tedy na case poohlednout se nekde jinde po kostlivcich, kteri nase problemy zpusobuji.

Tohle je podle mě ona největší brzda. Jednoznačně souhlas. Ne že bych x86 viděl jako něco principielně špatného, ale ony všechny rozšíření neustále přidávají složitost, zvětšují velikost instrukcí, snižují efektivitu. Nová architektura od základu navržená jako SIMD, se zaměřením na nejčastěji používané instrukce, s předpřipravenými pomocnými instrukcemi pro brzký odhad větvení a prefetch... to by přineslo výkonu mnohem víc než multicore. Beztak po nějakých cca. osmi jádrech už nemá multicore (vyjma speciálních aplikací) význam, neboť vynucený pokles frekvence způsobí větší snížení výkonu, než co přinese další jádro. Přidávání dalších jader je tedy velice krátkozraké, řešení tak na nejbližších pět let maximálně.

[Rainbow]

2) Programovaci paradigmata. V roce 1967 vznikl objektove orientovany jazyk Simula s garbage collectorem. Pak v 1980 Smalltalk prinesl spoustu novych myslenek, ktere jsou dodnes vetsine programatoru nezname (objektove programovani bez trid resp. kdy trida je objektem, jazyk, kde neni prikaz pro cyklus ani pro podminku pripada mnohym jako z Marsu ale uz si neuvedomi, ze to jsou konstrukce proceduralniho programovani, ktere v objektovem pristupu nemaji co delat). Posledni zmenu, ktera stoji za zminku- vyjimky popravde nevim, kde se vyskytly prvne. V Cfront 1983 uz ale byly. Deklarativni a funkcionalni jazyky stoji zcela stranou pozornosti. Tady bohuzel nemuzu navrhnout reseni. Nevim jak z toho ven a popravde ani kterym smerem. V kazdem pripade to je odvetvi, ve kterem nedoslo uz pres 20 let k zadne zasadni zmene v tak dynamicky se menicim prostredi.

Ked ma byt nieco aspon trochu efektivne, tak sa spravidla pouziva C - prikladom su jadra Linux a BSD, Unixove systemove nastroje a servery. Aj C++ ma svoje vyuzitie, len ked sa objekty nasilu pouzivaju tam, kde nemaju zmysel, tak to potom zle dopadne.
Smalltalk je v praxi uplne nepouzitelny - musel som v tom chvilu robit a ked ti Pentium pocita jeden sinus z konstatny 10 sekund...
Cim je jazyk vyssej urovne, tym viac plytva systemovymi prostriedkami (procesorovym casom, pamatou, miestom na disku).

[DRTiCZ]

http://home.pacbell.net/ouster/threa...0bad%20idea%22

vlakna jsou zkratka problem a opravdu si myslite, ze se v nich nekdo u games bude nejak zvlast babrat?

[Fox!MURDER]

http://home.pacbell.net/ouster/threa...0bad%20idea%22

vlakna jsou zkratka problem a opravdu si myslite, ze se v nich nekdo u games bude nejak zvlast babrat?

a jako potvrzeni tohohle 11 let staryho dokumentu zacal Sun vyrabet procesory s CoolThreads ...
navic se ten dokument zabejva temer vyhradne navrhem UI a lowend serveru... o hrach ani slovo ...

a docela by asi stalo za to vypichnout Threads more powerful than events, but power is rarely needed. ... sakra nevzpominate si nekdo, proc ze jsme se ted k tem threadum dostali? ... hmm ... nebylo to nahodou proto, ze potrebujeme 'more power'?

To docela mění zde nastolený směr diskuze - zjevně nebude problém zatížit jedno jádro výpočtem fyziky a kolizí, potíž bude v tom, že chceme-li, aby tato fyzika probíhala realtime (tj. aby například jedno auto neprojelo celé druhým a až pak byla zjištěna kolize), musí být fyzika spočítána hodně rychle, protože se jedná o sekvenční záležitost. A je zřejmě jasné, že když data musíme překopírovat z jednoho CPU do druhého, může DC dokonce i zpomalovat výpočet.

tady zas naopak vydim moznost pouziti symetrickejch threadu ... nemam moc tuseni, jak konkretne probiha vypocet fyziky ve scene, ale pocitam, ze se postupne pro jednotlivy objekty vypocitavaj drahy. proc neudelat jednoduchej box model pro urceni spolu nekolidujicich objektu a ty potom pocitat separatne v ruznejch vlaknech? samozrejme, zvetsi to komplexitu kodu, ale porad lepsi komplexnejsi kod, nez zadnej kod, nebo kod, kterej proste dnesni cpu nestihne. a zastavit vyvoj vseho do doby, nez se da dohromady nejaka jina architektura, mi prijde trosicku radikalni ...

mimochodem, nekde kus zpet jsi tvrdil, ze vice jader je reseni na max 5 let ... neni to tak akorat doba na to, abychom dali dohromady prechod na nejakou jinou architekturu, vymysleli nejaky jiny reseni?
me to prijde asi stejny, jako rict, ze benzinovy motory jsou spatny reseni, protoze jsou slozitejsi, mame prece paru, ropa jednou dojde a je to tim padem jem docasny reseni. jenze my chcem jezdit, chcem jezdit rychle a chcem jezdit ted.

[Caleb]

mimochodem, nekde kus zpet jsi tvrdil, ze vice jader je reseni na max 5 let ... neni to tak akorat doba na to, abychom dali dohromady prechod na nejakou jinou architekturu, vymysleli nejaky jiny reseni?

Me by spise zajimalo, zda je prechod na jinou architekturu realizovatelny - pochopitelne u Linuxu to neni skoro zadny problem, vetsina programu pujde s napr. s drobnyma upravama prekompilovat pro jinou architekturu a je to - ale v pripade Windows, tj 9x% vsech pocitacu/uzivatelu? Cela tahle masinerie funguje uz od dob 086tek na principu zpetne kompatibility a uzavrenem kodu drtive vetsiny aplikaci - pro prechod by musela byt imho k dispozi nova architektura radove vykonejsi nez stavajici x86, pak build Windowsu na novou architekturu (asi nejvetsi problem) a kvalitni emulator starych procesoru - tj. aby fungovaly napr. DirectX hry, starej software, ktery nema ekvivalentni nahradu atd. Takovemu Macintoshi se to povedlo (i kdyz narust vykonu byl v pripade emulovanych aplikaci zaporny) ale v pripade Microsoftu sem pomerne skepticky - navic softwarova zakladna u Mac a Windows je ponekud neporovnatelna. Toto tema by si mozna zaslouzilo zvlastni thread, dost by me zajimalo jakou ma kdo predstavu od odpoutani se od 8mi bitove kompatibility, BIOSu a podobnych prezitku.

[Eagle]

tady zas naopak vydim moznost pouziti symetrickejch threadu ... nemam moc tuseni, jak konkretne probiha vypocet fyziky ve scene, ale pocitam, ze se postupne pro jednotlivy objekty vypocitavaj drahy. proc neudelat jednoduchej box model pro urceni spolu nekolidujicich objektu a ty potom pocitat separatne v ruznejch vlaknech? samozrejme, zvetsi to komplexitu kodu, ale porad lepsi komplexnejsi kod, nez zadnej kod, nebo kod, kterej proste dnesni cpu nestihne. a zastavit vyvoj vseho do doby, nez se da dohromady nejaka jina architektura, mi prijde trosicku radikalni ...

Separátně? Nekolidující? Jak bys to jako chtěl určit? Napřed musíš vypočítat, jak se ta konkrétní věc bude chovat (jinými slovy kam v příštím frame poletí) a následně zjistit, zda některé z těchto objektů do sebe nenarazily. Kdybys prováděl výpočty pro každý objekt separátně na jednom jádře, nejspíš to bude šíleně pomalé kvůli tomu, že přenos výstupních dat mezi jádry bude trvat příliš mnoho času. A ani to nemůžeš počítat dopředu, protože to je interaktivní záležitost a jediný klik uživatele může změnit pohyb objektů.

me to prijde asi stejny, jako rict, ze benzinovy motory jsou spatny reseni, protoze jsou slozitejsi, mame prece paru, ropa jednou dojde a je to tim padem jem docasny reseni. jenze my chcem jezdit, chcem jezdit rychle a chcem jezdit ted.

To je zcestné srovnání, překrucuješ. Parní stroj je velký a má malou účinnost. Jezdí na uhlí nebo ropu, které jsou vzhledem k objemu energeticky ne právě úžasné. Benzínový motor má mnohem větší účinnost, palivo do něj je skladné a dobře se transportuje. Prostě benzínový motor je po všech stránkách lepší než parní stroj. Samozřejmě, za čas dojde ropa, pak se třeba bude jezdit na vodík, který je dneska výrobně drahý. BTW, benzínový motor byl v některých případech dávno nahrazen - ponorky a letadlové lodě většinou používají teplo z jaderného štěpení a elektromotory, některé americké lokomotivy a třeba tank Abrams pak gas turbine, která má vysoký poměr výkon/hmotnost (za cenu spotřeby). To jsou alternativní řešení, která mají pro některé aplikace opodstatnění (stejně jako dual-core do určitého počtu jader u serverů), nicméně pro běžné použití se nehodí.

Me by spise zajimalo, zda je prechod na jinou architekturu realizovatelny

Bez emulátoru (a lá DOSbox nebo druhé jádro pro x86) určitě ne. Hlavní problém je ale vymyslet onu novou architekturu. Věci jako VLIW v Itaniu jsou IMHO nepoužitelné, musel by to být CISC s podpůrnými informacemi v kódu, zcela nové konstrukce tak, aby ubcházel limity v hardware. Vytvořit něco takového by zabralo mnoho let.

[Fox!MURDER]

Separátně? Nekolidující? Jak bys to jako chtěl určit? Napřed musíš vypočítat, jak se ta konkrétní věc bude chovat (jinými slovy kam v příštím frame poletí) a následně zjistit, zda některé z těchto objektů do sebe nenarazily. Kdybys prováděl výpočty pro každý objekt separátně na jednom jádře, nejspíš to bude šíleně pomalé kvůli tomu, že přenos výstupních dat mezi jádry bude trvat příliš mnoho času. A ani to nemůžeš počítat dopředu, protože to je interaktivní záležitost a jediný klik uživatele může změnit pohyb objektů.

vsak jsem taky navrhl jednu moznost, jak zjistit nekolidujici objekty ...

To je zcestné srovnání, překrucuješ. Parní stroj je velký a má malou účinnost. Jezdí na uhlí nebo ropu, které jsou vzhledem k objemu energeticky ne právě úžasné. Benzínový motor má mnohem větší účinnost, palivo do něj je skladné a dobře se transportuje. Prostě benzínový motor je po všech stránkách lepší než parní stroj. Samozřejmě, za čas dojde ropa, pak se třeba bude jezdit na vodík, který je dneska výrobně drahý. BTW, benzínový motor byl v některých případech dávno nahrazen - ponorky a letadlové lodě většinou používají teplo z jaderného štěpení a elektromotory, některé americké lokomotivy a třeba tank Abrams pak gas turbine, která má vysoký poměr výkon/hmotnost (za cenu spotřeby). To jsou alternativní řešení, která mají pro některé aplikace opodstatnění (stejně jako dual-core do určitého počtu jader u serverů), nicméně pro běžné použití se nehodí.

prekroutit se to snazis ty. me tady slo o princip ... mimochodem ... prvni spalovaci motory mely 250BHP pri spotrebe 10l/100km ve meste, byly z lehkejch slitin, 99% spolehlivy a ekologicky? kdy zacaly jezit prvni dieslovy lokomotivy?
vis, kdyby kazdej uvazoval jako ty, stylem 'to nejde a ani nepude a kdyz to pude tak to bude moc drahy a kdyz to nebude moc drahy, tak to alespon nebude 100%ne efektivni a kdyby to naodou bylo 100%ne efektivni tak je to proste stejne spatny, protoze jsem to rek' tak porad pouzivame pazourky, ty jsou 100%ne efektivni. nastesti porad plati zasada ....

Nikdy neříkej, že něco nejde, protože se vždycky najde nějaký blbec,který neví, že to nejde a udělá to !!!

...
a dovolim si jeste jednu citaci ...

Kdo chce, hleda zpusoby, kdo nechce, hleda prekazky...

a ver mi, ze ti prvni jsou ti, kdo tahnou vyvoj dopredu...

[Eagle]

prvni spalovaci motory mely 250BHP pri spotrebe 10l/100km ve meste, byly z lehkejch slitin, 99% spolehlivy a ekologicky?

Jednak se mi to nezdá a i kdyby - jaká byla cena?

vis, kdyby kazdej uvazoval jako ty, stylem 'to nejde a ani nepude a kdyz to pude tak to bude moc drahy a kdyz to nebude moc drahy, tak to alespon nebude 100%ne efektivni a kdyby to naodou bylo 100%ne efektivni tak je to proste stejne spatny, protoze jsem to rek'

Já uvažuju ekonomicky, nejsem fantasta. Prosaditelné je pouze to řešení, u nějž benefity převáží náklady (včetně časové hodnoty peněz). Dual-core momentálně ony benefity nemá. Až je mít bude, tak se budeme bavit jinak. Ale já prostě nehodlám sponzorovat někoho, kdo si jen tak usmyslel, že svůj problém přesune na jiné lidi. Prostě můj ekonomický názor je ten, že pakliže výrobci CPU nejsou schopni nabídnout vyšší výkon pro stávající programy (nebo zajistit tvorbu vhodných programů jakožto náhrady zdarma!), pak není důvod kupovat jejich nové výrobky, a proto tito výrobci by měli značně klesnout s tržbami, popřípadě i zkrachovat. Nějaké fyzikální důvody stojící za jejich problémy mě absolutně nezajímají, protože to mi žádný benefit nepřinese. Nejsem nějaký štědrý sponzor, který bude vyjadřovat politování a jako projev soucitu věnovat někomu svoje peníze. A že by to bylo možná dobré do budoucna? No a? Já nebudu ten, kdo tuto budoucnost bude platit, chovám se racionálně - jako free rider (= když to můžeš zaplatit ty, tak proč bych to platil já?).