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.
Nuz doba sa zmenila. Dnes nikoho nativny kod nezaujima (teda az na specificke vecsinou okrajove systemy). Na serveroch vecsina bezi bud cez nejaky VM (java,.net a podobne) alebo interpetovy jazyk ktory aj tak sa skompiluje do nejakeho bajtkodu v pameti a potom zasa bezi nad nejakym vm (javascript, python, php a dalsie). No a na desktopoch je to podobne. Same web aplikacie alebo potom splacane aplikacie v .nete/jave. Docela by ma zaujimalo ci sa dnes este uci nieco o assemblery a nejake kompilovane jazyky. No a mobilny svet, ten je uplne inde. A do buducna to uz asi ani hry nevyrthnu. Mimo fakt narocnych aaa titulov, ktorych je aj tak mensina a vecsinou su multiplatformove (ich narok nepresahuje to co dosahuju dnesne konzole, cize staci v podsate hocijake dnesne desktopove cpu z manstreamu) vecsina hier si vystaci s hocicim a tak isto sa zacina viac vyuzivat na vypocty aj GPU. A Intel si za to moze sam. Stagnacia vo vykone, fakt prehnane ceny hlavne za vykonne cpu (xeony su dost predrazene aj ked to ma byt korporat a highend segment len ten vykon tomu vzdy neodpoveda). A tak isto samotna platforma sa moc nevyvyja. V postate aj tych par zaujimavych veci co Intel priniesol, tak domrvil. Napriklad Thnuderbolt v podstate odpisal vdaka dohode s Applom. Ani sa Googlu a ostatnym nedivim. Ale mozno to aspon nastartuje nejaku revoluciu.
Google pouziva interne ve velkem C/C++ a Go, ale pokud maji dobre napsane aplikace, tak neni velky problem odladit kod i pro Power. Koneckoncu systemove knihovny Linuxu jsou porad stejne, takze se musi odladit pametove bariery a je +- hotovo. Ty maji mozna i hotove, protoze memory model Poweru se sice volnejsi nez u x86, ale dost blizko ARMu. Pokud maji v kodu assembler, tak by meli mit i fallback ve vyssim jazyce. Klidne se muze stat, ze Power bude mit diky uplne jine architekture jina uzka hrdla nez x86.
C++ kod se na ppc64 jen preklada gcc nebo ibm xlc-ckem, ktere je propriatarni ale poskytuje vyssi stupen optimalizace pro dany HW. GCC stanadardne +100% narust vykonu per core proti x86 u C++, u xlc +130%. Nicmene v pripade Google se jedna o zcela novy pristup, P9 jsou zaintegrovany pres NV-Link s Nvidia GPU, takze ta aplikace se musi radikalne upravit, idealne prepsat. Google je zakladajicim clenem OpenPOWER, takze zrejme aplikace na CPU/GPU uz davno testuje a optimalizuje. Tyto servery jsou jiz k dispozici od 2014, jen nemaji NV-Link, ktery pak u P9 pouze zrychli komunikaci. https://developer.nvidia.com/cuda-zone
Řekl bych, že v Googlu asi opravdu budou mít zájem provozovat co nejvíc věcí v Go, takže jestli je pro ně XLC relevantní, to tedy nevím. S těmi souběžnými servery v C++ si prý taky užili svoje. Navíc toolchain pro Go je minimálně v tuhle chvíli mnohem pružnější než zásahy do GCC. A umím si představit, že Go team bude celý žhavý do nové výzvy, zvlášť když teď portují ten původní 9c-based kompilátor do Go nad SSA.
No, to je na diskusiu ze co vlastne Google pouziva. Vzhladom na to aky je Google alebo skor Alphabet velky, tak asi pouzivaju skoro vsetko. Javu - Android, Python, mozno aj nejaky ten Frotran by sa nasiel (Boston Dynamics, kedze je tam dost vedcov). Tak isto tazko povedat ake je vlastne rozlozenie serverov co do poctu a do vytazenia, sak maju kopec internetovych sluzieb - gmail, vyhladavac, reklamy, apps store a kopec dalsich veci. Dost pochybujem ze by vsetko bezalo len na c/c++.
Nezapomeňte na https://google.github.io/styleguide/lispguide.xml - kdysi koupili ITA Software. ;-)
No ved prave. Osobne si ale myslim ze v Google nebudu zrovna nejaky lumeni. Alebo skor tam panuje chaos a vela veci sa robit adhoc alebo sa to lepi docasne. Iste bude zalezat od oddelania k oddeleniu. Minimalne ale co sa tyka Androidu tak to je hnus. Chapem ze je to kupena firma a boh vie ako maju nastavne pravidla ale predsa len uz su pod Googlom docela dlho. Google stale nieje schopny vydat slusne SDK a o NDK ani nehovoriac. Pracovat s tym je niekedy fakt utrpenie a je to ako za trest.
V tomto posobi Google fakt moderne, presne ako dnesne hipsterske startup firmy. Na screenshotoch to vyzera cool stylovo ale za tym je dolepeny spaghety kod lebo sak dolezite je vydat vsetko rychlo.
No pokud dobre posloucham tu pani z Googlu, tak je jedno v cem to aktualne maji, protoze oni uz to naportovane davno maji (c: gmail, maps, youtube, atd. : http://openpowerfoundation.org/presentations/leveraging-opencompute-and-...
U Google se nejedna o virtualizaci, pouzivaji PowerNV tj. bare metal podle specificace z OCP (Open Compute Project). Krome GPU/CPU Google vyuzije i programovatelne FPGA pres CAPI rozhrani, rada novych algoritmu se takto da offloadovat a x-krat zrychlit. Nektere karty jsou zde : http://openpowerfoundation.org/wp-content/uploads/2016/04/HardwareReveal...
Intel koupil Alteru za 17mld USD, ktera delala OpenPOWER karty pro rychle pripojeni flashe pres CAPI, aktualne je nekolik dalsich firem ktere delaji to same Xiling, Nallatech atd. Toto pripojeni je podobne rychle jako NVMe.
"Dnes nikoho nativny kod nezaujima (teda az na specificke vecsinou okrajove systemy). Na serveroch vecsina bezi bud cez nejaky VM (java,.net a podobne)"
Ty ovšem dnes také generují nativní kód, takže zase říkat, že to nikoho nezajímá, není tak úplně přesné. Řekl bych, že autory těch VM implementací nativní kód (a jak ho účinně vytvářet) zajímá docela hodně.
No ano ale to je prave to. OS si dnes nepise kazdy na kolene, tak isto VM si dnes nebude pisat kazdy vyvojar aplikacii. Problemy okolo pameti (hlavne alokacie a uvolnovania), optimalizacii atd. sa presunuli od vyvojarov beznych aplikacii na firmy a ich vyvojarov co dodavaju VM (Oracle - Java, MS - .NET, Google - Dalvik/ART atd.). Ty co potrebuju optimalizovat, tak optimalizuju ale gro aplikacii to nepotrebuje. To je proste ako s ovladacmi k HW. Tak isto dnes nemusi kazdy vyvojar pri hre pisat si vlastne ovladace pre grafiku ako za cias dosu a Vesa standardov (Univbe a podobne) alebo pre kazdu zvukovu kartu (Miles sound system, dost rozsireny). O to sa postara par vyvojarov vyrobcu zvukovky, napisu driver a par ludi od MS ktory to zaobalia do API (DirectX, atd.) a herny vyvojar uz pouzije hotove API a dalej neriesi.
Takže vymění 60 let starou von Neumannovu architekturu za superskalární. Tedy jen 35 let starou. To je pokrok ve výpočetní technice...
K puvodni von Neumannove architekture ma ten Power a Intel uplne stejne daleko a superskalarni jsou taky oba, akorat ten Intel to zkousi trochu zamaskovat. Odhozeni x86 kompatibility lze sice brat jako pokrok, ale rozhodne nijak vyznamny. Tady jde opravdu jen o to, ze Google neni vydany Intelu na milost.
"Takže vymění 60 let starou von Neumannovu architekturu za superskalární."
To je asi tak smysluplná věta jako tvrzení, že nahradí červenou za kulatou. ;) Tyhle dvě věci přeci nejsou v rozporu.
"Formátem půjde o 48V server pro 48V rack."
Co je 48V rack? Nebude to spis 48U rack? Mozna bylo mysleno, ze to bude mit 48V napajeni...
Vychazi ze specifikace Open Compute Project : http://www.opencompute.org/wiki/Server/SpecsAndDesigns
48V rack - otevřený standard (Open Rack) propagovaný Googlem s 48V napájením.
Servery jsou bez zdroju a pripoji se do optimalizovaneho racku (OU) pro lepsi chlazeni nez je standardni rack (je vetsi a jinak je dimenzovane prodeni vzduchu), OCP ma standard 12V DC nicmene Google + Rackspace prosazuji 48V DC v racku, kvuli GPU.
Bolo tu pár príspevkov o tom, že pri prechode z x86 na POWER ISA by museli prekompilovať väčšinu bináriek...
Ale, je to problém?
To isté ale musia robiť pri každom novo vydanom Xeone, pokiaľ chcú aby fungoval efektívnejšie, inak by fungoval na rovnakej úrovni ako predchádzajúci (alebo dokonca horšie).
A rovnako musia prepisovať rutiny písané v assembly, pretože síce ich tam dnes už nieje veľa, ale spravidla sú na miestach ktoré nedokáže riešiť kompilátor (napríklad hypervisory), alebo kde má ručne písaný assembly kód reálny vplyv na výkon (AVX). Či už pridajú inštrukcie nové (AVX512), alebo upravia existujúce (zmena latencie, priepustnosti), tak sa musia prepísať aj rutiny ktoré ich používajú, inak nebudú fungovať optimálne. A že sa menia dosť často... spravidla, čím častejšie sa inštrukcia používa, tým vyšší tlak na jej hardvérovú optimalizáciu.
Čiže to, že je súčasný kód optimalizovaný na súčasné x86 procesory nieje argument, prečo sa držať x86, pretože prechod na inú architektúru vyžaduje rovnaké úpravy, ako prechod na novšiu verziu rovnakej architektúry. Takže to sú len kecy, ktoré majú udržať stabilné stádo oviec závislých na x86.
Pro bezneho uzivatele je to problem a proto dodnes pouziva programy optimalizovane pro Intel Pentium, rozumej to prvni. Pro Google to problem neni, protoze ke vsemu co skutecne pouziva ma zdrojove kody a programatory co to zvladnou upravit, a navic jim i "pouha" optimalizace stoji za to.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.