AMD Steamroller/Excavator (28nm)-informace, spekulace

[flanker]

chyběl spíš dobrý OS, ne soft, ačkoliv už XP v 64-bit byl slušný systém...

[froxic]

S tím nemůžu souhlasit. Ne každá aplikace potřebuje využívat rozšířenou adresaci a nemusí být také paměťově náročná. Problém je spíše v paralelismu u samotných aplikací a v problematickém vývoji takto optimalizovaných aplikacích (v případech, že je možné paralelní nebo alespoň pseudo-paralelní kód vytvořit). Pokud se nové instrukce nebudou využívat, tak budou pouze v papírových specifikací procesorů a nikdo z toho nebude mít užitek.

[DOC_ZENITH]

bez softu ti je aké koľvek CPU nanič a nové inštrukcie na tom nič nemenia
to že x86 už dýcha z posledného je známe už asik 20r
problém je to neskutočné množstvo softu a aj istá kompatibila smerom dozadu kedy funguje aj soft starý 30r a toho sa ľudia iba ťažko vzdajú či už to má význam alebo nie
stačí pozrieť koľko trvalo aby sa rozšírili X64 OS a pritom CPU to zvládajú dlho predlho

Apple tohle zvládnul. Když přecházel z PowerPC na Intel, tak OSX leopard a snow leopard měly oba dva přmo v Kernelu zabudovanej emulátor celé PPC platformy. Šly nainstalovat na obě dvě platformy ana Intelu šly spouštět programy psané pro POwerPC. Ano jistě jednalo se o emulaci takže pomaleji, ale fungovalo to na 100%. A člověk by i čekal že to pojede extrémě pomalu, ale zkoušeli jsme Unreal trounament 2004 ve verzi pro PowerPC a x86 na Core2 duo 2,4Ghz A místo 85 fps jsme měli 35. To je na emulaci komplet celé platformy sec sakra dobrej výsledek. Proč tohle MS neudělá a z x86 konečně neuteče.

Ona nás totiž ani tak nebrzdí x86 ale Microsoft a jeho OS co na ničem jiném nefunguje. Lidem jde to aby spistili své 10 let (většinou účetní, atd.) programy. Tam vůbec nejde o výkon ty by se klidně mohly emulovat. I staré hry by se mohly, proč ne. Jedinej problém by nastal u novějších CPU náročnejch her, které si za to stejně můžou samy protože stále sedí na x87 a jejich tvůrci se neobtěžují psát pro moderní CPU instrukce.

Vinu na tom všem má dle mého názoru největší Microsoft. Tlustou čáru mohl udělat s windows 8, jenže neudělal, naopak je to ještě horší. Budou mít 3 verze. X86/64 PC, ARM verze a x86 tablet verze, všechny 3 jsou navzájem nekompatibilní a na ARM verui x86 SW nespustíš, a naopak. Takže bravo. Skutečně bravo, hlavně že budeme mít to šílené metro ve kterym nejde pořádně dělat multitasking a MS si asi myslí že všichni doma máme dotykové displaye a ovládáme PC tak že na něj hmatéme a něco někam taháme..... bože muj....

[webwalker]

No, nejenom Microsoft, ale nezapomínejme, že tu byla neprůstřelná "aliance" wintel
Naštěstí, dnes to vypadá, že byla ukončena. Imho MS nic jiného nezbývá, musí zachovat kompatabilitu s minulostí.
Pokud pominu windows 32/64bit, tak nás vlastně čekají jen dvě verze - klasický desktop (Winxx) a Metro(WinRT).
Desktop je x86only, ale Metro je x86/ARM (co spustíš pod Metrem na x86, to také spustíš na ARM).
Bohužel ARM se dost fláká se svým 64bit cpu (ARMv8)

[DOC_ZENITH]

K čemu, vždyť ty ARMy jsou slabší jak Atom, výkonnostně jsou to useless stroje. Spousta lidí v tom vidí spásu ale nemaj vůbec šajn o tom jak strašně špatnej je reálnej výkon těchto zařízení.

[webwalker]

DOC_ZENITH: Slíbili to
Imho na tablety to bude naprosto v poho, no a třeba časem ....

[Trovaricon]

Ja mam vzdy problem pochopit, co maju ludia proti x86 a stale spominaju jeho nevhodnost. Nahradenim CISC-u x86 napriklad takym RISC ARM by zavislost na prekladaci pri viacerych nezavislych vyrobcoch CPU (tym chcem povedat, ze spolocnu by vyrobcovia mali len instrukcnu sadu) este vyrazne vzrastla a o problemoch s kompatibilitou ani nehovorim.

