Vlákno názorů k článku Jak je na tom Česko s IT odborníky? od LENIN POWER! - kdybyjste premysleli co za IT technologii se naucit...
-
Článek je starý, nové názory již nelze přidávat.
-
LENIN POWER! (neregistrovaný)kdybyjste premysleli co za IT technologii se naucit tak zkuste tohle, zajem o lidi co tohle umi je znacny a platy jsou priblizne 3x vyssi nez maji standardni coderi.
motivacni videa:
http://www.youtube.com/watch?v=RedECYAgksc
http://www.youtube.com/watch?v=B97p8AyeHn8
http://www.youtube.com/watch?v=3-njaI8Apao
http://www.youtube.com/watch?v=yGf9tPfw1PA
http://www.youtube.com/watch?v=29lhO49PUiU
no nechteli by jste s timhle hw pracovat? -
BLEK. (neregistrovaný)IBM Z-series vykonává všechny instrukce dvakrát paralelně dvěma procesory, má i paměť odolnou vůči výpadku kteréhokoli celého čipu (ECC, co je běžně v x86 serverech ti opraví jenom jeden bit). A když se některý procesor nebo paměť pokazí, tak se to za běhu dá vyměnit, aniž by se musely shazovat aplikace (dokonce to v takovém případě prý samo zavolá na support IBM).
Je to drahé jaxviňa, ale pro někoho to asi význam má. -
LENIN POWER! (neregistrovaný)Podivejte se jake clusterovaci moznosti nabizi linux a jake maji mainframe class OS. Je v tom znacny rozdil.
Krom toho co na tom linux clusteru chcete pouzivat za SW? Oracle RAC? To je ale dost neskalovatelny software znamy svou nespolehlivosti. Prectete si nejake nezavisle studie o Oracle RAC.
Intel je sice levnejsi, ale je vyhodne pouzivat intel servery jen pokud jich nemate mnoho. Pokud uz jich mate hodne je dobre se preoritentovat na midrange hw (pseries, SUN SPARC64, iseries). Vyjde to levneji. Musite pocitat celkove TCO a ne jenom prozovaci cenu hw, ktera cini tak 10-15% z celkoveho TCO. SW je typicky levnejsi pro midrange servery a je potreba mene lidi, mene prostoru, mene energie nez pri par stovkach intelech. Vetsina serveru byva zatizena tak na 10-15%, takze jeden midrage server i kdyz vezmete nejaky levny SUN je schopen nahradit stado intelu, nemluve o vyssi spolehlivosti. -
Rejpal (neregistrovaný)Nechtěli, jsou to neskutečný krávy a umí to mnohem míň, než by na základě spotřeby, velikosti a technologie mělo. Když člověk uváží, že v sedmdesátých letech mohl PDP-11 obsloužit několik desítek interaktivních uživatelů a současně řídil teleskop v reálném čase a ještě dělal spektrální analýzy, a že v osmdesátých letech totéž zvládlo IBM PC (za předpokladu použití kvalitního softwaru), vyvstanou dinosauři od IBM v úplně jiném světle. Procesor x18 rulez. Pro pár stovek jader v pětiwattovém pouzdře by se jistě našlo docela dost aplikací.
-
Rejpal (neregistrovaný)BTW, "Energy & Environment" - to je výsměch! Ty svoje kecy o "too big, too complex, too inefficient" by IBM klidně mohla vztáhnout na sebe, včetně toho jejich z10. Jak může z/OS zabrat DVDčko, to asi nikdy nepochopím. Dnes je state-of-the-art mikroprocesorová technologie někde u hranice sto-sto padesáti miliard instrukcí na watt a dvaceti miliwattů na 2000- až 3000MIPSové jádro. Ale bohužel, dnes už jen málokdo umí *doopravdy* efektivně programovat ty opravdu úsporné architektury, tak se lepičům jako jste vy dělají ústupky. Třeba CAD v deseti kilobajtech je dnes už asi jen ten jediný. Přiznejme si to - dnes se o skutečně zelené technologie skoro nikdo doopravdy nesnaži. ;/
-
Rejpal (neregistrovaný)
x18, a první a druhá část interview s demonstrací softwaru OKAD (na naprosto staré šunce v roce 93) a jím navrženého křemíku. Ty parametry v prvním odkazu tam jsou pro 180 nm výrobní proces, tím se vyráběl naposledy 1.4 GHz PIII Tualatin, jestli se nepletu, a je vidět, že s asynchronním návrhem x18 šel dvojnásobek. Dneska máme 45 nm, takže stačí extrapolovat. Nebyl by problém zvětšit šířku sběrnice a lokální scratchpad, je to docela flexibilní. :-)
Akorát se to musí umět programovat, toť vše. Procesor samozřejmě sám moc neumí, nicméně se lze domnívat, že při minimalizaci složitosti celého systému hardware+software pro konkrétní úkol a maximalizaci poměru celkový výkon/spotřeba by kdokoli dokonvergoval k podobnému řešení. I při softwarovém řešení některých operací to může být i v průměru (ne jen ve špičce) pekelně rychlé (to se prokázalo už dávno, viz třeba tady (tu knihu doporučuju) - "...a rule-based system...runs approximately 740 times faster on the RTX 32P [pozn.: 8 MHz] than on a standard 4.77 MHz 8088 PC"). Instrukce na jeden takt i bez pajplajny, extrémně levné větvení podporující factoring (není zapotřebí inlinovat, volání je deterministicky na jeden takt a návrat trvá nula taktů), reakce na přerušení deterministicky jeden takt...spousta výhodných vlastností. :-) Proto se to taky hodně cpalo (a cpe) do vesmírných sond, protože tam člověk chce mít co nejvyšší výkon, ale přitom musí kvůli radiační odolnosti mít co nejnižší složitost zapojení a hodinovou frekvenci.
Každopádně tvzení o tom, že mainframový HW a mainframový SW jsou nějak superúsporné, je trošku mimo. Jsou možná tak asi uprostřed technologické stupnice, lepší než PC a spol., ale zase žádný zázrak. :-) -
JS (neregistrovaný)Diky, vypada to zajimave (jsem zastance registrove architektury, ale mozna me to presvedci :)). Ptam se taky proto, ze mainframy programuju. Hardware (specialne z10) je podle me dost dobry, procesory jsou sice trosku pozadu nez na PC, ale hlavni sila mainframu je I/O propustnost. Ze je velmi velmi drahy je pravda, ale to je takovy folklor - velke korporace proste maji tendenci prodavat si navzajem drahe cetky (tim nechci rict ze mainframe je cetka, tim chci rict, ze jsou ochotne platit ohromne castky za nepatrna zvyseni spolehlivosti). Co se SW tyce, z/OS je co se tyka nekterych vlastnosti dost napred pred ostatnimi systemy (treba takove GDPS, WLM nebo SMS jsou uzasne hracky), akorat ma hodne bradavic, co se nahromadily za ta leta. A treba z/VM hypervisor napsali uz v 70.letech, takze je hodne svizny (co jsem slysel, vyplati se provozovat vice Linuxu pod VM nez jeden Linux, protoze Linuxove thready hur skaluji). Asi nejvetsi problem mainframu (z HW i SW hlediska) je historicka zatez - prece jen jsou tu uz 40 let. Jinak si myslim, ze budoucnost mainframe ma oproti clusterum uz z fyzikalniho hlediska - kdyz tahate data na mensi vzdalenosti, nakonec te nizsi spotreby dosahnete.
-
Rejpal (neregistrovaný)No je pravda, že ty disky by mi nevadily. :-) A tehdy to nebyl z/VM, to bylo VM/370, ale taky myslím, že to je miláššek. MVS|z/OS zrovna nemusím, ale z/VM a věci, které vymysleli Popek a Goldberg obecně nás pošouply hodně dopředu, to mi je jasný. :-) BTW, ještě jedna hezká knížka je Thinking Forth (taky se dá stáhnout), i kdyby v tom člověk nakonec nedělal, jsou tam pěkný myšlenky, co se snad dají uplatnit i jinde.
-
LENIN POWER! (neregistrovaný)Solaris 10ka je taky na jednom DVD, Visty jsou na CD nebo DVD?
Oproti solarisu mam pripominky ze je prilis slozity, protoze ta jeho slozitost je zbytecna. Solaris nenabizi zadne podstatnejsi vyhody oproti jenodusimu linuxu. Mainframe OS ale prinaseji znacne vyhody, takze u nich mi jejich slozitost nevadi. Krom toho pracovat s mainframe os neni zadna specialni hruza, kdyz chcete unix shell a unix userland, muzete ho tam mit. -
Rejpal (neregistrovaný)Uáá, takhle znásilňovat technologie! Teda se SLESem pro System Z mám společného mnohem víc, než běžný kolemjdoucí, ale stejně mi to přijde jako humus. Prakticky všechen dnešní SW je nabobtnalý do té míry, že tvrdit, bůhvíjak "nás produkt je úsporný a nenáročný" je pokrytectví. Úsporný SW se dneska už nedělá, možná tak algoritmicky, ale v absolutních číslech už dávno ne. Snad ještě VM/370 nebo NetBSD si troufnu označit za malé hezké čisté věci, tedy z toho, co se běžně používá. (Děsím se, co se mezitím stalo se z/VM. iOS možná taky nebude tak špatný, ale bloat dneska vládne světu.)
-
JS (neregistrovaný)Kdyz jsme tak u te uspory, vis, jak tenhle problem vyresit? Ja ne. Vysvetlim: Taky samozrejme vnimam, ze software bobtna a v zasade jeho nabobtnalost odpovida dobe, v ktere vznikl. Ale u kazdeho slozitejsiho programu je obtizne poznat, jestli by mohl bezet rychleji. Vyvojar to otestuje a bezi mu to (na novem hardware) rychle. Jak pozna, ze neco dela spatne a mohlo by to bezet rychleji? Nemuze si udelat teoreticky model a ten spocitat, protoze ten software je moc slozity. Potom ale vuci cemu to muze porovnat? Je lehke si stezovat, ale fakt nemam tuseni, jak se s tim vyporadat.
-
Rejpal (neregistrovaný)To ví dokonale jen Charles Moore. ;-) V Thinking Forth je zmíněno hodně zásad, ale všechy spojuje Einsteinovo "dělat věci tak jednoduché, jak je to jen možné, ale ne složitější". BTW, Chuck je mnohými považovaný za podivína (nejen kvůli Forthu :-)), ale asi moc lidí neví, že Intel od něj má licencované patenty na úsporné technologie v moderních procesorech. Takže už teď používáme spoustu jeho výtvorů, kterými se svět počítadel snažil učinit lepším, i když si z nich mainstream vzal "jen něco". (Matně mě napadají patenty na dynamické přepínání frekvence různých částí čipu. Intel nemá SpeedStep z vlastní hlavy. ;-))
-
JS (neregistrovaný)No, nevim, uprimne receno, delat veci jednoduse lze jen v omezene mire, protoze:
1. Delat veci jednoduse chce velky intelekt a predvidavost, a lidsky intelekt neskaluje tak dobre, jak bychom si prali, s velikosti projektu, ktere se delaji.
2. Nejrychlejsi algoritmy jsou zridka ty nejjednodussi. Jednoduche algoritmy byvaji obvykle rychle, ale pokud chcete jeste pridat, zacne se to dost komplikovat.
3. S kazdym dalsim pozadavkem slozitost rychle roste, a tim roste slozitost pouzitych algoritmu, a tim klesa sance poznat, co je vlastne spravna cesta.
Teoreticky a v cipech to mozne je, ale v modernich programech, nevim. Cipy nejsou zdaleka tak slozite jako moderni programy. -
Rejpal (neregistrovaný)To je možný, a já netvrdím, že v kontextu dnešní doby je to univerzálně aplikovatelný postup, nebo přinejmenším že bych o tom mohl lidi univerzálně přesvědčit. :-) Ale když už jsem viděl CAD v deseti kilech a prakticky všecho další forthové maximálně ve stovce (což může být sakra hodně, když instrukce může mít pět bajtů a jazyk vybízí k maximální faktorizaci kódu, algoritmy nealgoritmy), aspoň mě to přimělo k zamyšlení. Chuck používal "agilní programování" čtyřicet let před tím, než se z toho stal buzzword, objektové programování o dvacet let dřív... Zkuste si aspoň přečíst Thinking Forth a Stack Computers, myslím, že i jako mainframovému assembleristovi Vás to obohatí, přinejmenším o nové úhly pohledu. ;-) (Přičemž o "moderních" (velkých?) programech je tam takový pichlavý obrázek. ;-))
-
Rejpal (neregistrovaný)Má, pokud je rychlejší a přesnější než produkty Cadence a Mentor Graphics. Myslím, že jeden z důvodů, proč si Chuck napsal vlastní CAD, byl ten, že konkurence byla desetkrát pomalejší a ještě ani v simulátoru nezohledňovala vlivy teploty na chování unipolárního tranzistoru, což nutně potřeboval. On totiž Chuck ten křemík dělá "tak trochu na hraně" (jinak by nemohl dosáhnout v roce 2001 taktu 2.4 GHz ;-)), nicméně zjistil, že mu ani tolik nedělá problém ten křemík nechat spolehlivě vyrobit (v továrně mu nevěřili, že se 0,8mikronovým postupem (i486) dá vyrobit čip pro 500 MHz, a nakonec fungoval na první pokus), jako spíš jak ho navrhnout tak, aby z těch z pohledu továrny "nepravděpodobných masek" vylezlo něco, co nakonec překvapivě funguje. A to se bez dostatečně realistické simulace udělat nedá.
BTW, ty jeho čipy byly už před patnácti lety plně asynchronní - "taktují se samy" na maximální možnou rychlost, případně na minimální spotřebu na vykonaný výpočet, záleží na úhlu pohledu - což je design, který zatím u procesoru snad nikdo jiný nezvládl. (Intel aspoň koupil od Chucka patenty nutné pro SpeedStep, aby ty jejich notebookové procesory nevypadaly tolik trapně. ;-)) Jo a Chuck využívá jistě desítky a stovky megabajtů paměti, ale na návrhová data. Doslova řekl něco jako "nemám nic proti využívání stovek megabajtů paměti, pokud nejsou zaplněny kódem, který bych musel debugovat". -
Rejpal (neregistrovaný)Teď jsem našel ten důležitý citát:
"I have demonstrated in the past, ad nauseam, applications where I can reduce the amount of code by 90% percent and in some cases 99%. It can be done, but in a case by case basis. The general principle still eludes me."
Asi je to tvůrčí činnost a nedá se to zgeneralizovat. :-/ Asi jako expertní systém Bacon, který kdysi dokázal z naměřených dat o planetách vydedukovat Keplerovy zákony stejně, jako to kdysi udělal Kepler, ale to z něj ještě nedělá inteligentního tvůrčího tvora na úrovni člověka. -
LENIN POWER! (neregistrovaný)jaky znasilnovani technologii? Ja to povazuju za naprosto normalni pouziti. My jedeme na RHEL pro System Z. Jinak z/VM je opravdu vynikajici hracka, ale to textove login logo, to fakt chce vylepsit.
http://www.redhat.com/rhel/server/mainframe/
