AMD Ontario: útok na osamocený Atom

"úsporné procesory CULV (Consumer Ultra-Low Voltage) od Intelu, které jsou poslední dobou taktéž hojně nasazovány i v netboocích"

muzete mi nekdo ukazat nejaky notebook, ktery se zacal u nas prodavat v nedavne dobe a ma CULV procesor?

Tak treba rada Acer Timeline (bez X) a pak treba Asus UL

oboje obsahuje nejaky CULV procesor SUxxxx. A je to dokonce prodavano jiz dele nez nedavna doba.

No prave!!! Obe rady jsou tu uz buhvijak dlouho. Ale nic noveho... Zda se mi, ze CULV koncept uz proste neni in...

Z osobních zkušeností vím že všechny mobilní počítače s vysokým výkonem častokrát předčí ve výdrži i ty nej-energeticky nenáročnější ostatní mobilní počítače o stupeň nižší výkonnostní třídy. Je sice hezký že spotřebuje o 30-45% míň energie, ale když bude převádět filmy 2x pomaleji, tak je mu to k ničemu. Hlavně miluju jak někdy někdo přinese netbook a říká jak ho miluje a teď se někdo ukáže s alienware za 50 litrů, on jen čumí říká že tohle nemůže vydržet víc jak 3 hodiny, a pak za 5 hodin, no vydíš mě se to vybilo až teď! A chlápek s alienware jenom "mě zbývá ještě 70%".

:D

Eh.. takže prostě kdybych si měl za půl roku vybrat netbook, tak beru AMD. A ne proto že mi kámoši na něm budou pařit counter strike....

Ten alienware má nejakú litiovú alternatívu 42Ah autobaterky, ze?

Pardon, ale to je hroznej blabol

Jen do toho AMD !!!

Pravděpodobnost pádu systému je přímo úměrná času od restartovaní.

DirectX 11

i u těch nejlevnějších netbooků vypadá neuvěřitelně. Vždyť i dnes Nvidia nenabízí u notebooků DirectX 11.

Za 5000 - 6000Kč by to bylo výborné. Doufám, že se AMD dostane na cenu dnešních nejlevnějších netbooků s Atomem.

Navíc ceny půjdou dolů, již nyní přímo padají ceny pamětí a displejů.

Taky doufám, platforma Atom potřebuje už nějakou konkurenci.

Pokud AMD opravdu splní, co se zde píše, tak se můžeme těšit na dostatečně výkonný notebook s velmi nízkou spotřebou a podporou moderních technologií.

to slysim snad pres rok, ze AMD vyrukuje s necim do segmentu netbooku ale mame podzim 2010 a kde nic tu nic, oni snad oznamuji svoje vyrobky, kdyz jsou jeste "na papiru" intel je taky brepta ale ten ma aspon neco na trhu...

bude umet onen vestaveny radeon 5xxx akceleraci HD videa ve stejnych spec. jako napr. stara GF8200 ? tzn. až 16RF pri High@L5.1 ? pokud ano, tak rikam super a na to nejde nereagovat vytkou, proc to sakra tak dlouho trvalo, kdyz nVidia to umi uz roky...

Budou ještě před (čínským) Novým rokem.

Já kupuji notebooky v únoru, tedy před Novým rokem ( myslím Nový rok v Číně).

To jsou již na trhu notebooky s procesory předvedené na veletrhu v Las Vegas.

Letos ale možná budu kupovat 2. Notebook s Intelem Sandy Bridge a grafikou AMD 6000 kolem 20 000 a k tomu bych přibalil i netbook Bobcat za 6000 Kč.

Já nemám tolik peněz a proto nyní vyčkávám do února.

Já jsem vždy četl, že AMD představí zcela nové čipy až v roce 2011, tedy BOBCAT a BULDOZER přijdou podle plánu.

U BOBCATu nemám strach se spotřebou jako autor, protože BOBCAT byl navrhován v první řadě s ohledem na spotřebu. Když nebudete hrát hry, honit grafiku, tak spotřeba může být nižší než u Atomu.