Treba si uvedomit, ze este stale sa predavaju mobily s uarch ARMv6 (ARM11) a taka Mozilla Firefox vyzaduje Android s ARMv7 (Cortex) CPU... Kompatibilita ako remen, co ?

SIMD vice mene muze pouzit vsude kde opakujes nejakou cinnost nad polem bez overheadu. Jenze to bud nejde jako v pripade C#/Javy bez volani nativniho kodu, nebo je to naroubovany prez assembler a makra jako v pripade C++. Az nekdo prijde s nejakou user friendly implementacej budou vsichni hrozne vdecny a treba se to i zacne pouzivat

C# SIMD (konkretne SSE) bez volania nativneho kodu.

Kód: Vybrat vše

using Mono.Simd;
...
Vector4f a = new Vector4f (1f, 2f, 3f, 4f);
Vector4f b = new Vector4f (0.5f); 
Vector4f c = a * b;

C++ intrinsics su uplne primitivna zalezitost, ktoru triumfne uz len sposob zapisu v C#, ktory som uviedol hore. Ak programator vyzaduje este primitivnejsi sposob ako ponuka C++, tak to by sa do riesenia tychto performance critical casti vobec nemal pustat, lebo je velmi velka pravdepodobnost, ze to len pokazi. (ak je niekto copy&paste master a nerozumie, co vlastne robi)

DOC_ZENITH: kam by mal MS utekat ? Noze spomen tu ultra speci architekturu, ktora realne moze zajtra nahradit x86 (_64) a jej vyhody. Samozrejme vyhadzat vsetky nepotrebne legacy instrukcie pre 16bit a 32bit mod by (zrejme) zretelne zjednodusilo dekoder a par dalsich casti, ale naco sa potom amd s*alo s x86 rozsirenim, ktore si zachovava full rychlost aj s legacy kodom ?

Moj nazor je, ze prave naopak este rozsirit x86-64. Doplnit instrukcie na nasadenie alternativy x87. Kedze v 64bit mode mame k dispozicii 16 GP registrov, tak preco do nich nestrkat priamo "floaty", ale kopirovat ich to stredovekych x87 registrov ? Kolko aplikacii vyuziva 80bit vysledky x87 instrukcii ? Pripadne by bolo mozne do GPR ukladat aj vysledky existujucich x87 instrukcii so zachovanim "spravneho" zaokruhlovania ako pri povodnom x87 (to by ale musel takto poriesit prekladac aby sa to nesnazil vkladat do x87 reg).

Nerozumiem akym sposobom by mohla ina architektura ovela rychlejsie riesit flow control a pocitanie skalarov - ved dnesne CPU v alu nic ine nerobia. Kto v dnesnej dobe pise algoritmus typu "nasobenie matic"(transformacie 3d objektov / render / kodovanie av) bez pouzitia rozsireni*, tak si zasluzi odtat ruky. Tam nepomoze ani nova architektura, za ktoru by autori dostali 10 Nobelovych cien.

*na 32bit floaty staci dnes uz prehistoricky SSE (ved je vyse 10 rokov v CPU) - tak nech ma nikto neserie, ked zbadam "vcera pisany" kod a v nom pekne krasne v cykle pod sebou 3x prip. 4x kod generujuci x87 instukcie (prepocet v priestore) a nasledne stale na forach citam, ake je x86 "nedobre".

Osobne vidim jedinu moznost ako hromadne popularizovat nasadzovanie novych rozsireni x86 je urobit spolocnu skupinu kniznic, ktora sa bude v programoch pouzivat ako c++ intrinsics a na vykonanie pouzije vzdy najrychjelsiu dostupnu instrukciu(instrukcie), alebo pred vykonavanim "prehnat" instrukcie programu cez "JIT prekladac", ktory bude priamo v OS a ak narazi na instrukciu nepodorovanu v CPU, tak ju nahradi "legacy instrukciami". V podstate nieco ako mikrokod na urovni OS. Presne takto funguje po prelozeni kod, ktory som uviedol v tomto prispevku (akurat, ze sa nejedna o OS, ale Mono JIT compiler)

[yuri.cs]

AVX je tu uz od uvedeni SB ale realne vyuziti/prinos je skoro 0 (prozatim). Myslim ze takovemu slabemu cpu jako Jaguar bude podpora AVX uplne na prd,to same u Atomu.Bude se to akorat dobre vyjimat v urcitych benchmarcich...

