Vlákno názorů k článku Vlastní linuxová distribuce na Azure od vlado - Základom každej pevnej a bezpečnej stavby sú základy....

Všechno co jsem napsal jsou prostá technická fakta. Pokud je podle vás lepší systém s příšernou latency, "navržený" s BKL a bez multithreadingu, se zobrazováním X11 bez vazby na tisk, bez service manageru a hromady dalších API pro správu, s administrací primárně přes command line utility, s mizernou dokumentací a značně omezeným API, tak je problém na vašem přijímači.

Už je to CTRL+C/V z těch vyplachovacích materiálů docela nudné. Zkus něco nového.

Zobrazování X11 bez vazby na tisk?? Proč by se měl X Window System vázat na tisk, když každé dělá něco jiného a může pracovat samostatně?? Mohl byste mi to prosím objasnit, není mi to zcela jasné.

Koukněte se na Windows nebo MacOS. V obou případech na úrovni API nějakou plochu, po které kreslíte. Ta plocha může být obsah okna, nebo stránka tiskárny. Pokud chcete zobrazit dokument nebo grafiku, necháte svůj kód kreslit do kontextu okna (případně komponenty v tom okně). Pokud chcete tisknout, tím samým kódem kreslíte po tištěné stránce, a nakonec jen řeknete "stránka je hotová".
Minimálně v případě Windows exportují i drivery pro grafickou kartu a tiskárnu stejné funkce. Pokud dané zařízení něco neumí (řekněme grafická karta neumí kreslit křivky), GDI to převede na jiné operace, případně danou věc vyrastruje.

Z hlediska autora aplikace je to super, protože používá ten samý kód pro kreslení do jakéhokoliv kontextu. Z hlediska GDI i autora driveru je to také super, protože se používá velmi podobný driver model pro kreslení po více typech zařízení.

Na Unixech máte standardně na zobrazení X11lib, což je pravěká příšera, kterou měl dávno někdo popravit. Na tisk máte k dispozici leda print spooler, a obsah si musíte vygenerovat sám. A pak se nad tuhle hrůzu lepí věci jako Cairo, které má na jedné straně API se surfaces (obdoba GDI contextu), a na druhé straně různé úplně odlišné back-endy s naprosto odlišnými vlastnostmi, jako je PostScript, Xlib, Xlib s X Render extension a XCB. Pokud chcete tisknout na běžnou PCL tiskárnu, nejspíš v Cairu vygenerujete PS nebo PDF, a pak to proženete RIPem, aby to celé bylo čistší a elegantnější. A k tomu se paralelně už od roku 2008 píše Wayland (ať žije rychlost), a teď i samozřejmě Mir, přičemž Cairo neumí ani Wayland ani Mir, a Wayland ani Mir pro jistotu neumí vzdálený přístup po síti. Jistě se shodneme, že je tohle není dobrý design, ale fialový radioaktivní hnus.

Mám produkční linuxový server už asi 4 roky a ještě vživotě jsem nepotřeboval nic rendrovat pro lokální tisk, stejně tak jako jsem nepotřeboval žádné lokální GUI. Co s tím GUI pořád máte? 90% věcí spáchám v lokální query, zbytek v term. Ve firmě máme 10 linux serveru, ani jeden s GUI. Zkoušel jste někdy nastavit v GUI FW? Zkoušel jste někdy v GUI nastavit 50ti skupinám práva na adresářovou strukturu?

Nevím jak spravujete servery vy, ale mi GUI tak akorát zvedá tlak. Běžte s ním do nejtemnějšího otvroru!

Blábolíte tady pěkné nesmysly.

Na většině serverů toho moc zobrazovat a tisknout nepotřebujete. Také si všimněte, že když už se Linux dostane do nějaké firmy, zpravidla bývá v roli serveru, kde zrovna tisk a GUI není tolik potřeba. Naopak na desktopech Linux propadl.

Firewall přes GUI občas nastavuji. Kdybych to dělal každý den, možná bych použil konzoli.
Nastavování práv chce na prvním místě analýzu, pak návrh, typicky v Excelu. Nakonec ty permissions nastaví buď makro přímo z Excelu, nebo skript v Excelu vygenerovaný.