Mám trochu obavu o cenu. Myslím si, že BOBCAT nedosáhne ceny levných netbooků s Atomem pod 6000 Kč, příští rok 5000 Kč. Nejspíše bude cena značně vyšší.

Až budeme znát cenu, tak budeme moci soudit.

tak by mně zajímalo jak to budou číslovat ty výrobní technologie až to pujde pod 1 mn

asi 0,#

na to nemusis byt genius aby si vedel ake cisla su mensie ako 1.

Jak, např pm (piko metr), takže po 1nm bude třeba 666pm

666pm? Tak to bude asi pekelně dobrej procesor

Hlavně že tu někdo nedávno psal článek o tom že se procesorová výrobní technologie blíží fyz. hranice 12nm, kde je tranzistor už příliš nestabilní aby udržel polaritu(nebo co-že to už nemoh udržet?)

On je problém i v tom, že velikost atomu je řádově 1E-10 m, tj 100pm. Takže o moc méně než řádově nanometry se dostat nejspís stejně nedá.

No, teoreticky by šlo udělat jakýsi "virtuální" tranzistor z fotonů světla. Ale teoreticky jde všechno, a tohohle se těžko dožijeme.

spíš se bude řešit jiná technologie než zmenšování do 1/nekonečka

Nestabilita pod 10 nm.

Jak se ukazuje, tak již pod 10nm nás čeká velká nestabilita, únikové proudy, ... .

Doposud používané výrobní technologie budou muset být nahrazené zcela novými.

memristory, kvantové počítače...

neni to az tak davno, kdy se bezne cislovalo v mikrometrech

Tohle jadro vypada zajimave. Pokud by se jim to podarilo vyplnit, tak by asi nebyl problem poslepovat treba 60 techto jader k sobe a mit 60 jadrovej procesor (sice s taktem cca 1.6GHz) a s velmi nizkou spotrebou. Samozrejme s plnou podporou x86 a x64 instrukci. Pro praci s videem by to mohlo byt celkem dobre.

A obecne by to mohlo primet programatory vyvijet vicevlaknove aplikace. Protoze ted ty procesory maj proste malo jader. Ono napsat aplikaci tak aby byla schopna vyuzit vice jader neni zase tak snadne. A kdyz vetsinou maji lide 2 nebo 4 jadra, tak tu aplikaci mohou cca 2x nebo 4x urychlit. A to jim za tu praci navic nekdy nestoji. Ale kdyby aplikaci urychlili 60x, tak uz by si dali zalezet a napsali to vicevlaknove.

Ne všechny úlohy lze paralelizovat (na zpracování videa se spíš hodí grafická karta) a nárůst výkonu s počtem jader klesá = 2x více jader dá dejme tomu max 1.9x výkonu ale 4x více jader dá už jenom 3.6x výkonu (no prostě míň než 2*1.9).

tak to ste trafili capa s tym prikladom

multijadra vacsinou vyuzivaju system SMP, kde vykon rastioe s odmocninou poctu jadier

teda 4 jadra maju 2x taky vykon ako 1 jadro a 2 jadra maju zhruba 1,44 nasobny vykon ako jedno jadro

Keby tam vsak bola NUMA (Intel a este skor AMD ju mali pre multiprocesorove servere medzi procesormi) tam to rastie zhruba ako ste napisali v priklade

Výskumník a vyučujúci predmetu Unix/Linux... na 101. najlepšej univerzite v oblasti informatika na svete shanghairanking.com/SubjectCS2012.html , . ACM Professional member #5480576

Jasne ze vse se paralelizovat neda, ale u dosti veci to jde. A s tim narustem vykonu to taky nemusi byt pravda, zalezi na tom jak je ten algoritmus navrzeny. Klidne muze dojit k vyssimu narustu vykonu, tj pro 2 procesory ti naroste vykon treba 2.5x