Bez velke penetrace trhu HW je pachteni se SW naprosto zbytecne. Jake procento trhu ma aktualne SB a IB (a FX)?

Dokud nebudou AVX standard od mobile po workstation, tak se situace nema sanci zlepsit. Je fuk, ze pak aplikace na mobile casto brutalne pohori, ale binarka pujde spustit.

Jak tu nekdo spravne zminoval, vnuceni jenom SSE(2) jakozto minimalnich pozadavku SW je casto spojeno s peknou panikou...

//Vyhazovani 16b a 32b modu tu uz jednou bylo. Vysledek nic moc.

[zumpar1234]

Desktop je x86only, ale Metro je x86/ARM (co spustíš pod Metrem na x86, to také spustíš na ARM).

Ako je táto kompatibilita dosiahnuta? Ako možu dve nekompatiubilne procesorove architektury spustit rovnake programy?

[DOC_ZENITH]

Easy, všechny metro appliance budou jen přes store microsoftu a kdo je tam chce dát, bude must uvést verze pro obě platformy.

[ttxman]

Ono je hezky, ze je x86 zastarala, ale ze by nekdo rek jak zastarala, nebo jak to resit to ne. Je dulezity si uvedomit, ze v dnesnich CPU bezi x86 instrukce vlastne na HW emulatoru.
Kdyz se tu resi ten single thread vykon tak na trhu neni ani naznak neceho potencionalne vykonejsiho nez x86-64 architektura.