Konzole má při administraci své místo, ale řadu věcí je daleko snazší dělat z GUI - pokud tedy zrovna nesedíte u nějakého Unixu :). Jinak souhlas, z GUI na Unixech se mi také zvedal tlak.

Zřejmě se snažíte svérázným způsobem říci, že Linux na desktopu je nesmysl.

V tom s vámi nesouhlasím, Linux je použitelný i na desktop, byť to místy hodně skřípe.

A který OS neskřípe?

http://www.top500.org/statistics/list/

Linux bezi na 96% nejvetsich superpocitacu sveta. Jak to vysvetlis? Pokud je tak priserny, zrejme to znamena, ze osatni OS jsou jeste horsi :P

Superpočítače jsou v naprosté většině případů gridy. Jde o spoustu racků, do kterých jsou typicky naskládané x84-64 PC, pospojované v nejjednodušším případě gigabitovým ethernetem, případě něčím lepším, jako je InfiniBand. Řídící počítač rozkouskuje úlohu - kdyby to bylo rendrování animovaného filmu, každému nodu by přidělil nějaké snímky, které se rendrují prakticky nezávisle. V podstatě můžeme říct, že grid je něco jako SETI@home v jedné serverovně.

Teď se zamyslete, co musí umět node takového gridu. GUI, grafiku a tisk? Nody ovládáte vzdáleně a nemají grafiku ani tiskárnu. Nízkou latency kernelu? Nepracujete s multimédii ani nereagujete na časově kritické události. Dobrou SMP škálovatelnost? Node má jednotky jader CPU. Výkonný multithreading? Kalkulace vám klidně mohou běžet v procesech, nebo v pár threadech. API které umí všechno možné i nemožné? Potřebujete běžet jen poměrně primitivní program, který míchá s daty, a API OS využívá minimálně. Node musí umět jen správu procesů, paměti, a nějaký ten networking, aby si vyzvedl úlohu a předal (mezi)výsledky.
Tak proč byste platil za OS na každý node, když můžete mít zdarma OS, který umí vše potřebné?

Samozřejmě tenhle přístup má i svá omezení. Za týden postavíte grid s vysokým teoretickým špičkovým výkonem, a pak kolem něj půl roku skáče velká spousta lidí, aby z něj nějakou část toho teoretického výkonu vymlátila. A pak většinu těch lidí máte na krku do smrti (v lepším případě toho gridu), protože ho musejí opečovávat. Pokud se vaše společnost jmenuje DARPA, Lawrence Livermore National Laboratory, Los Alamos Neutron Science Center nebo NSA, jistě potřebujete velmi vysoký výkon, a nemáte problém zaměstnat všechny ty lidi, kteří vám grid nastaví a budou udržovat.

Pokud ale jde o pojišťovnu vyhodnocující finanční rizika, automobilku pracující na optimalizaci aerodynamiky, vlastních frekvencí a deformací, případně výzkum v oblasti genetiky, najednou to není to pravé. Takový zákazník nepotřebuje nejvýkonnější superpočítač na světě, a určitě nechcete platit hromadu lidí, kteří okolo něj budou skákat. Proto si koupí Windows HPC. Za pár dní firma přiveze racky, zapojí je, nainstaluje SW, a je hotovo. Můžete jet prakticky ihned, bez pokusů, dlouhého ladění a vývoje. A když chcete něco vyvíjet, máte k dispozici Visual Studio včetně remote debuggingu. Plus samozřejmě můžete vlastní výpočetní výkon doplnit cloudem, například MS Azure, případně do něj aplikaci kompletně přesunout.

Odpověděl jsem na vaši otázku?

Odpověděl jsem na vaši otázku?

Ne, zato si vyplodil další tunu bezcenných marketingovejch sraček.

Já se obávám, že on všemu co říká, dokonce nezdolně věří. Soudruzi z MS BrainWash Center odvedli na Laelovi vskutku kvalitní práci. (tleskánky)

Tie vyplody sa nedaju ani citat a su stale dlhsie. Ked uz davaju peniaze niekomu aby ovplyvnoval mienku na diskusach mohol by to byt aspon expert.