A co se tyce zpracovani videa, tak jsem zatim nenasel program co by mi vyhovoval. Uz jsem jich vyzkousel dost a co jsem nalezl tak bych rekl ze jsou urceny pro BFU, tj same graficke sr*cky ale moznost konfigurace mizerna. Rozliseni vetsinou neslo nastavit libovolne, jen vyber z prednastavenych hodnot. Orezat cerne pruhy z videa taky moc nejde. Neco jako dvoupruchodove enkodovani tam neexistuje... Osobne bych chtel neco jako je Avidemux, ale s podporou GPU. A nic takoveho jsem nenasel.

To by mě zajímalo, co to je za algoritmus. Takže jeden člověk (procesor) udělá za jednotku času jeden úkol a když na to pustim dva lidi (procesory) tak zvládnou za stejnou časovou jednotku 2.5 úkolu?? To se mi nechce věřit - navíc ještě musíme připočítat synchronizaci. http://en.wikipedia.org/wiki/Amdahl's_law...

Chtěl bych vidět takovej kouzelnej algoritmus.

ciste prakticky s lidma(kdyz jste vztahl procesor na člověka): ukol je premistit 10ks zeleza o hmotnosti 80kg.

- jeden clovek premisti 1ks za 5 minut protoze to bude tahat po zemi a bude strhanej jak pes.

- dva lidi ten 1ks čapnou a odnesou za 1 minutu.

Ach jo, stejnak pořád chci vidět ten algoritmus co je 2.5x rychlejší při 2x počtu procesorů. S těma lidma jsem dal špatnej příklad.

V tvém příkladu jeden člověk odtáhne 1ks železa za 5 minut ale dělá mnohem víc práce (táhne železo + reje rejhu do hlíny) kdežto dva lidé jenom táhnou železo, kdyby pak ještě měli dělat tu rejhu, určitě nebudou s prací hotovi dříve než za polovinu času, kdyby to dělal jenom jeden člověk. A že bude jeden člověk strhanej jako pes - procesor se neunaví. Dal jsem špatnej příklad, no.

Pamatuju si z paralelních systémů, že jde o tzv. "superlineární zrychlení". Nedochází k němu zaručeně vždy, ale třeba u prohlédávání binárního stromu do hloubky, tak na 2 procesorech najde většinou řešení dřív než v 50% čase. Pokud je to řešení hluboko, tak prostě ve 2 to najde daleko dříve, ale musí mít člověk zase "štěstí".

Jak psal kolega dole, v některých speciálních případech skutečně můžou být 2 CPU třeba 2.5-krát rychlejší než 1. Typicky pokud se nemusí se procházet celý stavový prostor - pak každé CPU začne někde a je šance, že jedno z nich najde řešení.

Je to asi jako když třeba hledáš ztracené dítě v lese - předpokládej, že bude v jedné čtvrtině. Pokud ho bude hledat jeden člověk a půjde z blbé strany, tak musí přejít 3/4 lesa. Pokud půjdou dva z opačného konce, tak jeden ho najde už když ujde jenom 1/4, takže oproti jednomu člověku by stačila třetina času a ne polovina.

Nojo ale to je náhoda, když budu něco hledat v poli o sto prvcích a ono to bude v předposledním, tak mi to bude trvat 99 jednotek času, když budu hledat ve dvou z každého konce najdu to za 2 jedotky času (zrychlení jaxviňa), ale průměrná složitost je furt O(n/2), ve dvou rozdělím pole na dvě stejné části a zase to bude O(n/2) jenomže n bude poloviční.

Tak to co jsem napsal byl příklad, našel bys třeba i lepší. Jinak na datech sice záleží vždycky, ale důležité je, jak se algoritmus chová pro normální data a ne pro extrémy. Třeba složitost quicksortu se uvádí O(n.log n), ale v nejhorším případě je to n^2. Nicméně takové případy v praxi moc často nenastanou, takže se dá používat. Jinak pokud bych chtěl v nějakém poli hledat často, tak asi místo pole použiju něco jiného .

