7. 8. 2008 - 16:44https://diit.cz/clanek/architektura-intel-larrabee/diskusewow, super clanek, to muselo dat hodne pracehttps://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432783
+
7. 8. 2008 - 16:48https://diit.cz/clanek/architektura-intel-larrabee/diskuseno ja bych tam ten anandtech jako zdroj pripsal ;)
http://anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3367&p=15https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432792
+
Mazec. Ale je (dnes) tilebased rendering plne realizovatelny? Jak se resi postprocess efekty na hranach ctvercu?
+1
0
-1
Je komentář přínosný?
Ren1 https://diit.cz/profil/ren1
7. 8. 2008 - 16:51https://diit.cz/clanek/architektura-intel-larrabee/diskuseMazec. Ale je (dnes) tilebased rendering plne realizovatelny? Jak se resi postprocess efekty na hranach ctvercu?https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432799
+
weepy: díky za upozornění, samozřejmě že AnandTech mezi zdroje patří, přidán.
+1
+1
-1
Je komentář přínosný?
David Ježek https://diit.cz/autor/david-jezek
7. 8. 2008 - 16:54https://diit.cz/clanek/architektura-intel-larrabee/diskuseweepy: díky za upozornění, samozřejmě že AnandTech mezi zdroje patří, přidán.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432807
+
Nechám se překvapit, jak to vše dopadne :) ale je to hodně zajímavé a mohlo by to totálně zamíchat kartama na poli gpu/cpu
+1
0
-1
Je komentář přínosný?
Groover One https://diit.cz/profil/groover99
7. 8. 2008 - 16:55https://diit.cz/clanek/architektura-intel-larrabee/diskuseNechám se překvapit, jak to vše dopadne :) ale je to hodně zajímavé a mohlo by to totálně zamíchat kartama na poli gpu/cpu https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432815
+
Rekl bych ze postprocess se resi az po slozeni tilu...ale v tom pripade bude zase postprocess brzdit rendering...
+1
0
-1
Je komentář přínosný?
xneal (neověřeno) https://diit.cz
7. 8. 2008 - 16:56https://diit.cz/clanek/architektura-intel-larrabee/diskuseRekl bych ze postprocess se resi az po slozeni tilu...ale v tom pripade bude zase postprocess brzdit rendering...https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432824
+
Ren: jsou dvě možnosti, buď každý procesor počítá s určitým přesahem a krajní body jsou tedy (zbytečně) vypočteny 2x, nebo se musí nějak vyřešit sdílení paměti ... podle druhu úlohy může být výhodnější jedna nebo druhá metoda. Každopádně to není žádný velký problém.
+1
-6
-1
Je komentář přínosný?
Azazel (neověřeno) https://diit.cz
7. 8. 2008 - 17:06https://diit.cz/clanek/architektura-intel-larrabee/diskuseRen: jsou dvě možnosti, buď každý procesor počítá s určitým přesahem a krajní body jsou tedy (zbytečně) vypočteny 2x, nebo se musí nějak vyřešit sdílení paměti ... podle druhu úlohy může být výhodnější jedna nebo druhá metoda. Každopádně to není žádný velký problém.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432832
+
"V době Radeonu X1800 přišla AMD s poměrně flexibilní obousměrnou prstencovou paměťovou sběrnicí a kartám to velmi prospělo. Mezitím na ní zapracovali a v poslední generaci HD 4800 to dotáhli prakticky k dokonalosti s unikátním paměťovým hubem"
Ono je to trochu jinak. A kdyby jste si pořádně přečeti jeden z vašich zdrojů (anandtech), tak by jste na to přišli.
Ringbus ati/amd VYMĚNILA za klasickou hub architekturu, protože zjistili, že je to těžký overkill, který jen žral plochu čipu, ale žádná z minulých, ani současných grafik (by) ho nevyužila.
Je jen zajímavé, jak z toho, že snížili výkon se u nás stal klad.
K tomu dali číslo, že se zvýšila efektivita a novináři byli hned nadšeni(ne, že by nebylo jasné, že se zvýší efektivita, když se lépe saturuje přenosová kapacita, ale na papíře to vypadá pěkně).
+1
-1
-1
Je komentář přínosný?
ptipi (neověřeno) https://diit.cz
7. 8. 2008 - 17:24https://diit.cz/clanek/architektura-intel-larrabee/diskuse"V době Radeonu X1800 přišla AMD s poměrně flexibilní obousměrnou prstencovou paměťovou sběrnicí a kartám to velmi prospělo. Mezitím na ní zapracovali a v poslední generaci HD 4800 to dotáhli prakticky k dokonalosti s unikátním paměťovým hubem"
Ono je to trochu jinak. A kdyby jste si pořádně přečeti jeden z vašich zdrojů (anandtech), tak by jste na to přišli.
Ringbus ati/amd VYMĚNILA za klasickou hub architekturu, protože zjistili, že je to těžký overkill, který jen žral plochu čipu, ale žádná z minulých, ani současných grafik (by) ho nevyužila.
Je jen zajímavé, jak z toho, že snížili výkon se u nás stal klad.
K tomu dali číslo, že se zvýšila efektivita a novináři byli hned nadšeni(ne, že by nebylo jasné, že se zvýší efektivita, když se lépe saturuje přenosová kapacita, ale na papíře to vypadá pěkně).https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432840
+
Ha - Intelova odpověď na moderní GPU? Kupte si hromadu Pentií 1. Myslím, že nVidia a ATI si můžou oddychnout. :-)
Ale teď vážně - myslíte, že pro to někdo bude umět programovat a napsat drivery? Aby to neskončilo jako slavný Cell, který je sice báječný a úžasně rychlý, ale v praxi je to pro normální práci pěkný šnek, protože většina kódu prostě nepočítá s tím, že by někdy mohla na něčem takovém běžet a musí se k němu ještě "přibalit" normální DX9 grafika, aby to mohlo fungovat aspoň jako konzole.
+1
-2
-1
Je komentář přínosný?
xvasek https://diit.cz/profil/xvasek
7. 8. 2008 - 17:50https://diit.cz/clanek/architektura-intel-larrabee/diskuseHa - Intelova odpověď na moderní GPU? Kupte si hromadu Pentií 1. Myslím, že nVidia a ATI si můžou oddychnout. :-)
Ale teď vážně - myslíte, že pro to někdo bude umět programovat a napsat drivery? Aby to neskončilo jako slavný Cell, který je sice báječný a úžasně rychlý, ale v praxi je to pro normální práci pěkný šnek, protože většina kódu prostě nepočítá s tím, že by někdy mohla na něčem takovém běžet a musí se k němu ještě "přibalit" normální DX9 grafika, aby to mohlo fungovat aspoň jako konzole.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432847
+
xvasek: No Cell pokial sa na nom emuluje x86 je naozaj pomaly ale pokial ide na nom pren napisany os tak to su potom ine vykony. V paralelnych vypoctoch niekolko krat predci akykolvek x86 CPU.
Co sa tyka Larabee tak som si tiez myslel ze to bude dalsie itanium no po precitani clanku na anandtechu si myslim ze je to nadejna architektura ktora bude schopna rozbehat ako terajsie hry na DirectX tak aj hry zalozene na inom rozhrani - resp. bez rozhrania napisane priamo pre Larabee.
btw. xvasek - larabee nie je len hromada pentii - kazde jadro totizto obsahuje 16 vektorovych jednotiek, a vies kolko takychto jednotiek obsahovalo pentium? Ziadnu. :D
+1
0
-1
Je komentář přínosný?
Rotavator (neověřeno) https://diit.cz
7. 8. 2008 - 18:30https://diit.cz/clanek/architektura-intel-larrabee/diskusexvasek: No Cell pokial sa na nom emuluje x86 je naozaj pomaly ale pokial ide na nom pren napisany os tak to su potom ine vykony. V paralelnych vypoctoch niekolko krat predci akykolvek x86 CPU.
Co sa tyka Larabee tak som si tiez myslel ze to bude dalsie itanium no po precitani clanku na anandtechu si myslim ze je to nadejna architektura ktora bude schopna rozbehat ako terajsie hry na DirectX tak aj hry zalozene na inom rozhrani - resp. bez rozhrania napisane priamo pre Larabee.
btw. xvasek - larabee nie je len hromada pentii - kazde jadro totizto obsahuje 16 vektorovych jednotiek, a vies kolko takychto jednotiek obsahovalo pentium? Ziadnu. :Dhttps://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432857
+
Eh, ta hrubá síla je spíš Intel, když nahrazuje specializovaný HW hromadou univerzálních CPU a softwarovou vrstvou. Nicméně že tím bude mít výhodu větší přizpůsobivosti asi bude pravda. BTW mám silný pocit, že Intel tímhle docela kopíruje Cell. U něj je ta vektorová výbavička v zvláštních jednotkách, u Intelu přío v jádrech. Efekt asi stejný...
Jinak GPU mají taky systémy pro kašlání na neviditelné elementy.
+1
+2
-1
Je komentář přínosný?
Mandarincatko (neověřeno) https://diit.cz
7. 8. 2008 - 18:32https://diit.cz/clanek/architektura-intel-larrabee/diskuseEh, ta hrubá síla je spíš Intel, když nahrazuje specializovaný HW hromadou univerzálních CPU a softwarovou vrstvou. Nicméně že tím bude mít výhodu větší přizpůsobivosti asi bude pravda. BTW mám silný pocit, že Intel tímhle docela kopíruje Cell. U něj je ta vektorová výbavička v zvláštních jednotkách, u Intelu přío v jádrech. Efekt asi stejný...
Jinak GPU mají taky systémy pro kašlání na neviditelné elementy.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432865
+
Rotavator (byls rychlejší):
1. Není to 16 jednotek, je to jedna 512bitová.
2. Cell nemá aža takový výkon - přes 200gflops, ale při double precision to klesne pod sedminu. Nicméně nové modely mohou nsdno přidat větší počet jader, a snad i něco udělat s tím double precision. Snad se ty léta neflákali.
+1
0
-1
Je komentář přínosný?
Mandarincatko (neověřeno) https://diit.cz
7. 8. 2008 - 18:36https://diit.cz/clanek/architektura-intel-larrabee/diskuseRotavator (byls rychlejší):
1. Není to 16 jednotek, je to jedna 512bitová.
2. Cell nemá aža takový výkon - přes 200gflops, ale při double precision to klesne pod sedminu. Nicméně nové modely mohou nsdno přidat větší počet jader, a snad i něco udělat s tím double precision. Snad se ty léta neflákali.
https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432873
+
Ufff, tak jsem dočetl. Pěkně hutný materiál. Vypadá to hodně dobře a uvidíme, jak to Intel prosadí. Nicméně, i kdyby se to nepodařilo prosadit do Game segmentu, tak mezi profi grafikami to může nadělat pěknou paseku. Doufám, že Intel nezklame a bude tu bezproblémová podpora Linuxu.
+1
-2
-1
Je komentář přínosný?
corwin78 https://diit.cz/profil/corwin78
7. 8. 2008 - 18:41https://diit.cz/clanek/architektura-intel-larrabee/diskuseUfff, tak jsem dočetl. Pěkně hutný materiál. Vypadá to hodně dobře a uvidíme, jak to Intel prosadí. Nicméně, i kdyby se to nepodařilo prosadit do Game segmentu, tak mezi profi grafikami to může nadělat pěknou paseku. Doufám, že Intel nezklame a bude tu bezproblémová podpora Linuxu.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432880
+
V celem clanku mi chybi zasadni porovnani a to s CELL, silne mi ho to pripomina, a teda o nejake revoluci bych zas moc nemluvil.
At je intel jaky chce, paralelizovat cokoli neni zrovna trivialni takze bych tak optimisticky nebyl. (i kdyz je mi jasne ze inzenyri v intelu do toho vidi lepe nez ja)
Mimochodem k cemu nam bude v roce 2010 AA? Pri tom rozliseni uz to bude uplne jedno :)
+1
0
-1
Je komentář přínosný?
zzz (neověřeno) https://diit.cz
7. 8. 2008 - 18:41https://diit.cz/clanek/architektura-intel-larrabee/diskuseV celem clanku mi chybi zasadni porovnani a to s CELL, silne mi ho to pripomina, a teda o nejake revoluci bych zas moc nemluvil.
At je intel jaky chce, paralelizovat cokoli neni zrovna trivialni takze bych tak optimisticky nebyl. (i kdyz je mi jasne ze inzenyri v intelu do toho vidi lepe nez ja)
Mimochodem k cemu nam bude v roce 2010 AA? Pri tom rozliseni uz to bude uplne jedno :) https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432889
+
Tak jsem sice spíš AMDčkař ale doufám že tohle se chytne, protože to vypadá zajímavě.
Jen mám takový dotaz. Jak jsem pochopil Intelácké procesory sebou táhnou léta staré chyby v návrhu. Pokud se použijí jádra založená na pentiu, tak většina chyb zmizí, ne? A jaká je šance, že opraví i to, co bylo už v pentiích?
+1
-1
-1
Je komentář přínosný?
Pavelll (neověřeno) https://diit.cz
7. 8. 2008 - 18:48https://diit.cz/clanek/architektura-intel-larrabee/diskuseTak jsem sice spíš AMDčkař ale doufám že tohle se chytne, protože to vypadá zajímavě.
Jen mám takový dotaz. Jak jsem pochopil Intelácké procesory sebou táhnou léta staré chyby v návrhu. Pokud se použijí jádra založená na pentiu, tak většina chyb zmizí, ne? A jaká je šance, že opraví i to, co bylo už v pentiích?https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432897
+
7. 8. 2008 - 19:37https://diit.cz/clanek/architektura-intel-larrabee/diskusePojede mi na tom Solitaire rychleji?https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432909
+
> hinnat : Jistě. Jen ty už to nebudeš schopen poznat... ;-)
+1
-3
-1
Je komentář přínosný?
-pao- (neověřeno) https://diit.cz
7. 8. 2008 - 19:44https://diit.cz/clanek/architektura-intel-larrabee/diskuse> hinnat : Jistě. Jen ty už to nebudeš schopen poznat... ;-)https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432917
+
Rotavator: Pentium melo vektorovou jednotku :)... jen ty vektory mely jen jednu slozku :D.
zzz: jakepak srovnani, kdyz nemas produkt, ale jen extrapolace namlsavacich a kusych prezentaci intelu?
S tou paralelizaci se pletes, neco se paralelizuje lip a neco hur. Grafika je v tomhle ohledu to nejsnadnejsi. Intel v tomhle dela to, co dava az strasidelne dobry smysl a ja jen doufam, ze AMD neco podobneho taky pece.
Pavell: jestli miris na FDIV bug, intel mel na opravu techto veci 10 let. Ono to z pentia stejne jen vychazi, ma to s nim spolecne charakteristiky, jako in-order exekuce, kolik ma alu a priblizne radove pocet tranzistoru. Ale vnitrek je totalne prekopany, vzdyt to bude umet 64-bit x86 kod, ctyrnasobny multithreading, bude to mit hlubsi pipeline a FPU, co bude makat nad 16 floatama najednou, prefetchery, synchonizace cache... Pentium to bude maximalne tak "filozoficky pripominat".
+1
+2
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
7. 8. 2008 - 19:47https://diit.cz/clanek/architektura-intel-larrabee/diskuseDavid Jezek: np :)
Rotavator: Pentium melo vektorovou jednotku :)... jen ty vektory mely jen jednu slozku :D.
zzz: jakepak srovnani, kdyz nemas produkt, ale jen extrapolace namlsavacich a kusych prezentaci intelu?
S tou paralelizaci se pletes, neco se paralelizuje lip a neco hur. Grafika je v tomhle ohledu to nejsnadnejsi. Intel v tomhle dela to, co dava az strasidelne dobry smysl a ja jen doufam, ze AMD neco podobneho taky pece.
Pavell: jestli miris na FDIV bug, intel mel na opravu techto veci 10 let. Ono to z pentia stejne jen vychazi, ma to s nim spolecne charakteristiky, jako in-order exekuce, kolik ma alu a priblizne radove pocet tranzistoru. Ale vnitrek je totalne prekopany, vzdyt to bude umet 64-bit x86 kod, ctyrnasobny multithreading, bude to mit hlubsi pipeline a FPU, co bude makat nad 16 floatama najednou, prefetchery, synchonizace cache... Pentium to bude maximalne tak "filozoficky pripominat".https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432925
+
Mno, osobně si myslím, že TOTO (Larrabee) nemá šanci na širší úspěch. Bezesporu to bude asi dobrý konkurent pro CUDA a spol., ale pro SOHO grafické karty to s ohledem na očekávánou spotřebu (včetně idle) bude velmi nepoužitelné.
+1
-5
-1
Je komentář přínosný?
TyNyT https://diit.cz/profil/tynyt
7. 8. 2008 - 19:49https://diit.cz/clanek/architektura-intel-larrabee/diskuseMno, osobně si myslím, že TOTO (Larrabee) nemá šanci na širší úspěch. Bezesporu to bude asi dobrý konkurent pro CUDA a spol., ale pro SOHO grafické karty to s ohledem na očekávánou spotřebu (včetně idle) bude velmi nepoužitelné.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432932
+
No to jsem zvědavý, jak se programátorům bude chtít na to psát aplikace, aby ten paralelismus využili. Nebo to bude jednovláknová aplikace a o rozdělení se postará operační systém? Tomu bych nevěřil ani kdyby to byl Linux, natož Windows. Myslím že jako CPU pro to nikdo nebude psát aplikace. Jako GPU nicméně dost dobrý. Možná si u Intelu řekli, že udělají CPU, ale když se to jako CPU nechytne, musí se to dát prodat aspoň jako GPU. A proto to je tak univerzální, aby to nezkončilo jako Cell. Prostě aby se ten vývoj vyplatil.
+1
+1
-1
Je komentář přínosný?
Milan M (neověřeno) https://diit.cz
7. 8. 2008 - 19:51https://diit.cz/clanek/architektura-intel-larrabee/diskuseNo to jsem zvědavý, jak se programátorům bude chtít na to psát aplikace, aby ten paralelismus využili. Nebo to bude jednovláknová aplikace a o rozdělení se postará operační systém? Tomu bych nevěřil ani kdyby to byl Linux, natož Windows. Myslím že jako CPU pro to nikdo nebude psát aplikace. Jako GPU nicméně dost dobrý. Možná si u Intelu řekli, že udělají CPU, ale když se to jako CPU nechytne, musí se to dát prodat aspoň jako GPU. A proto to je tak univerzální, aby to nezkončilo jako Cell. Prostě aby se ten vývoj vyplatil.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432941
+
Problém je... že pokud by larrabee uspělo, ohrozí to nvidii, ati, ale hlavně pozici microsoftu, jelikož poslední věc co drží lidi na jeho OS resp. kvůli které ani nevyzkouší jiný OS, jsou hry pod DirectX... což by tímto počinem padlo.... takže pokud by intel uspěl, tak to bude doslova navzdory všem...
+1
+1
-1
Je komentář přínosný?
Buffalo (neověřeno) https://diit.cz
7. 8. 2008 - 19:52https://diit.cz/clanek/architektura-intel-larrabee/diskuseProblém je... že pokud by larrabee uspělo, ohrozí to nvidii, ati, ale hlavně pozici microsoftu, jelikož poslední věc co drží lidi na jeho OS resp. kvůli které ani nevyzkouší jiný OS, jsou hry pod DirectX... což by tímto počinem padlo.... takže pokud by intel uspěl, tak to bude doslova navzdory všem...https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432949
+
Jo zni to vsechno uzasne,ale ma to chybicku.Vsichni si zvykli na DirectX a OpenGl a tezko budou od piky delat novej render pro larabee, kdyz 98 procent hernich pocitacu ma grafiky typu ati a nvidia. Jeste k tomu maji odladene ovladace pro hry coz intel mit nebude. Larabee skonci jako itanium , nepouzitelny dinosaur, ktery zahyne diky sve velikosti.Bude ale stejne tak dlouho umele ozivovany.
+1
+1
-1
Je komentář přínosný?
kingpin (neověřeno) https://diit.cz
7. 8. 2008 - 20:09https://diit.cz/clanek/architektura-intel-larrabee/diskuseJo zni to vsechno uzasne,ale ma to chybicku.Vsichni si zvykli na DirectX a OpenGl a tezko budou od piky delat novej render pro larabee, kdyz 98 procent hernich pocitacu ma grafiky typu ati a nvidia. Jeste k tomu maji odladene ovladace pro hry coz intel mit nebude. Larabee skonci jako itanium , nepouzitelny dinosaur, ktery zahyne diky sve velikosti.Bude ale stejne tak dlouho umele ozivovany.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432957
+
Pár předchozích příspěvků: Tahle věc se přece s DX ani O GL nevylučuje.
weepy:Měl jsem za to, že těch chyb je víc a ne všechny jsou opravené.
+1
+4
-1
Je komentář přínosný?
Pavelll (neověřeno) https://diit.cz
7. 8. 2008 - 20:58https://diit.cz/clanek/architektura-intel-larrabee/diskusePár předchozích příspěvků: Tahle věc se přece s DX ani O GL nevylučuje.
weepy:Měl jsem za to, že těch chyb je víc a ne všechny jsou opravené.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432975
+
to: Buffalo
ale nie, vsak ludia budu chciet hrat aj starsie tituly a myslis ze ich niekto prerobi do noveho kodu. Za dalsie MS uprednostnuje platformu Intel a nepisane dohody "my zvysime narocnost naseho OS aby vase CPU isli lepsie na odbyt" tak ze nejake Larrabee nezabije MS.
+1
-3
-1
Je komentář přínosný?
Torx Miller https://diit.cz/profil/torx
7. 8. 2008 - 21:10https://diit.cz/clanek/architektura-intel-larrabee/diskuseto: Buffalo
ale nie, vsak ludia budu chciet hrat aj starsie tituly a myslis ze ich niekto prerobi do noveho kodu. Za dalsie MS uprednostnuje platformu Intel a nepisane dohody "my zvysime narocnost naseho OS aby vase CPU isli lepsie na odbyt" tak ze nejake Larrabee nezabije MS. https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432982
+
Milan M: Larrabee se bude chtit prosadit nejdriv hlavne jako GPU s tim, ze to bude mit i sirsi uplatneni - kdo chce, vykon larrabee vyuzije, neni to jako s CPU, kde s prechodem na dvoujadro ziskas misto 20GFlops 40 GFlops s velkymi naroky na vyvoj.. tady se bavime o radove vyssim vykonu, x86 @ TFlops, to uz neco bude znamenat, tam se do vyvoje investovat uz sakra vyplati.
Torx: vystizne :)
+1
+5
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
7. 8. 2008 - 21:42https://diit.cz/clanek/architektura-intel-larrabee/diskuseMilan M: Larrabee se bude chtit prosadit nejdriv hlavne jako GPU s tim, ze to bude mit i sirsi uplatneni - kdo chce, vykon larrabee vyuzije, neni to jako s CPU, kde s prechodem na dvoujadro ziskas misto 20GFlops 40 GFlops s velkymi naroky na vyvoj.. tady se bavime o radove vyssim vykonu, x86 @ TFlops, to uz neco bude znamenat, tam se do vyvoje investovat uz sakra vyplati.
Torx: vystizne :)
https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432991
+
re TyNyT: kdyby se o to pokoušel kdokoliv jiný, určitě bych s tebou souhlasil, ale intel má takové prostředky, které si nikdo jiný dovolit nemůže (nemyslím jen prachy, ale i know-how, nejlepší výrobní linky,...). Navíc klidně to narozdíl od kohokoliv jiného může ze začátku prodávat bez výdělku za výrobní náklady.
+1
-1
-1
Je komentář přínosný?
ptipi (neověřeno) https://diit.cz
7. 8. 2008 - 21:44https://diit.cz/clanek/architektura-intel-larrabee/diskusere TyNyT: kdyby se o to pokoušel kdokoliv jiný, určitě bych s tebou souhlasil, ale intel má takové prostředky, které si nikdo jiný dovolit nemůže (nemyslím jen prachy, ale i know-how, nejlepší výrobní linky,...). Navíc klidně to narozdíl od kohokoliv jiného může ze začátku prodávat bez výdělku za výrobní náklady. https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-432999
+
Jen takový nápad..... Neustále se řeší starý známý problém - speciální hardware, který nabízí pro speciální úkoly vysokou efektivitu a také výkon , avšak za s nevýhodou malé univerzálnosti.... versus hardware, který je připraven na široké množství zpracování různých úloh, avšak ve srovnání se specializovaným hardware tyto úlohy obecně řeší méně efektivně....
Což to takhle toto mnohaleté dilema vyřešit třeba použitím univerzálního programovatelného hradlového pole (FPGA)? - Např. grafická karta by obsahovala tento obvod, který sám o sobě sice nezvládá vůbec nic, ale podle typu právě řešené úlohy by ještě před zavedením vlastního programu byl design FPGA (či nějakého podobného obvodu) naprogramován na maximálně výkonnou podporu v dané konkrétní aplikaci.... např. svůj vlastní design by mohly mít různé fyzikální enginy, dále DX, OpenGL, atd.... každý design by byl navržen na podání maximálního výkonu pro dané rozhraní... Co na to říkáte? Programovat - flexibilně (za chodu) měnit design - přímo hardware... je to moc ujetý nápad? Proč s tím ještě nikdo nepřišel?
+1
0
-1
Je komentář přínosný?
Ma (neověřeno) https://diit.cz
7. 8. 2008 - 21:54https://diit.cz/clanek/architektura-intel-larrabee/diskuseJen takový nápad..... Neustále se řeší starý známý problém - speciální hardware, který nabízí pro speciální úkoly vysokou efektivitu a také výkon , avšak za s nevýhodou malé univerzálnosti.... versus hardware, který je připraven na široké množství zpracování různých úloh, avšak ve srovnání se specializovaným hardware tyto úlohy obecně řeší méně efektivně....
Což to takhle toto mnohaleté dilema vyřešit třeba použitím univerzálního programovatelného hradlového pole (FPGA)? - Např. grafická karta by obsahovala tento obvod, který sám o sobě sice nezvládá vůbec nic, ale podle typu právě řešené úlohy by ještě před zavedením vlastního programu byl design FPGA (či nějakého podobného obvodu) naprogramován na maximálně výkonnou podporu v dané konkrétní aplikaci.... např. svůj vlastní design by mohly mít různé fyzikální enginy, dále DX, OpenGL, atd.... každý design by byl navržen na podání maximálního výkonu pro dané rozhraní... Co na to říkáte? Programovat - flexibilně (za chodu) měnit design - přímo hardware... je to moc ujetý nápad? Proč s tím ještě nikdo nepřišel?https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433007
+
STejně jako Corwin78 si myslím, že Intel míří spíš do profesionálních grafik. Tam by to mohlo docela zamíchat trhem. Třeba takové počítání efektů ve Photoshopu, nebo rovnou na videu. Případně jako akcelerátor některých operací v CADech. Například update výkresu při změně modelu/sestavy apd, kde se často jedná o lehce paraelizovatelné procesy by to mohlo být dopst zajímavé.
+1
0
-1
Je komentář přínosný?
Vebloud https://diit.cz/profil/vebloud
7. 8. 2008 - 22:22https://diit.cz/clanek/architektura-intel-larrabee/diskuseSTejně jako Corwin78 si myslím, že Intel míří spíš do profesionálních grafik. Tam by to mohlo docela zamíchat trhem. Třeba takové počítání efektů ve Photoshopu, nebo rovnou na videu. Případně jako akcelerátor některých operací v CADech. Například update výkresu při změně modelu/sestavy apd, kde se často jedná o lehce paraelizovatelné procesy by to mohlo být dopst zajímavé.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433023
+
Lidi podle me je zbytecny se hadat o tom co tento cip bude umet a co ne nebo jaka bude jeho efektivnost. Jedina a dulezita vec je co z toho intel dokaze vytriskat. Je jedno jaka je to archyrchytekura jestli je to ATI NVIDIA nebo INTEL nakonec vzdycky zvitezi ti kteri podaji nejlepsi pomer cena/vykon. V tomto pripade ma ale intel neco navic a to TEORETICKOU zpetnou kompatibylitu x86 ktera by sama o sobe mohla docela zamichat kartama. A jeste se zamyslete - nepripomina vam tato archytektura neco? Mne jo a to cip s "pracovnim" nazvem Terrascale coz je cip kterej ma zvladat neco kolem 1-2TFLOPs podle frekvence akoratze "predprodukcni" vzorek neumel x86 sadu a nasazeni podobne archytektury Intel planuje NEJDRIV kolem roku 2015. Zacina se nam to pekne vybarvovat. Ted si do toho zamicham NVIDIU a jeji udajnej ustup z trhu chipovich sad. NVIDIA ted uvede ovladace ktere umozni pocitat fyziku primo na GK a stahne se z oblasti vyroby cip. sad pro AMD a Intel (je jedno zda nucene nebo tim ze nedokaze konkurovat) posledni hrac na poly procesoru zustava VIA ale ta zdaleka nestaci vykonem na svoje vetsi soupere. Ale co se stane pokud procesoru odlehcime tim ze u her (napriklad) nebude muset pocitat fyziku? bude mit vic casu na ostatni ukoli a tim se setrou rozdili. VIA (napriklad) pojede vytizena na 95% zatimco Intel na 60% ale koho z beznych zakazniku to zajima? Prakticky nikoho zvlast pri spotrebe procesoru VIA. Kdyz k tomu pridam to ze (pouze ma spekulace) se v budoucnu obevi software kterej dokaze predat u her spravu kompletni AI na bedra GK tak pak uz bude procesor jen a pouze cip kterej ridi komunikaci mezi jednotlivima periferiemi a tim padem nebude potreba takovej vykon jako dnes. KDYBY nahodou nastala sytuace kterou sem zde nastinil pak by VIA mela vyhrany - sice nizkej vykon CPU ale zase extreme nizka spotreba kombinovana s DOSTATECNYM vykonem a tim docela vysoka efektivita prace CPU narozdil od konkurence ktera ma sice spoustu vykonu ale v porovnani s VIA procesory docela nizkou efektivitu na W at si tvrdi co chtej.
+1
+4
-1
Je komentář přínosný?
NeomeN (neověřeno) https://diit.cz
7. 8. 2008 - 22:37https://diit.cz/clanek/architektura-intel-larrabee/diskuseLidi podle me je zbytecny se hadat o tom co tento cip bude umet a co ne nebo jaka bude jeho efektivnost. Jedina a dulezita vec je co z toho intel dokaze vytriskat. Je jedno jaka je to archyrchytekura jestli je to ATI NVIDIA nebo INTEL nakonec vzdycky zvitezi ti kteri podaji nejlepsi pomer cena/vykon. V tomto pripade ma ale intel neco navic a to TEORETICKOU zpetnou kompatibylitu x86 ktera by sama o sobe mohla docela zamichat kartama. A jeste se zamyslete - nepripomina vam tato archytektura neco? Mne jo a to cip s "pracovnim" nazvem Terrascale coz je cip kterej ma zvladat neco kolem 1-2TFLOPs podle frekvence akoratze "predprodukcni" vzorek neumel x86 sadu a nasazeni podobne archytektury Intel planuje NEJDRIV kolem roku 2015. Zacina se nam to pekne vybarvovat. Ted si do toho zamicham NVIDIU a jeji udajnej ustup z trhu chipovich sad. NVIDIA ted uvede ovladace ktere umozni pocitat fyziku primo na GK a stahne se z oblasti vyroby cip. sad pro AMD a Intel (je jedno zda nucene nebo tim ze nedokaze konkurovat) posledni hrac na poly procesoru zustava VIA ale ta zdaleka nestaci vykonem na svoje vetsi soupere. Ale co se stane pokud procesoru odlehcime tim ze u her (napriklad) nebude muset pocitat fyziku? bude mit vic casu na ostatni ukoli a tim se setrou rozdili. VIA (napriklad) pojede vytizena na 95% zatimco Intel na 60% ale koho z beznych zakazniku to zajima? Prakticky nikoho zvlast pri spotrebe procesoru VIA. Kdyz k tomu pridam to ze (pouze ma spekulace) se v budoucnu obevi software kterej dokaze predat u her spravu kompletni AI na bedra GK tak pak uz bude procesor jen a pouze cip kterej ridi komunikaci mezi jednotlivima periferiemi a tim padem nebude potreba takovej vykon jako dnes. KDYBY nahodou nastala sytuace kterou sem zde nastinil pak by VIA mela vyhrany - sice nizkej vykon CPU ale zase extreme nizka spotreba kombinovana s DOSTATECNYM vykonem a tim docela vysoka efektivita prace CPU narozdil od konkurence ktera ma sice spoustu vykonu ale v porovnani s VIA procesory docela nizkou efektivitu na W at si tvrdi co chtej.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433033
+
Ma: to už tady bylo. Měla to v obdobné kdysi Amiga...
+1
0
-1
Je komentář přínosný?
TyNyT https://diit.cz/profil/tynyt
7. 8. 2008 - 22:58https://diit.cz/clanek/architektura-intel-larrabee/diskuseMa: to už tady bylo. Měla to v obdobné kdysi Amiga... https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433040
+
Rotavator: nepochopil jsi muj vtip, celociselnou vektorovou praci nepocitam, FPU tam je furt jedno, pointa mela byt v tom, ze jednoslozkovy vektor a cislo jsou to samy...
+1
-2
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
7. 8. 2008 - 22:58https://diit.cz/clanek/architektura-intel-larrabee/diskuseRotavator: nepochopil jsi muj vtip, celociselnou vektorovou praci nepocitam, FPU tam je furt jedno, pointa mela byt v tom, ze jednoslozkovy vektor a cislo jsou to samy...https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433050
+
ptipi: Nevím, jak jsi přišel na to, že ring-bus je overkill, žrout tranzistorů, nebo že hub je něco klasického :-) nVidia G200 na realizaci 512bit sběrnice využívá téměř 25% plochy jádra jen pro paměťový subsystém. Přepočteme-li to na rozměry R600, která byla též 512 bitová a využívala ring-bus, tak je jasné, že s konceptem řadiče, který využívá nVidia na G200, by R600 musela být tvořena z 50% jen paměťovým řadičem - stačí se podívat na die-shot R600 a hned je jasné, jaký je to nesmysl a tedy o kolik byl ring-bus menší. Se 4 SIMDs byl ring-bus pro R600 ideální, protože díky pouhým čtyřem ring-stops byl nejúspornějším možným řešením při implementaci 512-bitového paměťového rozhraní. Krom toho ring-bus jako jediné řešení umožňoval nezávislost počtu paměťových kanálů na počtu ROPs, takže dodatečně umožňoval redukci zbytečných ROPs. Jediný důvod, proč od něj ATi upustila, je, že při 10 SIMDs RV770 by počet ring-stops (a tím i komplexnost řadiče) příliš narostly. Krom toho ring-bus zastával i úlohy, které jsou nyní řešeny implementací lokálních řadičů, jež v R600 nebyly přítomny.
+1
+1
-1
Je komentář přínosný?
no-X (neověřeno) https://diit.cz
7. 8. 2008 - 23:05https://diit.cz/clanek/architektura-intel-larrabee/diskuseptipi: Nevím, jak jsi přišel na to, že ring-bus je overkill, žrout tranzistorů, nebo že hub je něco klasického :-) nVidia G200 na realizaci 512bit sběrnice využívá téměř 25% plochy jádra jen pro paměťový subsystém. Přepočteme-li to na rozměry R600, která byla též 512 bitová a využívala ring-bus, tak je jasné, že s konceptem řadiče, který využívá nVidia na G200, by R600 musela být tvořena z 50% jen paměťovým řadičem - stačí se podívat na die-shot R600 a hned je jasné, jaký je to nesmysl a tedy o kolik byl ring-bus menší. Se 4 SIMDs byl ring-bus pro R600 ideální, protože díky pouhým čtyřem ring-stops byl nejúspornějším možným řešením při implementaci 512-bitového paměťového rozhraní. Krom toho ring-bus jako jediné řešení umožňoval nezávislost počtu paměťových kanálů na počtu ROPs, takže dodatečně umožňoval redukci zbytečných ROPs. Jediný důvod, proč od něj ATi upustila, je, že při 10 SIMDs RV770 by počet ring-stops (a tím i komplexnost řadiče) příliš narostly. Krom toho ring-bus zastával i úlohy, které jsou nyní řešeny implementací lokálních řadičů, jež v R600 nebyly přítomny.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433058
+
re no-X: nepřišel jsem na to já, ale lidé od anandtechu, kterým to pro změnu řekli lidé od amd/ati. stačí si to přečíst.
+1
0
-1
Je komentář přínosný?
ptipi (neověřeno) https://diit.cz
7. 8. 2008 - 23:15https://diit.cz/clanek/architektura-intel-larrabee/diskusere no-X: nepřišel jsem na to já, ale lidé od anandtechu, kterým to pro změnu řekli lidé od amd/ati. stačí si to přečíst.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433066
+
re no-X: a jak jsem přišel na to, že hub je klasika? protože např. crossbar byl použit, pokud vím, třeba už u geforce 3. crossbar je klasická implementace přepínače. jen to tehdy všichni stále nazývali paměťovým řadičem. amd by jen těžko uspělo s tím, že se vracejí ke klasice (protože zjistili, že poměr výkon/plocha nebyl nejlepší), tak to samozřejmě označili jinak.
i když je fakt, že do toho "hubu" teď jdou i linky z pciex a cf. to je ale spíš jen otázka jiného rozdělení.
+1
-3
-1
Je komentář přínosný?
ptipi (neověřeno) https://diit.cz
7. 8. 2008 - 23:26https://diit.cz/clanek/architektura-intel-larrabee/diskusere no-X: a jak jsem přišel na to, že hub je klasika? protože např. crossbar byl použit, pokud vím, třeba už u geforce 3. crossbar je klasická implementace přepínače. jen to tehdy všichni stále nazývali paměťovým řadičem. amd by jen těžko uspělo s tím, že se vracejí ke klasice (protože zjistili, že poměr výkon/plocha nebyl nejlepší), tak to samozřejmě označili jinak.
i když je fakt, že do toho "hubu" teď jdou i linky z pciex a cf. to je ale spíš jen otázka jiného rozdělení.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433074
+
re no-x: a ještě jedna drobnost- neřekl jsem žout tranzistorů, ale PLOCHY. ringbus totiž bral plochu i velkým množstvím spojů (opět převzeto z anandtechu).
+1
0
-1
Je komentář přínosný?
ptipi (neověřeno) https://diit.cz
7. 8. 2008 - 23:28https://diit.cz/clanek/architektura-intel-larrabee/diskusere no-x: a ještě jedna drobnost- neřekl jsem žout tranzistorů, ale PLOCHY. ringbus totiž bral plochu i velkým množstvím spojů (opět převzeto z anandtechu).https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433082
+
:) Larabee je přesně to , co se dalo o tomto projektu vytušit už dříve - univerzální procesor .
+1
0
-1
Je komentář přínosný?
Xspy https://diit.cz/profil/xspy
8. 8. 2008 - 03:10https://diit.cz/clanek/architektura-intel-larrabee/diskuse:) Larabee je přesně to , co se dalo o tomto projektu vytušit už dříve - univerzální procesor .https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433088
+
Po přečtení mne napadly dvě věci:
- Probůh, vždyť to je snad x86 Cell!
- To se té zkriplené x86 architektury už vážně nikdy nezbavíme? :-(
+1
-1
-1
Je komentář přínosný?
JirkaSik (neověřeno) https://diit.cz
8. 8. 2008 - 08:06https://diit.cz/clanek/architektura-intel-larrabee/diskusePo přečtení mne napadly dvě věci:
- Probůh, vždyť to je snad x86 Cell!
- To se té zkriplené x86 architektury už vážně nikdy nezbavíme? :-(
https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433099
+
je hezké, že se mluví o starých hrách, jenže to má háček. Ty staré hry totiž na dnešních windows ani nespustíte, takže podporu grafiky nemusíte řešit. :-) A co dále? Vývojáři budou hry dělat klasicky jako teď, takže to nakonec dopadne tak, že Intel se bude muset přizpůsobovat ATI/NV a budou mít sice univerzální, ale málo výkonou kartu, kterou nikdo nebude chtít a dopadne asi jako grafiky SiS nebo kdo to byl. Intel má pouze výhodu velkého kapitálu, kterým může něco protlačit.
+1
0
-1
Je komentář přínosný?
Stíhačka (neověřeno) https://diit.cz
8. 8. 2008 - 08:27https://diit.cz/clanek/architektura-intel-larrabee/diskuseje hezké, že se mluví o starých hrách, jenže to má háček. Ty staré hry totiž na dnešních windows ani nespustíte, takže podporu grafiky nemusíte řešit. :-) A co dále? Vývojáři budou hry dělat klasicky jako teď, takže to nakonec dopadne tak, že Intel se bude muset přizpůsobovat ATI/NV a budou mít sice univerzální, ale málo výkonou kartu, kterou nikdo nebude chtít a dopadne asi jako grafiky SiS nebo kdo to byl. Intel má pouze výhodu velkého kapitálu, kterým může něco protlačit. https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433109
+
Víte někdo jaký má mít Larabee (maximální) výkon? Někde jsem četl, že jedno jádro na 2 GHz bude mít zhruba stejný výkon jako C2D na poloviční frekvenci. To by ale znamenalo, že Larabee bude několikrát rychlejší než současné CPU. Jenže GPU jsou dneska zhruba 100x rychlejší než CPU, tj. Larabee bude nejspíš poněkud výkonově zaostávat za GPU.
+1
+3
-1
Je komentář přínosný?
XXJack (neověřeno) https://diit.cz
8. 8. 2008 - 09:03https://diit.cz/clanek/architektura-intel-larrabee/diskuseVíte někdo jaký má mít Larabee (maximální) výkon? Někde jsem četl, že jedno jádro na 2 GHz bude mít zhruba stejný výkon jako C2D na poloviční frekvenci. To by ale znamenalo, že Larabee bude několikrát rychlejší než současné CPU. Jenže GPU jsou dneska zhruba 100x rychlejší než CPU, tj. Larabee bude nejspíš poněkud výkonově zaostávat za GPU.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433118
+
Hezký článek. Larrabee je vážně zajímavý počin. Ale něco jako herní grafiku to bude používat jen blázen. 1. Nebude primárně určena na hry, díky své univerzálnosti to bude spíše výpočetní karta na nejrůznější věci. 2. S tím souvisí cena, všechno co je koncipováno pro bussiness a ne pro spotřebitele je X krát dražší. 3. Výkon - Univerzální řešení jsou známa tím, že velkou část výkonu spolkne režie - klidně 30% i více, proto budou s GK se svými optimalizovanými shadery na tom v DX a OGL lépe. 4. X86 architektura - té se asi bohužel nezbavíme nikdy a vždycky to bude největší brzda, na druhou stranu to chápu, není jiná možnost, pokud to má být tak univerzální. 5. Spotřeba - i když jsou jádra v Larrabee jednodušší než třeba v Core a Larrabe má ještě nějaký ten rok do uvedení, kde se dá předpokládat lepší technologický proces výroby jádra (jader), přeci jen jich tam bude hodně a můžete si představit kolik asi bude papat např. 40jádrové CPU
Závěř - Larrabe bude dobrou alternativou k výpočetním kartám postaveným na GPU, oproti nim toho totiž nabídne mnohem více. OGL a DX podpora zůstane jen jako taková třešnička na dortu a když budeme číst recenzi na výkon té či oné GK, nebude chybět Larrabee jen tak pro srovnání, její výkon ale bude pochopitelně nižší, což vůbec nevadí, protože je určena primárně na něco úplně jiného
+1
+1
-1
Je komentář přínosný?
MACHINA (neověřeno) https://diit.cz
8. 8. 2008 - 09:07https://diit.cz/clanek/architektura-intel-larrabee/diskuseHezký článek. Larrabee je vážně zajímavý počin. Ale něco jako herní grafiku to bude používat jen blázen. 1. Nebude primárně určena na hry, díky své univerzálnosti to bude spíše výpočetní karta na nejrůznější věci. 2. S tím souvisí cena, všechno co je koncipováno pro bussiness a ne pro spotřebitele je X krát dražší. 3. Výkon - Univerzální řešení jsou známa tím, že velkou část výkonu spolkne režie - klidně 30% i více, proto budou s GK se svými optimalizovanými shadery na tom v DX a OGL lépe. 4. X86 architektura - té se asi bohužel nezbavíme nikdy a vždycky to bude největší brzda, na druhou stranu to chápu, není jiná možnost, pokud to má být tak univerzální. 5. Spotřeba - i když jsou jádra v Larrabee jednodušší než třeba v Core a Larrabe má ještě nějaký ten rok do uvedení, kde se dá předpokládat lepší technologický proces výroby jádra (jader), přeci jen jich tam bude hodně a můžete si představit kolik asi bude papat např. 40jádrové CPU
Závěř - Larrabe bude dobrou alternativou k výpočetním kartám postaveným na GPU, oproti nim toho totiž nabídne mnohem více. OGL a DX podpora zůstane jen jako taková třešnička na dortu a když budeme číst recenzi na výkon té či oné GK, nebude chybět Larrabee jen tak pro srovnání, její výkon ale bude pochopitelně nižší, což vůbec nevadí, protože je určena primárně na něco úplně jiného https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433127
+
>NeomeN: Nazory mas vlastni, dobre, ted jenom trosku vypilovat tu gramatiku, co rikas? Nebo jsi to psal jen jako nejakou vystrednost? Pro tve dobro doufam, ze ano.
Jinak, podle me, je Larrabee docela slibny pocin a, domnivam se, ze jeho ucelem je nahradit CPU+ext.GPU jednou plne programovatelnou jednotkou. Trochu mi to pripomina projekt Fusion, ale mnohem vykonnejsi (a vetsi a zravejsi). Ale je to jen muj nahled, treba to je/bude uplne neco jineho.
+1
0
-1
Je komentář přínosný?
ljelinek (neověřeno) https://diit.cz
8. 8. 2008 - 09:24https://diit.cz/clanek/architektura-intel-larrabee/diskuse>NeomeN: Nazory mas vlastni, dobre, ted jenom trosku vypilovat tu gramatiku, co rikas? Nebo jsi to psal jen jako nejakou vystrednost? Pro tve dobro doufam, ze ano.
Jinak, podle me, je Larrabee docela slibny pocin a, domnivam se, ze jeho ucelem je nahradit CPU+ext.GPU jednou plne programovatelnou jednotkou. Trochu mi to pripomina projekt Fusion, ale mnohem vykonnejsi (a vetsi a zravejsi). Ale je to jen muj nahled, treba to je/bude uplne neco jineho.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433139
+
To weepy: Kde bereš tu jistotu, že to bude mít řádově vyšší výkon? Já jsem z článku pochopil, že tak maximálně 8x (oproti současným CPU, ne oproti Pentium I). A pokud bereme řády v desítkové soustavě, tak 8x to není ani řád. Ve dvojkové to jsou ale řády tři, že?
+1
+1
-1
Je komentář přínosný?
Milan M (neověřeno) https://diit.cz
8. 8. 2008 - 10:05https://diit.cz/clanek/architektura-intel-larrabee/diskuseTo weepy: Kde bereš tu jistotu, že to bude mít řádově vyšší výkon? Já jsem z článku pochopil, že tak maximálně 8x (oproti současným CPU, ne oproti Pentium I). A pokud bereme řády v desítkové soustavě, tak 8x to není ani řád. Ve dvojkové to jsou ale řády tři, že?https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433149
+
Výborný článek a nejlepší je název kapitoly "Co se může podělat?" :-)
Jinak to vypadá hodně zajímavě, moderní CPU přidávají jádra, tak proč jich nepřidat hodně a neudělat to univerzální s jistou mírou specializace na grafické (a podobné) paralelní výpočty. Proč pořád řešit poměr výkonu CPU ke GPU, když by se to mohlo operativně (softwarově) přizpůsobovat. Určitě je potřeba najít nový směr vývoje počítačů a procesorů.
+1
+2
-1
Je komentář přínosný?
Luděk Růžička https://diit.cz/profil/flash
8. 8. 2008 - 11:37https://diit.cz/clanek/architektura-intel-larrabee/diskuseVýborný článek a nejlepší je název kapitoly "Co se může podělat?" :-)
Jinak to vypadá hodně zajímavě, moderní CPU přidávají jádra, tak proč jich nepřidat hodně a neudělat to univerzální s jistou mírou specializace na grafické (a podobné) paralelní výpočty. Proč pořád řešit poměr výkonu CPU ke GPU, když by se to mohlo operativně (softwarově) přizpůsobovat. Určitě je potřeba najít nový směr vývoje počítačů a procesorů.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433164
+
ptipi: Recenze a články na Anadtechu obsahují mnoho spekulací a většinou špatných. Stejně tak i nový článek o Larrabee. Jak už jsem napsal, stačí si porovnat plochu jádra potřebnou pro implementaci 512bit sběrnice na R600 a na G200.
RV770 nepoužívá crossbar řadič (jediný crossbar v čipu je lokální distribuce texelů mezi texture caches). Pro nižší trafic využívá hub, který narozdíl od crossbaru nenarůstá s počtem klientů exponenciálně, ale lineárně a hlavní konzumenti bandwidth (ROPs a L2TC) jsou přímo nafixovné na paměťových kanálech (opět žádný crossbar).
+1
+3
-1
Je komentář přínosný?
no-X (neověřeno) https://diit.cz
8. 8. 2008 - 12:02https://diit.cz/clanek/architektura-intel-larrabee/diskuseptipi: Recenze a články na Anadtechu obsahují mnoho spekulací a většinou špatných. Stejně tak i nový článek o Larrabee. Jak už jsem napsal, stačí si porovnat plochu jádra potřebnou pro implementaci 512bit sběrnice na R600 a na G200.
RV770 nepoužívá crossbar řadič (jediný crossbar v čipu je lokální distribuce texelů mezi texture caches). Pro nižší trafic využívá hub, který narozdíl od crossbaru nenarůstá s počtem klientů exponenciálně, ale lineárně a hlavní konzumenti bandwidth (ROPs a L2TC) jsou přímo nafixovné na paměťových kanálech (opět žádný crossbar).https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433175
+
To Milan M: Tak vidis, sam si nasel duvod, proc mam pravdu, tri rady je dost, ne ;)? Ja ti jich jeste par nalozim. Za prvy, pletes si vykon v x86 instrukcich a ve floating point operacich. V x86 to bude jedno larrabee jaderko samozrejme mene schopne nez stolni procesor, ale ve floatovych instrukcich ho rozdrti. A ty workoady se planujou jako vetsinove float vektorove a sem tam x86 (jumpy, loopy, zasobnik). 2 az 3 rady ve flops to da. Za druhy, pokud by larrabee nemelo fp vykon v radech tflops, tak by nemohlo konkurovat dnesnim hi-end GPU v rasterizaci, coz intel k prosazeni na trhu potrebuje (viz clanek).
+1
+1
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
8. 8. 2008 - 12:39https://diit.cz/clanek/architektura-intel-larrabee/diskuseTo Milan M: Tak vidis, sam si nasel duvod, proc mam pravdu, tri rady je dost, ne ;)? Ja ti jich jeste par nalozim. Za prvy, pletes si vykon v x86 instrukcich a ve floating point operacich. V x86 to bude jedno larrabee jaderko samozrejme mene schopne nez stolni procesor, ale ve floatovych instrukcich ho rozdrti. A ty workoady se planujou jako vetsinove float vektorove a sem tam x86 (jumpy, loopy, zasobnik). 2 az 3 rady ve flops to da. Za druhy, pokud by larrabee nemelo fp vykon v radech tflops, tak by nemohlo konkurovat dnesnim hi-end GPU v rasterizaci, coz intel k prosazeni na trhu potrebuje (viz clanek). https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433183
+
Souhlasím s no-X. Spekulace mají jednu výhodu. Jsou zadarmo a při obratné argumentaci se dá vysvětlit, proč nevyšly. Jako ekonomické prognózy. Nejlepší je už dopředu používat formulace typu: "se bude chtit prosadit", "kdo chce, ... vyuzije". Hlavně nic konkrétního, aby za tím pak člověk nemusel stát. Že weepy?
+1
0
-1
Je komentář přínosný?
Milan M (neověřeno) https://diit.cz
8. 8. 2008 - 12:47https://diit.cz/clanek/architektura-intel-larrabee/diskuseSouhlasím s no-X. Spekulace mají jednu výhodu. Jsou zadarmo a při obratné argumentaci se dá vysvětlit, proč nevyšly. Jako ekonomické prognózy. Nejlepší je už dopředu používat formulace typu: "se bude chtit prosadit", "kdo chce, ... vyuzije". Hlavně nic konkrétního, aby za tím pak člověk nemusel stát. Že weepy?https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433191
+
Tak bacha, cast jsou spekulace, cast jsou data poskytnuta intelem... My si vzajemne co do konkretnosti a spekulaci nemame co vycitat. Podivej se na svuj prispevek... "Nebo to bude jednovláknová aplikace a o rozdělení se postará operační systém?" Moje spekulace maji aspon nejaky zaklad... Jestli keca intel, kecam taky, uznavam. Ale takovou vec, jako ze to bude muset k uspechu mit srovnatelny vykon v rasterizaci jako GPU v te dobe na trhu v dane cenove relaci, to si spocita i male dite, to se na me nezlob. A ze se to intelovi jednou povede, o tom nepochybuju, kdyz ne na 45nm, tak o fous pozdeji.
+1
0
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
8. 8. 2008 - 13:30https://diit.cz/clanek/architektura-intel-larrabee/diskuseTak bacha, cast jsou spekulace, cast jsou data poskytnuta intelem... My si vzajemne co do konkretnosti a spekulaci nemame co vycitat. Podivej se na svuj prispevek... "Nebo to bude jednovláknová aplikace a o rozdělení se postará operační systém?" Moje spekulace maji aspon nejaky zaklad... Jestli keca intel, kecam taky, uznavam. Ale takovou vec, jako ze to bude muset k uspechu mit srovnatelny vykon v rasterizaci jako GPU v te dobe na trhu v dane cenove relaci, to si spocita i male dite, to se na me nezlob. A ze se to intelovi jednou povede, o tom nepochybuju, kdyz ne na 45nm, tak o fous pozdeji.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433201
+
Nojo, červení fanatici nechtějí připustit, že jejich milovanou ATI ohrožuje další velký hráč na trhu v modrém dresu.
+1
0
-1
Je komentář přínosný?
blah (neověřeno) https://diit.cz
8. 8. 2008 - 13:34https://diit.cz/clanek/architektura-intel-larrabee/diskuseNojo, červení fanatici nechtějí připustit, že jejich milovanou ATI ohrožuje další velký hráč na trhu v modrém dresu.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433209
+
weepy: bacha na to, 2-3 řády rovná se stokrát až tisíckrát. O.O
Jinak bych se rád ohradil proti těm řečem, že x86 je největší brzda a podobně. Je to takový populární nesmysl (experti!). Výkonější proceosry než x86 se objevují jen z času na čas, x86 je tak dynamická, že drží krok, a posledních 9 let je spíš na čele než ne.
Ono když máte dost místa na tranzistory a firmy, které vám to za těžké prachy koupí, tak si můžete vymýšlet (power6), ale podívejte se, co dokáže Intel levně vyrábět pod jménem core 2 quad... trhač asfaltu.
+1
-5
-1
Je komentář přínosný?
Mandarincatko (neověřeno) https://diit.cz
8. 8. 2008 - 13:37https://diit.cz/clanek/architektura-intel-larrabee/diskuseweepy: bacha na to, 2-3 řády rovná se stokrát až tisíckrát. O.O
Jinak bych se rád ohradil proti těm řečem, že x86 je největší brzda a podobně. Je to takový populární nesmysl (experti!). Výkonější proceosry než x86 se objevují jen z času na čas, x86 je tak dynamická, že drží krok, a posledních 9 let je spíš na čele než ne.
Ono když máte dost místa na tranzistory a firmy, které vám to za těžké prachy koupí, tak si můžete vymýšlet (power6), ale podívejte se, co dokáže Intel levně vyrábět pod jménem core 2 quad... trhač asfaltu.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433217
+
To weep: Můj příspěvek byl konkrétní. Tu větu, co cituješ, to byla otázka (měla na konci otazník). A dlužno dodat, že nesmyslná. Pokud je aplikace psaná jednovláknově, operační systém ji ve víc vláken a tedy na víc procesorů efektivně nerozdělí. Takže příště zkus najít něco, kde jsem se nekonkrétně vyjádřil. Nicméně z tveho posledniho prispevku je videt, ze uz zacinas hledat duvody, proc ti spekulace nevyjdou: "cast jsou data poskytnuta intelem", "Jestli keca intel, kecam taky, uznavam." Hledej si vinika kde chces, treba v Intelu. Kazdopadne nepatrim mezi ty, co slepe skoci na vse, co ukazuje, jak ten vyvoj a vsechno jde milovymi kroky dopredu. A je mi jedno, jestli to vymysleli modry, cerveny, zeleny, oranzovy, rudy, nebo treba kafe-bronz-dozelena. Mam trochu alergii na takovy to buseni se v prsa, jak jsme dobri. Za komancu se treba verilo, ze az vyrobime nejvic tun oceli na svete, tak se budem mit nejlip. Uz se to v SSSR male podarilo.
+1
+4
-1
Je komentář přínosný?
Milan M (neověřeno) https://diit.cz
8. 8. 2008 - 14:00https://diit.cz/clanek/architektura-intel-larrabee/diskuseTo weep: Můj příspěvek byl konkrétní. Tu větu, co cituješ, to byla otázka (měla na konci otazník). A dlužno dodat, že nesmyslná. Pokud je aplikace psaná jednovláknově, operační systém ji ve víc vláken a tedy na víc procesorů efektivně nerozdělí. Takže příště zkus najít něco, kde jsem se nekonkrétně vyjádřil. Nicméně z tveho posledniho prispevku je videt, ze uz zacinas hledat duvody, proc ti spekulace nevyjdou: "cast jsou data poskytnuta intelem", "Jestli keca intel, kecam taky, uznavam." Hledej si vinika kde chces, treba v Intelu. Kazdopadne nepatrim mezi ty, co slepe skoci na vse, co ukazuje, jak ten vyvoj a vsechno jde milovymi kroky dopredu. A je mi jedno, jestli to vymysleli modry, cerveny, zeleny, oranzovy, rudy, nebo treba kafe-bronz-dozelena. Mam trochu alergii na takovy to buseni se v prsa, jak jsme dobri. Za komancu se treba verilo, ze az vyrobime nejvic tun oceli na svete, tak se budem mit nejlip. Uz se to v SSSR male podarilo.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433225
+
To weepy: Moc se v tvych prispecich neorientuje. Muzes mi rict jednu vec? Jaky je podle tebe v soucasne dobe pomer mezi vykonem GPU a CPU. Chci cislo, zadne spekulace. (Odpoved doufam nebude dva az tri rady.)
+1
+1
-1
Je komentář přínosný?
Milan M (neověřeno) https://diit.cz
8. 8. 2008 - 14:29https://diit.cz/clanek/architektura-intel-larrabee/diskuseTo weepy: Moc se v tvych prispecich neorientuje. Muzes mi rict jednu vec? Jaky je podle tebe v soucasne dobe pomer mezi vykonem GPU a CPU. Chci cislo, zadne spekulace. (Odpoved doufam nebude dva az tri rady.)https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433242
+
blah: no nevím, ale nebyla to právě nVidia, kdo nejvíc kritizoval Larrabee, vektorovou architekturu i ring-bus? :-)
+1
+1
-1
Je komentář přínosný?
no-X (neověřeno) https://diit.cz
8. 8. 2008 - 14:40https://diit.cz/clanek/architektura-intel-larrabee/diskuseblah: no nevím, ale nebyla to právě nVidia, kdo nejvíc kritizoval Larrabee, vektorovou architekturu i ring-bus? :-)https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433250
+
Milan M: Cim dal vic divergujes od tematu a zbytecne kritizujes me za neco, co sam delas. "Myslím že jako CPU pro to nikdo nebude psát aplikace." je spekulace. Na spekulaci neni nic spatneho, spekuluj dal a ja udelam to same.
Core 2 Quad Q6600 dela 30 GFlops, HD4870 X2 2400GFlops. Pomer je 80:1 v tomhle konkretnim pripade.
Mandracito: 1000x uz je uz fakt hodne, 100x je realne, neco mezi, tomu verim. Nedelal jsem konkretni research, pointa v tom mojem prispevku byla, ze prepisovat jednovlaknovou aplikaci, protoze nekdo zdvojnasobil pocet jader (threadu) na procesoru, se nevyplati, ale kdyz se ten pocet threadu zvysi prudce, tak to uz ma smysl.
+1
-3
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
8. 8. 2008 - 15:06https://diit.cz/clanek/architektura-intel-larrabee/diskuseMilan M: Cim dal vic divergujes od tematu a zbytecne kritizujes me za neco, co sam delas. "Myslím že jako CPU pro to nikdo nebude psát aplikace." je spekulace. Na spekulaci neni nic spatneho, spekuluj dal a ja udelam to same.
Core 2 Quad Q6600 dela 30 GFlops, HD4870 X2 2400GFlops. Pomer je 80:1 v tomhle konkretnim pripade.
Mandracito: 1000x uz je uz fakt hodne, 100x je realne, neco mezi, tomu verim. Nedelal jsem konkretni research, pointa v tom mojem prispevku byla, ze prepisovat jednovlaknovou aplikaci, protoze nekdo zdvojnasobil pocet jader (threadu) na procesoru, se nevyplati, ale kdyz se ten pocet threadu zvysi prudce, tak to uz ma smysl.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433262
+
To weepy: Kdyz je GPU 80x vykonnejsi nez CPU, proc se teda vypocty provadi na pomalem CPU a ne na 80x rychlejsim GPU? Nebude to treba tim, ze GFlops neni objektivnim meritkem vykonu? Anebo tim, ze maloco se da paralelizovat na vic jader nez 10? Ohledne te me "spekulace". Je pravda, ze uz zacinaji vznikat aplikace, co vyuziji 2 nebo vic jader. Da se to pri prevodu videa, archivaci souboru, hrach apod. Ale chvili to trvalo, nez to zacali programatori takhle psat. A neni to jednoduche. Navic spousta vypoctu (hlavne vedeckych) rozdelit do vice vlaken nejde.
+1
+1
-1
Je komentář přínosný?
Milan M (neověřeno) https://diit.cz
8. 8. 2008 - 15:25https://diit.cz/clanek/architektura-intel-larrabee/diskuseTo weepy: Kdyz je GPU 80x vykonnejsi nez CPU, proc se teda vypocty provadi na pomalem CPU a ne na 80x rychlejsim GPU? Nebude to treba tim, ze GFlops neni objektivnim meritkem vykonu? Anebo tim, ze maloco se da paralelizovat na vic jader nez 10? Ohledne te me "spekulace". Je pravda, ze uz zacinaji vznikat aplikace, co vyuziji 2 nebo vic jader. Da se to pri prevodu videa, archivaci souboru, hrach apod. Ale chvili to trvalo, nez to zacali programatori takhle psat. A neni to jednoduche. Navic spousta vypoctu (hlavne vedeckych) rozdelit do vice vlaken nejde.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433278
+
Milan M: Nemas pravdu, vypocty se provadeji, jak na CPU, tak na GPU. GPU je specializovane na paralelni vypocet ve floatech, je to omezeny okruh uloh, ale porad ma obrovsky zaber. Jsou ulohy, ktere se paralelizuji perfektne (jako malovani, kdyz mas velkou plochu, muze ti obraz malovat n maliru a maji to n-krat rychleji) a ulohy, ktere se paralelizovat nedaji (jako vyroba ja nevim treba vrstvenych macenych bombonu, kde ke kazde operaci potrebujes vysledek serie jinych operaci). Pak je obrovska skupina uloh, ktere jsou mezi tim, a ktere jsou kombinacemi obou extremu (paralelni vyroba bombonu...). Vzhledem k tomu, ze problemu si vymyslis spocetne mnoho a tomu, ze ta skala neni cernobila, nema ani cenu se bavit kterych problemu je vic. Nedostatek uloh, ktere zparalelizujes na vice nez 10 vlaken, nehrozi.
Priklad: existuje cela trida problemu, ktere jsou velmi tezke na vypocet, a musi se na ne brute force. Pro reseni techto problemu casto existuji algoritmy, ktere davaji vysledek v rozumnem case, ale s urcitou pravdepodobnosti chyby. Neustalym opakovanim (nebo paralelnim spustenim) lze tuto pravdepodobnost zvysovat, ale nikdy to nebude 100%, ale v praxi se s tim smirime. Princip techto algoritmu je v nahodnem hadani, vybirani vzorku a podobne, coz je naprosto nezavisly a perfektne paralelizovatelny proces. Akorat se tam casto potrebuje branchovat, jumpovat, resit neco rozdelenim na podproblemy a norit se do podprogramu, to vsechno dneska GPGPU frameworky horko tezko obchazeji. Larrabee bude pro tyhle ulohy raj.
+1
+1
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
8. 8. 2008 - 16:51https://diit.cz/clanek/architektura-intel-larrabee/diskuseMilan M: Nemas pravdu, vypocty se provadeji, jak na CPU, tak na GPU. GPU je specializovane na paralelni vypocet ve floatech, je to omezeny okruh uloh, ale porad ma obrovsky zaber. Jsou ulohy, ktere se paralelizuji perfektne (jako malovani, kdyz mas velkou plochu, muze ti obraz malovat n maliru a maji to n-krat rychleji) a ulohy, ktere se paralelizovat nedaji (jako vyroba ja nevim treba vrstvenych macenych bombonu, kde ke kazde operaci potrebujes vysledek serie jinych operaci). Pak je obrovska skupina uloh, ktere jsou mezi tim, a ktere jsou kombinacemi obou extremu (paralelni vyroba bombonu...). Vzhledem k tomu, ze problemu si vymyslis spocetne mnoho a tomu, ze ta skala neni cernobila, nema ani cenu se bavit kterych problemu je vic. Nedostatek uloh, ktere zparalelizujes na vice nez 10 vlaken, nehrozi.
Priklad: existuje cela trida problemu, ktere jsou velmi tezke na vypocet, a musi se na ne brute force. Pro reseni techto problemu casto existuji algoritmy, ktere davaji vysledek v rozumnem case, ale s urcitou pravdepodobnosti chyby. Neustalym opakovanim (nebo paralelnim spustenim) lze tuto pravdepodobnost zvysovat, ale nikdy to nebude 100%, ale v praxi se s tim smirime. Princip techto algoritmu je v nahodnem hadani, vybirani vzorku a podobne, coz je naprosto nezavisly a perfektne paralelizovatelny proces. Akorat se tam casto potrebuje branchovat, jumpovat, resit neco rozdelenim na podproblemy a norit se do podprogramu, to vsechno dneska GPGPU frameworky horko tezko obchazeji. Larrabee bude pro tyhle ulohy raj.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433299
+
sry, oprava, opakovanim stochastickeho algoritmu se pravdepodobnost toho, ze vysledek je chybny, samozrejme snizuje..
+1
-1
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
8. 8. 2008 - 17:02https://diit.cz/clanek/architektura-intel-larrabee/diskusesry, oprava, opakovanim stochastickeho algoritmu se pravdepodobnost toho, ze vysledek je chybny, samozrejme snizuje..https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433311
+
Vyborny clanik Davide! Vdaka za perfektny a uceleny prehlad toho co sa doteraz o Lerrabee vie.
Inak, v suvislosti s (neskorsim) clankom "nVidia si licencuje Transmeta technologie" ma dost prekvapuje ze si nVidia nelicencovala aj technologie ktore by jej umoznili riesit x86-kompatibilne vypocty. Transmeta to vedela, aj ked nepriamo - ale pravdupovediac si nie som isty ci to mala nejako licencne/patentovo podchytene.
Ak sa totiz Larrabee ujme (a verim ze ano), bude nVidia vo _velmi_ tazkej pozicii - ATI ma vyhodu v spojeni s AMD, ale nVidia je co sa tyka rieseni typu Larrabee uplne mimo...
+1
+1
-1
Je komentář přínosný?
MicE (neověřeno) https://diit.cz
9. 8. 2008 - 12:01https://diit.cz/clanek/architektura-intel-larrabee/diskuseVyborny clanik Davide! Vdaka za perfektny a uceleny prehlad toho co sa doteraz o Lerrabee vie.
Inak, v suvislosti s (neskorsim) clankom "nVidia si licencuje Transmeta technologie" ma dost prekvapuje ze si nVidia nelicencovala aj technologie ktore by jej umoznili riesit x86-kompatibilne vypocty. Transmeta to vedela, aj ked nepriamo - ale pravdupovediac si nie som isty ci to mala nejako licencne/patentovo podchytene.
Ak sa totiz Larrabee ujme (a verim ze ano), bude nVidia vo _velmi_ tazkej pozicii - ATI ma vyhodu v spojeni s AMD, ale nVidia je co sa tyka rieseni typu Larrabee uplne mimo...https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433375
+
To weepy: V leccem nemas pravdu. Ulohy ktere se paralelizovat nedaji, zesmesnujes oznacenim typu: vyroba vrstvenych macenych bombonu. Tim jsi dokazal, ze se absolutne neorientujes. Vetsina vedeckych a jinych vypoctu bohuzel vede na soustavy N linearnich rovnic o N neznamych, kde N dosahuje velkych radu (miliony). Reseni teto ulohy se paralelizuje velmi spatne, pokud vubec. Druhou moznosti je rozlozeni oblasti (struktury) na mensi casti a resit je po castech. To samozrejme jde paralelizovat, ale provadi se to hlavne kvuli tomu, ze se snizovanim N ta narocnost klesa rapidne. Tento typ rozkladu struktury vsak neni uplne bez problemu, teprve se rozviji. V elektromagnetickych vypoctech je timto prikladem Fast Multipole Method.
Velke moznosti paralenich vypoctu vidim v optimalizaci. Tam je treba resit ruzne varianty same struktury treba 200x. To by se pak dalo resit na vice procesorech. Ale aby toto bylo efektivni, musi mit jeden procesor velky vykon, ne na urovni Pentium I. Takze taky nic kde by se Larrabee dalo vyuzit.
Dalsi omyl je tvuj priklad. Myslim si, ze se v aplikovane matematice orientuji. Mam doktorat z numerickych metod v elektromagnetickych vypoctech. V soucasnoti pracuji v jedne firme zabyvajici se navrhem elektronickych zarizeni. Ale o tve "cele tride problemu" jsem v zivote neslysel. Ze by se tohle v praxi pouzivalo? Muzes prosim uvest prakticky priklad, kde se to pouziva?
+1
+2
-1
Je komentář přínosný?
Milan M (neověřeno) https://diit.cz
9. 8. 2008 - 13:15https://diit.cz/clanek/architektura-intel-larrabee/diskuseTo weepy: V leccem nemas pravdu. Ulohy ktere se paralelizovat nedaji, zesmesnujes oznacenim typu: vyroba vrstvenych macenych bombonu. Tim jsi dokazal, ze se absolutne neorientujes. Vetsina vedeckych a jinych vypoctu bohuzel vede na soustavy N linearnich rovnic o N neznamych, kde N dosahuje velkych radu (miliony). Reseni teto ulohy se paralelizuje velmi spatne, pokud vubec. Druhou moznosti je rozlozeni oblasti (struktury) na mensi casti a resit je po castech. To samozrejme jde paralelizovat, ale provadi se to hlavne kvuli tomu, ze se snizovanim N ta narocnost klesa rapidne. Tento typ rozkladu struktury vsak neni uplne bez problemu, teprve se rozviji. V elektromagnetickych vypoctech je timto prikladem Fast Multipole Method.
Velke moznosti paralenich vypoctu vidim v optimalizaci. Tam je treba resit ruzne varianty same struktury treba 200x. To by se pak dalo resit na vice procesorech. Ale aby toto bylo efektivni, musi mit jeden procesor velky vykon, ne na urovni Pentium I. Takze taky nic kde by se Larrabee dalo vyuzit.
Dalsi omyl je tvuj priklad. Myslim si, ze se v aplikovane matematice orientuji. Mam doktorat z numerickych metod v elektromagnetickych vypoctech. V soucasnoti pracuji v jedne firme zabyvajici se navrhem elektronickych zarizeni. Ale o tve "cele tride problemu" jsem v zivote neslysel. Ze by se tohle v praxi pouzivalo? Muzes prosim uvest prakticky priklad, kde se to pouziva?https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433389
+
To weepy: Taky se rad nencham poucit v jine veci. Pises: "GPU je specializovane na paralelni vypocet ve floatech." Floatech myslis Floating point operacich? Asi ano, zkratka Flops to naznacuje. Pokud ano, pak nerozumim tomu, proc se obraz na pocitaci v GPU zpracovava s pohyblivou radovou carkou. Nejsem expert na zpracovani obrazu, ale mam pocit, ze na jejich zpracovani (jak obrazky, tak videa) bohate staci 32 bitove zpracovani v pevne radove carce. Pevna radova carka je na samzrejme mene vypocetne narocna. Lidske oko nema takovou dynamiku, aby bylo nutne pouzit vypocty v pohyblive radove carce. Takze v GPU se obraz podle meho nazoru zpracovava v pevne radove carce.
Jedina trida aplikaci kde se obraz zpracovava v pohyblive radove carce, je v biomedicinskych pristrojich. Mam na mysli zobrazeni vysledku pocitacoveho tomografu (CT), Magneticke rezonance (MR) apod. Zde totiz pomerne mala "cmouha" rozhoduje o tom, zde ma pacient rakovinu ci nikoliv. Ta by se tam pri zpracovani v pevne radove carce mohla vyskytnout v dusledku zaokrouhlovacich chyb behem a po filtraci. To je vsak trida uloh velmi specificka.
+1
0
-1
Je komentář přínosný?
Milan M (neověřeno) https://diit.cz
9. 8. 2008 - 14:21https://diit.cz/clanek/architektura-intel-larrabee/diskuseTo weepy: Taky se rad nencham poucit v jine veci. Pises: "GPU je specializovane na paralelni vypocet ve floatech." Floatech myslis Floating point operacich? Asi ano, zkratka Flops to naznacuje. Pokud ano, pak nerozumim tomu, proc se obraz na pocitaci v GPU zpracovava s pohyblivou radovou carkou. Nejsem expert na zpracovani obrazu, ale mam pocit, ze na jejich zpracovani (jak obrazky, tak videa) bohate staci 32 bitove zpracovani v pevne radove carce. Pevna radova carka je na samzrejme mene vypocetne narocna. Lidske oko nema takovou dynamiku, aby bylo nutne pouzit vypocty v pohyblive radove carce. Takze v GPU se obraz podle meho nazoru zpracovava v pevne radove carce.
Jedina trida aplikaci kde se obraz zpracovava v pohyblive radove carce, je v biomedicinskych pristrojich. Mam na mysli zobrazeni vysledku pocitacoveho tomografu (CT), Magneticke rezonance (MR) apod. Zde totiz pomerne mala "cmouha" rozhoduje o tom, zde ma pacient rakovinu ci nikoliv. Ta by se tam pri zpracovani v pevne radove carce mohla vyskytnout v dusledku zaokrouhlovacich chyb behem a po filtraci. To je vsak trida uloh velmi specificka.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433400
+
To weepy: Jestli te tim neobtezuji, jeste by me zajimala jedna vec. Pises: "vypocty se provadeji, jak na CPU, tak na GPU." Muzes mi prosim rici, jake druhy vypoctu krome zpracovani obrazu se dela v GPU? Mam totiz takove tuseni, ze pokud na svem pocitaci pustim vypocet, provadi se vyhradne v CPU. Proc se to teda neprovede v GPU, kdyz ma 80x vyssi vykon?
+1
0
-1
Je komentář přínosný?
Milan M (neověřeno) https://diit.cz
9. 8. 2008 - 14:29https://diit.cz/clanek/architektura-intel-larrabee/diskuseTo weepy: Jestli te tim neobtezuji, jeste by me zajimala jedna vec. Pises: "vypocty se provadeji, jak na CPU, tak na GPU." Muzes mi prosim rici, jake druhy vypoctu krome zpracovani obrazu se dela v GPU? Mam totiz takove tuseni, ze pokud na svem pocitaci pustim vypocet, provadi se vyhradne v CPU. Proc se to teda neprovede v GPU, kdyz ma 80x vyssi vykon?https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433408
+
Pripustil jsem existenci tveho typu uloh a to ze ty odmitas videt, ze univerzum problemu je sirsi nez to, z ceho ty mas doktorat, je tvuj problem ;). Nezesmesnoval jsem, uvadel jsem priklad, nechtel jsem se dotknout tveho ega. Usmevne mi prijde to, jak mi postupne v tvych prispevcich davas za pravdu, ani nemusim lezt do googlu a hledat protipriklady... takze neobtezujes :)
Na GPU se provadeji graficke vypocty (prekvapko!!!). Nikdy jsem nerekl, ze GPU umi pocitat tvoje ridky nebo husty megamatice, s CUDA by to melo jit, nevim, ale tvrdim, ze larrabee to umet bude (pac to bude x86).
+1
-1
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
9. 8. 2008 - 14:48https://diit.cz/clanek/architektura-intel-larrabee/diskusePripustil jsem existenci tveho typu uloh a to ze ty odmitas videt, ze univerzum problemu je sirsi nez to, z ceho ty mas doktorat, je tvuj problem ;). Nezesmesnoval jsem, uvadel jsem priklad, nechtel jsem se dotknout tveho ega. Usmevne mi prijde to, jak mi postupne v tvych prispevcich davas za pravdu, ani nemusim lezt do googlu a hledat protipriklady... takze neobtezujes :)
Na GPU se provadeji graficke vypocty (prekvapko!!!). Nikdy jsem nerekl, ze GPU umi pocitat tvoje ridky nebo husty megamatice, s CUDA by to melo jit, nevim, ale tvrdim, ze larrabee to umet bude (pac to bude x86). https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433417
+
To weeppy: Zdar, meho ega ses nedotkl, nemam ho jak nakladak a nepotrebuju si ho zvetsovat. Zarazi me ale, jak odbihas k osobnim utokum. Spis bych ocenil, kdybys mi odpovedel na to, co jsem se te ptal. Stejne tuhle diskuzi cteme jen my dva, tak je to fuk.
+1
-2
-1
Je komentář přínosný?
Milan M (neověřeno) https://diit.cz
9. 8. 2008 - 20:01https://diit.cz/clanek/architektura-intel-larrabee/diskuseTo weeppy: Zdar, meho ega ses nedotkl, nemam ho jak nakladak a nepotrebuju si ho zvetsovat. Zarazi me ale, jak odbihas k osobnim utokum. Spis bych ocenil, kdybys mi odpovedel na to, co jsem se te ptal. Stejne tuhle diskuzi cteme jen my dva, tak je to fuk.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433433
+
fanATIci mají v povaze osobní útoky, když jim dojdou argumenty.Zvykej si.
+1
+6
-1
Je komentář přínosný?
ehm (neověřeno) https://diit.cz
10. 8. 2008 - 05:54https://diit.cz/clanek/architektura-intel-larrabee/diskusefanATIci mají v povaze osobní útoky, když jim dojdou argumenty.Zvykej si.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433447
+
Milan M: Vzhledem k tomu, ze to, ze ti neco vysvetluju, pro tebe znamena osobni utok, tak je nacase prestat. Uz jsem ti predal dost informaci, zbytek viz internet nebo knihovna, tema slozitost..
ehm: jak se pozna fanATIk... jako obhajce intelovych roadmap :D?
+1
-1
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
10. 8. 2008 - 14:52https://diit.cz/clanek/architektura-intel-larrabee/diskuseMilan M: Vzhledem k tomu, ze to, ze ti neco vysvetluju, pro tebe znamena osobni utok, tak je nacase prestat. Uz jsem ti predal dost informaci, zbytek viz internet nebo knihovna, tema slozitost..
ehm: jak se pozna fanATIk... jako obhajce intelovych roadmap :D?https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433458
+
weepy: Pokud te to uz nebavi mi odpovidat, muzes mi prosim odpovedet aspon na jednu otazku co jsem se te ptal? Muzes prosim uvest prakticky priklad, kde se pouziva reseni typu brute force, o kterem pises? Pises o cele tride problemu, zajimalo by me nekolik prikladu pouziti.
+1
0
-1
Je komentář přínosný?
Milan M (neověřeno) https://diit.cz
11. 8. 2008 - 09:44https://diit.cz/clanek/architektura-intel-larrabee/diskuseweepy: Pokud te to uz nebavi mi odpovidat, muzes mi prosim odpovedet aspon na jednu otazku co jsem se te ptal? Muzes prosim uvest prakticky priklad, kde se pouziva reseni typu brute force, o kterem pises? Pises o cele tride problemu, zajimalo by me nekolik prikladu pouziti.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433503
+
Milan, Weepy: aby vám nebylo líto, že si povídáte sami se sebou, tak se taky zapojím - jsem jednoznačně na weepyho straně, většina existujících úloh je velmi dobře paralelizovatelná. Jak může někdo, kdo studoval numerické metody tvrdit, že by se numerické úlohy špatně paralelizovaly, to vůbec nedokáži pochopit - to je naopak přesně ten typ úloh, které jsou k paralelizaci jako stvořené.
Mohl bys, Milane, napsat jakou metodu pro řešení soustavy lineárních rovnic používáš?
+1
0
-1
Je komentář přínosný?
Azazel (neověřeno) https://diit.cz
11. 8. 2008 - 13:39https://diit.cz/clanek/architektura-intel-larrabee/diskuseMilan, Weepy: aby vám nebylo líto, že si povídáte sami se sebou, tak se taky zapojím - jsem jednoznačně na weepyho straně, většina existujících úloh je velmi dobře paralelizovatelná. Jak může někdo, kdo studoval numerické metody tvrdit, že by se numerické úlohy špatně paralelizovaly, to vůbec nedokáži pochopit - to je naopak přesně ten typ úloh, které jsou k paralelizaci jako stvořené.
Mohl bys, Milane, napsat jakou metodu pro řešení soustavy lineárních rovnic používáš? https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433547
+
Typicky se pouziva Gaussova eliminace, vypocet inverzni matice a nasobeni prave strany s touto inverzni matici, iteracni metody (mnoho variant), LU rozklad (casto pouzivany). No posledni dobou jsem spise uzivatel techto algoritmu, ty neprogramuju a tedy nevim, jak je paralelizovat. Ale u konkretnich metod jako Method of Moment (vyuziva Zeland IE3D, Agilent ADS, Ansoft Designer), Finite Element Method (Ansoft HFSS, Ansys, Comsol) jsem o nejake paralelizaci neslysel. Podotykam, ze se jedna se profesionalni sw. Ani tak principielne jednoducha metoda jako FDTD (CST microwave studio, Zeland Fidelity) je paralelizovana v jednom softu, ktery je spis na okraji zajmu.
+1
0
-1
Je komentář přínosný?
Milan M (neověřeno) https://diit.cz
11. 8. 2008 - 14:46https://diit.cz/clanek/architektura-intel-larrabee/diskuseTypicky se pouziva Gaussova eliminace, vypocet inverzni matice a nasobeni prave strany s touto inverzni matici, iteracni metody (mnoho variant), LU rozklad (casto pouzivany). No posledni dobou jsem spise uzivatel techto algoritmu, ty neprogramuju a tedy nevim, jak je paralelizovat. Ale u konkretnich metod jako Method of Moment (vyuziva Zeland IE3D, Agilent ADS, Ansoft Designer), Finite Element Method (Ansoft HFSS, Ansys, Comsol) jsem o nejake paralelizaci neslysel. Podotykam, ze se jedna se profesionalni sw. Ani tak principielne jednoducha metoda jako FDTD (CST microwave studio, Zeland Fidelity) je paralelizovana v jednom softu, ktery je spis na okraji zajmu.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433563
+
Azazel: Podle tebe "většina existujících úloh je velmi dobře paralelizovatelná" "to je naopak přesně ten typ úloh, které jsou k paralelizaci jako stvořené". Můžeš na oplátku uvést příklady ty? Já jsem příklady uvedl, weepy není schopen, a já bych se celkem rád něčemu přiučil. Zřejmě ta weepyho "cela trida problemu, ktere jsou velmi tezke na vypocet, a musi se na ne brute force" je jen teorie bez uzitku (nebo weepy porad jeste googli?). No nicmene zajimaji me prakticke problemy, ne nejaka teorie. Neco, co se prodava, a za co jsou ochotni lidi zaplatit. Vyse zminene softy se prodavaji za radu deseti-tisice dolaru (1 plna licence). Tak neco na ten zpusob.
+1
0
-1
Je komentář přínosný?
Milan M (neověřeno) https://diit.cz
11. 8. 2008 - 14:57https://diit.cz/clanek/architektura-intel-larrabee/diskuseAzazel: Podle tebe "většina existujících úloh je velmi dobře paralelizovatelná" "to je naopak přesně ten typ úloh, které jsou k paralelizaci jako stvořené". Můžeš na oplátku uvést příklady ty? Já jsem příklady uvedl, weepy není schopen, a já bych se celkem rád něčemu přiučil. Zřejmě ta weepyho "cela trida problemu, ktere jsou velmi tezke na vypocet, a musi se na ne brute force" je jen teorie bez uzitku (nebo weepy porad jeste googli?). No nicmene zajimaji me prakticke problemy, ne nejaka teorie. Neco, co se prodava, a za co jsou ochotni lidi zaplatit. Vyse zminene softy se prodavaji za radu deseti-tisice dolaru (1 plna licence). Tak neco na ten zpusob.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433574
+
Milan M: "neni schopen" No tak tohle je dost uboha demagogie z tvy strany :(. Staci, ze toho jses schopny ty, fakt nemusim nic vyjmenovavat. Azazel ma pravdu, treba prave nasobeni matic nebo odecitani radku se paralelizuji naprosto v pohode. Naopak ja chci od tebe, abys ukazal, proc to nejde. K vypoctu jednoho policka soucinu matic nepotrebujes zadne jine policko, neni tam zavislost, neni duvod, proc bys nemohl pustit vypocet kazdeho policka nezavisle ve zvlastnim threadu!
A jestli ten google neumis pouzit sam, tak ze jses to ty... rusove s pomoci CUDA louskaji md5kou zakodovana hesla, vsechny monte carlo metody jsou inherentne paralelizovatelne (a aby ses tady po me nevozil, ze nejsem konkretni, tak vyjmenuju treba vypocet pi nebo shlukovani vektoru), veskera grafika, at uz rasterizace nebo raytracing.. a dal se snaz sam. Pikantni je, ze existuje Monte Carlo algoritmus pro pocitani inverzi hustych matic, a v tom bys jako numerik mel mit prehled: http://portal.acm.org/citation.cfm?id=1361924&jmp=cit&coll=GUIDE...
+1
-2
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
11. 8. 2008 - 16:37https://diit.cz/clanek/architektura-intel-larrabee/diskuseMilan M: "neni schopen" No tak tohle je dost uboha demagogie z tvy strany :(. Staci, ze toho jses schopny ty, fakt nemusim nic vyjmenovavat. Azazel ma pravdu, treba prave nasobeni matic nebo odecitani radku se paralelizuji naprosto v pohode. Naopak ja chci od tebe, abys ukazal, proc to nejde. K vypoctu jednoho policka soucinu matic nepotrebujes zadne jine policko, neni tam zavislost, neni duvod, proc bys nemohl pustit vypocet kazdeho policka nezavisle ve zvlastnim threadu!
A jestli ten google neumis pouzit sam, tak ze jses to ty... rusove s pomoci CUDA louskaji md5kou zakodovana hesla, vsechny monte carlo metody jsou inherentne paralelizovatelne (a aby ses tady po me nevozil, ze nejsem konkretni, tak vyjmenuju treba vypocet pi nebo shlukovani vektoru), veskera grafika, at uz rasterizace nebo raytracing.. a dal se snaz sam. Pikantni je, ze existuje Monte Carlo algoritmus pro pocitani inverzi hustych matic, a v tom bys jako numerik mel mit prehled: http://portal.acm.org/citation.cfm?id=1361924&jmp=cit&coll=GUIDE&dl=GUIDEhttps://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433596
+
weepy: Zajimave je, ze paralelni reseni jedne soustavy rovnic zadny z komercnich softu neopuziva. Asi to bude v necem jinem. Co se tyce Monte Carlo, tak je to dobry priklad metody, pro urcitou velmi uzkou skupinu problemu velmi dobre pouzitelny. Priklad z praxe znam jen jako worst case analyza, ale to je v praxi jen relativne malo pouzivana opsna v softech. Pokud znas jiny prakticky priklad co se da pomoci Monte Carlo resit, tak klidne uved. Vypocet inverznich matic pomoci Monte Carlo mi prijde jako ze nejaky vedec nemel co delat. Vyuziti paralelismu u grafiky jsem nikdy nezpochybnoval. Ty ses ale porad ohanel sirokym pouzitim.
+1
+1
-1
Je komentář přínosný?
Milan M (neověřeno) https://diit.cz
11. 8. 2008 - 17:38https://diit.cz/clanek/architektura-intel-larrabee/diskuseweepy: Zajimave je, ze paralelni reseni jedne soustavy rovnic zadny z komercnich softu neopuziva. Asi to bude v necem jinem. Co se tyce Monte Carlo, tak je to dobry priklad metody, pro urcitou velmi uzkou skupinu problemu velmi dobre pouzitelny. Priklad z praxe znam jen jako worst case analyza, ale to je v praxi jen relativne malo pouzivana opsna v softech. Pokud znas jiny prakticky priklad co se da pomoci Monte Carlo resit, tak klidne uved. Vypocet inverznich matic pomoci Monte Carlo mi prijde jako ze nejaky vedec nemel co delat. Vyuziti paralelismu u grafiky jsem nikdy nezpochybnoval. Ty ses ale porad ohanel sirokym pouzitim.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433607
+
weepy: Louskat md5kou zakodovana hesla povazujes za praktickou aplikaci? Podle me je to spis takova hricka, zajimavost.
+1
0
-1
Je komentář přínosný?
Milan M (neověřeno) https://diit.cz
11. 8. 2008 - 17:42https://diit.cz/clanek/architektura-intel-larrabee/diskuseweepy: Louskat md5kou zakodovana hesla povazujes za praktickou aplikaci? Podle me je to spis takova hricka, zajimavost.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433615
+
Milan:A co chceš přesně slyšet? Mám tady vyjmenovat všechny programy co existují? Tak prosím, tady jsou: kódování videa (ale i přehrávání), jakékoli zpracování obrazu - obecně počítačová grafika/fyzika, prakticky všechny simulace (např. počasí, lékařství, chemie, ...), antiviry, jakýkoli víceuživatelský informační systém (webserver, mailserver, ...), databáze, kompilátory, prostě prakticky všechno co člověka napadne !
To co jsem vyjmenoval by se dalo rozdělit do dvou skupin
přirozeně paralelizovatelné úlohy (např. ta počítačová grafika)
velké množství nezávislých úloh (třeba webserver)
U obojího se dá masivní paralelizace výhodně využít.
Argument, že 'žádný komerční soft to nepoužívá' je hodně špatný a to ze dvou (souvisejících) důvodů:
paralelní algoritmy je významně složitější napsat, takže se to nedá udělat ze dne na den
mainstreamové vícejádrové počítače jsou tu zatraceně krátce, takže motivace k psaní takových programů se teprve pomalu objevuje
PS: jako bonus dokument o paralelním řešení řídké soustavy lineárních rovnic:http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.5441
+1
-1
-1
Je komentář přínosný?
Azazel (neověřeno) https://diit.cz
11. 8. 2008 - 18:00https://diit.cz/clanek/architektura-intel-larrabee/diskuseMilan:A co chceš přesně slyšet? Mám tady vyjmenovat všechny programy co existují? Tak prosím, tady jsou: kódování videa (ale i přehrávání), jakékoli zpracování obrazu - obecně počítačová grafika/fyzika, prakticky všechny simulace (např. počasí, lékařství, chemie, ...), antiviry, jakýkoli víceuživatelský informační systém (webserver, mailserver, ...), databáze, kompilátory, prostě prakticky všechno co člověka napadne !
To co jsem vyjmenoval by se dalo rozdělit do dvou skupin
přirozeně paralelizovatelné úlohy (např. ta počítačová grafika)
velké množství nezávislých úloh (třeba webserver)
U obojího se dá masivní paralelizace výhodně využít.
Argument, že 'žádný komerční soft to nepoužívá' je hodně špatný a to ze dvou (souvisejících) důvodů:
paralelní algoritmy je významně složitější napsat, takže se to nedá udělat ze dne na den
mainstreamové vícejádrové počítače jsou tu zatraceně krátce, takže motivace k psaní takových programů se teprve pomalu objevuje
PS: jako bonus dokument o paralelním řešení řídké soustavy lineárních rovnic:http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.5441https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433623
+
11. 8. 2008 - 18:06https://diit.cz/clanek/architektura-intel-larrabee/diskuseJeště proč jsem se ptal na použitou metodu:
http://www.google.cz/search?hl=cs&q=parallel+gauss+elimination+method
http://www.mathematik.uni-halle.de/reports/sources/2002/02-06report.pdfhttps://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433631
+
Milan M: Jsi v koncich a uhybas, jak se da ;). Vzhledem k tomu, ze to nekdo v praxi pouziva, tak se nebojim to oznacit jako prakticke. To, ze mnozina monte carlo algoritmu ti pripada omezena a ze kryptografie je pro tebe okrajovy obor, hricka, je opet problem spis v tvojem omezenem vnimani.
Zakladni vec kterou ty si myslis je, ze pro larrabee nikdo nebude programovat (prvni prispevek od tebe), a ja tvrdim, ze larrabee zbori dalsi hranici, ktera ted brzdi rust GPGPU aplikaci.
+1
+7
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
11. 8. 2008 - 19:46https://diit.cz/clanek/architektura-intel-larrabee/diskuseMilan M: Jsi v koncich a uhybas, jak se da ;). Vzhledem k tomu, ze to nekdo v praxi pouziva, tak se nebojim to oznacit jako prakticke. To, ze mnozina monte carlo algoritmu ti pripada omezena a ze kryptografie je pro tebe okrajovy obor, hricka, je opet problem spis v tvojem omezenem vnimani.
Zakladni vec kterou ty si myslis je, ze pro larrabee nikdo nebude programovat (prvni prispevek od tebe), a ja tvrdim, ze larrabee zbori dalsi hranici, ktera ted brzdi rust GPGPU aplikaci.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433641
+
To Azazel: Ok, ses dobrej. Uznavam, paralelizovat neco z toho jde. Uvidi se, co z toho se ujme. Asi jsem zaspal dobu, do numerickych metod uz delam jen jako konicek, nove trendy ohledne paralelizace me unikly. Souhlasim s tebou tom, neni to jednoduchy, psat ty aplikace nebo metody vice-vlaknove. Proto se to asi jeste ve specialnich CAD komercnich softech nechytlo.
+1
-5
-1
Je komentář přínosný?
Milan M (neověřeno) https://diit.cz
11. 8. 2008 - 20:11https://diit.cz/clanek/architektura-intel-larrabee/diskuseTo Azazel: Ok, ses dobrej. Uznavam, paralelizovat neco z toho jde. Uvidi se, co z toho se ujme. Asi jsem zaspal dobu, do numerickych metod uz delam jen jako konicek, nove trendy ohledne paralelizace me unikly. Souhlasim s tebou tom, neni to jednoduchy, psat ty aplikace nebo metody vice-vlaknove. Proto se to asi jeste ve specialnich CAD komercnich softech nechytlo.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433650
+
To weepy: Mnozina aplikaci Monte Carlo algoritmu se mi omezena nezda, je omezena. Kryptografie jiste neni okrajovy obor a ani hricka. To mi podsouvas, to jsem nenapsal. Napsal jsem, ze "Louskat md5kou zakodovana hesla .. je hricka, zajimavost." Souhlasim, ze to, ze se louskaji hesla pomoci brute force souvisi s kryptografii, ale je to jen jeji mala cast. Daleko dulezitejsi je louskat hesla bez brute force. Ale kryptografie je hlavne o tom, jak vymyslet kod tak, aby se do nej nikdo nedostal.
Co se tyce psani vicevlaknovych aplikaci, tak skutecne je nikdo nebude mit chut psat. Ja nejsem programamtor, ale znam nektere programatory, co takovy sw pisou. A je to hodne tezky. Navic vicevlaknove aplikace maji velkou rezii, ktera s tim rozdelenim souvisi. Proto je lepsi mit jeden vykonny jednojadrovy procesor, nez 16 malo-vykonnych jader v jednom procesoru. Samozrejme ze nejlepsi je mit 16 vykonnych jednojadrovych procesoru, pokud mas dobre napsanou aplikaci, a dostatecne silny privod elektriky. A samozrejme ten paralelismus nesmi sezrat moc vykonu na rezii, jinak je to k nicemu.
Co se tyce uhybani, tak mi pripada, ze uhybas ty. Nedokazes odpovedet na to, co se te ptam (vse co ma na konci ? je otazka). Meles dalsi nadsene veci, co sis nekde precetl, a kdyz to jinak nejde, utocis.
Postupne mi davas za pravdu. Puvodne jsi videl uplatneni snad vsude (cituji "to bude mit i sirsi uplatneni"). Ted pises o grafice a videu, lousknuti hesel a Monte Carlu. Takze zas tak moc toho neni.
+1
+1
-1
Je komentář přínosný?
Milan M (neověřeno) https://diit.cz
11. 8. 2008 - 22:03https://diit.cz/clanek/architektura-intel-larrabee/diskuseTo weepy: Mnozina aplikaci Monte Carlo algoritmu se mi omezena nezda, je omezena. Kryptografie jiste neni okrajovy obor a ani hricka. To mi podsouvas, to jsem nenapsal. Napsal jsem, ze "Louskat md5kou zakodovana hesla .. je hricka, zajimavost." Souhlasim, ze to, ze se louskaji hesla pomoci brute force souvisi s kryptografii, ale je to jen jeji mala cast. Daleko dulezitejsi je louskat hesla bez brute force. Ale kryptografie je hlavne o tom, jak vymyslet kod tak, aby se do nej nikdo nedostal.
Co se tyce psani vicevlaknovych aplikaci, tak skutecne je nikdo nebude mit chut psat. Ja nejsem programamtor, ale znam nektere programatory, co takovy sw pisou. A je to hodne tezky. Navic vicevlaknove aplikace maji velkou rezii, ktera s tim rozdelenim souvisi. Proto je lepsi mit jeden vykonny jednojadrovy procesor, nez 16 malo-vykonnych jader v jednom procesoru. Samozrejme ze nejlepsi je mit 16 vykonnych jednojadrovych procesoru, pokud mas dobre napsanou aplikaci, a dostatecne silny privod elektriky. A samozrejme ten paralelismus nesmi sezrat moc vykonu na rezii, jinak je to k nicemu.
Co se tyce uhybani, tak mi pripada, ze uhybas ty. Nedokazes odpovedet na to, co se te ptam (vse co ma na konci ? je otazka). Meles dalsi nadsene veci, co sis nekde precetl, a kdyz to jinak nejde, utocis.
Postupne mi davas za pravdu. Puvodne jsi videl uplatneni snad vsude (cituji "to bude mit i sirsi uplatneni"). Ted pises o grafice a videu, lousknuti hesel a Monte Carlu. Takze zas tak moc toho neni.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433658
+
Dal jsem ti tridy problemu a podle tebe jsem utocil a chtel jsi neco konkretniho. Dal jsem ti konkretni problemy, podle tebe utocim a kritizujes me, ze je to prilis uzke. Ja uz nevim kudy kam.
Asi ti neporadim nic jineho, nez abys cetl pozorneji.. To, ze ty rikas, ze moje odpoved je o nicem, neznamena, ze jsem neodpovedel (promin, ale tohle si neodpustim, delas mi to furt: odpoved je ta hromada pismenek nadepsana mym nickem, kterou musis cist zleva doprava po radcich).
Fraze "monte carlo method" dava tri a pul milionu hitu v googlu, to nesvedci o omezenosti pouziti. Ze vicevlaknove aplikace se programuji tezko... to je vec, o ktere se hodne pise, ale je to opet generalizace, ktere ty jako user snadno sednes na lep. Zase je to o tom, ze nekde to jde lip a nekde to jde hur, v zavislosti na tom, jak moc spolu musi thready komunikovat nebo cekat na vysledky jineho. Zopakuju ti, ze prudkym zvysenim poctu soucasne vykonavanych threadu stoupne i motivace psat veci multithreadove, protoze ty zvysene naklady na vyvoj budou vyvazeny vyslednym vykonem.
Jo v tomhle stadiu jsou to zatim jen nadsene kecy... ale vzhledem k tomu, ze to ctes taky, tak mi nemas co vycitat ;).
+1
+1
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
12. 8. 2008 - 08:55https://diit.cz/clanek/architektura-intel-larrabee/diskuseDal jsem ti tridy problemu a podle tebe jsem utocil a chtel jsi neco konkretniho. Dal jsem ti konkretni problemy, podle tebe utocim a kritizujes me, ze je to prilis uzke. Ja uz nevim kudy kam.
Asi ti neporadim nic jineho, nez abys cetl pozorneji.. To, ze ty rikas, ze moje odpoved je o nicem, neznamena, ze jsem neodpovedel (promin, ale tohle si neodpustim, delas mi to furt: odpoved je ta hromada pismenek nadepsana mym nickem, kterou musis cist zleva doprava po radcich).
Fraze "monte carlo method" dava tri a pul milionu hitu v googlu, to nesvedci o omezenosti pouziti. Ze vicevlaknove aplikace se programuji tezko... to je vec, o ktere se hodne pise, ale je to opet generalizace, ktere ty jako user snadno sednes na lep. Zase je to o tom, ze nekde to jde lip a nekde to jde hur, v zavislosti na tom, jak moc spolu musi thready komunikovat nebo cekat na vysledky jineho. Zopakuju ti, ze prudkym zvysenim poctu soucasne vykonavanych threadu stoupne i motivace psat veci multithreadove, protoze ty zvysene naklady na vyvoj budou vyvazeny vyslednym vykonem.
Jo v tomhle stadiu jsou to zatim jen nadsene kecy... ale vzhledem k tomu, ze to ctes taky, tak mi nemas co vycitat ;). https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433688
+
Pls fakt otevri ten google a koukni se, co je kryptografie. Ta je naopak zalozena na tom, abys MUSEL pouzit brute force k prolomeni.
+1
-2
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
12. 8. 2008 - 09:07https://diit.cz/clanek/architektura-intel-larrabee/diskusePls fakt otevri ten google a koukni se, co je kryptografie. Ta je naopak zalozena na tom, abys MUSEL pouzit brute force k prolomeni.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433696
+
to weepy: Tvuj problem je, ze nemas vlastni nazor. Vsechno hledas v googlu a kdyz je tam hodne odkazu, myslis si, ze to ma smysl. Dam ti 2 priklady nesmyslnych spojeni, co me napadly. Oba mely pri vyhledani na googlu pres milion: fractal stability (1.1 milionu), antenna social (2.6 milionu). No ani jedno z toho nema smysl.
+1
-1
-1
Je komentář přínosný?
Milan M (neověřeno) https://diit.cz
12. 8. 2008 - 09:24https://diit.cz/clanek/architektura-intel-larrabee/diskuseto weepy: Tvuj problem je, ze nemas vlastni nazor. Vsechno hledas v googlu a kdyz je tam hodne odkazu, myslis si, ze to ma smysl. Dam ti 2 priklady nesmyslnych spojeni, co me napadly. Oba mely pri vyhledani na googlu pres milion: fractal stability (1.1 milionu), antenna social (2.6 milionu). No ani jedno z toho nema smysl.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433709
+
Milan M: To neni argument... sam vis, ze Monte carlo method je smysluplne spojeni, hodne presne a pritom zdaleka ne vycerpavajici vsechny relevantni zdroje. Ze vsechno hledam v googlu je blbost, to mi nepodsouvej, neni to pravda ;). Naopak ty zauvazuj, jestli bys nejaky vyhledavac nemel pouzit, nez zas neco placnes (to neni utok, to je konstatovani).
+1
0
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
12. 8. 2008 - 09:43https://diit.cz/clanek/architektura-intel-larrabee/diskuseMilan M: To neni argument... sam vis, ze Monte carlo method je smysluplne spojeni, hodne presne a pritom zdaleka ne vycerpavajici vsechny relevantni zdroje. Ze vsechno hledam v googlu je blbost, to mi nepodsouvej, neni to pravda ;). Naopak ty zauvazuj, jestli bys nejaky vyhledavac nemel pouzit, nez zas neco placnes (to neni utok, to je konstatovani).https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433725
+
weepy, Milan M> Panove, vasi debatu jsem sledoval vcelku se zajmem, ale ne tematicky, ale jako sociologickou studii. V tematu se take trochu orientuji, takze jsem mohl snado videt, jakym zpusobem kdo argumentujete a vedete spor. A to je ten problem. Uvedomujete si, ze kdybyste se k tehle debate dostali nekde v realu, tak jste mohli zapadnout treba do hospy a fakt paradne to probrat jako kamosi? Ale jak je to na Netu, hned se vsichni stekaji jak psi, to je uroven. Stydte se.
+1
-4
-1
Je komentář přínosný?
Ren1 https://diit.cz/profil/ren1
12. 8. 2008 - 14:44https://diit.cz/clanek/architektura-intel-larrabee/diskuseweepy, Milan M> Panove, vasi debatu jsem sledoval vcelku se zajmem, ale ne tematicky, ale jako sociologickou studii. V tematu se take trochu orientuji, takze jsem mohl snado videt, jakym zpusobem kdo argumentujete a vedete spor. A to je ten problem. Uvedomujete si, ze kdybyste se k tehle debate dostali nekde v realu, tak jste mohli zapadnout treba do hospy a fakt paradne to probrat jako kamosi? Ale jak je to na Netu, hned se vsichni stekaji jak psi, to je uroven. Stydte se.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433811
+
Ren: no tak flame uz je sociologicky prostudovany skrz naskrz :). Abych pravdu rekl, parkrat me presne to o ty hospode a pivu napadlo... ale pak jsem si to zase rychle rozmyslel. Podel se prosim, co jsi o nas vyzkoumal :)...
+1
+5
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
12. 8. 2008 - 14:58https://diit.cz/clanek/architektura-intel-larrabee/diskuseRen: no tak flame uz je sociologicky prostudovany skrz naskrz :). Abych pravdu rekl, parkrat me presne to o ty hospode a pivu napadlo... ale pak jsem si to zase rychle rozmyslel. Podel se prosim, co jsi o nas vyzkoumal :)... https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433823
+
weepy> Urcite nic, co bys sam davno nevedel. Ze i rozumni a vzdelani lide se v pisemne anonymni forme meni v ustekane squaw a debaty, ktere by mohly nekam vest, se meni v nesmyslne hadky a presvedcovani o tom, kdo ma pravdu.
+1
+1
-1
Je komentář přínosný?
Ren1 https://diit.cz/profil/ren1
13. 8. 2008 - 09:51https://diit.cz/clanek/architektura-intel-larrabee/diskuseweepy> Urcite nic, co bys sam davno nevedel. Ze i rozumni a vzdelani lide se v pisemne anonymni forme meni v ustekane squaw a debaty, ktere by mohly nekam vest, se meni v nesmyslne hadky a presvedcovani o tom, kdo ma pravdu.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433941
+
Vsimas si, ze ses timto vlozil sam do diskuse, stejne anonymne a zpusobem, ktery by mohl pusobit jako prilivani oleje do ohne ;)?
Ja myslim, ze to bylo celkem plodne, aspon jeden z nas ziskal hromadu novych znalosti. :D
Zdravi te stekajici squaw. Asi si to dam na vizitky :D
+1
-6
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
13. 8. 2008 - 11:06https://diit.cz/clanek/architektura-intel-larrabee/diskuseVsimas si, ze ses timto vlozil sam do diskuse, stejne anonymne a zpusobem, ktery by mohl pusobit jako prilivani oleje do ohne ;)?
Ja myslim, ze to bylo celkem plodne, aspon jeden z nas ziskal hromadu novych znalosti. :D
Zdravi te stekajici squaw. Asi si to dam na vizitky :Dhttps://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-433984
+
weepy> Tak pocitam, ze uz bylo po debate, takze jsem se k tomu jen vyjadril, navic nemyslim (doufam), ze by to mohlo zapusobit jako prilevani oleje do ohne. Mozna v nejake debate usmrkancu by se to stalo, ty take obvykle ignoruji. Ale napadlo me, ze dva lidi jako vy by se nad tim opravdu zamyslet mohli.;-)
+1
-5
-1
Je komentář přínosný?
Ren1 https://diit.cz/profil/ren1
13. 8. 2008 - 13:17https://diit.cz/clanek/architektura-intel-larrabee/diskuseweepy> Tak pocitam, ze uz bylo po debate, takze jsem se k tomu jen vyjadril, navic nemyslim (doufam), ze by to mohlo zapusobit jako prilevani oleje do ohne. Mozna v nejake debate usmrkancu by se to stalo, ty take obvykle ignoruji. Ale napadlo me, ze dva lidi jako vy by se nad tim opravdu zamyslet mohli.;-)https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-434019
+
weepy> Hehe, zase ta neurcita cestina..:-) Tak pro jistotu, to doufam v zavorce znamenalo, ze jsem NEmel v umyslu pusobit provokativne.
+1
0
-1
Je komentář přínosný?
Ren1 https://diit.cz/profil/ren1
13. 8. 2008 - 13:19https://diit.cz/clanek/architektura-intel-larrabee/diskuseweepy> Hehe, zase ta neurcita cestina..:-) Tak pro jistotu, to doufam v zavorce znamenalo, ze jsem NEmel v umyslu pusobit provokativne.https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-434027
+
Ren: Prostredky, kterych pouzivas, se nelisi od tech nasich. Vlastne jsi napsal, ze pokud na nas pusobis provokativne, je to proto, ze jsme usmrkanci. Neni to prilis fer, protoze komunikace je zalezitost vzdy dvou a vice lidi a za prenos informace nesou zodpovednost vsichni zucastneni. Proto prosim o zamysleni take z tve strany...
+1
-1
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
13. 8. 2008 - 19:10https://diit.cz/clanek/architektura-intel-larrabee/diskuseRen: Prostredky, kterych pouzivas, se nelisi od tech nasich. Vlastne jsi napsal, ze pokud na nas pusobis provokativne, je to proto, ze jsme usmrkanci. Neni to prilis fer, protoze komunikace je zalezitost vzdy dvou a vice lidi a za prenos informace nesou zodpovednost vsichni zucastneni. Proto prosim o zamysleni take z tve strany...https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-434103
+
weepy> Ale no tak..:-( Myslis, ze bys dokazal alespon na vterinu prestat predpokladat, ze se Te kazdy snazi urazit? Ja to vubec nemyslel zle, dokonce jsem to i napsal. Proc to ohybas tak, ze to mohlo vypadat jako utok? Chces mi dokazat ze jsem se ve svem odhadu spletl?
Co to s tim svetem je?
+1
+2
-1
Je komentář přínosný?
Ren1 https://diit.cz/profil/ren1
14. 8. 2008 - 13:59https://diit.cz/clanek/architektura-intel-larrabee/diskuseweepy> Ale no tak..:-( Myslis, ze bys dokazal alespon na vterinu prestat predpokladat, ze se Te kazdy snazi urazit? Ja to vubec nemyslel zle, dokonce jsem to i napsal. Proc to ohybas tak, ze to mohlo vypadat jako utok? Chces mi dokazat ze jsem se ve svem odhadu spletl?
Co to s tim svetem je?https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-434195
+
Proc myslis, ze si myslim, ze me kazdy chce urazit?
+1
+3
-1
Je komentář přínosný?
weepy (neověřeno) https://diit.cz
14. 8. 2008 - 14:39https://diit.cz/clanek/architektura-intel-larrabee/diskuseProc myslis, ze si myslim, ze me kazdy chce urazit?https://diit.cz/clanek/architektura-intel-larrabee/diskuse#comment-434217
+
wow, super clanek, to muselo dat hodne prace
no ja bych tam ten anandtech jako zdroj pripsal ;)
http://anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3367&p=15
Mazec. Ale je (dnes) tilebased rendering plne realizovatelny? Jak se resi postprocess efekty na hranach ctvercu?
weepy: díky za upozornění, samozřejmě že AnandTech mezi zdroje patří, přidán.
Nechám se překvapit, jak to vše dopadne :) ale je to hodně zajímavé a mohlo by to totálně zamíchat kartama na poli gpu/cpu
Rekl bych ze postprocess se resi az po slozeni tilu...ale v tom pripade bude zase postprocess brzdit rendering...
Ren: jsou dvě možnosti, buď každý procesor počítá s určitým přesahem a krajní body jsou tedy (zbytečně) vypočteny 2x, nebo se musí nějak vyřešit sdílení paměti ... podle druhu úlohy může být výhodnější jedna nebo druhá metoda. Každopádně to není žádný velký problém.
"V době Radeonu X1800 přišla AMD s poměrně flexibilní obousměrnou prstencovou paměťovou sběrnicí a kartám to velmi prospělo. Mezitím na ní zapracovali a v poslední generaci HD 4800 to dotáhli prakticky k dokonalosti s unikátním paměťovým hubem"
Ono je to trochu jinak. A kdyby jste si pořádně přečeti jeden z vašich zdrojů (anandtech), tak by jste na to přišli.
Ringbus ati/amd VYMĚNILA za klasickou hub architekturu, protože zjistili, že je to těžký overkill, který jen žral plochu čipu, ale žádná z minulých, ani současných grafik (by) ho nevyužila.
Je jen zajímavé, jak z toho, že snížili výkon se u nás stal klad.
K tomu dali číslo, že se zvýšila efektivita a novináři byli hned nadšeni(ne, že by nebylo jasné, že se zvýší efektivita, když se lépe saturuje přenosová kapacita, ale na papíře to vypadá pěkně).
Ha - Intelova odpověď na moderní GPU? Kupte si hromadu Pentií 1. Myslím, že nVidia a ATI si můžou oddychnout. :-)
Ale teď vážně - myslíte, že pro to někdo bude umět programovat a napsat drivery? Aby to neskončilo jako slavný Cell, který je sice báječný a úžasně rychlý, ale v praxi je to pro normální práci pěkný šnek, protože většina kódu prostě nepočítá s tím, že by někdy mohla na něčem takovém běžet a musí se k němu ještě "přibalit" normální DX9 grafika, aby to mohlo fungovat aspoň jako konzole.
xvasek: No Cell pokial sa na nom emuluje x86 je naozaj pomaly ale pokial ide na nom pren napisany os tak to su potom ine vykony. V paralelnych vypoctoch niekolko krat predci akykolvek x86 CPU.
Co sa tyka Larabee tak som si tiez myslel ze to bude dalsie itanium no po precitani clanku na anandtechu si myslim ze je to nadejna architektura ktora bude schopna rozbehat ako terajsie hry na DirectX tak aj hry zalozene na inom rozhrani - resp. bez rozhrania napisane priamo pre Larabee.
btw. xvasek - larabee nie je len hromada pentii - kazde jadro totizto obsahuje 16 vektorovych jednotiek, a vies kolko takychto jednotiek obsahovalo pentium? Ziadnu. :D
Eh, ta hrubá síla je spíš Intel, když nahrazuje specializovaný HW hromadou univerzálních CPU a softwarovou vrstvou. Nicméně že tím bude mít výhodu větší přizpůsobivosti asi bude pravda. BTW mám silný pocit, že Intel tímhle docela kopíruje Cell. U něj je ta vektorová výbavička v zvláštních jednotkách, u Intelu přío v jádrech. Efekt asi stejný...
Jinak GPU mají taky systémy pro kašlání na neviditelné elementy.
Rotavator (byls rychlejší):
1. Není to 16 jednotek, je to jedna 512bitová.
2. Cell nemá aža takový výkon - přes 200gflops, ale při double precision to klesne pod sedminu. Nicméně nové modely mohou nsdno přidat větší počet jader, a snad i něco udělat s tím double precision. Snad se ty léta neflákali.
Ufff, tak jsem dočetl. Pěkně hutný materiál. Vypadá to hodně dobře a uvidíme, jak to Intel prosadí. Nicméně, i kdyby se to nepodařilo prosadit do Game segmentu, tak mezi profi grafikami to může nadělat pěknou paseku. Doufám, že Intel nezklame a bude tu bezproblémová podpora Linuxu.
V celem clanku mi chybi zasadni porovnani a to s CELL, silne mi ho to pripomina, a teda o nejake revoluci bych zas moc nemluvil.
At je intel jaky chce, paralelizovat cokoli neni zrovna trivialni takze bych tak optimisticky nebyl. (i kdyz je mi jasne ze inzenyri v intelu do toho vidi lepe nez ja)
Mimochodem k cemu nam bude v roce 2010 AA? Pri tom rozliseni uz to bude uplne jedno :)
Tak jsem sice spíš AMDčkař ale doufám že tohle se chytne, protože to vypadá zajímavě.
Jen mám takový dotaz. Jak jsem pochopil Intelácké procesory sebou táhnou léta staré chyby v návrhu. Pokud se použijí jádra založená na pentiu, tak většina chyb zmizí, ne? A jaká je šance, že opraví i to, co bylo už v pentiích?
Pojede mi na tom Solitaire rychleji?
> hinnat : Jistě. Jen ty už to nebudeš schopen poznat... ;-)
David Jezek: np :)
Rotavator: Pentium melo vektorovou jednotku :)... jen ty vektory mely jen jednu slozku :D.
zzz: jakepak srovnani, kdyz nemas produkt, ale jen extrapolace namlsavacich a kusych prezentaci intelu?
S tou paralelizaci se pletes, neco se paralelizuje lip a neco hur. Grafika je v tomhle ohledu to nejsnadnejsi. Intel v tomhle dela to, co dava az strasidelne dobry smysl a ja jen doufam, ze AMD neco podobneho taky pece.
Pavell: jestli miris na FDIV bug, intel mel na opravu techto veci 10 let. Ono to z pentia stejne jen vychazi, ma to s nim spolecne charakteristiky, jako in-order exekuce, kolik ma alu a priblizne radove pocet tranzistoru. Ale vnitrek je totalne prekopany, vzdyt to bude umet 64-bit x86 kod, ctyrnasobny multithreading, bude to mit hlubsi pipeline a FPU, co bude makat nad 16 floatama najednou, prefetchery, synchonizace cache... Pentium to bude maximalne tak "filozoficky pripominat".
Mno, osobně si myslím, že TOTO (Larrabee) nemá šanci na širší úspěch. Bezesporu to bude asi dobrý konkurent pro CUDA a spol., ale pro SOHO grafické karty to s ohledem na očekávánou spotřebu (včetně idle) bude velmi nepoužitelné.
No to jsem zvědavý, jak se programátorům bude chtít na to psát aplikace, aby ten paralelismus využili. Nebo to bude jednovláknová aplikace a o rozdělení se postará operační systém? Tomu bych nevěřil ani kdyby to byl Linux, natož Windows. Myslím že jako CPU pro to nikdo nebude psát aplikace. Jako GPU nicméně dost dobrý. Možná si u Intelu řekli, že udělají CPU, ale když se to jako CPU nechytne, musí se to dát prodat aspoň jako GPU. A proto to je tak univerzální, aby to nezkončilo jako Cell. Prostě aby se ten vývoj vyplatil.
Problém je... že pokud by larrabee uspělo, ohrozí to nvidii, ati, ale hlavně pozici microsoftu, jelikož poslední věc co drží lidi na jeho OS resp. kvůli které ani nevyzkouší jiný OS, jsou hry pod DirectX... což by tímto počinem padlo.... takže pokud by intel uspěl, tak to bude doslova navzdory všem...
Jo zni to vsechno uzasne,ale ma to chybicku.Vsichni si zvykli na DirectX a OpenGl a tezko budou od piky delat novej render pro larabee, kdyz 98 procent hernich pocitacu ma grafiky typu ati a nvidia. Jeste k tomu maji odladene ovladace pro hry coz intel mit nebude. Larabee skonci jako itanium , nepouzitelny dinosaur, ktery zahyne diky sve velikosti.Bude ale stejne tak dlouho umele ozivovany.
to pao
nejak nechapu, proc bych to nemel poznat?
Pár předchozích příspěvků: Tahle věc se přece s DX ani O GL nevylučuje.
weepy:Měl jsem za to, že těch chyb je víc a ne všechny jsou opravené.
to: Buffalo
ale nie, vsak ludia budu chciet hrat aj starsie tituly a myslis ze ich niekto prerobi do noveho kodu. Za dalsie MS uprednostnuje platformu Intel a nepisane dohody "my zvysime narocnost naseho OS aby vase CPU isli lepsie na odbyt" tak ze nejake Larrabee nezabije MS.
Milan M: Larrabee se bude chtit prosadit nejdriv hlavne jako GPU s tim, ze to bude mit i sirsi uplatneni - kdo chce, vykon larrabee vyuzije, neni to jako s CPU, kde s prechodem na dvoujadro ziskas misto 20GFlops 40 GFlops s velkymi naroky na vyvoj.. tady se bavime o radove vyssim vykonu, x86 @ TFlops, to uz neco bude znamenat, tam se do vyvoje investovat uz sakra vyplati.
Torx: vystizne :)
re TyNyT: kdyby se o to pokoušel kdokoliv jiný, určitě bych s tebou souhlasil, ale intel má takové prostředky, které si nikdo jiný dovolit nemůže (nemyslím jen prachy, ale i know-how, nejlepší výrobní linky,...). Navíc klidně to narozdíl od kohokoliv jiného může ze začátku prodávat bez výdělku za výrobní náklady.
Jen takový nápad..... Neustále se řeší starý známý problém - speciální hardware, který nabízí pro speciální úkoly vysokou efektivitu a také výkon , avšak za s nevýhodou malé univerzálnosti.... versus hardware, který je připraven na široké množství zpracování různých úloh, avšak ve srovnání se specializovaným hardware tyto úlohy obecně řeší méně efektivně....
Což to takhle toto mnohaleté dilema vyřešit třeba použitím univerzálního programovatelného hradlového pole (FPGA)? - Např. grafická karta by obsahovala tento obvod, který sám o sobě sice nezvládá vůbec nic, ale podle typu právě řešené úlohy by ještě před zavedením vlastního programu byl design FPGA (či nějakého podobného obvodu) naprogramován na maximálně výkonnou podporu v dané konkrétní aplikaci.... např. svůj vlastní design by mohly mít různé fyzikální enginy, dále DX, OpenGL, atd.... každý design by byl navržen na podání maximálního výkonu pro dané rozhraní... Co na to říkáte? Programovat - flexibilně (za chodu) měnit design - přímo hardware... je to moc ujetý nápad? Proč s tím ještě nikdo nepřišel?
2 weepy: obaja mame pravdu: http://www.tomshardware.com/reviews/intel-cpu-history,1986-5.html
Povodne pentium nemalo vektorove jednotky ale Pentium MMX uz ano.
STejně jako Corwin78 si myslím, že Intel míří spíš do profesionálních grafik. Tam by to mohlo docela zamíchat trhem. Třeba takové počítání efektů ve Photoshopu, nebo rovnou na videu. Případně jako akcelerátor některých operací v CADech. Například update výkresu při změně modelu/sestavy apd, kde se často jedná o lehce paraelizovatelné procesy by to mohlo být dopst zajímavé.
Lidi podle me je zbytecny se hadat o tom co tento cip bude umet a co ne nebo jaka bude jeho efektivnost. Jedina a dulezita vec je co z toho intel dokaze vytriskat. Je jedno jaka je to archyrchytekura jestli je to ATI NVIDIA nebo INTEL nakonec vzdycky zvitezi ti kteri podaji nejlepsi pomer cena/vykon. V tomto pripade ma ale intel neco navic a to TEORETICKOU zpetnou kompatibylitu x86 ktera by sama o sobe mohla docela zamichat kartama. A jeste se zamyslete - nepripomina vam tato archytektura neco? Mne jo a to cip s "pracovnim" nazvem Terrascale coz je cip kterej ma zvladat neco kolem 1-2TFLOPs podle frekvence akoratze "predprodukcni" vzorek neumel x86 sadu a nasazeni podobne archytektury Intel planuje NEJDRIV kolem roku 2015. Zacina se nam to pekne vybarvovat. Ted si do toho zamicham NVIDIU a jeji udajnej ustup z trhu chipovich sad. NVIDIA ted uvede ovladace ktere umozni pocitat fyziku primo na GK a stahne se z oblasti vyroby cip. sad pro AMD a Intel (je jedno zda nucene nebo tim ze nedokaze konkurovat) posledni hrac na poly procesoru zustava VIA ale ta zdaleka nestaci vykonem na svoje vetsi soupere. Ale co se stane pokud procesoru odlehcime tim ze u her (napriklad) nebude muset pocitat fyziku? bude mit vic casu na ostatni ukoli a tim se setrou rozdili. VIA (napriklad) pojede vytizena na 95% zatimco Intel na 60% ale koho z beznych zakazniku to zajima? Prakticky nikoho zvlast pri spotrebe procesoru VIA. Kdyz k tomu pridam to ze (pouze ma spekulace) se v budoucnu obevi software kterej dokaze predat u her spravu kompletni AI na bedra GK tak pak uz bude procesor jen a pouze cip kterej ridi komunikaci mezi jednotlivima periferiemi a tim padem nebude potreba takovej vykon jako dnes. KDYBY nahodou nastala sytuace kterou sem zde nastinil pak by VIA mela vyhrany - sice nizkej vykon CPU ale zase extreme nizka spotreba kombinovana s DOSTATECNYM vykonem a tim docela vysoka efektivita prace CPU narozdil od konkurence ktera ma sice spoustu vykonu ale v porovnani s VIA procesory docela nizkou efektivitu na W at si tvrdi co chtej.
Ma: to už tady bylo. Měla to v obdobné kdysi Amiga...
Rotavator: nepochopil jsi muj vtip, celociselnou vektorovou praci nepocitam, FPU tam je furt jedno, pointa mela byt v tom, ze jednoslozkovy vektor a cislo jsou to samy...
ptipi: Nevím, jak jsi přišel na to, že ring-bus je overkill, žrout tranzistorů, nebo že hub je něco klasického :-) nVidia G200 na realizaci 512bit sběrnice využívá téměř 25% plochy jádra jen pro paměťový subsystém. Přepočteme-li to na rozměry R600, která byla též 512 bitová a využívala ring-bus, tak je jasné, že s konceptem řadiče, který využívá nVidia na G200, by R600 musela být tvořena z 50% jen paměťovým řadičem - stačí se podívat na die-shot R600 a hned je jasné, jaký je to nesmysl a tedy o kolik byl ring-bus menší. Se 4 SIMDs byl ring-bus pro R600 ideální, protože díky pouhým čtyřem ring-stops byl nejúspornějším možným řešením při implementaci 512-bitového paměťového rozhraní. Krom toho ring-bus jako jediné řešení umožňoval nezávislost počtu paměťových kanálů na počtu ROPs, takže dodatečně umožňoval redukci zbytečných ROPs. Jediný důvod, proč od něj ATi upustila, je, že při 10 SIMDs RV770 by počet ring-stops (a tím i komplexnost řadiče) příliš narostly. Krom toho ring-bus zastával i úlohy, které jsou nyní řešeny implementací lokálních řadičů, jež v R600 nebyly přítomny.
re no-X: nepřišel jsem na to já, ale lidé od anandtechu, kterým to pro změnu řekli lidé od amd/ati. stačí si to přečíst.
re no-X: a jak jsem přišel na to, že hub je klasika? protože např. crossbar byl použit, pokud vím, třeba už u geforce 3. crossbar je klasická implementace přepínače. jen to tehdy všichni stále nazývali paměťovým řadičem. amd by jen těžko uspělo s tím, že se vracejí ke klasice (protože zjistili, že poměr výkon/plocha nebyl nejlepší), tak to samozřejmě označili jinak.
i když je fakt, že do toho "hubu" teď jdou i linky z pciex a cf. to je ale spíš jen otázka jiného rozdělení.
re no-x: a ještě jedna drobnost- neřekl jsem žout tranzistorů, ale PLOCHY. ringbus totiž bral plochu i velkým množstvím spojů (opět převzeto z anandtechu).
:) Larabee je přesně to , co se dalo o tomto projektu vytušit už dříve - univerzální procesor .
Po přečtení mne napadly dvě věci:
- Probůh, vždyť to je snad x86 Cell!
- To se té zkriplené x86 architektury už vážně nikdy nezbavíme? :-(
je hezké, že se mluví o starých hrách, jenže to má háček. Ty staré hry totiž na dnešních windows ani nespustíte, takže podporu grafiky nemusíte řešit. :-) A co dále? Vývojáři budou hry dělat klasicky jako teď, takže to nakonec dopadne tak, že Intel se bude muset přizpůsobovat ATI/NV a budou mít sice univerzální, ale málo výkonou kartu, kterou nikdo nebude chtít a dopadne asi jako grafiky SiS nebo kdo to byl. Intel má pouze výhodu velkého kapitálu, kterým může něco protlačit.
Víte někdo jaký má mít Larabee (maximální) výkon? Někde jsem četl, že jedno jádro na 2 GHz bude mít zhruba stejný výkon jako C2D na poloviční frekvenci. To by ale znamenalo, že Larabee bude několikrát rychlejší než současné CPU. Jenže GPU jsou dneska zhruba 100x rychlejší než CPU, tj. Larabee bude nejspíš poněkud výkonově zaostávat za GPU.
Hezký článek. Larrabee je vážně zajímavý počin. Ale něco jako herní grafiku to bude používat jen blázen. 1. Nebude primárně určena na hry, díky své univerzálnosti to bude spíše výpočetní karta na nejrůznější věci. 2. S tím souvisí cena, všechno co je koncipováno pro bussiness a ne pro spotřebitele je X krát dražší. 3. Výkon - Univerzální řešení jsou známa tím, že velkou část výkonu spolkne režie - klidně 30% i více, proto budou s GK se svými optimalizovanými shadery na tom v DX a OGL lépe. 4. X86 architektura - té se asi bohužel nezbavíme nikdy a vždycky to bude největší brzda, na druhou stranu to chápu, není jiná možnost, pokud to má být tak univerzální. 5. Spotřeba - i když jsou jádra v Larrabee jednodušší než třeba v Core a Larrabe má ještě nějaký ten rok do uvedení, kde se dá předpokládat lepší technologický proces výroby jádra (jader), přeci jen jich tam bude hodně a můžete si představit kolik asi bude papat např. 40jádrové CPU
Závěř - Larrabe bude dobrou alternativou k výpočetním kartám postaveným na GPU, oproti nim toho totiž nabídne mnohem více. OGL a DX podpora zůstane jen jako taková třešnička na dortu a když budeme číst recenzi na výkon té či oné GK, nebude chybět Larrabee jen tak pro srovnání, její výkon ale bude pochopitelně nižší, což vůbec nevadí, protože je určena primárně na něco úplně jiného
>NeomeN: Nazory mas vlastni, dobre, ted jenom trosku vypilovat tu gramatiku, co rikas? Nebo jsi to psal jen jako nejakou vystrednost? Pro tve dobro doufam, ze ano.
Jinak, podle me, je Larrabee docela slibny pocin a, domnivam se, ze jeho ucelem je nahradit CPU+ext.GPU jednou plne programovatelnou jednotkou. Trochu mi to pripomina projekt Fusion, ale mnohem vykonnejsi (a vetsi a zravejsi). Ale je to jen muj nahled, treba to je/bude uplne neco jineho.
To weepy: Kde bereš tu jistotu, že to bude mít řádově vyšší výkon? Já jsem z článku pochopil, že tak maximálně 8x (oproti současným CPU, ne oproti Pentium I). A pokud bereme řády v desítkové soustavě, tak 8x to není ani řád. Ve dvojkové to jsou ale řády tři, že?
Výborný článek a nejlepší je název kapitoly "Co se může podělat?" :-)
Jinak to vypadá hodně zajímavě, moderní CPU přidávají jádra, tak proč jich nepřidat hodně a neudělat to univerzální s jistou mírou specializace na grafické (a podobné) paralelní výpočty. Proč pořád řešit poměr výkonu CPU ke GPU, když by se to mohlo operativně (softwarově) přizpůsobovat. Určitě je potřeba najít nový směr vývoje počítačů a procesorů.
ptipi: Recenze a články na Anadtechu obsahují mnoho spekulací a většinou špatných. Stejně tak i nový článek o Larrabee. Jak už jsem napsal, stačí si porovnat plochu jádra potřebnou pro implementaci 512bit sběrnice na R600 a na G200.
RV770 nepoužívá crossbar řadič (jediný crossbar v čipu je lokální distribuce texelů mezi texture caches). Pro nižší trafic využívá hub, který narozdíl od crossbaru nenarůstá s počtem klientů exponenciálně, ale lineárně a hlavní konzumenti bandwidth (ROPs a L2TC) jsou přímo nafixovné na paměťových kanálech (opět žádný crossbar).
To Milan M: Tak vidis, sam si nasel duvod, proc mam pravdu, tri rady je dost, ne ;)? Ja ti jich jeste par nalozim. Za prvy, pletes si vykon v x86 instrukcich a ve floating point operacich. V x86 to bude jedno larrabee jaderko samozrejme mene schopne nez stolni procesor, ale ve floatovych instrukcich ho rozdrti. A ty workoady se planujou jako vetsinove float vektorove a sem tam x86 (jumpy, loopy, zasobnik). 2 az 3 rady ve flops to da. Za druhy, pokud by larrabee nemelo fp vykon v radech tflops, tak by nemohlo konkurovat dnesnim hi-end GPU v rasterizaci, coz intel k prosazeni na trhu potrebuje (viz clanek).
Souhlasím s no-X. Spekulace mají jednu výhodu. Jsou zadarmo a při obratné argumentaci se dá vysvětlit, proč nevyšly. Jako ekonomické prognózy. Nejlepší je už dopředu používat formulace typu: "se bude chtit prosadit", "kdo chce, ... vyuzije". Hlavně nic konkrétního, aby za tím pak člověk nemusel stát. Že weepy?
Tak bacha, cast jsou spekulace, cast jsou data poskytnuta intelem... My si vzajemne co do konkretnosti a spekulaci nemame co vycitat. Podivej se na svuj prispevek... "Nebo to bude jednovláknová aplikace a o rozdělení se postará operační systém?" Moje spekulace maji aspon nejaky zaklad... Jestli keca intel, kecam taky, uznavam. Ale takovou vec, jako ze to bude muset k uspechu mit srovnatelny vykon v rasterizaci jako GPU v te dobe na trhu v dane cenove relaci, to si spocita i male dite, to se na me nezlob. A ze se to intelovi jednou povede, o tom nepochybuju, kdyz ne na 45nm, tak o fous pozdeji.
Nojo, červení fanatici nechtějí připustit, že jejich milovanou ATI ohrožuje další velký hráč na trhu v modrém dresu.
weepy: bacha na to, 2-3 řády rovná se stokrát až tisíckrát. O.O
Jinak bych se rád ohradil proti těm řečem, že x86 je největší brzda a podobně. Je to takový populární nesmysl (experti!). Výkonější proceosry než x86 se objevují jen z času na čas, x86 je tak dynamická, že drží krok, a posledních 9 let je spíš na čele než ne.
Ono když máte dost místa na tranzistory a firmy, které vám to za těžké prachy koupí, tak si můžete vymýšlet (power6), ale podívejte se, co dokáže Intel levně vyrábět pod jménem core 2 quad... trhač asfaltu.
To weep: Můj příspěvek byl konkrétní. Tu větu, co cituješ, to byla otázka (měla na konci otazník). A dlužno dodat, že nesmyslná. Pokud je aplikace psaná jednovláknově, operační systém ji ve víc vláken a tedy na víc procesorů efektivně nerozdělí. Takže příště zkus najít něco, kde jsem se nekonkrétně vyjádřil. Nicméně z tveho posledniho prispevku je videt, ze uz zacinas hledat duvody, proc ti spekulace nevyjdou: "cast jsou data poskytnuta intelem", "Jestli keca intel, kecam taky, uznavam." Hledej si vinika kde chces, treba v Intelu. Kazdopadne nepatrim mezi ty, co slepe skoci na vse, co ukazuje, jak ten vyvoj a vsechno jde milovymi kroky dopredu. A je mi jedno, jestli to vymysleli modry, cerveny, zeleny, oranzovy, rudy, nebo treba kafe-bronz-dozelena. Mam trochu alergii na takovy to buseni se v prsa, jak jsme dobri. Za komancu se treba verilo, ze az vyrobime nejvic tun oceli na svete, tak se budem mit nejlip. Uz se to v SSSR male podarilo.
To weepy: Moc se v tvych prispecich neorientuje. Muzes mi rict jednu vec? Jaky je podle tebe v soucasne dobe pomer mezi vykonem GPU a CPU. Chci cislo, zadne spekulace. (Odpoved doufam nebude dva az tri rady.)
blah: no nevím, ale nebyla to právě nVidia, kdo nejvíc kritizoval Larrabee, vektorovou architekturu i ring-bus? :-)
Milan M: Cim dal vic divergujes od tematu a zbytecne kritizujes me za neco, co sam delas. "Myslím že jako CPU pro to nikdo nebude psát aplikace." je spekulace. Na spekulaci neni nic spatneho, spekuluj dal a ja udelam to same.
Core 2 Quad Q6600 dela 30 GFlops, HD4870 X2 2400GFlops. Pomer je 80:1 v tomhle konkretnim pripade.
Mandracito: 1000x uz je uz fakt hodne, 100x je realne, neco mezi, tomu verim. Nedelal jsem konkretni research, pointa v tom mojem prispevku byla, ze prepisovat jednovlaknovou aplikaci, protoze nekdo zdvojnasobil pocet jader (threadu) na procesoru, se nevyplati, ale kdyz se ten pocet threadu zvysi prudce, tak to uz ma smysl.
To weepy: Kdyz je GPU 80x vykonnejsi nez CPU, proc se teda vypocty provadi na pomalem CPU a ne na 80x rychlejsim GPU? Nebude to treba tim, ze GFlops neni objektivnim meritkem vykonu? Anebo tim, ze maloco se da paralelizovat na vic jader nez 10? Ohledne te me "spekulace". Je pravda, ze uz zacinaji vznikat aplikace, co vyuziji 2 nebo vic jader. Da se to pri prevodu videa, archivaci souboru, hrach apod. Ale chvili to trvalo, nez to zacali programatori takhle psat. A neni to jednoduche. Navic spousta vypoctu (hlavne vedeckych) rozdelit do vice vlaken nejde.
Milan M: Nemas pravdu, vypocty se provadeji, jak na CPU, tak na GPU. GPU je specializovane na paralelni vypocet ve floatech, je to omezeny okruh uloh, ale porad ma obrovsky zaber. Jsou ulohy, ktere se paralelizuji perfektne (jako malovani, kdyz mas velkou plochu, muze ti obraz malovat n maliru a maji to n-krat rychleji) a ulohy, ktere se paralelizovat nedaji (jako vyroba ja nevim treba vrstvenych macenych bombonu, kde ke kazde operaci potrebujes vysledek serie jinych operaci). Pak je obrovska skupina uloh, ktere jsou mezi tim, a ktere jsou kombinacemi obou extremu (paralelni vyroba bombonu...). Vzhledem k tomu, ze problemu si vymyslis spocetne mnoho a tomu, ze ta skala neni cernobila, nema ani cenu se bavit kterych problemu je vic. Nedostatek uloh, ktere zparalelizujes na vice nez 10 vlaken, nehrozi.
Priklad: existuje cela trida problemu, ktere jsou velmi tezke na vypocet, a musi se na ne brute force. Pro reseni techto problemu casto existuji algoritmy, ktere davaji vysledek v rozumnem case, ale s urcitou pravdepodobnosti chyby. Neustalym opakovanim (nebo paralelnim spustenim) lze tuto pravdepodobnost zvysovat, ale nikdy to nebude 100%, ale v praxi se s tim smirime. Princip techto algoritmu je v nahodnem hadani, vybirani vzorku a podobne, coz je naprosto nezavisly a perfektne paralelizovatelny proces. Akorat se tam casto potrebuje branchovat, jumpovat, resit neco rozdelenim na podproblemy a norit se do podprogramu, to vsechno dneska GPGPU frameworky horko tezko obchazeji. Larrabee bude pro tyhle ulohy raj.
sry, oprava, opakovanim stochastickeho algoritmu se pravdepodobnost toho, ze vysledek je chybny, samozrejme snizuje..
Vyborny clanik Davide! Vdaka za perfektny a uceleny prehlad toho co sa doteraz o Lerrabee vie.
Inak, v suvislosti s (neskorsim) clankom "nVidia si licencuje Transmeta technologie" ma dost prekvapuje ze si nVidia nelicencovala aj technologie ktore by jej umoznili riesit x86-kompatibilne vypocty. Transmeta to vedela, aj ked nepriamo - ale pravdupovediac si nie som isty ci to mala nejako licencne/patentovo podchytene.
Ak sa totiz Larrabee ujme (a verim ze ano), bude nVidia vo _velmi_ tazkej pozicii - ATI ma vyhodu v spojeni s AMD, ale nVidia je co sa tyka rieseni typu Larrabee uplne mimo...
To weepy: V leccem nemas pravdu. Ulohy ktere se paralelizovat nedaji, zesmesnujes oznacenim typu: vyroba vrstvenych macenych bombonu. Tim jsi dokazal, ze se absolutne neorientujes. Vetsina vedeckych a jinych vypoctu bohuzel vede na soustavy N linearnich rovnic o N neznamych, kde N dosahuje velkych radu (miliony). Reseni teto ulohy se paralelizuje velmi spatne, pokud vubec. Druhou moznosti je rozlozeni oblasti (struktury) na mensi casti a resit je po castech. To samozrejme jde paralelizovat, ale provadi se to hlavne kvuli tomu, ze se snizovanim N ta narocnost klesa rapidne. Tento typ rozkladu struktury vsak neni uplne bez problemu, teprve se rozviji. V elektromagnetickych vypoctech je timto prikladem Fast Multipole Method.
Velke moznosti paralenich vypoctu vidim v optimalizaci. Tam je treba resit ruzne varianty same struktury treba 200x. To by se pak dalo resit na vice procesorech. Ale aby toto bylo efektivni, musi mit jeden procesor velky vykon, ne na urovni Pentium I. Takze taky nic kde by se Larrabee dalo vyuzit.
Dalsi omyl je tvuj priklad. Myslim si, ze se v aplikovane matematice orientuji. Mam doktorat z numerickych metod v elektromagnetickych vypoctech. V soucasnoti pracuji v jedne firme zabyvajici se navrhem elektronickych zarizeni. Ale o tve "cele tride problemu" jsem v zivote neslysel. Ze by se tohle v praxi pouzivalo? Muzes prosim uvest prakticky priklad, kde se to pouziva?
To weepy: Taky se rad nencham poucit v jine veci. Pises: "GPU je specializovane na paralelni vypocet ve floatech." Floatech myslis Floating point operacich? Asi ano, zkratka Flops to naznacuje. Pokud ano, pak nerozumim tomu, proc se obraz na pocitaci v GPU zpracovava s pohyblivou radovou carkou. Nejsem expert na zpracovani obrazu, ale mam pocit, ze na jejich zpracovani (jak obrazky, tak videa) bohate staci 32 bitove zpracovani v pevne radove carce. Pevna radova carka je na samzrejme mene vypocetne narocna. Lidske oko nema takovou dynamiku, aby bylo nutne pouzit vypocty v pohyblive radove carce. Takze v GPU se obraz podle meho nazoru zpracovava v pevne radove carce.
Jedina trida aplikaci kde se obraz zpracovava v pohyblive radove carce, je v biomedicinskych pristrojich. Mam na mysli zobrazeni vysledku pocitacoveho tomografu (CT), Magneticke rezonance (MR) apod. Zde totiz pomerne mala "cmouha" rozhoduje o tom, zde ma pacient rakovinu ci nikoliv. Ta by se tam pri zpracovani v pevne radove carce mohla vyskytnout v dusledku zaokrouhlovacich chyb behem a po filtraci. To je vsak trida uloh velmi specificka.
To weepy: Jestli te tim neobtezuji, jeste by me zajimala jedna vec. Pises: "vypocty se provadeji, jak na CPU, tak na GPU." Muzes mi prosim rici, jake druhy vypoctu krome zpracovani obrazu se dela v GPU? Mam totiz takove tuseni, ze pokud na svem pocitaci pustim vypocet, provadi se vyhradne v CPU. Proc se to teda neprovede v GPU, kdyz ma 80x vyssi vykon?
Pripustil jsem existenci tveho typu uloh a to ze ty odmitas videt, ze univerzum problemu je sirsi nez to, z ceho ty mas doktorat, je tvuj problem ;). Nezesmesnoval jsem, uvadel jsem priklad, nechtel jsem se dotknout tveho ega. Usmevne mi prijde to, jak mi postupne v tvych prispevcich davas za pravdu, ani nemusim lezt do googlu a hledat protipriklady... takze neobtezujes :)
Na GPU se provadeji graficke vypocty (prekvapko!!!). Nikdy jsem nerekl, ze GPU umi pocitat tvoje ridky nebo husty megamatice, s CUDA by to melo jit, nevim, ale tvrdim, ze larrabee to umet bude (pac to bude x86).
To weeppy: Zdar, meho ega ses nedotkl, nemam ho jak nakladak a nepotrebuju si ho zvetsovat. Zarazi me ale, jak odbihas k osobnim utokum. Spis bych ocenil, kdybys mi odpovedel na to, co jsem se te ptal. Stejne tuhle diskuzi cteme jen my dva, tak je to fuk.
fanATIci mají v povaze osobní útoky, když jim dojdou argumenty.Zvykej si.
Milan M: Vzhledem k tomu, ze to, ze ti neco vysvetluju, pro tebe znamena osobni utok, tak je nacase prestat. Uz jsem ti predal dost informaci, zbytek viz internet nebo knihovna, tema slozitost..
ehm: jak se pozna fanATIk... jako obhajce intelovych roadmap :D?
weepy: Pokud te to uz nebavi mi odpovidat, muzes mi prosim odpovedet aspon na jednu otazku co jsem se te ptal? Muzes prosim uvest prakticky priklad, kde se pouziva reseni typu brute force, o kterem pises? Pises o cele tride problemu, zajimalo by me nekolik prikladu pouziti.
Milan, Weepy: aby vám nebylo líto, že si povídáte sami se sebou, tak se taky zapojím - jsem jednoznačně na weepyho straně, většina existujících úloh je velmi dobře paralelizovatelná. Jak může někdo, kdo studoval numerické metody tvrdit, že by se numerické úlohy špatně paralelizovaly, to vůbec nedokáži pochopit - to je naopak přesně ten typ úloh, které jsou k paralelizaci jako stvořené.
Mohl bys, Milane, napsat jakou metodu pro řešení soustavy lineárních rovnic používáš?
Typicky se pouziva Gaussova eliminace, vypocet inverzni matice a nasobeni prave strany s touto inverzni matici, iteracni metody (mnoho variant), LU rozklad (casto pouzivany). No posledni dobou jsem spise uzivatel techto algoritmu, ty neprogramuju a tedy nevim, jak je paralelizovat. Ale u konkretnich metod jako Method of Moment (vyuziva Zeland IE3D, Agilent ADS, Ansoft Designer), Finite Element Method (Ansoft HFSS, Ansys, Comsol) jsem o nejake paralelizaci neslysel. Podotykam, ze se jedna se profesionalni sw. Ani tak principielne jednoducha metoda jako FDTD (CST microwave studio, Zeland Fidelity) je paralelizovana v jednom softu, ktery je spis na okraji zajmu.
Azazel: Podle tebe "většina existujících úloh je velmi dobře paralelizovatelná" "to je naopak přesně ten typ úloh, které jsou k paralelizaci jako stvořené". Můžeš na oplátku uvést příklady ty? Já jsem příklady uvedl, weepy není schopen, a já bych se celkem rád něčemu přiučil. Zřejmě ta weepyho "cela trida problemu, ktere jsou velmi tezke na vypocet, a musi se na ne brute force" je jen teorie bez uzitku (nebo weepy porad jeste googli?). No nicmene zajimaji me prakticke problemy, ne nejaka teorie. Neco, co se prodava, a za co jsou ochotni lidi zaplatit. Vyse zminene softy se prodavaji za radu deseti-tisice dolaru (1 plna licence). Tak neco na ten zpusob.
Milan M: "neni schopen" No tak tohle je dost uboha demagogie z tvy strany :(. Staci, ze toho jses schopny ty, fakt nemusim nic vyjmenovavat. Azazel ma pravdu, treba prave nasobeni matic nebo odecitani radku se paralelizuji naprosto v pohode. Naopak ja chci od tebe, abys ukazal, proc to nejde. K vypoctu jednoho policka soucinu matic nepotrebujes zadne jine policko, neni tam zavislost, neni duvod, proc bys nemohl pustit vypocet kazdeho policka nezavisle ve zvlastnim threadu!
A jestli ten google neumis pouzit sam, tak ze jses to ty... rusove s pomoci CUDA louskaji md5kou zakodovana hesla, vsechny monte carlo metody jsou inherentne paralelizovatelne (a aby ses tady po me nevozil, ze nejsem konkretni, tak vyjmenuju treba vypocet pi nebo shlukovani vektoru), veskera grafika, at uz rasterizace nebo raytracing.. a dal se snaz sam. Pikantni je, ze existuje Monte Carlo algoritmus pro pocitani inverzi hustych matic, a v tom bys jako numerik mel mit prehled: http://portal.acm.org/citation.cfm?id=1361924&jmp=cit&coll=GUIDE...
weepy: Zajimave je, ze paralelni reseni jedne soustavy rovnic zadny z komercnich softu neopuziva. Asi to bude v necem jinem. Co se tyce Monte Carlo, tak je to dobry priklad metody, pro urcitou velmi uzkou skupinu problemu velmi dobre pouzitelny. Priklad z praxe znam jen jako worst case analyza, ale to je v praxi jen relativne malo pouzivana opsna v softech. Pokud znas jiny prakticky priklad co se da pomoci Monte Carlo resit, tak klidne uved. Vypocet inverznich matic pomoci Monte Carlo mi prijde jako ze nejaky vedec nemel co delat. Vyuziti paralelismu u grafiky jsem nikdy nezpochybnoval. Ty ses ale porad ohanel sirokym pouzitim.
weepy: Louskat md5kou zakodovana hesla povazujes za praktickou aplikaci? Podle me je to spis takova hricka, zajimavost.
Milan:A co chceš přesně slyšet? Mám tady vyjmenovat všechny programy co existují? Tak prosím, tady jsou: kódování videa (ale i přehrávání), jakékoli zpracování obrazu - obecně počítačová grafika/fyzika, prakticky všechny simulace (např. počasí, lékařství, chemie, ...), antiviry, jakýkoli víceuživatelský informační systém (webserver, mailserver, ...), databáze, kompilátory, prostě prakticky všechno co člověka napadne !
To co jsem vyjmenoval by se dalo rozdělit do dvou skupin
přirozeně paralelizovatelné úlohy (např. ta počítačová grafika)
velké množství nezávislých úloh (třeba webserver)
U obojího se dá masivní paralelizace výhodně využít.
Argument, že 'žádný komerční soft to nepoužívá' je hodně špatný a to ze dvou (souvisejících) důvodů:
paralelní algoritmy je významně složitější napsat, takže se to nedá udělat ze dne na den
mainstreamové vícejádrové počítače jsou tu zatraceně krátce, takže motivace k psaní takových programů se teprve pomalu objevuje
PS: jako bonus dokument o paralelním řešení řídké soustavy lineárních rovnic:http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.5441
Ještě proč jsem se ptal na použitou metodu:
http://www.google.cz/search?hl=cs&q=parallel+gauss+elimination+method
http://www.mathematik.uni-halle.de/reports/sources/2002/02-06report.pdf
Milan M: Jsi v koncich a uhybas, jak se da ;). Vzhledem k tomu, ze to nekdo v praxi pouziva, tak se nebojim to oznacit jako prakticke. To, ze mnozina monte carlo algoritmu ti pripada omezena a ze kryptografie je pro tebe okrajovy obor, hricka, je opet problem spis v tvojem omezenem vnimani.
Zakladni vec kterou ty si myslis je, ze pro larrabee nikdo nebude programovat (prvni prispevek od tebe), a ja tvrdim, ze larrabee zbori dalsi hranici, ktera ted brzdi rust GPGPU aplikaci.
To Azazel: Ok, ses dobrej. Uznavam, paralelizovat neco z toho jde. Uvidi se, co z toho se ujme. Asi jsem zaspal dobu, do numerickych metod uz delam jen jako konicek, nove trendy ohledne paralelizace me unikly. Souhlasim s tebou tom, neni to jednoduchy, psat ty aplikace nebo metody vice-vlaknove. Proto se to asi jeste ve specialnich CAD komercnich softech nechytlo.
To weepy: Mnozina aplikaci Monte Carlo algoritmu se mi omezena nezda, je omezena. Kryptografie jiste neni okrajovy obor a ani hricka. To mi podsouvas, to jsem nenapsal. Napsal jsem, ze "Louskat md5kou zakodovana hesla .. je hricka, zajimavost." Souhlasim, ze to, ze se louskaji hesla pomoci brute force souvisi s kryptografii, ale je to jen jeji mala cast. Daleko dulezitejsi je louskat hesla bez brute force. Ale kryptografie je hlavne o tom, jak vymyslet kod tak, aby se do nej nikdo nedostal.
Co se tyce psani vicevlaknovych aplikaci, tak skutecne je nikdo nebude mit chut psat. Ja nejsem programamtor, ale znam nektere programatory, co takovy sw pisou. A je to hodne tezky. Navic vicevlaknove aplikace maji velkou rezii, ktera s tim rozdelenim souvisi. Proto je lepsi mit jeden vykonny jednojadrovy procesor, nez 16 malo-vykonnych jader v jednom procesoru. Samozrejme ze nejlepsi je mit 16 vykonnych jednojadrovych procesoru, pokud mas dobre napsanou aplikaci, a dostatecne silny privod elektriky. A samozrejme ten paralelismus nesmi sezrat moc vykonu na rezii, jinak je to k nicemu.
Co se tyce uhybani, tak mi pripada, ze uhybas ty. Nedokazes odpovedet na to, co se te ptam (vse co ma na konci ? je otazka). Meles dalsi nadsene veci, co sis nekde precetl, a kdyz to jinak nejde, utocis.
Postupne mi davas za pravdu. Puvodne jsi videl uplatneni snad vsude (cituji "to bude mit i sirsi uplatneni"). Ted pises o grafice a videu, lousknuti hesel a Monte Carlu. Takze zas tak moc toho neni.
Dal jsem ti tridy problemu a podle tebe jsem utocil a chtel jsi neco konkretniho. Dal jsem ti konkretni problemy, podle tebe utocim a kritizujes me, ze je to prilis uzke. Ja uz nevim kudy kam.
Asi ti neporadim nic jineho, nez abys cetl pozorneji.. To, ze ty rikas, ze moje odpoved je o nicem, neznamena, ze jsem neodpovedel (promin, ale tohle si neodpustim, delas mi to furt: odpoved je ta hromada pismenek nadepsana mym nickem, kterou musis cist zleva doprava po radcich).
Fraze "monte carlo method" dava tri a pul milionu hitu v googlu, to nesvedci o omezenosti pouziti. Ze vicevlaknove aplikace se programuji tezko... to je vec, o ktere se hodne pise, ale je to opet generalizace, ktere ty jako user snadno sednes na lep. Zase je to o tom, ze nekde to jde lip a nekde to jde hur, v zavislosti na tom, jak moc spolu musi thready komunikovat nebo cekat na vysledky jineho. Zopakuju ti, ze prudkym zvysenim poctu soucasne vykonavanych threadu stoupne i motivace psat veci multithreadove, protoze ty zvysene naklady na vyvoj budou vyvazeny vyslednym vykonem.
Jo v tomhle stadiu jsou to zatim jen nadsene kecy... ale vzhledem k tomu, ze to ctes taky, tak mi nemas co vycitat ;).
Pls fakt otevri ten google a koukni se, co je kryptografie. Ta je naopak zalozena na tom, abys MUSEL pouzit brute force k prolomeni.
to weepy: Tvuj problem je, ze nemas vlastni nazor. Vsechno hledas v googlu a kdyz je tam hodne odkazu, myslis si, ze to ma smysl. Dam ti 2 priklady nesmyslnych spojeni, co me napadly. Oba mely pri vyhledani na googlu pres milion: fractal stability (1.1 milionu), antenna social (2.6 milionu). No ani jedno z toho nema smysl.
Milan M: To neni argument... sam vis, ze Monte carlo method je smysluplne spojeni, hodne presne a pritom zdaleka ne vycerpavajici vsechny relevantni zdroje. Ze vsechno hledam v googlu je blbost, to mi nepodsouvej, neni to pravda ;). Naopak ty zauvazuj, jestli bys nejaky vyhledavac nemel pouzit, nez zas neco placnes (to neni utok, to je konstatovani).
weepy, Milan M> Panove, vasi debatu jsem sledoval vcelku se zajmem, ale ne tematicky, ale jako sociologickou studii. V tematu se take trochu orientuji, takze jsem mohl snado videt, jakym zpusobem kdo argumentujete a vedete spor. A to je ten problem. Uvedomujete si, ze kdybyste se k tehle debate dostali nekde v realu, tak jste mohli zapadnout treba do hospy a fakt paradne to probrat jako kamosi? Ale jak je to na Netu, hned se vsichni stekaji jak psi, to je uroven. Stydte se.
Ren: no tak flame uz je sociologicky prostudovany skrz naskrz :). Abych pravdu rekl, parkrat me presne to o ty hospode a pivu napadlo... ale pak jsem si to zase rychle rozmyslel. Podel se prosim, co jsi o nas vyzkoumal :)...
weepy> Urcite nic, co bys sam davno nevedel. Ze i rozumni a vzdelani lide se v pisemne anonymni forme meni v ustekane squaw a debaty, ktere by mohly nekam vest, se meni v nesmyslne hadky a presvedcovani o tom, kdo ma pravdu.
Vsimas si, ze ses timto vlozil sam do diskuse, stejne anonymne a zpusobem, ktery by mohl pusobit jako prilivani oleje do ohne ;)?
Ja myslim, ze to bylo celkem plodne, aspon jeden z nas ziskal hromadu novych znalosti. :D
Zdravi te stekajici squaw. Asi si to dam na vizitky :D
weepy> Tak pocitam, ze uz bylo po debate, takze jsem se k tomu jen vyjadril, navic nemyslim (doufam), ze by to mohlo zapusobit jako prilevani oleje do ohne. Mozna v nejake debate usmrkancu by se to stalo, ty take obvykle ignoruji. Ale napadlo me, ze dva lidi jako vy by se nad tim opravdu zamyslet mohli.;-)
weepy> Hehe, zase ta neurcita cestina..:-) Tak pro jistotu, to doufam v zavorce znamenalo, ze jsem NEmel v umyslu pusobit provokativne.
Ren: Prostredky, kterych pouzivas, se nelisi od tech nasich. Vlastne jsi napsal, ze pokud na nas pusobis provokativne, je to proto, ze jsme usmrkanci. Neni to prilis fer, protoze komunikace je zalezitost vzdy dvou a vice lidi a za prenos informace nesou zodpovednost vsichni zucastneni. Proto prosim o zamysleni take z tve strany...
weepy> Ale no tak..:-( Myslis, ze bys dokazal alespon na vterinu prestat predpokladat, ze se Te kazdy snazi urazit? Ja to vubec nemyslel zle, dokonce jsem to i napsal. Proc to ohybas tak, ze to mohlo vypadat jako utok? Chces mi dokazat ze jsem se ve svem odhadu spletl?
Co to s tim svetem je?
Proc myslis, ze si myslim, ze me kazdy chce urazit?
...
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.