Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Hm, tak to teda hodně štěstí. Vůbec netuším, proč a pro jakou aplikaci bych měl v dnešní době chtít ARM server. Jedna věc se x86 upřít nedá - v "malých" serverech je to bomba - za pár korun železo, klidně dva-tři fyzické nody clusteru pro failover, na něj hypervisor, do něj pak klidně pět - deset virtuálů a celá firma je pořešená.
Ale co s ARMem? Jako že bych to měl rychlejší, úspornější, pěknější, nebo co?
myslím, že tou hlavní výhodou by byl poměr výkon/spotřeba.
...za předpokladu, že se x86 nebude vyvíjet ;)
Já mám spotřebu na jeden server (virtuální) okolo 12W (100W/8 serverů), kam si asi tak představují, že to dostanou? Navíc mi tam ještě běží jedny Windows, to bych taky nepodceňoval.
no muj raspberry ma 2.5W..
...ještě napiš kolik ti na těch 2.5w běží virtuálů a kolik windowsů :D
byla tu rec o 12W/virtual. Ja mam fyzicky stroj = virtual = 2.5W, skoro petinu spotreby. Na primerene navstevovany web to staci. Windows hosting nepotrebuji, co bych s nim delal..
Tak to gratuluju. No a teď si představ, že někomu nevydělává linux, ale wokýnka - to jsou paradoxy co?
Takhle se to přeci počítat nedá. Efektivita se vyjadřuje poměrem výpočetní výkon/spotřeba a nikoliv počet (neznámo jak vytížených) serverů/spotřeba.
Souhlas, cílem bylo demonstrovat, že i na x86 se dají provozovat servery s nízkou spotřebou. A co se týká efektivity, docela bych se divil, pokud by arm o stejném výkonu žral méně, než Xeon, v poslední době se riscu moc nedaří něco ukázat
Třeba takový CDN server na spouuuuustu malých požadavků, nebo Memcache server, teda v případě, že by procesor měl hodně jader a velké množstžví připojitelné paměti.
Nebo proxy server, opět obsluha spousty malých požadavků. Nebo load balancer, který taky musí obsloužit mraky požadavků, ale nepotřebuje na to brutální výkon, protože o zpracování se postará jiný server. Aplikací se dá najít dost. Specielně v dnešní době globálních i firemních cloudů.
No jo, ale proč pro to pořizovat samostatný hardware? Konkrétně u toho proxy mi to přijde jako úplná blbost, proxy přilepím ke kterémukoli serveru jako samostatný virtuál s prstem v nose.
Až bude potřeba aby zvládala 10 000 requestů za minutu nebo vyšší čísla, tak bude mít ten virtuál prst v nose tak hluboku, až se z toho položí. Všechny příklady co jsem uvedl jsou masivně paraelní věci, kde spousta jednodušších jader, kde je velký potenciál na to, aby měli lepší poměry pořizovací ceny, počtu vyřízených požadavků a spotřeby.
Chtel bych se zeptat, jako amater - pokud budu kvuli vykonu nucen navysovat pocet jader, nebudu take zvysovat spotrebu? A jak jsem to pochopil, hlavni vyhoda ARMu je prave spotreba/vykon.
Samozřejmě, že se při zvýšeném počtu jader zvýší i spotřeba nicméně, spotřeba jednoho jádra ARMu je naprosto jinde, než například jednoho jádra Intel procesorů, tudíž při masivně paraelním zatížení je efektivnější mít vícero jednoduších výpočetních jednotek než jednu složitou super rychlou. Samozřejmě to záleží na tom co je to za task a architektůře. Proto se mimo jiné i dělají servery stavěné na atomu, jestli se nepletu, tak je právě dělala ta firma, kterou koupila AMD a teď podobné věci staví na AMD procesorech.
Třeba Google používal nebo používá dvouprocesorové/24 jádrové servery od AMD jako memchache servery, díky více jednodušším jádrům a velkému množství paměti, které ten procesor umí využít.
Ty, já ti nevím, nikdy jsem nic takového nestavěl, ale na proxy s 10 000 requesty za minutu mi z dnešního pohledu nepřijde ARM jako úplně dobrý nápad... (A nechtěl bych být u šéfa na koberečku a vysvětlovat mu, že jsem to koupili, protože to má o 20W nižší spotřebu. :-) Ale třeba to za 3 roky budu vidět jinak.
Držím palce.
Jeste je dobry pripomenout, ze uz v dobe predstaveni APU, coz byla Fusion konference 2011, tam mel jedno z nejlepsich keynote prave reditel ARMu, takze to mohly obe firmy drzet pod poklickou docela dlouho. Jinak ARM musi rechtat blahem, protoze co si budem povidat, AMD mozna nestiha na Intel, ale proti vetsine vyrobcu ARMich SoC ma knowhow o rad jinde. Pokud se ARMu bude v serverech darit, tak bude potrebovat veci jako rychly radice pameti nebo HyperTransport ... jaka nahoda, ze oboji AMD uz davno umi.
Původně ohlásili jen SW partnerství (resp. společnou podporu vývoje softwaru pro heterogenní systémy - důsledkem pro AMD je snad i AppZone), poté Read začal přesvědčovat hlavouny, že by mohli začít spolupracovat, ještě nějakou dobu to AMD oficiálně vyvracela, ale interně imho mohlo padnout rozhodnutí už začátkem prosince 2011.
RISCové serverové procesory. No jen si to představte!
Tos zabil :D
Tak to je cesta do pekel!
Ikdyz si myslim, ze to nebude tak horke, spis pujde o nejake jednoduche reseni na ty podelane cloudy a ostatni <|>viny, kde zadny vykon neni potreba.
Jako kdyby tu mela vyrust druha platforma, tak to by bylo fakt na posrani. Cele roky platformy chcipaly na ukor x86 a je to tak pochopitelne spravne a ted by mela prijit dalsi nova platforma? Tomu moc neverim, z evolucniho hlediska je to totiz uplne spatne.
Kdyz uz i Intel zacal kafrat do mobilu, treba RAZR i, ktery ma udajne stejnou vydrz jak jeho ARM dvojce, ale o rad vyssi vykon .... tak pochybuju, ze tohle Intel dovoli. Cele je to jenom o tom, ze Intel je/byl neefektivni, dlouhe roky nehledel na spotrebu. Stacilo zapracovat na architekture, suspend modech atd ... a ejhle, umi byt stejne efektivni jak ARM ..... s tim rozdilem, ze kdyz chce, tak umi byt o 3 rady rychlejsi a navic vzhledem k tomu, ze je x86 kompatibilni, tak moc konkurence v ARM nema ...
Je blbost, myslet si, ze Intel uz davno nema vyvinuto pro 3 generace dopredu .... je jen otazka casu, nez vyda ARM zabijaka pro masy.
Co me ale trochu desi, ze MS zacal podporovat ARM .... dnesnimu facebookovemu stadu staci jen prohlizec, takze by mohli na desktopu x86 klidne zatopit. Ikdyz je zase fakt, ze tam na tech RT asi nepujdou intalovat aplikace nativne pro ARM, takze se minimalne na Windows nestane, ze by nekdo zacal delat aplikace x86 nekompatibilni.
Kazdopadne je ale potreba drzet ARM, tam kde patri ..... v propadlisti dejin a na nevykonnych facebookovych frontendech ..... jak se zacne spekulovat o pseudoserverech (byt jen radic na cloud) nebo nedejboze o desktopech, tak se toho jeste nejaky trotl chyti a bude pruser na svete ......
a proč myslíš že Itel tolik tlačí na rychlé uvádění nových výrobních procesu ala 22nm Tri Gate a nižších ???
> Kdyz uz i Intel zacal kafrat do mobilu, treba RAZR i, ktery ma udajne stejnou vydrz jak > jeho ARM dvojce, ale o rad vyssi vykon
to je pekna blbost. Ten vykon je v radu procent a druha vec je, ze na stejne frekvenci je ARM rychlejsi. RARZ M ma 1.5GHz ARM, RAZR i ma 2.0GHz.
Je rychlejsi .... navic je jednojadrovy. U ARM nahrazujou vykon poctem jader, coz umi kazdy dement a x86 k tomu zacala sahat teprve nedavno, ale ARM tim prakticky zacina, protoze uz nema kam rust.
Jediny dulezity faktor vykonu procesoru je vykon v jednom vlakne, vse ostatni se da multiplikovat. Ikdyz je mozna 4 jadrovy Galaxy S3 teoreticky v hrube sile o neco rychlejsi nez tenhle 1 jadrovy, tak tenhle 1 jadrovy bude v podstate realne skoro 4x rychlejsi, protoze se vse (ani nahodou) neda paralelizovat. A jak jsem cetl nejaky clanek o andoidu, kde mu system i gui bezi v jednom vlakne (proto je to takove zdechle a furt se to seka, nezavisle na CPU), protoze to blbe navrhli, tak tam je vysoky vykon jednoho vlakna naprosto krucialnim pozadavkem.
Kazdopadne tu mame WP8, ktere snad vyjdou i s nejakym Intelem, takze se mame na co tesit:)
Netrpelive cekam na asymetricky cip ve stylu 2x x86 jadro a 32x ARM jadro. Kazda aplikace by se prelozila pro tu architekturu na kterou vic pasuje. IMHO nejlepsi reseni situace, kdy kazda ta architektura ma sve vyhody a nevyhody ...
a mimochodem, x86 je ta nejhorsi architektura, co existuje.. staci sledovat, jak se s ni Intel (a pripadni jini) musi prat, emulace x86 kodu na hradlovem poli, hromada operacnich rezimu (x86 (16bit, 32bit), x86_64, real mode, protected). Naopak bych byl mnohem radeji, kdyby x86 chciplo uplne a prosadila se cista RISC architektura.
Ke vsemu dnesni CISC x86 CPU jsou interne resene jako RISC stroje s prekladem na mikro instrukce... mozna by stacilo zariznout vsechny vcerejsi mody a nechat jenom nativni 64bit real :-)
To nejde. Nativni 64bit mod x86 CPU ma prilis dlouhe instrukce a umoznuje obejit HW oddeleni kernelu od aplikaci. Ale urcite by se dala navrhnout instrukcni sada, u ktere by se vetsina instrukci prekladala 1:1 a tudiz podstatne rychleji. Mysleno vetsina podle pouzivani, je jedno kolik "ostatnich" instrukci bude pomalych kdyz se pusti 4x pri bootu a pak po celou dobu behu systemu nebudou zapotrebi.
RISC je mozna usporny, ale v dnesni dobe (kdy casto komplexni instrukce ma stejny throughput jako jednoducha) ma velke vykonnostni omezeni. Pro vykonne CPU je mnohem vyhodnejsi CISC, kteremu k vyssimu vykonu postaci prihodit par tranzistoru a udelat rychlejsi implementaci nejake instrukce. Naopak RISC k tomu potrebuje vyssi paralelizaci provadeni instrukci, coz je velice slozite, ba temer nemozne.
Samozrejme, ze x86 by nejake drobne procisteni potrebovalo, ale neni to takova hruza - spis to zeslozituje vyvoj a testovani, nez ze by to byla nejaka velka brzda.
Tak tak, RISC je potřeba chápat jako nápad ze sedumdesátých let, kdy bylo hlavním problémem procesorů "to vůbec vyrobit". Pro dnešní technologie je x86 vlastně takový bytekód, u kterého je naopak potřeba dodat ještě komplexnější instrukce pro určité typy úloh.
Ano to je pravda, dnešní x86 si drží v pipeline komplexní strukturu instrukce co to jen jde, ale zrovna v tomhle případě úsporných cpu se tahle výhoda zas tak neprojeví. Dnešní Atomy mají propustnost "pouze" dvou instrukcí a k tomu x86 složité a žravé dekodéry.
Dokud Atomy nebudou vybaveny novou uarch, budou imho hrát v tomto segmentu druhé housle a to jak výkonem, tak hlavně spotřebou.
Nerekl bych, ze je to pravda. "Vypocetni" sila runtime CPU vs. kompilace/optimalizace prekladace hraje v neprospech CISC. Kompilator ma mnohem vetsi sanci vyrobit lepsi kod nez emulatory na CPU, ktere navic ten kod musi emulovat znova a znova (modulo Intel L1 cache, ktera drzi mikro instrukce misto instrukci), takze aplikace ma vetsi sanci bezet energeticky usporneji na CPU, ktery ji nemusi z CISC instrukci "emulovat".
A nevidim nic nemozneho v tom, aby kompilator vyrobil kvalitni kod pro RISC, rekl bych, ze VLIW architektura je na tom mnohem hur a presto existuji vhodne kompilatory i tam. Naopak ma kompilator vetsi sanci vytvorit dobry kod, kdyz bude prekladat jazyk vysoke urovne primo na mikroinstrukce daneho procesoru.
Jednu nevyhodu spatruji v tom, ze aplikace pak je kompilovana na miru konkretni generaci CPU a pro novou generaci by bylo mozna nutne provest novou optimalizaci. Kdyz tohle dela CPU, tak se to muze lepe prizpusobit.
Ty to píšeš, jako by pro x86 kompilátory byly optimalizace zakázané a RISC si do jednoho bytu cache ukládal instrukce po třech. :-)
No pokud kompilator x86 preklada jen do x86 kodu, tak se ho muze nejak snazit optimalizovat, ale pokud CPU dela dalsi preklad x86 kodu do mikroinstrukci, nemusi byt to, co vyprodukuje kompilator, to nejlepsi, pokud a) nezna detaily o prekladu do mikroinstrukci, b) ten x86 kod muze "zavazet" protoze primo pomoci mikroinstrukci by kod sel udelat lepe v cemz ma prave vyhodu cisty RISC, ze uz nema v ceste dalsi emulacni vrstvu.
Zase to píšeš, jako by kompilátory nesměly hledět na výsledný mikrokód, přitom jak se to nakonec rozpadne a kolik to bude potřebovat cyklů je dopředu známá věc. Kompilátor sice výsledný mikrokód neprodukuje, ale to neznamená, že vůbec nemůže jeho kvalitu ovlivnit - proto jsou tam ty přepínače pro jednotlivé cílové procesory.
Emulatory ? Naprosta vetsina bezne pouzivanych x86 instrukci je v modernich CPU primo zadratovana v execution pipeline (pripadne jejich znacne casti) a nepotrebuji vic nez 2 mikroinstrukce (typicky instrukce s pametovym pristupem). Jen velmi malo raritnich a slozitych instrukci je mikrokodovanych (zejmena x87 FPU). Naopak, spousta funkci se na RISC v podstate musi neefektivne "emulovat" kompilatorem, protoze na ne neni instrukce.
Priklad: x86 instrukce MPSADBW, ktera ju dulezita pro prevod videa, rozpoznavani obrazu atd. se na i7 provadi v jednom taktu (s latenci 6 taktu). Cisty RISC na stejnou funkcionalitu potrebuje desitky instrukci. Podobne je to napr. s AES, stringovymi instrukcemi (SSE4.2), instrukcemi pro hashovani, kontrolni soucty, skalarni soucin, brzy pribude Gather ...
Samozrejme, ne vzdy je to takhle extremni. Ale zakladni idea je - pokud CPU (RISC) provede v jednom taktu 3 jednoduche instrukce, zatimco jine CPU (CISC) provede v jednom taktu 2 komplexni a jednu jednoduchou instrukci, tak je jasne, kdo je vitez. Samozrejme, ze RISC bude uspornejsi (lepsi vyuziti zdroju, jednodussi dekodovani), ale nebude nikdy rychlejsi, protoze bude muset zpracovat mnohem vic instrukci. Navic treba Haswell uz pry bude umet vypinat nevyuzite casti pipeline, takze i tady se to vyrovnava. RISC jde zrychlit jen vyssi frekvenci, nebo masivnejsim out-of-order, ale oboji je velmi problematicke a energeticky narocne.
A co se tyce te cache, tak tam to pro RISC se stejne dlouhymi instrukcemi (typicky 32b) taky nevyzniva nejlepe. Nejcasteji pouzivane x86 instrukce jsou kratsi a tim zabiraji mene mista v cache.
Slabinou CISC jsou prave kompilatory, ktere moc neumi vyuzivat ty komplexnejsi instrukce, ale to se da dohnat rucni optimalizaci a vhodnymi knihovnami.
za emulator povazuji preklad jedne CISC instrukce byt na 2 mikroinstrukce. preklad je proste emulace.
Co se tyce SIMD, tak Arm ma, pokud vim, v nekterych verzich NEON rozsireni a vektorove jednotky, podle me se SIMD s RISC sadou nevylucuje.
A jen takove logicke cviceni, pokud se nejaka CISC instrukce prelozi na N mikroinstrukci, ktere procesor zpracuje 1 za takt, v cem presne je to horsi oproti poslani N RISC instrukci, ktere procesor zpracuje 1 za takt? A nota bene kdyz ty mikro instrukce +- odpovidaji RISC instrukcim.
Myslím, že 0xR to myslel tak, že komplexní instrukce je složena z několika mikroinstrukcí, třeba při při instrukci typu load-modify na 2uops, ale třeba také při instrukci typu load-modify-store dokonce na 3uops.
Nejsem sice znalec RISC, ale tam se jedná o load/store uarch, takže každá práce s pamětí má svou instrukci (aritmetika pracuje pouze s registrem), kdežto u CISC je již L/S zahrnuta v té komplexní aritmetické instrukci.
Pokud tedy takový dnešní x86 cpu má propustnost 4 komplexních instrukcí, jedná se vlastně z pohledu RISC o propustnost 4 - 12 instrukcí.
To opravdu nelze brat jako preklad. Nektere instrukce jsou sice rozlozene na micro-ops, ale to jsou takove polotovary tezce optimalizovane pro danou architekturu, takze je mozne jich v optimalnim pripade zpracovat 5 (Core2) - 8 (Haswell) za takt. Prakticky vsechny casto pouzivane instrukce jsou ale 1 micro-op (nektere dokonce diky macro-op fusion dokonce 0.5 micro-op), takze vas priklad neodpovida realite.
Realnejsi priklad: 3 CISC instrukce na vstupu daji 5 micro-ops, ktere se vsechny zpracuji paralelne v 1 taktu. Naopak RISC na stejnou ulohu potrebuje 6 instrukci a dokaze zpracovat 3 soucasne - takze ulohu zpracuje za 2 takty. Druhy (mozna v praxi castejsi) priklad: 3 CISC instrukce daji 3 narocne micro-ops, ktere se provedou ve 2 taktech (dve paralelne, jedna musi pockat, protoze sdili pipeline). RISC potrebuje 8 instrukci s prumernym vytizenim 2 pipelines ze tri (kvuli vzajemnym zavislostem). Vysledek je tedy hotovy za 4 takty... (pozn.: ve vsech pripadech zanedbavam latenci, ktera by mela byt maskovana ooo enginem).
Ja ale porad nevidim, v cem ma byt lepsi, ze ten preklad na mikroinstrukce z CISCovych instrukci dela samotny procesor pred tim, kdyz bude kod rovnou z mikroinstrukci, ktere se jiz takrka rovnaji RISC instrukcim.
Pro komentar vyse: x86 uz nejakou load/store jednotku ma. Opravdu je interni architektura Intel procesoru velmi blizko RISC, jen ma nad tim vsim CISC emulator. A je otazka, zda je nahodou, ze Intel zacal delat slusna CPU po koupi licenci Alpha procesoru, coz je RISC architektura. (Slusna CPU = nastupci nepovedene P4.)
Teď si nejsem zcela jist, ale nebyly (RISC) microinstrukce součástí již Pentia PRO?
Byly. A AMD K5. Vilgefortz nejspis mel na mysli, ze po koupi licence Alpha mohl Intel do svych "CISC" x86 procesoru strcit kvalitnejsi RISC jadro.
Protoze dneska uz uvnitr zadne klasicke RISC jadro proste neni. To je jen mytus. Uvnitr je 5 - 8 ruzne slozitych pipelines, ktere jsou krmeny frontendem tim, co Intel nazyva mikroinstrukce. To ale neznamena, ze tyto "mikroinstrukce" nemuzou byt velmi vypocetne narocne.
Cela vyhoda spociva prave v tehle "magii" uvnitr. P4 mel mensi mikroinstrukce a vyssi frekvence. To byl propadak, tak Core ma vetsi mikroinstrukce a nizssi frekvence. Kazda dalsi generace ma navic nove specializovane instrukce. Napred se daji jen do dekoderu a kdyz je zacne SW pouzivat, tak se v pristi generaci implementuji primo do nektere exekucni pipeline. S RISCem si takhle nevyhrajete :).
Je tu jeste jeden rozdil - "opravdove" instrukce maji vyssi rezii (nebo spis omezeni), nez mikroinstrukce. RISC by 8 exekucnich pipelines nikdy nedokazal naplnit. Mozna se specialnim kompilatorem primo pro dane jadro, ale to uz je vlastne skoro VLIW ;). Pak by cely svet musel pouzivat jen tento jeden kompilator a Intel/AMD by nemohli vyvijet nova jadra s odlisnou architekturou. Neco jako Itanium.
A porad zbyvaji specializovane instrukce, ktere nejdou jednoduse nahradit. Napr. POPCNT - instrukce co spocita pocet jednicek ve slove, prevod FP32 na FP16 (nove pridane v Ivy Bridge) atd. x86 ma dnes hodne pres 1000 instrukci a porad se pridavaji dalsi, protoze jsou pro neco potreba a neco podstatne zrychluji. RISC by musel byt radove rychlejsi, aby dokazal tyto chybejici funkce nahradit hrubou silou a to nikdy nebude.
Abych to cele shrnul: Puvodni myslenka RISC byla delat min, ale rychleji. Rychlost narazila na strop (frekvence, paralelismus), ale delat vic neni problem. Neco jako kdyz po dalnici jede auto se 4 osobami 130 km/h (RISC) a autobus se 40 osobami 100 km/h (CISC). Sice nastupovani do auta bude jednodussi, ale N milionu osob prepravite rychleji busem :).
Nemyslim ze do pekiel. Vid uspech ARM v tabletoch a smartphones
Pri vhodnej optimalizacii nevidim dovod preco by nemohol byt ARM uspesny aj v serveroch. Hlavne aby si zabezpecili kvalitnu a siroku softwarovu podporu.
Jen víc a větší kapky, jinak Intel zase usne na vavřínech...
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.