Je to možné díky vlivu cache. Představ si třeba , že máš řadu kladných čísel a máš za úkol najít v ní největší číslo a tímto číslem pak každé číslo v této řadě vydělit (tzn. provést normalizaci hodnot na interval 0 až 1). Pokud bude celá řada čísel tak krátká, aby se celá vešla do L1 cache, tak běhěm hledání největšího čísla se sice budou hodnoty číst z pomalé paměti, ale při dělení už budou data k dispozici rychle z cache. Pokud ale velikost řady překročí velikost L1 cache, bude se muset během dělení znovu celá řada načítat z pomalé paměti. Když se řada rozdělí mezi několik procesorů tak, aby se část, která připadá na každý procesor celá věšla do jeho cache, budou mít procesory data pro dělení opět k dispozici rychle (díky cache) a výpočet bude víc než N krát rychlejší (N je počet procesorů), než kdyby výpočet provádělo jedno jádro a muselo během dělení čekat na pomalou paměť.

Pochopitelně bude záležet na tom, jak dlouho bude procesoru trvat dělení, porovnávání čísel a na poměru doby trvání přístupu do RAM a L1 cache, ale v některých případech bude zrychlení algoritmu větší než lineární (tzn. N procesorů bude více než N krát rychlejší než jeden procesor).

Viděl jsem na youtube video nějakýho produktu Adobe (vyšel asi v červnu) kde na nVidii quattro s 4GB VRAM prováděli něco neuvěřitenlýho 4 fullhd videi najednou. Ale to bude drahota.

"N550 maximální spotřebu pouze 8,5 W. AMD celou dobu nebyla schopná nabídnout konkurenceschopné řešení se stejnou spotřebou." ... "AMD v případě Ontaria počítá s maximálním TDP 9 W, což je vzhledem k výkonu grafického čipu a podpoře technologií skutečně konkurenceschopná spotřeba." atď atď.

Prečo mám pocit, že autor mieša a zamieňa spotrebu s TDP a naopak.

(Ustijuf = Tralalák)

Co maj pořád s tím Out-of-Order-Execution? To nemůže ty instrukce "správně" seřadit už kompilátor? Protože jsou kompilátory neschopné, tak výrobci mikročipů do nich přidali další logiku na "vylepšování" vstupního strojového kódu.

Nebo jsem neznalej a ve skutečnosti udělat pořádnej kompilátor není vůbec jednoduchý udělat? Máme tu mnoho druhů procesorů a každej to má rád seřazený jinak? A co na to VLIW - very large instruction word, kde se v jednom taktu (on to ve skutečnosti nebude asi jenom jeden takt) provede více instrukcí naráz? (ale to funguje jenom u některých instrukcí, kompilátor musí rozhodnout co se dá zkombinovat aby to správně (a rychle) fungovalo)

Kompilator asi muze, ale samozrejme to nemuze udelat rekneme u 5 samostatnych aplikaci tam musi rozhodnout "nekdo vis"

Jako myslíš, že na jednom procesoru běží 5 aplikací? Ony ale neběží "naráz", operační systém mezi nimi přepíná, říká se tomu context switch a ten nastává jenom zřídka (tedy pokud to bereme z pohledu procesoru - ten má dneska zhruba 1-3 GHz) takže mezi tím, než se provede jeden context switch, se provede spoustu a spoustu kódu jenom jedné aplikace a pak teprve se přepne na jinou a tam nemá cenu aby procesor něco optimalizoval (ukládání registrů do paměti) ve smyslu OoOE nebo pipelinigu.

Prepinani kontextu neni ridke. Uz jenom proto, ze tomu, co rikate, "se provede spoustu a spoustu kódu jenom jedné aplikace", je nesmysl. Protoze systemu napr. musi reagovat na akce uzivatele - pohyb kurzoru atd.