Mýlím se v něčem? Pište konkrétně v čem, technicky a věcně. Pokud nemáte nic k věci a chcete jen léčit své mindráky nějakými fekálními výlevy, tak to myslím nikoho nezajímá.

Prostě už ty tvoje hemzy nikoho nebaví. Běž dům dál, kde ještě neví, že MS je vždycky za každých okolností lepší než všichni ostatní. Tady už to víme, děkujeme, rádo se stalo.

To nemyslite vazne, technicky vyvratit taky rekordne dlhy prispevok to by dalo riadne zabrat.
No kde zacat predpokladam ze ste nemyslel x84-64 PC ale x86-64. Podla http://www.top500.org/ je v top10 polovica x86-64. Potom su tam spaky, poverpc NVidia grafiky.

"Teď se zamyslete, co musí umět node takového gridu...... Nepracujete s multimédii ani nereagujete na časově kritické události. "

To keby som tak vedel ako IBM alebo HP robi svoje superpocitace :-) ale ked sa zamyslim tak synchronizacia je casovo kriticka operacia. Ked to prirovnavate k polickam filmu v prvom odstavci tak preco to v druhom vyvraciate?

"Za týden postavíte grid s vysokým teoretickým špičkovým výkonem, a pak kolem něj půl roku skáče velká spousta lidí, aby z něj nějakou část toho teoretického výkonu vymlátila."

Neviem kde som videl take video kde stavali superpocitac v USA, mali tam problem ze im na napajanie vychadzali medenne kable neuveritelnych prierezov uz si nepametam ako to vyriesli. V kazdom pripade len tak niekto nepostavi superpocitac, a ak hovorite o tyzdni na postevenie superpocitaca tak asi o problematike nemate predstavu. Co by tam asi tak toho pol roka po postaveni ty ludia robili? Kopali do toho aby to slo rychlejsie? :-).

A este to GUI ktoremu venujete taku pozornost. Zamyslat sa ci v superpocitaci je nejake GUI je ako spekulovat ci je vlajka na leitadlovej lodi z bavlny. Nikdy Vas tam nepustia aby ste sa pozrel a keby som uz bol na lietadlovej lodi urcite by som si pozeral ine veci.

Ad ste nemyslel x84-64 PC ale x86-64 - souhlas

Ad v top10 polovica x86-64 - souhlas, a v top500 je to okolo 80%:
http://upload.wikimedia.org/wikipedia/commons/e/ef/Processor_families_in_TOP500_supercomputers.svg

Ad synchronizacia je casovo kriticka operacia - node si vezme job ze serveru (řekněme model 3D scény), velmi dlouho počítá nad daty která dostal (rastruje snímky), nakonec předá výsledek na server (uploaduje snímky) a jde si pro další job. Žádné časově kritické události tam nejsou. Ty můžete naopak najít při práci s multimédii, řízení technologických procesů apod.

Ad ak hovorite o tyzdni na postevenie superpocitaca - je to spousta racků nacpaných typicky x86-64 HW. Samozřejmě řešíte napájení, chlazení atd., ovšem při projektování, ne při vlastní stavbě (a to se samozřejmě týká i každé větší serverovny).

Ad Co by tam asi tak toho pol roka po postaveni ty ludia robili - instalují (a mnohdy píšou) řídící SW, SW na nodech, konfigurují, pracují na paralelizaci úlohy, minimalizují nutnost předávání dat mezi nody (protože to je mnohem náročnější než operace nad pamětí nodu), a mnohokrát dokola zkouší, ladí, rekompilují, instalují, konfigurují, patchují, administrují nody...

Ad GUI - až na poslední otázku byla v druhém odstavci odpověď vždy "není relevantní". GUI se týká jen řídícího nodu.
http://sourceforge.net/p/unicore/bugs/_discuss/thread/c2bfaf0f/5ed1/attachment/URC-Screenshot.jpg

A to stale trvate na tom ze serverovnu postavite za tyzden?