ARM je super do doby nez zacnete intenzivne pouzivat FPU - tedy obdobu x87 instrukci a spominane 64bitove instrukce zatim nema.
Spotreba je taky super, ale dosazena nizkou frekvenci a blokaci jakykoliv modularity (podobne jako v atomech a bobcatech "umi jedno casovani pameti a musi to stacit" atd.. nalepite si periferie dovnitr cipu na relativne pomalou AMBA sbernici, uzpusobite cip tak aby to stihalo a hotovo. S necim jako PCI-Ex16 3.0 nejde vubec pocitat, jelikoz radic stihajicit ty prenosovy rychlosti je hrozne nenazranej a kdyby se to k armu prilepilo tak uz nebude uspornej.

Sunovsky SPARC vubec nema cenu resit ma 1 FPU a 2INT jednotky na 8 vlaken, vsechny s vektorovejma isntrukcema. Vykon je postavenej na optimalizaci programu a moznosti vsech vlaken na CPU sdilet registry, takze dokaze paralelne vykonavat i nekolik instrukci bez ztraty rychlosti na rezii.(softwarove rizeny zpracovani vic instrukci najenou) K tomu je ale nutna podpora v programovacim jazyce pripadne spolehat na kompilator. FPU jednotka je siroka 1024b (kam se hrabe AVX). Kdyz neoptimalizujeme x86 kod tak tohle nema moc sanci.

Itanium in order zpracovani instrukci + extremni pripad VLIW 128bit instukce (seskupeni az 6 po sobe jdoucich operaci do 1 instrukce) aneb softwarove rizeny in-order zpracovani instrukci. Vykona zase stoji na kompilatoru a optimalizaci programu.

Cell - vysoky pocetni vykon za cenu 2 ruznych instrukcnich sad v 1 CPU a az 8(1C1T) + 1(1C2T) jader v 1 CPU, 128b vektorovy vypocetni jednotky. Softwarove rizeny branch prediction (dalsi zesloziteni kodu). Zase strasne slozity programovani.

Vsechna konkurence x86 ma vykon za cenu zesloziteni programovani a optimalizaci primo na miru konkretnimu CPU obsahuje vektorovy vypocetni jednotky a spoleha na paralelni zpracovani kodu. Jediny co maji vsichni navic jsou vetsi pocty registru dostupny jednomu vlaknu, jenze registry navic jsou i v x86-64 a to se vlastne taky nepouziva, her co by mely 64b build je minimum.

Problemy softwarovejch optimalizaci se jakoukoliv jinou stavajici architekturou jenom zvetsujou: Branch prediction a rizeni vyuziti konkretnich casti CPU pada na programatora, vektorovy jednotky atd. Single thread vykon nijak neoslnuje. Kdyz se dneska nedelaj na x86 CPU jednoducha optimalizace nemuzeme cekat ze by se zacali se zmenou architektury delat ty slozity.

C# SIMD (konkretne SSE) bez volania nativneho kodu.

Jo sem nekde snad zminoval, ze to mono ma. Bohuzel je to mono specificky, microsofti .NET framework tu knihovnu neoptimalizuje a nepouziva na nic SIMD instrukce (teda pokud JIT kompilator neusoudi, ze by to zrovna mohlo fungovat).

C++ intrinsics su uplne primitivna zalezitost, ktoru triumfne uz len sposob zapisu v C#, ktory som uviedol hore. Ak programator vyzaduje este primitivnejsi sposob ako ponuka C++, tak to by sa do riesenia tychto performance critical casti vobec nemal pustat, lebo je velmi velka pravdepodobnost, ze to len pokazi. (ak je niekto copy&paste master a nerozumie, co vlastne robi)

Ano a ne. Neni to podpora promo v jazyce, takze se to kompilator od kompilatoru lisi (aspon teoreticky, gcc implementuje ty intelacky jak ostani to netusim). Prevazne volas jenom prejmenovany instrukce inline assembleru jsete s hnusnou __syntaxej. Ja bych to chtel pouzivat jako v "mono.simd" nebo mit primo v jazyku konstukce na vektorovy vypocty a ne volat nejaky makra, aby se to obevovalo v priruckach typu pro stredne pokrocile, aby se o tom vedelo a ne abys musel shanet specializovanou literaturu jenom kdyz chces videt aspon zminku.

Desktop je x86only, ale Metro je x86/ARM (co spustíš pod Metrem na x86, to také spustíš na ARM).

Ako je táto kompatibilita dosiahnuta? Ako možu dve nekompatiubilne procesorove architektury spustit rovnake programy?

No prevazne tim, ze vsekrej kod beha na .NET frameworku. Jakejkoliv nativni kod bude muset bejt na obe platformy zvlast nebu nebude na marketu na obou videt.

[zumpar1234]

ttxman: Aha takze jednoduche programceky budu behat na oboch vdaka "web technologiam" a nieco slozitejsie(ten nativny kod) co si zaziada aj vykon co ja viem napriklad WinRAr pre metro ktory bol ohlaseny bude vyhotoveny pre kazdu architekturu zvlast?

[froxic]

Ano chápeš to dobře.

OT:Prostě nestal se žádný zázrak a Windows 8 je pro mě v tomto ohledu fail. Místo aby více sjednotila, tak bude více schizofrenní než kdy dříve. ARM bude omezen pouze na metro aplikace a "desktop Win32 aplikace na tom nepůjdou". Takže mě napadá otázka – A není už v tom případě lepší Android nebo iOS, který sedí ARM daleko více? Aplikací je tam fůra a věřím, že ty v metru nebudou ničím úžasné./OT

[ttxman]

Ano chápeš to dobře.
OT:Prostě nestal se žádný zázrak a Windows 8 je pro mě v tomto ohledu fail. Místo aby více sjednotila, tak bude více schizofrenní než kdy dříve. ARM bude omezen pouze na metro aplikace a "desktop Win32 aplikace na tom nepůjdou". Takže mě napadá otázka – A není už v tom případě lepší Android nebo iOS, který sedí ARM daleko více? Aplikací je tam fůra a věřím, že ty v metru nebudou ničím úžasné./OT

Neni to schizofreni, API sedi, kod se pise jednou, kompiluje 2x viz niz. Jenom meli vydat windows pro ARM a pak s velkou slavou pridat podporu spousteni na desktopu a nikdo by tak moc nenadaval.

ttxman: Aha takze jednoduche programceky budu behat na oboch vdaka "web technologiam" a nieco slozitejsie(ten nativny kod) co si zaziada aj vykon co ja viem napriklad WinRAr pre metro ktory bol ohlaseny bude vyhotoveny pre kazdu architekturu zvlast?

Tak on dobre napsanej kod v .NET nebezi vyzname pomalejc nez v c++. (pri pouziti unsafe kodu jsou snad jedinou vyhodou C++ kouzla s templatama a inline assembler)

API windows RT je na obou platformach shodne, pokud budes mit vsechny dll knihovny taky pro obe platformy tak v nemusis zasahovat do kodu jenom to zkompilujes na ARM a x86. Problem nastava az pri pouziti inline assembleru pripadne mozna SIMD rozsireni (i kdyz u tech bych rek, ze bude v kompilatoru nejakej fallback pro platformu ktera je nepodporuje), kte ty casti kodu musis napsat 2x.

http://blogs.msdn.com/b/b8/archive/2012 ... cture.aspx

[zumpar1234]

OT: Tak osobne som toho nazoru ze najelegantnejsie riesenie z pohladu zakaznika by bolo prestat s oblbovanim ludi a zacat prezentovat skotočny stav. Napriklad Metro ako samostatny mobilny OS( Metro OS). Elegantne jednoduche prehladné. Nie napcha sa este aj metro do desktopu kde aspon na mna pôsoby ako päsť na oko.

Inak dik za odpovede.

[DOC_ZENITH]

Ano chápeš to dobře.
OT:Prostě nestal se žádný zázrak a Windows 8 je pro mě v tomto ohledu fail. Místo aby více sjednotila, tak bude více schizofrenní než kdy dříve. ARM bude omezen pouze na metro aplikace a "desktop Win32 aplikace na tom nepůjdou". Takže mě napadá otázka – A není už v tom případě lepší Android nebo iOS, který sedí ARM daleko více? Aplikací je tam fůra a věřím, že ty v metru nebudou ničím úžasné./OT

Neni to schizofreni, API sedi, kod se pise jednou, kompiluje 2x viz niz. Jenom meli vydat windows pro ARM a pak s velkou slavou pridat podporu spousteni na desktopu a nikdo by tak moc nenadaval.

ttxman: Aha takze jednoduche programceky budu behat na oboch vdaka "web technologiam" a nieco slozitejsie(ten nativny kod) co si zaziada aj vykon co ja viem napriklad WinRAr pre metro ktory bol ohlaseny bude vyhotoveny pre kazdu architekturu zvlast?

Tak on dobre napsanej kod v .NET nebezi vyzname pomalejc nez v c++. (pri pouziti unsafe kodu jsou snad jedinou vyhodou C++ kouzla s templatama a inline assembler)

API windows RT je na obou platformach shodne, pokud budes mit vsechny dll knihovny taky pro obe platformy tak v nemusis zasahovat do kodu jenom to zkompilujes na ARM a x86. Problem nastava az pri pouziti inline assembleru pripadne mozna SIMD rozsireni (i kdyz u tech bych rek, ze bude v kompilatoru nejakej fallback pro platformu ktera je nepodporuje), kte ty casti kodu musis napsat 2x.

http://blogs.msdn.com/b/b8/archive/2012 ... cture.aspx

Pokud budeš psát kód jednou a to aby fungoval na jiný architektuře zajistíš pouze tím že "použiješ jinej kompilátor" tak to je typickej případ moderního programování, ala optimalizace bude naprosto nulová a situace se oproti té dnešní, co se týče využívání výkonu HW, ještě zhorší.

[del42sa]

Pokud budeš psát kód jednou a to aby fungoval na jiný architektuře zajistíš pouze tím že "použiješ jinej kompilátor" tak to je typickej případ moderního programování, ala optimalizace bude naprosto nulová a situace se oproti té dnešní, co se týče využívání výkonu HW, ještě zhorší.

při současném přístupu programátorů to tak zřejmě bude vypadat Na druhou stranu Microsoft bude mít velký zájem na tom, aby uživatelé obou verzí OS byli spokojenými uživateli, čili minimálně u takových základních/zásadních aplikací jako je Office,IE Prohlížeče, Mailoví klienti,Antivirové programy,to určitě bude fungovat dobře. Jak budou fungovat ty ostatní bude záležet jen na tom jak dobře budou překompilované/optimalizované pro jednotlivé platformy.

[ttxman]

Obecne k tomu jak pridat podporu SIMD do programovacich jazyku:
Stacilo by pridat vektorovy instrukce ala matlab ".*" pro nasobeni prvek po prvku atd. A par novejch datovejch typu na "saturovanou" matematiku, pripadne vektory a hned by to bylo daleko lepsi. Komplikovanejsi instrukce nechat jako funkce/metody/makra, ale bylo by to nutny protlacit ve vsech nejpouzivanejsich jazycich jednotne. A tomu by se ted melo asi nejvic venovat AMD, jelikoz tem by to nejvic pomohlo. Navic by pak chytrejsi kompilator treba moh pouzivat i integrovany GPU.

Pokud budeš psát kód jednou a to aby fungoval na jiný architektuře zajistíš pouze tím že "použiješ jinej kompilátor" tak to je typickej případ moderního programování, ala optimalizace bude naprosto nulová a situace se oproti té dnešní, co se týče využívání výkonu HW, ještě zhorší.

minimálně u takových základních/zásadních aplikací ja...

Vyuzivani vykonu bude naprosto stejny jako dneska. Fakt nevim proc by se to melo zhorsit. Ve chvili kdy zacnes optimalizovat vykon budes mit podstatne vic prace, kdyz nebudes optimalizovat zadna ztrata, zadnej zisk.
Kdyz dneska vetsina desktopovejch aplikaci neni nijak optimalizovana tak mozna jeste budem z ARMu tezit, jelikoz tam to bezi pomalejc, tak se treba bude vic vyvojari vic snazit minimalne pri navrhu programu.

[webwalker]

Já tedy nevím, ještě jsem Win8 nepoužil, ale dle mého tady došlo k nějakému šumu.

Dle mého:
Pokud budete programovat pro Metro v "Managed Code" tedy klasicky HTML a Javascript nebo C#,VB a MFC bude kompilace (nebo spíše hotový instalační balíček) použitelný jak pro x86, tak také pro ARM. Nejedná se o klasický do binárky zkompilovaný soubor. Takto se bude dělat 99% aplikací.

Pouze v případě, když budete chtít využít nativní kód C++ (který by mohl přistupovat přímo k HW), budete muset provést kompilaci zvlášť pro x86, x64 a ARM.

Vše ostatní by imho nedávalo mnoho smyslu

[DOC_ZENITH]

MS měl vždy velkej zájem a jeho největší OS projekt ever (Vista) epic failnul stejně. ARMy jso uděsně slabé, slabší jak Atomy, programy tvořené tímto stylem na tom poběží jak hovno, neni to jak desktop Pv kde portnutá verze transport tyconu do flashe potřebuje Core2 duo 2Ghz a originál jen dobře na 486 DX4 100Mhz, a nikomu to nevadí (alespoŇ ne běžnejm uživatelům co nevědi co se děje) protože ty CPU maj prostě takovej výkon že se to ňák prorve. Tahle strategoe u ARMu nepůjde použít protože je moc slabej aby cokoliv prorvával hrubou silou, má problém operovat dobře i s optimalizovanemy softem (viz jak "nádherně" běhá android a jeho aplikace). Takže to bude buďo naprosto useless asi jako ty čínské tablety, nebo se vše bude optimalizovat pro ARM a pro deskto pse jen použije jinej compiler a bude se počítat s tim že tam je HW tak silnej že je to fuk.

Ale pak jsou tu zase x86 tablety, které se svym atomem tohle nedaj.

Takže tak či tak to někde bude drhnout a že by si MS dovolil to nechat drhnotu na jedné z platforem Intelu? No.... ehm...

Podle mě se akorát rozšří chaos, BFU uživatelné nebudou chápat rozdíly, dvojí ovládání u desktopových OS, a pro MS toto bude další epic fail. Celé win jsou psotavené na zpětné kompatibilitě a na tom že si něco nahraju na disk a spuspim to. Ňákej Microsoft store? Na to sere pes, to už si ty BFU raději koupěj Apple kde ten ekosystém funguje lépe. Už vidim lidi používat MS store u desktopu a používat Metro aplikace na desktopu pheh.... jo to určitě.

Tohle celé staví na propojení desktopového a mobilního OS, kterej MS nemá. Má defakto nulové zastoupení na trhu, vše ovládá Apple a Android, nepočítám li pomalu umírající Symbian a Blackberry. MS tam nemá nic krom 2 telefonů Nokie. To čekaj že se to najednou prosadí a rozšíří? Kor u lidí co se už třeba naučili užívat Android ři IOS? Na to už je pozdě, ti těžko přejdou na "windows RT".... MS s timhle přišel jednak špatně a druhak pozdě.

Co jsem testoval win8 tak mam řadu + pro ten systém a jedno velké -.

+ Univerzální kernel, konec nebootujícího OS/reinstalů při změně platrofmy což začalo s winXP.
+ Vylepšený scandisk.
+ Vylepšený task manager a explorer.
+ konec klasického Aera, deskop design je lepší.

- Metro a vše s tím společné. Naprosto heorzná věc, multitasking-unfriendly, user-unfriendly, olvádání myší a klávesnící je v tom naprostá tragédie, cpe ti to do držky věci co nehcceš, budou tam i reklamy. Všechny aplikace pro to budou z MS storu, tudiž o to nemam zájem už vůbec.