Rikal prepinani kontextu z pohledu procesoru... Ciste teoreticky pokud system prepina mezi aplikacema frekvenci 1000Hz, (Linux kernel ma defaultni hodnotu tusim 250Hz), tak tenhle procesor behem ty jedny milisekundy zvladne vykonat porad 3 000 000 instrukci... Rek bych ze prepnuti kontextu jednou za 3 000 000 instrukci je realtivne ridke ;)

V 1 procesoru běží vždy jen jeden proces, přepnutí procesu je poměrně složitá a dlouhá operace, trvá řádově tisíce instrukcí, takže nějaké prohazování instrukcí v rámci různých procesů je úplný nesmysl. Spíš bych to viděl na to, že kompilátor to optimalizuje obecně, zatímco pro každý jiný procesor jsou výhodnější jiné optimalizace.

to uz 9 rokov neplati. Mame tu viacjadrove procesory,co je de facto viacprocesorov v jednom puzdre so spolocnymi prvk

ami

Výskumník a vyučujúci predmetu Unix/Linux... na 101. najlepšej univerzite v oblasti informatika na svete shanghairanking.com/SubjectCS2012.html , . ACM Professional member #5480576

Kompilátor to přehodit může, ale pak takový kompilátor bude nepoužitelný. Kdyby mi kompilátor přehodil násobení před odčítání, když odčítání a pak násobení by mi dalo jiný výsledek, asi bych ho musel ušlapat. A procesor taky nemůže přehazovat instrukce jen tak, pokud je výsledek instrukce závislý na výsledku instrukce předchozí...

Přehazovat se může, ale nesmí se narušit sémantika kódu. To samé v pipeline, instrukce se provádí souběžně taky tak aby nenastala kolize nebo změna významu. Třeba, že se bude zapisovat do registru dříve než ho další instrukce chce číst a v kódu je, že ho nejprve přečte a pak do něj zapisuje.

Kompilátor to přehodit nemůže, protože out-of-order v procesoru přihlíží k tomu, jak jsou aktuálně dostupná i data (kompilátor má k dispozici jenom kód). Instrukce se přehazují třeba podle toho, jestli už jsou potřebná data načtená z paměti - tj. kompilátor by musel znát i poměr rychlostí zpracování a načítání z paměti, někdy i pozici dat v paměti (a typ paměti).

Jsi neznalej

Jenže kompilátor dopředu neví, v jakém pořadí se instrukce budou provádět. Stačí obyčejná podmínka a v reálu bude jednou pokračovat dál jedna část kódu, jindy jiná. Nebo stačí z jednoho programu přeloženého jedním kompilátorem zavolat knihovnu, kterou napsal někdo jiný a přeložil jiným kompilátorem. Vhodnost pořadí instrukcí také závisí na dostupnosti dat (třeba zda jsou zrovna v mezipaměti). Etc, etc, etc.

Procesor 1 umí zároveň 2 sčítání, 2 násobení a 1 dělení a nejrychlejší pořadí instrukcí je 1+3+5, 2, 4 (t.j. instrukce 1 a 3 5 zároveň - celkem za 3 takty)

Procesor 2 umí jen 1 sčítání, 1 násobení nebo dělení a nejrychlejší pořadí je 1+3, 2, 4, 5 - 4 takty

Procesor 3 umí 2 sčítání, 1 násobení, 1 dělení, nejrychlejší je 1+3, 2+4, 5 - 3 takty

Navíc se čeká na dat z operační paměti pokud není v cache (a i z různých úrovní cache jsou data dostupná různě rychle) t.j. i na tom samém procesoru může být nejrychlejší pořadí různé podle toho co je a není v cache.

Osatně na principu přestěhovat toto rozhodnutí do překladače bylo postavené Itanium (ano Itanic je VLIW i když ho tak Intel nerad nazývá) a ono se ukázalo, že napsat dostatečně inteligentní překladač není vůbec jednoduché a druhak to dost omezuje v možnosti zrychlit procesor přidáním další ALU, ... .