Node (povedzme ten xenon) si zoberie model 3D sceny, renderuje ho 10 sekund, cize 100 000 tisic nodov zrenderuje naraz 100 000 3D scen kazdemu to trva priblizne 10 sekund a vsetky to chcu naraz zapisat na ten server co ho tam spominate. Tam nic casovo kriticke nieje? Ak by to ten server nepolozilo tak by to aj tak trvalo dalsich 1000 sekund :-).
Takze Vasa predstava je ze IBM zmontuje superpocitac za tyzden. Za tyzden odovzda kluce od serverovne zakaznikom a neda im k tomu ziaden software, dokonca si ho zakaznik vyvija sam za pomoci hromady administratorov?

Ad stale trvate na tom ze serverovnu postavite za tyzden - mluvil jsem o počítači, ne o stavbě serverovny pro něj :). Koukněte se do nějaké větší serverovny, a představte si tam samé blade servery. Ty tam dostanete poměrně rychle, a rychle je i zapojíte.

Ad renderuje (snímek) 10 sekund - jeden snímek se rendruje průměrně 2-3 hodiny. U filmu Cars 2 to bylo průměrně 11.5 hodiny na snímek, u nejsložitějších scén 90 hodin na snímek. Časově kritické operace vypadají úplně jinak. Řízení reaktoru, přehrávání MIDI na koncertu, přehrávání videa v news roomu nebo v kině...

Ad neda im k tomu ziaden software, dokonca si ho zakaznik vyvija sam - SW můžete dostat, ale řada zákazníků si píše části ve vlastní režii. Záleží na aplikaci. Pokud potřebujete distribuovaný MATLAB, dostanete všechno od dodavatele. Pokud chcete provádět jednoduchý brute force attack, vyjdete asi z existujícího kódu, obalíte ho nějakou omáčkou pro nody, a na straně řídícího nodu budou stačit drobné úpravy. Pokud půjdete do jiné kryptoanalytické techniky, čeká vás s největší pravděpodobností spousta vývoje a pokusů. Samotná stavba superpočítače je ta méně náročná část.

Toto je pribeh z davnych cias ked cena mainframov bola zavratna a cena software malinka.
Dojednaval sa velky kontrakt, po dlhych a vycerpavajucich rokovaniach sa obe strany hohodli aky HW sa pouzije, ale posledny den pred podpisom sa jeden manager kupujucej strany nejako vrtel a cez prestavku prisiel k hlavnemu obchodnikovi predavajucej strany a tichucko sa spytal "A date nam aj nejaky software?"
A to je pravda a zjem svoj klobuk ak by som vam klamal.

Tímto redakci opět děkuji za zkurvenou ochranu proti spamu. Vizte pastebin.

http://pastebin.com/download.php?i=BcKYXdUq

Mne ziaden spam nechodi :-).
Myslel som ze to necham tak ale proti takym hlupostam sa jednoducho musim ozvat. Samozrejme Vas asi nepresvedcim ze serverovna sa neda postavit za tyzden, kto to niekedy robil sa tomu zasmeje kto nie tak ten Vam mozno uveri.
Zato taka predstava ze superpocitac rozdeli vypocet na kusky ktore sa robia 11 hodin sa da logicky vyvratit. Predstavte si ze pocitate na 100 000 procesoroch 100 000 snimkov. Vtedy sa vyuzitie pocitaca blizi 100%, co ale ak pocitate 100 001. Za 11 hodin to vypocita tych 100 000 snimkov a zvysny 1 snimok bude pocitat jedno jadro dalsich 11 hodin, ostatene jadra budu zahalat. V takomto pripade vyuzitie stroja bude 50%. A prosim nenapiste mi nejaku hlupost typu ze tie pocitace vtedy pocitaju snimky z filmu cars3 pretoze vetsina vypoctov je iteracnych, na to aby vedel pocitatac vypocitat ake bude pocasie v 4 hodine musi mat vypocitane ake bude pocasie v 3 hodine. V skutocnosti su pre taketo vypocty vzdy najvyhodnejsie co najmensie kusky.
Tiez je mi zahadou preco si myslite ze Linux nevie riadit elektrarne pretoze nema podla vas "Nízkou latency kernelu". Uistujem Vas ze na linuxe/unixe bezi ovladanie elektrarni. Funguje to tak ze program v centrale posle prikaz do elektrarne zapni vypinac 123. V elektrarni sa zapne vypinac 123 to trva tak 2 sekundy a riadiacemu program v central pride signal 10 alebo 01 podla toho ci je vypinac zapnuty alebo vypnuty, a to sa potom zobrazi operatorovi na obrazovke. A jadrovu elektraren riadi aspon u nas pocitac ruskej vyroby velky asi ako jedna kancelaria, tam by sa windows s "Nízkou latency kernelu" tiez neuplatnil.
Tiez predstava ze tam administratori "instalují, konfigurují, patchují, administrují nody" na co by to robili ked to bezi, ten pocitac nie je na internete, netreba tam davat nejake zaplaty, riadiaci software je napisany dodavatelom HW kazdu zmenu v HW alebo SW robi dodavatel. Uzivatelia nesmu zasahovat a ak to urobia stratia support.

Znovu: nemluvím o stavbě serverovny, ale o stavbě superpočítače v té serverovně, tj. o navezení HW a jeho zapojení.

Cars 2 má okolo 150k snímků, průměrná doba rendrování na snímek 11.5 hodiny, maximální doba okolo 80-90 hodin, rendrovací farma měla 12500 cores. To je průměrně 138 hodin rendrování na core.
http://www.cnet.com/news/new-technology-revs-up-pixars-cars-2/

V nejjednodušším modelovém případě si node řekne o 3D scénu per core, začne ji rendrovat na jednom core, a po dokončení rendrování si řekne o další práci. Pokud rendrování nějakého snímku běží 90 hodin, tak si prostě dané core vyrendruje jeden nebo dva snímky. Pokud to chcete řešit lépe, můžete nechat rendrovat části snímků (to je opět nezávislý proces bez nutnosti komunikace s dalšími nody). Například u ray tracingu se to implementuje celkem jednoduše. Samozřejmě při rozdělení také můžete vzít v úvahu složitost dané scény - některé snímky netřeba dělit, jiné můžete rozsekat na malé kusy. Pokud se bavíme o rozkouskování úlohy, tak si uvědomte, že zpracování okolo každého kousku obnáší nějakou režii. Příliš malé kusy proto snižují výkon; příliš velké samozřejmě mohou vést tomu, že různé části úlohy doběhnou v různý čas (což může a nemusí být pro danou aplikaci problém), nebo dokonce nebudete schopen vytížit všechna výpočetní jádra (čemuž se pochopitelně snažíte vyhnout). Správná velikost úlohy pro node je prostě taková, aby minimalizovala buď čas dokončení celé úlohy, nebo celkové využití zdrojů.
Samozřejmě existují i úlohy, kdy potřebujete předávat data mezi nody. V takovém případě se snažíte komunikaci mezi nimi minimalizovat, protože je vždy daleko pomalejší, než předání dat v rámci nodu. Navíc většinou přesně nevíte, jak dlouho bude trvat operace nad danou částí dat, a vzájemné závislosti vám mohou celkový výkon clusteru snadno poslat do kytek.
Ohledně vytížení superpočítače se samozřejmě mýlíte. Superpočítač má typicky na nodech více různého SW. Pokud vám těch 12499 cores dopočítalo danou úlohu, a jedno core potřebuje dalších 20 hodin na dokončení operace, můžete na zbytku superpočítače pustit další joby (řekněme rendrování dalšího filmu daného studia, nebo nějaké práce na postprodukci). Od toho je tam řídící SW.

Ad Linux nevie riadit elektrarne - nic takového jsem neříkal. Pro řízení rychlých dějů je potřeba RTOS. Může jít o Windows s RTX64, Windows CE, QNX, VxWorks, případně RTLinux (který ale před pár lety skončil).

Ad riadiaci software je napisany dodavatelom HW kazdu zmenu v HW alebo SW robi dodavatel - to záleží na aplikaci. Jak jsem už psal, mimo projektů typu distribuovaného MATLABu (kde dostanete superpočítač "v krabici s mašličkou" a nemusíte v podstatě na nic sáhnout - to je cílovka MS) je tu řada dalších, na kterých si zákazníci minimálně část SW píšou sami. To pak musíte psát kód, ladit, instalovat, experimentovat. Podobně servis HW si může minimálně částečně dělat zákazník. U většího clusteru vám bude každou chvíli odcházet nějaký HW. BTW Googlu údajně odchází HDD průměrně každou minutu nebo dvě.