HW novinky: Itanium před soudem, hraje se o stamilióny dolarů (diskuse)

[foldy]

Fajn takže celý svět odstavil Itania a já můžu celý svůj vývoj pomalu zabalit.. Jasně, že je nikdo nepotřebuje vždyť 99% problémů světa je jednoduše řešitelných na x86 a další specializovaná platforma pro HPC umře. No nic, je čas změnit obor, počítače a věda už není co bývala. Bez nože ani řezník nedokáže uříznout maso. Holt na 1% nikoho nezajímá.. Přežije jen počet :(

[Michal]

Tohle mě zajímá (opravdu, nedělám si legraci) - jaký typ problému je řešitelný Itaniem a ne na x86-64? Konec konců procesor je jen malá část řešení, v mnoha případech je úzkým hrdlem zbytek systému, sběrnice, paměti, I/O, atd. Pomohla by dejme tomu ne-PC platforma s x86-64? Nebo je na Itaniu něco tak speciálního co nejde s x86-64 provést?

[vlastikroot]

Nic o tom teda nevim, ale i zbezne porovnani architektury itania a x86-64 ukazuje obrovsky rozdil uz jen v poctu registru (itanium ma 128 64bit int + dalsich 128 82bit floating registru), dal pak WLIW instrukcni sada atd... Me se itanium vzdycky libil proto, ze sebou netaha obrovskou zpetnou kompatibilitu (resp. bordel) z x86.

[petr_p]

V určitých úlohách je procesor úzkým hrdlem. A není to kvůli špatným programům. Itanium se svojí implementací VLIW je opravdu schopno dosáhnout špičkových hodnot FLOP.

Stačí se podívat na dekódování videa. Když nepoužijete SIMD rozšíření dnešních FPU, tak i velmi výkoné amd64 se zapotí. A SIMD je jen první stupeň optimalizace, kde pořád budete mít problém s vyléváním keše a zastavováním rozpracovaných instrukcí kvůli skokům a v jiných případech budete jen tupě říkat procesoru další instrukce, další… Rozšířením na SMP, kam se dnešní vývoj vydal, mnoho nezískáte, pokud máte úlohu, kde data na sobě závisí. V ten okamžik potřebujete MIMD s vnitřní paralelizací, což právě Itanium nabízí.

[Michal Vyskočil]

Na druhou stranu i v takovém top500.org dnes najdete pouhý jeden stroj s Intaniem (aktuálně #430), který byl uvedený do provozu v roce 2008. Asi nejlepší roky byly 2002-2005, ale jelikož AMD uvedlo Opteron v roce 2003, sešup byl rychlejší, než Intel s HP čekali.

[foldy]

Omlouvám se, tohle je velmi obsáhlé téma, skusím to zkrátit na úroveň komentáře.

Dělám fyzikální (částicový) simulátor pro svůj soukromí projekt. na x86-64 lze ty problémy řešit. Problém je efektivita. Smysl Itania vzroste, začnete-li používat paralelizaci (3paralelní instrukce na cyklus) a výhody HPC procesorů. Představte si jednoduchý paralelizační problém, 10^28 částic ve vzájemném pohybu a vy vyhodnocujete jejich lokální interakce v reálném čase. Zapomeňte na obecná řešení, jde o brute force výpočty. A teď do toho zasaďte Itanium. Nakousnu, registry: 128(64bit)Integer, 64bit Predicate,128(64bit)Aplication,128(82bit)Floating point + mnoho dalších speciálních registrů (je jich okolo 400)samozdřejmostí jsou 128bit sběrnice. Když to umíte, spustíte paralelně 3 úlohy v 1 cyklu. Dál je tu EPIC(VLIW), spousty spousty spousty instrukcí, zadrátovaných přímo v procesoru, umožňující dělat všechno efektivněji a na méně instrukcí.

Otevírají se další možnosti, proč LOAD/STORE ten stačí použít jen jednou za čas,když si můžete připravovat další iterace a používat čísla přímo na úrovni registrů(rychlejší,efektivnější). To vše samozdřejmě s maximálními přesnostmi nativně. (pracuji v rozměrech planckovy délky..)

Zkuste to udělat na 4 integer a 4 floating-point registrech na x86, jde to ale... Kdysi jsem to testoval v roce 2003 a rozhodoval se co nasadím, udělal jsem pár specifických úkolů : Itanium vs Xeon (2003-2004) výkonnostní rozdíl 50000% ano opravdu vidíte správně, rozdíl je obrovský, ale jen pro specifické úlohy, které potřebuji... časově Xeon několik 10 minut, vůči pár vteřinám na Itaniu. Navíc můžete použít více procesorů (testuji na 4 proc Dellu, tam je díky návrhu Itania přímo pro HPC rozdíl ještě větší) + dalších 1000 speciálních použití které to umí AES, matice atd...

Power je super, ale o něco pomalejší a více specifický, RISC věci jsou taky super, ale takovéhle úlohy se vám nikdy nepodaří napsat na méně instrukcí a efektivněji než je navrhli stovky inženýrů pro dané úlohy na Itaniu a zadrátovali do procesoru.

Šlo by použít i vektorové procesory Cray,NEC, ty by byly úplně nejlepší... ale ty v potravinách asi u pultíku neseženu...

Pro mnoho lidí může být problém u vývoje na Itaniu nutnost Assembleru a C. Ale to jsou největší výhody.

[Luboš Doležel (Doli)]

Takové OpenCL, podporované současnými procesory, by nestačilo?

[foldy]

Open Cl o tom jsem něco slyšel, ale to je framework ne ? Bude to rychlejší než assembler ? U všech těch ostatních ostatních projektů mám velké obavy o přesnost. Tam jde výkon pak rapidně dolů. Pro mě je např. minimum 43 pozic ve FP a nejlépe začít s co největší přesností.. Chyba se s každou iterací nese dál takže pro 100 iterací začínám s přesnostma okolo 4300 des. míst.

Nemám možná tolik zkušeností, dělám to jako amatér pro sebe tak mě omluvte jestli řeším nějaké blbosti.

[nyan]

OpenCL je vicemene C jazyk doplneny o vektorove operace, plus runtime prostredi ktere dodavaji vyrobci hardwaru. Tzn. jde hlavne o to, ze napisete svuj soft v C-like jazyku, a pak by mel jit spustit na jakemkoliv vektorovem hardwaru, kterej ma opencl runtime (momentalne osobne znam jen runtimy - nvidia, amd, intel - pro GPU a CPU).

Bude to rychlejší než assembler ?

Todle je trochu nesmyslna otazka, ne ? :) Assembler na kterem hardware ?

[foldy]

Aha zní to na mě dost složitě. jak by se tam počítaly časy potřebné na operaci ? čili operace/kmitočet/čas ?

Omlouvám se, špatně specifikovaná otázka, o kolik instrukcí vyrobí ten kompilátor více kódu, než kdyby se to udělalo v assembleru ?

[deda.jabko]

Aha zní to na mě dost složitě. jak by se tam počítaly časy potřebné na operaci ? čili operace/kmitočet/čas ?

Tezko.

Omlouvám se, špatně specifikovaná otázka, o kolik instrukcí vyrobí ten kompilátor více kódu, než kdyby se to udělalo v assembleru ?

V podstate jde o to, ze mas nejaky program, typicky pracujici s vektory daty a OpenCL to prizpusobi HW na kterem to bezi. Bud pouzije SIMD instrukce procesoru nebo pokud ma k dispozici GPGPU tak to rozhodi na vsechny vypocetni jednotky, coz na ulohy tohoto typu muze byt docela narez.

[foldy]

Tam bude problém s tím počítáním operace/kmitočet/čas, aby jste mi rozuměl, ta úloha je velmi časově náročná, začal jsem s výpočetním časem 10^9 let dnes se pohybuji kolem 10^2 let. Ta paralelizace v rámci 1 procesoru je vyladěná v řádu nano - piko sekund. Některé intrukce jsou v tom paralelním výpočtu se předbníhají nebo opožďují schválně o ~ 100-150 piko sec. Jakmile se cokoliv stane posloupnostně jinak, výsledek je špatně. Bojím se u takto komplexsních frameworků o správné načasování a maximálním vylaďění... popravdě mám komplex z toho když něco mimo mě rozhoduje co se jak udělá.

Vesměs se to chová jako analogový počítač i když ve skutečnosti jde o velice jemné iterace, které se snaží dosáhnout přesnosti AP.

Dalšího zrychlení chci dosáhnout rozdělením přípravy těch podmínek, dle kterých se řídí ta daná paralelní interakce a předpřipravý se do daných registrů a pak ještě stroj, který bude data rozdistribuovávat po daných strojích. Mám ještě chvíli čas, protože ta na tu úlohu potřebuju ~700TB úložiště, což zatím nejsou mnou finančně dosažitelné možnosti. Zatím pracuju s 4x IA64-2 1.4GHz. Pro finální výpočet seženu něco modernějšího, víceprocesorového a sázím na to, že zvýšením kmitočtu bych měl dosáhnout na výpočetní čas okolo 1 měsíce, s tím, že se nic nerozladí, když jediná změna bude jen v kmitočtu a architektura se vším zůstane stejná.

Myslíte, že uvažuji správně ? Moc to s nikým externě neřeším.

[deda.jabko]

Tam bude problém s tím počítáním operace/kmitočet/čas, aby jste mi rozuměl, ta úloha je velmi časově náročná, začal jsem s výpočetním časem 10^9 let dnes se pohybuji kolem 10^2 let. Ta paralelizace v rámci 1 procesoru je vyladěná v řádu nano - piko sekund. Některé intrukce jsou v tom paralelním výpočtu se předbníhají nebo opožďují schválně o ~ 100-150 piko sec. Jakmile se cokoliv stane posloupnostně jinak, výsledek je špatně.

nevim sice poradne co delas, ale toto je desive. osobne odhaduju, ze prechod na jiny hw, ti cely ten projekt rozbije. nechapu, proc potrebujes synchronizovat vypocet vuci realnemu casu!

jinak merit rychlost operace/cas je na spouste dnesnich procesoru totalni nesmysl (zejmena x86), protoze jednotlive instrukce jsou rozkladany na mikroinstrukce, diky cemuz muzou byt instrukce zpracovavany paralelne, tzn. rychlost zpracovani zalezi na tom jake kombinace instrukci jdou za sebou.

[foldy]

Je to simulace proudění a simulace chování systému jako celku, laminární/turbulentní proudění různých látek pomocí částicového modelu. Nejde o zjednudušeninu ale reálný částicový systém s částicemi standartního modelu. Problém je že těch částic v mém experimentálním systému je 10^43. Nevím jestli to někdo předemnou zkoušel, asi ne, ale já to opravdu potřebuju pro svůj projekt. Musí to být naprosto přesně vůči reálnému systému.

Smysl proč to dělám v reálném čase, je ten, že to ušetří výpočetně 60% času. Zbavíš se tím stovek operací navíc. Snaha přihlížit se analogovému počítači. Je to jako s kuličkami které propadávají různými díramy na nakloněných plochách. Když to postavíš celé, nemusíš nic počítat, děje se to automaticky a kuličky sami propadávají do daných stavů. Kdyby se to nedělo paralelně ( rozuměj reálně) musel by jsi každý z těch stavů (propadnutí) udělat zvlášť, čili je to pak celkově o dost více výpočetně náročné. A pro tak velkou úlohu jsou rozdíly v řádu 1000 let.

s těmi částicemy to v itaniu dělám stejně jako s kuličkami, dělají se různé operace ovlivňované hodnotami v registrech a dělají se 3 částice zároveň, každá ovlivní nějakou charakteristiku dalších registrů v daném cyklu atd. celkově se spočítají 3 interakce jako na analogovém stroji najednou. Proto to časování, musí to být tak dobré jako analogové stroje. Kdyby to tak nebylo musel by jsi to rozsekat na 10000x jemnější interakce aby se zachovali přesnosti a dělat výpočet 3x kombinace 2 částic 1s2,1s3,2s3, s tím jsem kdysi začal a ten počet operací který se tím ušetří je obrovský třeba 10^3 let výpočetního času. V instrukcích je to třeba 1350 vůči 165 aktuálně. A těch 1350 by jsi musel udělat 10000x...

V anglii jsem zkoušel v jednom metacentru na testovacím stroji spustit to na novém itaniu 9000 a výsledky byly stejné, protože všechny ty principy a časy jsou stejné na starých itanium 2 i nových 9000. Funguje to. Netestoval jsem to blíže, měl jsem na to asi jen hodinu, ale výsledky vyšli přesně, takže časování muselo být ok.

[little.owl]

Musí to být naprosto přesně vůči reálnému systému.

A takovy model proudeni existuje?

[foldy]

Ne to je právě ten vtip. Ten model tvořím já. Ne matematickým modelem , ale experimentem. Nejdříve simulace pak reálný experiment.

[Hellboj]

Na modelovani proudeni pomoci diskretnich castic je Lattice Boltzmann Method, vylepseny stary CA modely, owsem tam se nesimuluje realtime (jeste) a uz wubec ne na urowni Planckowy delky ];) ted to spousty lidi reze na GPGPU, owsem udelat to w ASM to by byl narez, problem je ten ze ASM uz dneska nigdo neumi a matematici s fyzikama uz wubec ne (az na wyjimky samozrejme, ktery se ociwide nezabejwaj LBM ];) )

[Václav HFechs Švirga]

Ve vypatlanštině diskutovat o fyzice? Mě poser...

[David Jaša]

Hezký je, jak začal psát normálně, a toho Voskovca s Werichem si přemapoval až po první vedlejší větě.

[Hellboj]

Sam si wypatlanej rybizi a srat na tebe nebudu pac by se ti to urcite libilo ];)

[deda.jabko]

Nevim jestli ma smysl resit, zda itanium pujde nahradit necim jinym. Pristup, ktery zvolils je tak nikzkourovnovy a vychazejici ze specifickych vlastnosti procesoru, ze bys to pro jiny procesor musel ne preprogramovat, ale asi kompletne premyslet.

[foldy]

Ano s tím naprosto souhlasím, jen doufám, že ještě pár let ten vývoj poběží, protože se potřebuji posunout o pár desítek piko sekund dále a vylepšít to už spíše jen použitím novějšího itania, ještě se o kousek posunou a moje úloha bude reálně řešitelná. S tím souvisí i nemožnost úspěšného dokončení bez vývoje Itanium procesorů, budu muset doufat, že ještě dalších 5-7 let se budou snažit.

[pc2005]

nevim sice poradne co delas, ale toto je desive. osobne odhaduju, ze prechod na jiny hw, ti cely ten projekt rozbije. nechapu, proc potrebujes synchronizovat vypocet vuci realnemu casu!

Simuluje vesmír?

Co úplně jiný náhled na věc?

[Jendа]

Jó, Malý domeček plný FPGAček :). Spíš bych zkusil GPGPU, přecijen jsou dnes dostupnější…

[pc2005]

A to ještě nic není, když jsem v rámci svého výzkumu narazil na tohle tak jsem se mírně orosil .

[Jendа]

Hele, a nechtěl bys asi tak na měsíc emigrovat do Prahy a trošku nás v brmlabu v oblasti FPGA připovzdělat?

[pc2005]

No já nerad cestuju, takže emigrovat asi ne, ale přes mail nebo abíčkovkej jabber mě samozřejmě může kontaktovat kdokoliv .

Jinak ad brmlab: někdo někde linkoval video řezání plastu laserem na plotteru (jméno profilu bylo brmlab). Věděl bys jaký je zaostření toho laseru v praktické operaci (třeba i chvění motoru)? Tuhle jsme s kámošem kecali, když si vyráběl plošňák nad tím, zda má použít fix nebo nažehlování toneru, ale prej u nažehlování je u blbýho papíru šance, že okraje budou "chlupatý". Tak mě během diskuze napadlo, že by se dal ten papír teoreticky úplně vypustit a toner opatrně nasypat na celou plochu plošňaku a nechat laser vyřádit se a natavit/nalepit toner v místě ohřevu na měď.

Pokud nemáte s tím laserem co dělat (o čemž pochybuju ), tak to berte jako námět by: kolega z Liberce .

[Jendа]

No já nerad cestuju, takže emigrovat asi ne, ale přes mail nebo abíčkovkej jabber mě samozřejmě může kontaktovat kdokoliv .

Telelearning!

řezání plastu laserem na plotteru

Jediný „plast“, který jsme kdy přeřízli, byl polystyrenový kelímek z automatu na kávu.

PCB jsme zkoušeli - svítit near-UV laserem do fotocitlivého laku. Je to takové všelijaké, nevím, jestli zaostřením nebo něčím jiným. Každopádně bychom rádi udělali laserovou hlavici na RepRap - místo extrudéru se tam prostě dá laser.

Teď je ale trendem tohle.

[pc2005]

Jediný „plast“, který jsme kdy přeřízli, byl polystyrenový kelímek z automatu na kávu

Nepodceňuj PR .

Jo svícení UV do fotolaku mě taky před pár roky napadlo, ale nanášení barvy je jednodušší.

Teď je ale trendem tohle.

Hmm to přímo tiskli na měď? To si museli máknout aby ten prášek na tý mědi držel na správným místě (hlavně když nedrží často ani na papíru). Jinak ta metoda co jsem popisoval je vlastně to samý, akorát s vyloučením fotocitlivého válce na přenos prášku.

[Jendа]

Hmm to přímo tiskli na měď?

Jop, laserovkou s placatým průchodem (používají se třeba na potisk CD).

To si museli máknout aby ten prášek na tý mědi držel na správným místě

Po vyjetí tam drží silou vůle (nedýchat!), musí se nějak zažrat - buď prohřátím na danou teplotu (ale ne vyšší - roztekl by se a rozmazal) nebo několik minut v parách acetonu.

Jinak ta metoda co jsem popisoval je vlastně to samý, akorát s vyloučením fotocitlivého válce na přenos prášku.

Jo, a bojím se, že by ti ta měděná deska odvedla teplo z bodu, do kterého svítíš, tak rychle, že by se buď nic nezapeklo, nebo by se naopak připeklo rozsáhlé okolí…

[Stanislav Brabec]

Hmm to přímo tiskli na měď?

Jop, laserovkou s placatým průchodem (používají se třeba na potisk CD).

Už před lety existovaly laserovky, co uměly přímo exponovat světlocitlivé kovolisty.

[foldy]

joj to vypadá fakt dobře :) tak nějak to funguje na mém itaniu uměle vytvořeno..

[foldy]

skoro jo, jen je ten vesmír krapet menší :D

[Bedňa]

Foldy je známi u CERNu, neviem teda či je to on, ale možné to je

[foldy]

ne to nejsem asi já, ale o cernu vím dost, několikrát jsem s nima mailoval a řešil věci to jo...

[Jendа]

Přiznám se, že programování pro GPU vůbec nerozumím, ale co jsem koukal, kryptografické operace (bruteforce SHA1, SHA2, A5) se zrychlí klidně o tři řády, LFSR a podobné věci, na které lze použít bitslicing, ještě víc. Simulace částic v oddělených místech plynu by snad šla taky masivně paralelizovat, ne?

Navíc se to programuje ve vyšším jazyce, takže nejsi závislý na instrukcích jednoho konkrétního procesoru, a je to přenositelné, takže když se ti podaří ukecat správce nějakého clusteru, ať tě tam na noc pustí, můžeš to rozhodit přes tisíc strojů.

Osobně jsem si tedy myslel, že optimalizace strojového kódu na úrovni „tohle doběhne o dva takty dřív, takže se ještě stihne jedna operace“ skončilo někdy v 70. letech, a dnes ho používají maximálně čínští výrobci snažící se uřídit 3D CNCčko pomocí ATtiny :).

[pc2005]

Osobně jsem si tedy myslel, že optimalizace strojového kódu na úrovni „tohle doběhne o dva takty dřív, takže se ještě stihne jedna operace“

U FPGA se dokonce počítá s tím jak rychle doběhne z jednoho flipflopu signál do druhýho...

[Jendа]

Ale to nedělá aplikační programátor, ale takový ten soft, co to „kompiluje“, ne?

[pc2005]

Občas .

Rozhodně ale platí, že psaní HDL kódu s důrazem na to co se asi z daný sekce vytvoří, dokáže velmi pomoct syntetizátoru a placeru.

[Václav HFechs Švirga]

Jojo, znam pri projektech ve skole na fitkitu (VUT FIT bazmek se spartanem FPGA). Napises jednu vec, vysyntetizujes a nefunguje to, trosku to prepises (i kdyz by to treba v Cecku melo uplne stejny vyznam) a tralala, jede to.. magie

[pc2005]

Ono je to taky trochu kvůli tomu, že vytvoření projektu projde od zdrojových kódů (navíc VHDLkem se blbě vyjadřuje) dlouhou cestu, na které se to přes syntézu/mapping/placer/router ztratí část informací. Taky je implementace těch toolů neideální (=neotevřená) a tak nemusej prohledávat všechny varianty.

Nicméně ty tooly můžeš trochu popostrčit různejma volbama pro nastavení úsilí, občas se pak chytnou .

[foldy]

Rozdělit to nejde, oddělená místa plynu to sice jsou, ale závisí na míře komplexity a chaosu v celém celku. Kdyby se to řídilo časem tak by to šlo, ale ono je to řízeno entropií. Optimalizace strojového kódu je strašlivě důležitá, každá operace/zpoždění navíc se ti v 100000 iteracích projeví 100000x zpožděním, což není sranda...

[foldy]

jinak mě se to podařilo zrychlit ne o 3 řády ale o 7 časových řádů zatím.

[Foo Bar]

My jsme se tím trošku zabývali kvůli akceleraci RSA (DNSSEC) (prezentace je tady: http://ccnso.icann.org/meetings/sanfrancisco/workshop.htm) a přes veškerou snahu nás (hlavně kvůli přesunům dat) utloukl obyčejný vícejádrový procesor (tj. v souboji GPU vs. jedno jádro ještě vyhrávalo GPU, ale s počtem jader už to začalo být naopak).

Kdyby to někoho hodně zajímalo, tak k tomu máme i někde zdrojáky.

[Michal Kubeček]

Osobně jsem si tedy myslel, že optimalizace strojového kódu na úrovni „tohle doběhne o dva takty dřív, takže se ještě stihne jedna operace“ skončilo někdy v 70. letech, a dnes ho používají maximálně čínští výrobci snažící se uřídit 3D CNCčko pomocí ATtiny :).

Tak se zkus někdy podívat na kód přeložený gcc (se zapnutou optimalizací) a porovnat si ho se zdrojákem.

[trekker.dk]

To jsem v případě kódu pro ATmega párkrát udělal. Výsledek je děs a s novějším gcc to bylo zpravidla horší než se starším. Místo násobení sčítání v cyklu (ten procesor má hardwarovou násobičku), zbytečné nicnedělající instrukce a podobné chuťovky.

[Michal Kubeček]

Ne vždy jsou ty nesmyslně vypadající instrukce opravdu nesmyslné. Často se kvůli optimalizaci míchají instrukce z několika příkazů a některé instrukce, které nedělají opravdu nic, slouží jako hint pro prefetch nebo branch prediction. Aspoň na x86_64 to takhle funguje.

[pc2005]

Hmm atmega a branch prediction .

(Ale radši jsem se zeptal googlu )

Ideální by bylo kdyby trekker postnul kus kódu a jeho disassemblovanou část, ať tu nepovídáme na neznámými daty.

[little.owl]

AVR32 has branch prediction.

[pc2005]

Tak u 32bitovýho CPU je to celkem očekávatelné.

[trekker.dk]

Pár příkladů - už jsem je sem dokonce jednou psal, takže jenom copy & paste

1. to násobení konstantou - gcc vygenerovalo tohle

add r18, r18
add r18, r18
mov r19, r18
add r18, r18
add r19, r18
add r19, r18
; ... zde instrukce, které výsledek přičtou k indexovacímu registru

Místo mnohem rychlejšího:

ldi r19, 20
mul r18, r19 ; 2 tiky
; ... zde instrukce, které výsledek přičtou k indexovacímu registru
eor r1, r1

Překladač ignoruje fakt, že procesor má hardwarovou násobičku (násobení trvá dva takty)

(Ten eor - xor - na konci je k vynulování registru r1, kam se ukládá výsledek toho násobení. avr-libc předpokládá, že v r1 je vždy nula, tzn. kód, který to změní, tam tu nulu zase musí vrátit.)

2. zápis hodnoty do 3 po sobě jdoucích paměťových pozic:

unsigned char *j;
unsigned char a;

j = sdev->out_hlavicka; /* out_hlavicka je char[3] */
for (a = 3; a; a--) 
    *(j++) = b;

vygeneruje tohle:

adiw r26, 0x15 ; posun indexovacího registru
st X, r18
sbiw r26, 0x15 ; návrat na začátek struktury
adiw r26, 0x16 ; abychom se hned vrátili zpátky o byte dál
st X, r18
sbiw r26, 0x16
adiw r26, 0x17
st X, r18

místo mnohem rychlejšího:

adiw r26, 0x15 ; indexovací registr ukazující na začátek struct sdev
               ; se posune na prvek out_hlavicka
st X+, r18     ; hodnota v r18 se zkopíruje do tří po sobě 
st X+, r18     ; jdoucích pozic
st X+, r18

Tady překladač prostě ignoruje fakt, že a) pracuje s po sobě jdoucími daty a b) že procesor umí post-dekrement adresovacího registru.

3. kopírování bufferu:

v podání překladače:

movw r30, r10 ; r10:r11 obsahuje adresu bufferu, ze kterého se kopíruje,
              ; nahraje se do r30:r31
ld r24, Z+    ; Z je r30:r31, inkrementuje se
movw r10, r30 ; nové Z se uloží zpět do r10:r11
movw r30, r12 ; totéž pro cílovou adresu uloženou v r12:r13
st Z+, r24    ; kam se hodnota v r24 uloží
movw r12, r30 ; a nový ukazatel se vrátí do r12:r13
subi r16, 0x01 ; dekrementace počítadla a skok, pokud
sbci r17, 0x00 ; není nulové
brne .-22

v podání člověka:

   mov ZL, r10 ; jeden ukazatel do Z
   mov XL, r12 ; druhý ukazatel do X
1: ld r24, Z+
   st X+, r24
   subi r16, 0x01
   sbci r17, 0x00
   brne 1b

Každý průchod cyklem je v kódu od překladače prodloužen na dvojnásobek.

Někde mám možná ještě uloženo, co vznikne, když se člověk pokouší pracovat s jednotlivými bity číslených promenných...

[pc2005]

Njn koukal jsem se do bugzilly a opravdu tam podobný bugy jsou.

[joke alt="Vím taky tam jsou bugy"] O důvod víc přejít na Microchip [/joke]

Očividně maj rozhozený váhy pro optimalizace.

[trekker.dk]

O důvod víc přejít na Microchip

Co se osmibitových jednočipů týče, měl jsem možnost pracovat s obojím - PIC i AVR. Můj názor: člověk, který dobrovolně pracuje s PICem, je bláznivej masochista.

[little.owl]

+1

Zlate AVR!

[pc2005]

:-/ To, že na PICu člověk udělá řadič USB, asi moc nepomáhá, že?

Jinak ale v céčku je to snad jedno. Ideální je používat jejich makra na jména registrů a aplikaci si psát ve standalone režimu. Jako, že bych používal jejich vývojový prostředí to fakt nehrozí (zvlášť když jejich příklady byly napsány case insensitive a v linuxu jsem z toho pak málem zešílel).

[Jendа]

Myslel jsem tím hlavně programátory běžných aplikací, u tvůrců kompilátorů je to pochopitelné.

[Pepa]

A když to bude spočítaný, za měsíc, tak už to itanium nebude třeba ne?

[nyan]

Dulezita vlastnost OpenCL je prave nezavislost na HW, tudiz na instrukcni sade. Kazda generace GPU (a CPU taky), ktera prinasi trochu vice zmen, ma novou instrukcni sadu - tudiz jinej assembler. Navic samozrejme kvalita kompilatoru, jelikoz ho dodava vyrobce HW, zavisi od toho vyrobce. U CPU se myslim hlavne vyuziva SSE2, a u novejsich AVX.

Tudiz je tam trochu overhead - dulezitej kod (algoritmus) je v OpenCL, pak je tam nejakej kod kolem - ono se totiz (obvykle) OpenCL preklada primo pred spustenim, protoze nevite na jakem konkretnim HW pojede. Nicmene existuje moznost dopredu prelozit kod do binarek tech CPU/GPU ktere chcete podporovat, a pak poustet jen ty binarky.

AMD (predpokladam ze i nVidia) ma program, kteremu zadate opencl kod, a on vam ukaze assembler pro kazdej hardware, plus ruzne statistiky - cim je vysledny kod limitovan, predpokladany vykon na danem HW, procento "spakovani" instrukci do VLIW (u VLIW hardwaru), a dalsi. AMD ma myslim taky vlastni "intermediate language" - neco jako HW-nezavisly assembler.

BTW, ja sam s openCL si teprv zacinam pohravat tak kdyby vas neco zajimalo, klidne mi napiste na interstate60 /at/ runbox /tecka/ com

[vencas]

O zrychlení pomocí OpenCL rozhoduje povaha úlohy. Ukázkové aplikace (násobení matic apod) mají dokonale předpovídatelné přístupy do paměti, čehož lze využít a vyždímat z hardwaru maximum. Částicové simulace (nevím konkrétně, jen spekuju)), o kterých se tady psalo, nejsou tak hezky strukturované, pohybem se topologie mění a náhodné přístupy do paměti jsou v OpenCL katastrofou.

Nezávislost na HW je fajn, bohužel (zatím?) mají různé platformy taky svoje různé bugy (např. AMD špatně zarovnáva unie, Intel neumí anonymní unie, nVidia používá kód z cache i když se zdroják změnil), ale až se to časem zkonsoliduje, vzniknou nějaké knihovny, případně rozšíření jazyka jako šablony (pro kontejnery a tak), bude to dobré.

[nyan]

A jeste bych dodal - OpenCL je primo delane pro HPC, takze primo v standardu najdete napriklad povolenou (ne)presnost kazde operace, kterou musi HW splnovat.

[foldy]

to je celkem příjemné rozšíření :) kdyby itania skončily, budu se tím zabívat, vypadá to, že tam je pokračování budoucnosti. děkuji za váš čas :)

[deda.jabko]

Zkuste to udělat na 4 integer a 4 floating-point registrech na x86, jde to ale... Kdysi jsem to testoval v roce 2003 a rozhodoval se co nasadím, udělal jsem pár specifických úkolů : Itanium vs Xeon (2003-2004)

To je argument jak stehno. Mimochodem, x86 ma 7 GP registru a 8 FP, ale tyto procesory jsou uz passe jako kalhoty do zvonu.

Pokud si vezmu dnesni AMD64 a procesory sandy/ivy bridge mas tam pro vektorove instrukce 16 256bitovych registru, pocitac, ktery dneska ma 64 jader taky neni problem.

[little.owl]

Otazka zni zda-li lze jeho ulohu dobre paralelizovat, zase tolik o tom nerekl a to se pak tyka i uziti OpenCL.

[deda.jabko]

To je v konecnem dusledku jedno, pointa mojeho komentare byla v tom, ze delat zavery na zaklade pozorovani deset let starych procesoru, je hodne ,,odvazne''.

[little.owl]

Tak s tim souhlasim.

[foldy]

Jde o částice a jejich chování v turbulentním proudění(kompresory, turbodmychadla apod).

Itanium umí 3 větve takže dělám okolí 3 částic, které spolu právě interagují a jsou vzdálenější od jiných částic v tom lokálním okolí. Spustím současně všechny 3 interakce a mění se jejich polohy, rychlosti a enegrie dle závislostí obsažených v jiných registrech vztažené na dané podmýnky (teploty, síly rychlosti) a každá z těch částic dané parametry v jiných registrech malinko pozmění. 1 iterace musí být hotová v planckově čase nejpozději, rozpočítané podle počtu instrukcí na operaci a kmitočet. Podle toho kolik sad operací na jednu iteraci se vejde do daného časové úseku tak se provádí load/store dat, mění se minimum dat a postupuje se systematicky celým prostorem. Podmýnky se mění takže výpočet každého cyklu interace 3 částic netrvá stejně dlouho, musí být ovšem celkově vždy pod Planc. časem.

[Bluebear]

1 iterace musí být hotová v planckově čase nejpozději

Uf, cože?????

To jsi určitě myslel nějak jinak - počítač, který by dokázal provést instrukci za méně než Planckův čas, by musel být v jiném vesmíru

[foldy]

ano jasně že jsem to myslel jinak je to v poměrunapř 1:10^30, jde o to že ten poměr musí být co nejmenší, což samozdřejmě chápete, tím planckovým časem jsem se spíš snažil nastínit minimální přesnost, kterou to musí zachovat.

[Václav HFechs Švirga]

Právě Itanium to dá, jiné procáky ne, to je jasné .

<rejp - pochopil jsem, jak to autor myslel>

[foldy]

ok děkuji za info, ano máte pravdu je jich 7 a 8, na tom x86 dělal kod kamarad, ja ne, ja mam nastudovane jen Itanium, tak jsme to testovali, celkem už dost dávno.

AMD64 to je pro mě celkem nová věc, požívám techniku tak 2001-2004 zatím. Ještě nemám ani SATA disky :D:D

Zní to zajímavě jak se tam dělá paralelizace ?

[deda.jabko]

Zní to zajímavě jak se tam dělá paralelizace ?

Jsou tam operace typu SIMD.

Hledej rozsireni SSE2, 3 a 4. Treba tady: http://softpixel.com/~cwright/programming/simd/sse2.php

[little.owl]

A hlavne AVX.

[foldy]

díval jsem se na to rozšíření, ale není mi jasné jestli umí paralelně spustit souběžně 2 nebo více úloh v jednom cyklu.

[foldy]

napadla mě taková věc, ty registry mezi jednotlivými jádry na sebe vidí nebo ne ? Pokud ne a jedno jádro nemůže spustit více jak 1 úlohu nad konkrétnímy daty, nelze to pro můj úkol použít. Potřebuji souběžně ve stejném čase spustit min. 3 úlohy v reálném čase, které se navzájem ovlivňují nad daty z registrů které na sebe vidí. Podobně jako analogový počítač.

[nyan]

GPU ? jiste, v 2003-2004 jeste v tedle forme neexistovali, ale dnes jsou neprekonatelne v GFlops/Watt a GFlop/tolar...

A uprimne receno, sebelepsi CPU nikdy nedosahne na vykon GPU/vektorovych procesoru, uz jen kvuli tomu ze optimalizace na latenci jdou proti optimalizacim na propustnost...

In short, stavim becku piva, ze o 5 let v top 10 nejvykonnejsich masin sveta nebude jedina masina s ciste CPU procesory.

[Michal Kubeček]

A uprimne receno, sebelepsi CPU nikdy nedosahne na vykon GPU/vektorovych procesoru,

Ono to především nemá smysl porovnávat, protože GPU sice dosahují úžasného výkonu, ale hodí se jen pro velmi specifickou třídu úloh. Takže v těchto úlohách sice CPU porážejí na hlavu, ale v ostatních mají - sportovní terminologií řečeno - v zápisu DNS.

[nyan]

Specifickou tridu uloh - jestli tim myslite vsechno, co lze dobre paralelizovat, tak souhlas

Nicmene prave HPC simulace jsou neco, kde GPU obvykle vyniknou, tudiz mi prislo hodne zajimave, ze nekdo dela HPC na itaniu. Ale zas kdyz to zacali v 2003, pak to dava smysl, tehdy obecne pouzitelne GPU jeste nebyli.

[Michal Kubeček]

Opravdu všechno? Co třeba build většího projektu?

[Ondrej 'SanTiago' Zajicek]

Specifickou tridu uloh - jestli tim myslite vsechno, co lze dobre paralelizovat, tak souhlas

Nestaci aby sly paralelizovat, je treba aby ten paralelni vypocet byl dostatecne uniformni, tedy aby jednotlive thready bezely velmi podobne, 'nerozbihaly se'. Je spousta uloh, ktere jde velmi dobre paralelizovat, ale presto se na GPU vypocty vubec nehodi, prave kvuli tomuhle.

[foldy]

Děkuji za info, právě má úloha závisí na přesném načasování paralelních instrukcí, které se mnohdy liší v řádu nano-piko sekund. Jinak je vše špatně.

[little.owl]

na přesném načasování paralelních instrukcí,

Je to nejaky realtimovy system, ktery provadi mereni a musi ne ne reagovat? Jinak mi nejsou jasne ony casova omezeni/pozadavky. Navic, pokud je to spocitano vcas, je snad jedno, jestli je to spocitano seriove ci paralelne.

[foldy]

ee není to realtimový systém, ale tou paralelizací a typem výpočtu se ušetří statisíce operací navíc a výpočetní čas je objemově důležitý, spočítání 1 interakce 3 částic trvá nyní 114ps, ale v objemu 10^43 částic je to obrovský rozdíl, jestli to udělám za řád stovek ps nebo stovek ns. Každá instrukce a možnost dělat věci zároveň je významným ušetřením času. Ty kritické časy jsou dány tím, že při tom paralelním výpočtu 3 částic se ovlivňují různé parametry od kterých se odvíjejí každé z daných vláken. Pokud se něco předběhne byť jen o jedinou intrukci, je to celé špatně a neodpovídá to realitě.

[Jendа]

Hmm, tahle optimalizace fyzikálních simulací by mě docela zajímala, jmenuje se to nějak/jde to vygooglit/dá se někde sehnat popis, který pochopí i lama jako já?

Ty kritické časy jsou dány tím, že při tom paralelním výpočtu 3 částic se ovlivňují různé parametry od kterých se odvíjejí každé z daných vláken. Pokud se něco předběhne byť jen o jedinou intrukci, je to celé špatně a neodpovídá to realitě.

Řekl bych, že instrukce jsou v tomto případě už implementační záležitost (jak to na dostupném HW co nejvíc zrychlit - trošku mi to připomíná řízení Alfiho osmibitem :). Jednak ti jde o thread-safe paralelismus (to snad dneska zvládne každý vyšší jazyk defaultně) a pak to vypadá, že počítáš spoustu stejných výpočtů pro oddělené trojice částic. To by fakt šlo rozhodit po GPUčku nebo clusteru, ne?

(ber mě s rezervou, tomuhle fakt nerozumím :)

[Jendа]

thread-safe paralelismus

Nebo to ani ne, každý si hrabe na svém písečku a jde jenom o to, aby další krok výpočtu nezačal než doběhne předchozí, ne?

[foldy]

ne nedá se to vygooglit, je to můj vlastní model.

ne není to threat safe paralelzimus, je to spuštění různých intrukcí nad různými daty, které se vzájemně ovlivňují (a souvisí spolu) v rámci jednoho cyklu a procesoru v závislosti různých parametrů ( které mohou být také ovlivněny). Jsou to přímo 3 operace v 1 proc cyklu. Není to SIMD ale MIMD jako na starých vektorových Cray apod..

Ty trojice nejsou tak úplně oddělené,mohou zasahovat i jinam.

[Václav HFechs Švirga]

Příjde mi, že prostě objevil v Itaniu něco, co tam náhodou funguje jako hw akcelerátor těch jeho výpočtů - tedy že v jiném systému by musel řešit synchronizaci těch operací, což by výpočet podstatně zpomalilo, ale zrovna na itaniu to dokázal napsat nějak tak, že to funguje "samo" (synchronizaci vlastně zajišťuje samotná délka těch instrukcí a jiné hw paramtry toho cpu, se kterýma při tvorbě svého modelu počítal). Jestli je to dobrý či špatný přístup nevím, taky jsem to moc nepochopil, ale pokud mu ty výpočty vycházejí, zní to minimálně zajímavě. Ovšem obávám se, že při přechodu na GPU/FPGA by ten model musel celý překopat ;).

[Václav HFechs Švirga]

A pointa toho taky je, že pro něj asi to Itanium je relativně nenahraditelné, ale Intel to zajímat nebude, protože je to fakt extrémně specifické využití (něco jako že někdo ma doma umělou líheň na kuřata, kde je ohřev zařízen 100 W žárovkama a ony najednou nejdou sehnat a úsporky jsou tady úplně k hovnu - nejblbější příklad, co mě napadl ).

[pc2005]

Mě se zase nezdá, že by assemblerová ruční optimalizace na Itanium dávala o mnoho lepší výsledky než assemblerová ruční optimalizace na něco jinýho. Jakej má vůbec Itanium poměr cena/výkon proti třeba x86 nebo GPU?

[Jendа]

Mě se zase nezdá, že by assemblerová ruční optimalizace na Itanium dávala o mnoho lepší výsledky než assemblerová ruční optimalizace na něco jinýho.

Přečti si padesát ostatních příspěvků foldyho, je to tam popsané.

proti třeba x86

Netuším.

nebo GPU

U úloh vhodných pro GPU GPU jednoznačně vede, u úloh nevhodných pro GPU pochopitelně povede normální procesor.

[pc2005]

No z nich jsem pochopil to, že celý hw je skoro 10 let starý, za tu dobu se navýšil Mooreovým zákonem výkon jednoho čipu na docela hodně. Takže s dnešním hw (za +- stejnou cenu jako před 10 lety) by se to i s neefektivním počítáním furt mohlo výpočetně vyplatit.

[Václav HFechs Švirga]

Z těch jeho "děsivých" komentářů se zdá, že moc nepočítá . Spíše nějak "měří" chování toho Itania a vychází to... ale víc fakt nepochopím .

[Ondrej 'SanTiago' Zajicek]

Jakej má vůbec Itanium poměr cena/výkon proti třeba x86 ?

O tom nejvic vypovida jeho zastoupeni v rebricku Top 500 superpocitacu.

Puvodni verze (Merced) byly dost sklamanim co se tyce vykonu a i kdyz se pry nasledujici verze zlepsily, tak celkove Itanium zdaleka nesplnilo ocekavani do nej vkladana.

[little.owl]

Pokud nam nedate nejaky paper s rozumnym popisem, budou vase odpovedi generovat vice otazek nez odpovedi.

[foldy]

paper je moje hlava, smysl téhle diskuze ani není tak rozebrání mého problému spíše jako jestli to itanium na něco je.. a dá se nahradit něčím jiným. Nedokážu to komplexsně vysvětlit co dělám...

[Jendа]

Právě že je to čistá simulace (RT s nanosekundovou latencí by na PC asi fakt nešlo) a taky nechápu, jak se ten výpočet snaží zjednodušit. Ale přijde mi, že kdyby si předpočítal spoustu primitiv masivně paralelně a pak je nějak mergoval, tak by to taky mohlo jít a šlo by to rozhodit přes spoustu jader nějakého GPUčka.

[foldy]

to právě nejde, závisí na komplexitě celku a míře chaosu v daných lokalitách, výsledky nejsou závislé na čase ale na míře entropie . Nedá se to rozdělit a ty primitiva by musely měnit vlastnosti v průběhu výpočtu, takže to předpočítání by nemělo význam. Kritická je taky přesnost a načasování daných operací. Zjednodušení je uděláno tak, že se nachystají hodnoty v registrech, přes které se to paralelně prožene, přičemž se ty hodnoty průchodem dané částice můžou změnit a ovlivnit vedlejší částici v další operaci. Musí to být přesně načasované jinak to produkuje špatné výsledky. Vesměs to funguje jako analogový paralelní počítač. Problém je, že kdyby to nebylo v rámci jednoho procesoru/lokality, musel by se ovlivnit např parametr na vzdáleném GPU a skončilo by to tak, že by všechno na všechno čekalo.. Jedna částice totiž může ovlivnit jinou částici ve velmi vzdáleném bodě, proto to nejde rozdělit.

[stativ]

Já to z foldyho popisu chápu tak, že se to z globálního pohledu zpracovává lineárně a paralelizace na GPU by použít nešla. Jestli jsem to pochopil, tak to funguje tak, že se spočítají (paralelně) interakce tří částic. Každá z těch částic pak interaguje s dalšími dvěma částicemi, takže další výpočet je ovlivněn výsledky předchozího. Na GPU by pak merge stejně znamenal vše přepočítat znovu.

[Jendа]

Aha, ale tak to bude muset po každém výpočtu updatovat stav dalších ovlivněných částic, tj. hodněkrát seekovat po velkém úložišti, ne?

[foldy]

Ne dělám to jinak, pokud je to korekce, který se netýká těch 3 částic aktuálně, zapíše se to do volného registru (těch korekcí není tolik) a při load/store cyklu se nechají ve speciálním zásobníku, dostupném pro všechny procesory.

[little.owl]

Ano, dosel jsem k podobnemu zaveru ohledne moznosti paralelizace v jeho algoritmu. Nicmene to neodpovida na otazku, proc by implementace na soucasnem x86_64 musela byt nutne pomalejsi nez na deset let starem Itaniu, a prakticka stranka kdy autor - jak se zda - nema pristup k novejsimu Itanium HW - to musi byt brzda vyvoje jak hrom.

[foldy]

na x86_64 to nejde, právě kvůli tomu, že se nespouštějí paralelně 3 intrukce v 1 cyklu na 1 procesoru, využítám přesně této vlastnosti. Je to obrovská výkonnostní výhoda využívat principů podobných analogových počítačů na IA-64. Na deset let starém itaniu to ladím, až to budu mít hotové, prodám všechno vezmu půjčku a koupím co potřebuju, nebo koupím novější dostupné za aktuální peníze. Brzda vývoje to není, měl jsem možnost otestovat to na novějším itaniu 9000 řady a fungovalo to bezvadně, Itanium jako architektura je pro mě zatím zárukou, že to co odladím na staré Itanium 2 bude fungovat přesně stejně na 9000 jen rychleji.

[l0gik]

Ehm - tak spustíš ty tři instrukce po sobě, přinejhorším si předtím rozkopíruješ data po registrech, pokud by se měli ovlivňovat. On je pak procesor stejně udělá paralelně, když tam nebudou závislosti. Trojcestný "hardwired" paralelismus tedy něco málo přinese, ale rozhodně ne takové rozdíly, které tady zmiňuješ - samozřejmě x68 mělo (a má) méně registrů atd....), ale to zas vylepšuje lepší efektivitou cache (nevýhoda VLIW), frekvencí a hlavně cenou...

...a tedy za stejnou cenu získáš daleko více jader. Jelikož počítáš oblast plynu, kde se vzdálené molekuly neovlivňují, jde tam krásně implementovat paralelismus na vyšší úrovni (alespoň thread-level: itanium má max 4 jádra na core, x86 16) - různé domain decomposition metody aj.

Přečetl jsem celou diskusi a zatím mě Tvá argumentace nepřesvědčila, že víš, o čem mluvíš - pravděpodobně rozumíš dobře fyzice, ale ne HPC a paralelismu.

[foldy]

Ano HPC a paralelizmu nemusím ve všech oblastech hlavně mimo itanium rozumět.

Ehm - tak spustíš ty tři instrukce po sobě, přinejhorším si předtím rozkopíruješ data po registrech, pokud by se měli ovlivňovat. On je pak procesor stejně udělá paralelně, když tam nebudou závislosti.

Problém je hned s první věcí, tři instrukce se nesmí stát po sobě, ale zároveň, to je nutná podmínka. U každé takovéto paralelní interakce se totiž měří entropie procesoru (teplotně,napěťově,proudově), v daný čas výpočtu(přes ipmi[BMP],serial a externí snímače teploty na procesoru) dle které se všechno řídí a dále váží parametry dané interakce. Je to jedna z kritických podmýnek, bez které by to nefungovalo. Celé se to neřídí časem, ale entropií.

Musel bych navrhnout jiný přesný princip jak to udělat, kdysi jsem měl možnost začít na 72 proc SGI s RISC, ale nepodařilo se mi to vyřešit(taky jsem to neřešil úplně moc dlouho), tady bych asi dopadl stejně, musely by se nějak zesynchronizovat ty interakce tak, aby třeba na jádrech toho x86 procesoru proběhly všechny ve stejný čas paralelně a nic se nestalo kolem toho. Nevím jestli mezi jádry na sebe registry vidí, mění se tam některé věci v průběhu té paralelní interakce, nikdy jsem s multicore procesory nedělal.

Nejde o molekuly ale o částice, vzdálené se ovlivňují ale ne v rámci toho krátkého paralelního výpočtu.. Mám na to nějaké své mechanizmy.

Chápu tu výhodu těch peněz a rychlosti x86 nebo něčeho jiného. Tímhle principem, který jsem si navrhl posouvám tu úlohu k hranici vypočitatelnosti, ušetří to cca ~8,9^5 let.

Díky za tvůj zájem a čas, konzultace jsou pro mě důležité, děkuji.

[little.owl]

U každé takovéto paralelní interakce se totiž měří entropie procesoru (teplotně,napěťově,proudově), v daný čas výpočtu(přes ipmi[BMP],serial a externí snímače teploty na procesoru) dle které se všechno řídí a dále váží parametry dané interakce. Je to jedna z kritických podmýnek, bez které by to nefungovalo. Celé se to neřídí časem, ale entropií.

Tohle je dosti klicova vec - a z meho pohledu i silena.

přes ipmi[BMP],serial a externí snímače teploty na procesoru

Chcete mi tvrdit, ze v techto pripadech hraje roli casovani v radu trvani instrukci? Kouknete se treba na samplovaci frekvenci systemovych HW monitoru - je to velmi velmi pomale, se vsemi dopady na entropii systemu. Na strane druhe, nove Ivy Bridge procesory implementuji instrukci RdRand, ktera skutecne vyuziva vnitrni entropii procesoru.

[foldy]

Není to šílené, protože jste pochopil špatně význam té entropie. Není to vůbec entropie jako výraz který se používá v IT pro výpočet rand čísel, ale je to termodynamická entropie, čili míra neuspořádanosti stavu systému (degradace energie). Přiblížím... jde o termodynamickou entropii S. Jako když nalijete uspořádanou naftu do auta a vypustíte neuspořádaný plyn a míra degradace energie vám dá pohybovou energii pro běh motoru. Stejné je to s tím výpočtem, není to jen číselná simulace, ale funguje to jako celek stejně jako tepelný stroj. S tou entropií to musí být svázané, jde o to, že pokud by se to mělo udělat na něčem jiné,. musí se ta reálná termodynamická entropie změřit právě v průběhu toho paralelního výpočtu.

[little.owl]

Ja chapu entropii v sirsim smyslu a to treba jak v kontextu druheho termodynamickeho zakona, tak ve smyslu Shannona.

Jenze ve vasem pripade - pokud pouzivate data z teplotnich senzoru, je mira entropie velmi mala, nebot aktualizace techto dat je velmi pomala a z hlediska delky trvani instrukce temer lokalne stacionarni. Nova intelovska instrukce by vam slouzila nejspise mnohem lepe.

[foldy]

tam jsou 3 parametry, proud, napětí a teplo. takže je to dost přesné a stacionární to není. Jak by mi pomohla ta instrukce v měření energie pořebné k výpočtu a její míry degradace ?

[little.owl]

3 parametry, proud, napětí a teplo.

Jenze key-point je ze je to pomale, lokalne stacionarni, tudiz vam muze byt uplne jedno, jestli je to sejmuto ted nebo o 100 instrukci pozdeji. Pokud data pochazi z externich senzoru je to srovnani ospaleho sneka s F1.

Jak by mi pomohla ta instrukce v měření energie pořebné k výpočtu a její míry degradace ?

Protoze Intel implementoval a pouzil hardwarovy zdroj entropie, ktery na rozdil od vasich senzoru je rychly a vyuziva termalni sum uvnitr procesoru, ktery je zase mimo jine i funkci energie potrebne k vypoctu.

[foldy]

Aha, vy řešíte ty rychlosti, ne to je v pohodě, ono se to nebere jen z jednoho cyklu ale z celé operace balíku částic, to měřím cca 3s a za tu dobu se zpracuje okolo 9*10^9 interakcí. Proud se počítá cca po 1000 interakcích. Termalni sum ? Jak z toho dostat spotřebu procesoru a jeho efektivitu ?

[little.owl]

to měřím cca 3s

Pak je tedy snad jedno jestli je to x86_64 ci Itanium.

Proud se počítá cca po 1000 interakcích.

Proboha jak? 3*10^9 iteraci trva tri 3 sekundy, 1000 interakci cca 111 nanosekund. Jak takto rychle aktualizujete hodnoty spotreby? Tohle zadny externi HW monitor neumoznuje, odpovida tomu Nyquistova frekvence 4.5MHz, to je PC, ne spektralni analyzator.

Jak z toho dostat spotřebu procesoru a jeho efektivitu ?

Vy jste zabudoval termodynamicke parametry a performance charakteristiky konkretniho CPU do vaseho modelu? Spotrebu z toho nedostanete, ale my mluvili o entropii.

[Jindřich Makovička]

Moment... takže jedním z (mezi)výsledků té simulace je teplo vyprodukované CPU, které měříte a pak nějak dál zpracováváte?

Jestli tohle není šílené, pak už nevím co je :)

[little.owl]

Nedeterministicke vypocetni modely se obcas pouzivaji.

[foldy]

nejde jen o teplo ale o celkovou energii a míru její degradace. Teplo je jen jeden z parametrů.

[pc2005]

Ale docela zajímavé , výpočet počítá důsledky ovlivnění svého hardware svým během.

[l0gik]

A kde je problém si tu entropii změřit, uložit a pak sekvenčně udělat ty tři instrukce za pomocí uložených hodnot? Popř. v jednom threadu si dopředu ukládat ty náhodné hodnoty a druhým threadem si je jen vyzvedávat z paměti (nevím, jak je to čtení těch informací časově náročný, s tím jsem nikdy nedělal, pokud je pomalejší než výpočetní instrukce, tak se to hodí dělat tak... nebo pokud požaduješ čtení entropie v přesně definovaných intervalech, což si ale nedovedu představit proč - od toho je to entropie, aby nějaká její funkce nekorelovala s časem čtení).

Z principu je možné každý paralelní výpočet udělat sekvenčně, jediné, co co může vyžadovat navíc je "paměť" na počáteční stav, takže prostě není možné, aby to v Tvém případě nešlo.

Jádra mezi sebou na registry nevidí, thread level paralelismus jde v tomdle případě využít na nějaký domain decomposition, interakce, které jedna závisí na druhé se moc na jádra rozhodit nedají (ale často jde úlohu přeformulovat tak, že dostatečně velký blok výpočtu na okolí nezávisí, ale to jsme už zas u toho domain decomposition - která je ale z principu na takovéto výpočty velmi vhodná).

[little.owl]

Z principu je možné každý paralelní výpočet udělat sekvenčně,

Presne tak.

Popř. v jednom threadu si dopředu ukládat ty náhodné hodnoty a druhým threadem si je jen vyzvedávat z paměti ...

V okamziku, kdy tu pracujeme na urovni instrukci bych do toho thready moc netahal, neb jejich overhead bude znacny.

[foldy]

Jak jsem psal víše, není to entropie pro random number, ale termodynamická entropie pro tepelné stroje. S těmi registry by to bylo problém, celkově by to bylo velice složité rozchodit bez toho.

[l0gik]

Jenže jsou dvě možnosti: buďto opravdu závisí teplota procesoru (atd...) na datech, nad kterými je prováděn výpočet. Pak ovšem v podstatě tuto funkci analogově počítáš tím, že provádíš výpočty a měříš co udělá s procesorem. To je samozřejmě možné (byť velmi nepravděpodobné).

V tom případě je to ale silně závislé na konkrétní implementaci mikroprocesoru (stačí změnit latenci cache a najednou jsou k dispozici data, která dříve nebyla, procesor přestane čekat a zcela se změní teplotní gradient v daném místě výpočtu). Stejnětak to visí na rychlosti a přesnosti čidel v procesorech a X dalších proměných, které nejsou konstantní ani v jedné várce procesorů, natož v procesoru X generací novější.

Vzhledem k tomu, že Ti to běželo na dosti novější architektuře stejně, tak jsem dosti přesvědčen (samozřejmě, mohu se mýlit), že ta entropie, co získáváš z CPU, jsou jen náhodná čísla s vhodným rozložením a že Tvá metoda je ve skutečnosti něco jako pravděpodobnostní Monte Carlo s vhodnou heuristikou.

Jestli tomu je tak jde snadno zjistit: nasampluj si potřebná data z procesoru (teplotu atd...) z nějakého jiného výpočtu (nebo jen z běžného provozu) a instrukce na čtení entropie nahraď instrukcema na čtení těch nasamplovaných dat. Jsem dosti přesvědčen, že Ti vyjde to samé.

===

thread (či dokonce proces) level paralelismus pak samozřejmě nejde použít stejným způsobem, nicméně pro reálné použití na výpočetních clusterech či na GPU je to nutnost. Výkon CPU se zvyšovat už moc nebude, míra možného paralelismu ano.

[foldy]

Jenže jsou dvě možnosti: buďto opravdu závisí teplota procesoru (atd...) na datech, nad kterými je prováděn výpočet. Pak ovšem v podstatě tuto funkci analogově počítáš tím, že provádíš výpočty a měříš co udělá s procesorem. To je samozřejmě možné (byť velmi nepravděpodobné).

Ano přesně to dělám.

V tom případě je to ale silně závislé na konkrétní implementaci mikroprocesoru (stačí změnit latenci cache a najednou jsou k dispozici data, která dříve nebyla, procesor přestane čekat a zcela se změní teplotní gradient v daném místě výpočtu). Stejnětak to visí na rychlosti a přesnosti čidel v procesorech a X dalších proměných, které nejsou konstantní ani v jedné várce procesorů, natož v procesoru X generací novější.

Ano data jsou jiná. Pokud provedu stejný výpočet na každém ze 4 procesorů, data vyjdou malinko jinak. Ale vždy o stejný rozdíl, pokud provedu jinou sadu totožných výpočtů, ale to je v pořádku, tak se to má chovat, válce u motorů pálí taky každý jinak, ale pro totožné výbuchy budou hodnoty posunuty o určitou konstantu.

Vzhledem k tomu, že Ti to běželo na dosti novější architektuře stejně, tak jsem dosti přesvědčen (samozřejmě, mohu se mýlit), že ta entropie, co získáváš z CPU, jsou jen náhodná čísla s vhodným rozložením a že Tvá metoda je ve skutečnosti něco jako pravděpodobnostní Monte Carlo s vhodnou heuristikou.

Ty výsledky byly úplně jiné, ale byly správně. Zrekonstuovaný atraktor z té entropie a chování systému byl velmi podobný, čili dynamika byla zachována, ale samozdřejmě že šlo o jiný fyzikální systém (stroj) takže výsledky vyšli jinak a to je v pořádku. S tím nasamplováním, to jsem požíval při testování, ale pak je to rozmazané, chyby se pak nesou dál a dynamika není kompletní.

thread (či dokonce proces) level paralelismus pak samozřejmě nejde použít stejným způsobem, nicméně pro reálné použití na výpočetních clusterech či na GPU je to nutnost. Výkon CPU se zvyšovat už moc nebude, míra možného paralelismu ano.

Už není tak moc potřeba rapidně přidávat na výkonu, vývoj těch itanií příštích 5-7 let bude stačit. Migrovat nebudu muset, pokud to budou vyrábět a vyvíjet. Stejně mi to ještě bude trvat to připravit minimálně tak dlouho a tak velké úložiště jaké potřebuju taky není k dispozici zatím.

[l0gik]

Za předpokladu, že máš pravdu a tedy opravdu Tvůj výpočet nefunguje, pokud nedostane jako jeden ze vstupů charakteristiky jednoho konkrétního typu CPU, na kterém je výpočet spuštěn, pak je to IMHO náhoda. Vzhledem k tomu, že nikdo nezatručí, že se za pět let bude prodávat CPU se stejnou charakteristikou (protože tato charakteristika NEZÁVISÍ jen na architektuře CPU, ale na X dalších nedokumentovaných a NEZARUČENÝCH veličinách), zdá se mi to dosti krátkozraký postup.

Navíc, vzhledem k tomu, že se počítá vždy velký balík interakcí a průměruje, tak výpočet jedné interakce musí být jednoduchý, nebude tedy složité tuto funkci, kterou procesor analogově počítá, nějak odvodit a vyčíslit. Její výpočet je navíc na výpočtu nezávislý a tedy snadno paralelizovatelný na vedlejším jádru: takže bych doporučoval nějakou analýzou běžných výpočtů tuto funkci odvodit a oprostit se od závislosti na konkrétním kusu HW.

Ovšem z toho, co píšete (jakým způsobem ta data získáváte a používáte), tak dosti pochybuji, že opravdu to Itanium zrovna jako sideefekt analogově počítá nějaká užitečná data. Máte na to nějaký paper, kde to popisujete podrobněji?

[little.owl]

nikdo nezatručí, že se za pět let bude prodávat CPU se stejnou charakteristikou

Pokud vysledky nesedi, muze to poladit chladicem, pripadne termalni pastou ci otacky vetraku

Máte na to nějaký paper, kde to popisujete podrobněji?

Nema, jiz jsem se ptal.

[pc2005]

v daný čas výpočtu(přes ipmi[BMP],serial a externí snímače teploty na procesoru) dle

To sampluješ teplotu procesoru každou instrukci? :-O

[foldy]

ne, jde o balík interakcí, jde to přes průměr.

[foldy]

ano, pochopil jste to správně, na tom GPU by se to muselo přepočítat.

[foldy]

V dobe, kdy jsem se zabíval co zvolit za výpočetní architekturu (řešil jsem to na pár IRC fórech vývojářů), byl dost problém u GPU počítat floating point, což se už dnes patrně změnilo.

[w4rr10r]

Díky za politicky nekorektní článek, skvěle jsem se bavil. Popisované události už tak veselé nejsou, ale což… není každý den posvícení.

[Creator of Myths]

Proti politické nekorektnosti nic nemám, ale ten laciný humor byl opravdu laciný.

[Hue]

"... Western Digital po započetí prodejů značky Hitachi, si připsal 71 miliónů kusů." První asi překlep (započtení), druhý je nějak hooodně divnej slovosled...

[Luboš Doležel (Doli)]

Díky.

[Foo Bar]

> No řekněte sami, není kapitalismus skvělé zřízení?

Jako, že se v kapitalismu musí dodržovat uzavřené smlouvy?

> neboť Oracle měl mít s HP datově starší smlouvu zaručující, že Oracle tuto platformu bude podporovat.

No to je přece bezva, ne?

[Michal Kubeček]

Přesně tak. Nechápu, proč tolik komentátorů dělá z Oracle nějakou oběť zvůle HP a soudů. Stejně tak HP má závazky vůči svým zákazníkům a smlouvy s nimi musí dodržet (pokud se nedohodnou na jejich ukončení). Proto si smluvně pojistili, že Oracle bude tuto platformu podporovat, a je naprosto logické, že na dodržení smlouvy trvají.

[martin-ux]

ono to je skor "odplata" marka hurda za to, ako ho vyhodili z HP a ako musel platit za porusenie NDA po prechode do oraclu.

hasteria sa viac menej ako velki-mali chlapci.

[trekker.dk]

Jako, že se v kapitalismu musí dodržovat uzavřené smlouvy?

Kopat do kapitalismu je prostě moderní, a to i v případech, kdy to s danou tématickou vlastně ani tak moc nesouvisí.

A za ten rozsudek stejně může Klaus.

[Michal Kubeček]

…nebo Evropská unie. :-)

[Petr Tomášek]

Stejně do té doby všichni budemem mít voči chcíplý od toho, jak pořád čumíme do monitorů. 640x480 bude úplně stačit

[Martin]

Je to dnes krásná doba, kdy kdokoli, kdo má díru do zadku (včetně mě) a myslí si, že snědl veškerou moudrost (beze mě), může na web vyblejt spoustu nesmyslů a vydávat to za odborný komentář - že pane redaktore Ježku ? Itanium celosvětově drží cca 40% trhu s procesory/servery pro UNIX operační systémy. Vám to přijde, jako umírající "chcípák" ? No myslet si můžete samozřejmě co chcete. Další perla demagogická : Intel uvede ještě pár modelů Itania a pak to zabalí... to je opravdu perla. A zjistil jste si, kolik modelů svých CPU Power nebo SPARC má na roadmapě IBM resp Oracle/SUN ?? IBM uvede brzy Power 7+ a pak je zatím tma, Oracle nezveřejňuje nic... Takže co jste tím chtěl říci ? Že jediný Intel má jasnou roadmapu "UNIXových" CPU na dalších minimálně 7 let ?? Narozdíl od ostatních ? Nebo jak jste to myslel ? Myslíte, že to Intel záhy zabalí ? Proč ? Víte, že celosvětový trh CPU pro UNIX systémy (RISC/EPIC) je ročně ve výši cca 13 miliard USD ? A že přes 5 mld USD ročně z tohoto trhu ukousne Intel s Itaniem ? S vysokou marží... Vy byste to zabalil ? Uznávám, že konkurence systémů s CPU x86 (Linux/Windows) jsou na vzestupu a aplikace na těchto systémech se stávají stabilnější a mnohdy i rychlejší - a v důsledku toho se trh s CPU RISC/EPIC (Power, Itanium, Sparc, ..) snižuje rok od roka. Nicméně jsou kritické aplikace/databáze, které si dnes a v brzké době nikdo netroufne na x86/Linux posadit - důvod je dostupnost a stabilita celého systému především. Např. celá síť bankomatů a platebních terminálů v ČR (nejen zde) má za sebou výhradně stroje s "velkým" UNIXem - a divte se, minimálně v 80% jsou to servery HP s procesorem Itanium a HPUXem. Použil byste na tento komplexní provázaný systém, který musí obsloužit 30 až 500 bezhotovostních transakcí za vteřinu x86 s Linuxem ? Ono by to šlapalo, ale jak často byste musel celou síť shodit a patchovat servery nebo Linux? Nemluvě o nemožnosti řešení HW problémů (např vadný RAM čip apod) operačním prostředím tak, jak to umí UNIX. No prostě se mi Váš tendenční článek vůbec nelíbí. Plivat kolem sebe umí každý, ale aby jste si předem něco nastudoval... A jak někdo psal v komentáři výše: Smlouvy se musí dodržovat - a je úplně jedno, v jakém společenské řádu.

[plys]

Velmi pekny komentar, ktory poodhaluje ako to asi v skutocnosti je. Dakujem

[Jendа]

Mně teda hned první věta (to s těmi 40 %) přijde jako nesmysl…

[Luboš Doležel (Doli)]

Itanium celosvětově drží cca 40% trhu s procesory/servery pro UNIX operační systémy.

Tím UNIXem v tomhle případě myslíte i Linux, nebo máte na mysli 40 % toho trhu, co se každý rok rapidně zmenšuje a je podstatně menší než ten linuxový?

Vám to přijde, jako umírající "chcípák" ?

Mrkněte třeba na tu Wikipedii, jak tomu padá obrat a dodavatelé OS ruší svou podporu.

Ono by to šlapalo, ale jak často byste musel celou síť shodit a patchovat servery nebo Linux?

A jak s tím souvisí architektura CPU?

Nemluvě o nemožnosti řešení HW problémů (např vadný RAM čip apod) operačním prostředím tak, jak to umí UNIX.

Linux hotswap pamětí (i CPU) umí a už hodně dlouho. Musíte mluvit konkrétněji.

[z0rg]

Linux rastie na ukor roznych virtualok a virtualizacnych rieseni a nie preto ze je to popici ultra mega OS...Vlastne Linux je smiesne dieta 20 rokov pozadu co je lacne...a lacne. Tam to konci. Kdejaky homemade lamer sa tu bude ohanat redhatom, suse a neviem cim ale v enterprise sfere s tym nikdy nepracoval.

Veci akymi disponuje HP-UX,AIX,Solaris si moze Linux nechat zdat len z rychlika...ved to je uplne smiesne.

Korporacie co pouzivaju unix a prechadzaju na linux to nerobia kvoli tomu ze UNIX je na hovno a linux je uber duper OS ale kvoli tomu ze neustale hladaju sposob ako usetrit. Ale na dlhodobej trati zistia ze sa mylili.

Kto niekedy robil na dennej baze s obrovskymi environmentami UNIXov a Linuxov vie kde je pes zakopany a vsetic dojedneho tu tvrdime ze Red Hat je len banda prasivych hobbyist koderov.

Najvacssi "rozdiel" medzi UNIXom a Linuxom je to ze ked si kupujete UNIX tak si kupujete produkt kdezto pri linuxe si kupujete hmmm...hovno, ktore stale treba modelovat.

[Michal Kubeček]

Hodnotu vašeho rozboru poněkud snižuje, že vlastně nevíme ani kdo jste, ani co vlastně znamená "tu" ve větě "vsetic dojedneho tu tvrdime ze…", takže těžko posoudit, jak hluboké jsou ty vaše zkušenosti s enterprise systémy. I když… to, že si za obsahem svého příspěvku nestojíte ani natolik, abyste se odvážil k němu přihlásit, určité vodítko dává…

[aaaaaaaaaaaa]

Ale ma pravdu v tom, ze Linux je v porovnani napr. so Solarisom len nedorastene dieta.

Konkretne pripady, ktore mi chybaju v Linuxe:

1. Manazment beziacich sluzieb vratane nejakeho warningu v pripade padu, pokus o restart, rozumna podpora "runas" a capabilities
2. Zones - "chroot", ktory sa aktualizuje a moze byt pouzity k izolacii aj na sebe zavislych aplikacii bez vacsich problemov, pritom sa daju pouzivat ako plnohodnotny virtual
3. ZFS - volume management so snaphotami, volitelne deduplikaciou (zalohy) a sifrovanim, to sa v produkcnej verzii nevidi len tak

[kavol]

... Red Hat je len banda prasivych hobbyist koderov.

aniž bych tento výrok chtěl nějak potvrzovat nebo vyvracet, zeptal bych se, a ve které firmě to prosím ráčí býti lepší?

[little.owl]

To by mne take zajimalo. V praxi se za IP casto schovava jen neskutecny svincik a bordel, nikoliv technologicky naskok.

[j]

lol ... a proto se vsechny aktualni superpocitace stavi na linuxu ... protoze je nestabilni a nahovno ...

[Martin]

asi nebudu umět odpovědět na vše... ale 40% podíl na trhu jsem měl na mysli v rámci procesorů RISC/EPIC pro systémy "velkého" UNIXu (AIX, HPUX, Solaris, ..) případně úplně proprietálních systémů typu OS400/OpenVMS/... Prodeje CPU x86 (Intel Xeon, AMD,...) jsou samozřejmě řádově někde jinde (vyšší, pro jistotu :) ) - a to značně. Takže abych odpověděl, CPU typu x86 pro Linuxový svět tam nezahrnuji. (Jistě, Linux umí běhat i na Power, Itaniu i Sparcu, až mě bude někdo opravovat...ale to sem nepočítám, to je zlomek instalací).

No mě se primárně nelíbí označení Itania, jako chcípáku - souhlasím s Vámi v tom (i jsem to psal výše), že tržní podíl těchto CPU padá dolů v porovnání s x86 světem, ale tak pak, prosím, označte za "chcípáky" i Power a Sparc, jsou na tom úplně stejně (nebo i hůře) z tohoto pohledu.

Nejsem architekt CPU ani Linuxu nebo UNIXu - nicméně když se tady "navážíme" do HP, tak třeba HPUX 11v3 je na trhu asi 4 roky a bude až do roku 2022 - se stejným jádrem, pouze se 2x ročně vydají aktualizace, které ale nejsou povinné - prostě ten systém běží a běží a běží - což u aplikací typu "bankomaty" nebo řízení výrobní linky, která jede 360dní x 24hod je zatraceně důležité (můj názor). A UNIX je vždy psán tak, aby nejlépe 100% využil HW architekturu daného CPU, tzn HPUX na Itanium, AIX na Power atd... Jinými slovy HPUX nerozjedete na IBM Power, AIX nespustíte na Itaniu... Kdežto jádro open Linuxu se může díky zásahu vývojářů měnit neustále (někde jsem na to na webu narazil, ale nevím, už kde), třeba 40x denně - a pak byste mohli patchovat neustále (chápu, že se to nedělá). A celé to musí běžet na "všech" x86 CPU, kterých se denně chrlí miliony v různých specifikacích a 2x ročně vyjdou novinky... prostě Linux nemůže z podstaty vyždímat HW serveru ani CPUčka tak dokonale, jako UNIX. To není závada nebo hanění LINUXu, to je prostě realita. BTW: to samé jako pro Linux zde paltí i pro Windows.

Možná to částečně odpovídá i na poslední dotaz. 90% serverů x86 s Linuxem, které jsem viděl a u kterých odešel čip na RAMce, tak šly rovnou "nadržku", konec... Linux to možná umí (fakt nevím, věřím Vám), ale už to většinou neumí to železo pod ním.

[Michal Kubeček]

pro systémy "velkého" UNIXu

Nedávno jsem se na webu s žebříčkem 500 největších "superpočítačů" díval, jaký systém běží na prvních deseti. Na devíti z nich to byl Linux. Nabízí se tedy otázka, nakolik je ten přívlastek "velký" ještě na místě…

třeba HPUX 11v3 je na trhu asi 4 roky a bude až do roku 2022

Podíváte-li se na celkový lifetime RHEL 4 nebo SLES 9, dojdete k velmi podobnému (ne-li většímu) číslu a nic nenasvědčuje tomu, že u novějších verzí by tomu mělo být jinak.

pouze se 2x ročně vydají aktualizace, které ale nejsou povinné

Frekvence vydávání updatů má velmi malou vypovídací hodnotu, protože z ní nijak nevyplývá, že interval je tak dlouhý proto, že to častěji nebylo potřeba.

prostě ten systém běží a běží a běží - což u aplikací typu "bankomaty" nebo řízení výrobní linky, která jede 360dní x 24hod je zatraceně důležité

Opravdu si myslíte, že se pro takové aplikace Linux nepoužívá? Používá - a dnes už pravděpodobně i častěji než to, čemu vy říkáte "UNIX".

Jinými slovy HPUX nerozjedete na IBM Power, AIX nespustíte na Itaniu...

Což je také jeden z důvodů, proč řada zákazníků tyto systémy opouští a přechází na Linux. Ono to není jen kvůli ceně.

Kdežto jádro open Linuxu se může díky zásahu vývojářů měnit neustále (někde jsem na to na webu narazil, ale nevím, už kde), třeba 40x denně - a pak byste mohli patchovat neustále

To myslíte vážně? Opravdu si myslíte, že někdo v enterprise prostředí používá poslední commitnutou verzi z gitu? Pokud ne, tak proč vůbec takhle zavádějící argument používáte? Používají se maintenance updaty, které procházejí podobným procesem jako u toho HP-UX. Rozdíl je jen v tom, že kdo má zájem, může se podívat, co v nich je a jak se k nim došlo.

[z0rg]

ALE TY SI UPLNE JEBNUTY CECHUN OMFG.

SORRY ALE TAKY CHUJ AKO TY MA DENNODENNE VYTACA NA RED HAT SUPPORTE (zakaznik ma enterprise kontrakt) a je to nieco strasne...Chceme od nich root cause analyzy a podobne veci...nic zlozite (castokrat si to aj robime sami) ale to je boj s kokotmi z Brna kde jedina ich odpoved na cokolvek je "update na latest release"...ako sorry za nadavky ale uz len dnes som tak vytoceny ze ma ide z toho jebnut...

Což je také jeden z důvodů, proč řada zákazníků tyto systémy opouští a přechází na Linux. Ono to není jen kvůli ceně

Ten dovod je preto taky lebo korporacie ako HP,Oracle a IBM su jebnute a tak isto aj zakaznik....castokrat maju kontrakty s kade kym a potom im nechcu (je problem) zaslat danu "partu" ked sa nieco dodrbe na servery. Preto prechadzaju na Linux lebo je to lacne a party ti urobi kde kto. Ale oni na to pridu ze to nie je vsetko.

Jeden nas zakaznik pred 3mi rokmi premigroval zo Solarisov na rhely a dnes migruju naspat. Lebo tie Solarisy su jednoducho bambzilioooon lepsie ako spicene Red Haty co sa zjebavaju kazdu chvilu a su s nimi problemy.

To myslíte vážně? Opravdu si myslíte, že někdo v enterprise prostředí používá poslední commitnutou verzi z gitu? Pokud ne, tak proč vůbec takhle zavádějící argument používáte? Používají se maintenance updaty, které procházejí podobným procesem jako u toho HP-UX. Rozdíl je jen v tom, že kdo má zájem, může se podívat, co v nich je a jak se k nim došlo.

Nie latest commity ale ver tomu ze sa pouzivaju aj nove veci. Jeden nas zakaznik (circa 50 serverov) pouziva celkom nove kernely.

[little.owl]

ALE TY SI UPLNE JEBNUTY CECHUN OMFG. SORRY ALE TAKY CHUJ AKO TY MA DENNODENNE VYTACA NA RED HAT SUPPORTE

Neprehanite to jiz trochu?

[z0rg]

Ja sa ospravedlnujem neurazam vsetkych cechov...mam par dobrych a naskillovanych kolegov ale dennodenne ma vytacaju v Red Hate.

Preto aj menim zamestnanie.

[Lol Phirae]

Preto aj menim zamestnanie.

Jdeš dělat operátora hovnocucu?

[pavlix]

ALE TY SI UPLNE JEBNUTY CECHUN OMFG.

SORRY ALE TAKY CHUJ AKO TY

Asi bych měl varovat tvého ošetřujícího lékaře, ať ti nepůjčuje počítač.

[trekker.dk]

Je to zajímavé, ale ve významné části případů, když se tu objeví příspěvek tohoto řažení, je jeho autorem neregistrovaný a nepodepsaný slovák.

[podlesh]

A na těch redhatech provozujete db2, že?

[pavlix]

SQLERRMC=DB2ADMIN.KOKOT

Stučné a výstižné.

[Michal Kubeček]

Tak to je síla… Dostalo mne ovšem, když jsem se dole na stránce pod celým tím elaborátem dočetl

Chyba AnonymousUserException!
Pokud chcete přídat komentář, musíte se přihlásit přes účet na Gmail, Facebook, G+, Twitter nebo LinkedIn.

Kouzlo nechtěného… :-)

[waa]

to bude mozna schvalne…

[Lol Phirae]

ALE TY SI UPLNE JEBNUTY CECHUN OMFG.

SORRY ALE TAKY CHUJ AKO TY MA DENNODENNE VYTACA NA RED HAT SUPPORTE (zakaznik ma enterprise kontrakt) a je to nieco strasne...

Zkus nejdřív tohle před voláním na support, třeba se pak s tebou bude někdo bavit, evidentně se ti to tlačí na mozek.

[frEon]

vidis, ja sem na trojstovku solarisu pred 2 tydny instaloval kernel patch 147441-21, pred par dnema vysel "reuired/security" patch v revizi 22. Tak mi tu neco povidej o novejch kernelech...

[Jendа]

Děkujeme za rozšíření slovní zásoby.

Nie latest commity ale ver tomu ze sa pouzivaju aj nove veci. Jeden nas zakaznik (circa 50 serverov) pouziva celkom nove kernely.

Aha, takže protože někdo používá nová jádra, tak je celý Linux úplně na nic.

[kyytaM]

LOL. A co si myslis, ze co ti povedia HW vendors? Mate posledny mikrokod/firmware/OS na diskovom poli/blade chassis/SANdirectore? Nie? Tak chodte do pice...funguje to tak vsade, len pri OSS mas vyhodu v tom, nie si odkazany na jedneho spasitela, ale vies sa v tom povrtat aj sam, respektive nejaky iny dodavatel...

[j]

Muzu potvrdit - gold support dellu (garance zahajeni opravy do 4 hodin) ... kolega se snima 14 dnu dohadoval, nez se uracil nekdo prijet a vymenit MB. Od ty doby kupujem vsechno jen s NBDckem, protoze si stejne musime koupit rezervni HW - support khovnu prece nebudem platit.

[R]

Normalne su tie 4 hodiny "after diagnosis", tzn. casto chcu logy a pod. Ak sa s tym nechces babrat, zaplat si "mission critical".

[kavol]

Použil byste na tento komplexní provázaný systém, který musí obsloužit 30 až 500 bezhotovostních transakcí za vteřinu x86 s Linuxem ? Ono by to šlapalo, ale jak často byste musel celou síť shodit a patchovat servery nebo Linux? Nemluvě o nemožnosti řešení HW problémů (např vadný RAM čip apod) operačním prostředím tak, jak to umí UNIX.

ano, to umí jedině UNIX, a proto například NYSE, kde není transakcí 500 za sekundu ale o několik řádů víc, jede na Linuxu (a mimo jiné i x86 - Opterony)

[little.owl]

[sachy]

Na to se používají mainframy, ne trapné nixové servery. Garantovaná dostupnost 99.9999%, 40+ let *binární kompatibility a další featury žádný jiný enterprise systém nenabídne (hot-swap libovolného hw samozřejmostí) :)

Nezřídka na nových mainframech běží joby z doby nebreč, zkompilované pro 20, 30 let starou verzi procesoru a systému - běží a budou běžet dál.

Na milionech transakcí za sekundu a/nebo při masivním I/O si linux ani neškrtne...

[Käyttäjä 11133]

Garantovaná dostupnost 99.9999%

To totiž nezaručí ani ten zSeries box, když Tier 4 má OČEKÁVANOU dostupnost 99,995%.

[sachy]

Tier 4 není konec světa, ba ani fyzikální limit.

[Käyttäjä 11133]

Můžeš tedy nabídnout protipříklad datacentra (nejlépe vlastněného soukromou společností, ale vezmu i public sector) které má primární infrastrukturu na vyšší úrovni než Tier 4?

[aaaaaaaaaaaa]

6 deviatok sa zevraj vyzaduje u obrannych systemov USA a garancia sa zevraj robi tak, ze je rozumne zarucenych 5 deviatok a ostatne sa dorovnava tym, ze sa pocita s platenim pokut. Neviem ako u zSeries, ale mne bolo povedane, ze viac ako 5 deviatok nikto skutocne nemoze dat.

[deda.jabko]

pokud pocitam dobre, tak 5 devitek je vypadek na cca 3s jednou za rok, 6 devitek by pak melo byt 0.3s.

[Jendа]

Přijde na to, jestli jsou to devítky za desetinou čárkou u těch procent nebo devítky celkem.

[sachy]

Počítají se devítky celkem, 6 devítek = 99.9999%. Jinak by 90% bylo -2 devítek, a to zní trochu šíleně:)

[Zadejte vaše jméno]

Na milionech transakcí za sekundu a/nebo při masivním I/O si linux ani neškrtne...

No tak zrovna cena/vykon bude u amd64 urcite vyhodnejsi nez u jakehokoliv mainframe.

[sachy]

No zrovna cena/výkon bude u grafických karet určitě výhodnější než u amd64.

Nejde jen o surový výkon, ale i o spolehlivost a bezpečnost.

[kavol]

Na to se používají mainframy, ne trapné nixové servery.

"The new trading platform includes at least 600 servers from Hewlett-Packard. Specifically, the list includes 200 HP ProLiant DL-585 quad-core servers and 400 ProLiant BL 685c blades with AMD dual-core Opteron processors, according to Red Hat." (zdroj)

- hm, to nezní moc jako "mainframy" ...

Garantovaná dostupnost 99.9999%, 40+ let *binární kompatibility a další featury žádný jiný enterprise systém nenabídne (hot-swap libovolného hw samozřejmostí) :)

jednak nevím, kde bereš ty procenta, a jednak mícháš hrušky a jabka

RHEL samozřejmě běží i na hardwaru, co umí hotswap; že to některý hardware neumí je věc jiná

40 let kompatibility se těžko nabízí, když firma neexistuje ani polovinu té doby - nicméně řešení pro běh starého kódu RH má, a samotný systém má aktuálně plánovanou podporu na 13 let od vydání, zatímco například u opěvovaného HP-UX vidím na wiki podporu konkrétní verze na "nejméně" 5 let po vydání

Na milionech transakcí za sekundu a/nebo při masivním I/O si linux ani neškrtne...

když jako protipříklad nestačí NYSE, tak co takhle LHC?

[sachy]

"All of the top 25 world banks run their businesses on mainframes.
71% of global Fortune 500 companies are System z clients."
Předpokládám, že ty firmy ví proč to dělají. viz: https://www.ibm.com/developerworks/university/systemz/

Z roku 2001 - "A single iSeries 400 system delivers an average of 99.9+% availability. According to data collected by IBM over the last two years, AS/400 and iSeries 400 owners have experienced on average less than nine hours of unplanned down time per year."
Dokáže tohle jeden linuxový stroj?
http://www.redbooks.ibm.com/redpapers/pdfs/redp0501.pdf

Ok, spustím na nejnovějším RHELu *binárku pro nejstarší RHEL?

LHC má zaběhnutou x64 infrastrukturu, nemá důvod přecházet. Respektive přepsání SW vyjde dráž než zachování infrastruktury.

[Jindřich Makovička]

"All of the top 25 world banks run their businesses on mainframes.
71% of global Fortune 500 companies are System z clients."
Předpokládám, že ty firmy ví proč to dělají. viz: https://www.ibm.com/developerworks/university/systemz/

Z roku 2001 - "A single iSeries 400 system delivers an average of 99.9+% availability. According to data collected by IBM over the last two years, AS/400 and iSeries 400 owners have experienced on average less than nine hours of unplanned down time per year."
Dokáže tohle jeden linuxový stroj?
http://www.redbooks.ibm.com/redpapers/pdfs/redp0501.pdf

Nedokáže a ani na tom nezáleží, protože nikdo nebude HA instalaci stavět na jednom 1U severu. Redundance komponent tady prostě funguje na jiné úrovni než u zSeries nebo iSeries. Zatímco u zSeries za chodu vyměníte book, u x86 vyměníte blade a jedete dál.

Ok, spustím na nejnovějším RHELu *binárku pro nejstarší RHEL?

Ve virtuálním stroji téměř jistě ano, to se koneckonců dělá v z/VM taky. V Herculovi spustí dokonce i tu binárku pro OS/360 ;)

LHC má zaběhnutou x64 infrastrukturu, nemá důvod přecházet. Respektive přepsání SW vyjde dráž než zachování infrastruktury.

To platí i pro přechod z Mainframe jinam.

[Michal Kubeček]

"All of the top 25 world banks run their businesses on mainframes.
71% of global Fortune 500 companies are System z clients."
Předpokládám, že ty firmy ví proč to dělají. viz: https://www.ibm.com/developerworks/university/systemz/

To, že něco běží na zSeries, neznamená, že to neběží na Linuxu…

[kavol]

"All of the top 25 world banks run their businesses on mainframes.

71% of global Fortune 500 companies are System z clients."

Předpokládám, že ty firmy ví proč to dělají. viz: https://www.ibm.com/developerworks/university/systemz/

opět, hrušky a jabka

System Z je obchodní název pro mainframy od IBM - hardware, a na tom hardware běží různý software, mimo jiné i RHEL

kromě toho, nebyla tu řeč o tom, kolik procent na čem běží, nýbrž jestli to Linux zvládne (a jestli se na to používá)

Z roku 2001 - "A single iSeries 400 system delivers an average of 99.9+% availability. According to data collected by IBM over the last two years, AS/400 and iSeries 400 owners have experienced on average less than nine hours of unplanned down time per year."

Dokáže tohle jeden linuxový stroj?

viz výše, zřejmě dokáže

Ok, spustím na nejnovějším RHELu *binárku pro nejstarší RHEL?

ne, proč bych to dělal?

- jak již řekl kolega, spustím na tom virtuálku ve které tu binárku spustím

LHC má zaběhnutou x64 infrastrukturu, nemá důvod přecházet. Respektive přepsání SW vyjde dráž než zachování infrastruktury.

cool ... takže ... vlastně to tedy na tom x86 fungovat může, přestože výše se tvrdí opak, hm ...

[Michal Vyskočil]

System Z je obchodní název pro mainframy od IBM - hardware, a na tom hardware běží různý software

Ono je to s mainframy ještě o něco zamotanější, protože mají Integrated Facility for Linux - IBM mainframe processor dedicated to running the Linux operating system, with or without z/VM.

[little.owl]

když jako protipříklad nestačí NYSE, tak co takhle LHC?

A nebo treba London Stock Exchange smashes world record trade speed with Linux.

[Jendа]

Jo, to si pamatuju, chvíli byly na Rootu reklamy „Londýnská burza přešla na Windows, zjistěte proč (sic!)“, a pak jim to popadalo, tak přešli zpátky :).

[Xerces]

Nechme promluvit čas. Musím říct, že s článkem se ztotožňuji i přes moudré a údaji oplývající komentáře . Arch. Itánium a komerční UNIXY nejsou zas takový terno, aby to nešlo nahradit x86 a Linux based systémy. Ten poměr stabilita/náklady je dost diskutabilní.

[Jendа]

Itanium celosvětově drží cca 40% trhu s procesory/servery pro UNIX operační systémy.

Asi se pohybuju ve špatných kruzích, ale skoro všechno, co vidím, je Linux nebo FreeBSD na x86_64. Takže… ^{[citation needed]}

Bankomaty bych jako příklad radši nedával, protože jak je to s bezpečností všichni víme…

[Michal Kubeček]

Jak už bylo naznačeno v jedné z předchozích reakcí, trik je patrně v účelově zvolené definici toho, co patří do základu.

Celý ten komentář je přehnaně optimistický (z pohledu Itania). Na druhou stranu, je potřeba si uvědomit, že i když platforma zvolna umírá, v enterprise sféře může takové umírání trvat ještě poměrně dlouho a podpora takové platformy může být komerčně zajímavá.

[jehovista]

Jestli dneska nekde bezi HP-UX, tak je to jen z historickych duvodu, kvuli nicemu jinemu.

[Käyttäjä 11133]

Jestli dneska nekde bezi HP-UX, tak je to jen z historickych duvodu, kvuli nicemu jinemu.

Tohle je taky pěkný hlod :)

[majk]

+1 Niektori nadsenci naozaj netusia ako to funguje v enterprise sfere. Posledni dvaja nadnarodni zamestnavatelia (korporacie) mali nasadene na systemoch prevazne HP-UX + zopar linuxov na menej kriticke aplikacie a nove projekty (opar pre kriticke aplikacie) pocitali vzdy s HP-UX-om. PS: dokonca aj buduci zamestnavatel (zhodou okolnosti dalsia americka telekomunikacna korporacia) je na tom velmi podobne.

[deda.jabko]

Posledni dvaja nadnarodni zamestnavatelia (korporacie) mali nasadene na systemoch prevazne HP-UX

vetsinou jsou tyto rozhodnuti ale politickeho charakteru nez technickeho.

[jehovista]

Ja jsem nadsenec, ktery ale taky dela v Enterprise sfere a s HP-UXem ma sve zkusenosti. System musi bezet dej se co dej a vsechno je dvakrat zalohovane, takze je napriklad potreba podporovat dva OS(kdyby jeden selhal). Byl to Oracle Linux + HP-UX, ale HP-UX uz se drzi jenom kvuli smluvnim podminkam.

[j]

Dyk ma pravdu ... kdo to provozuje, tak prevazne z financnich/politickych duvodu. Jednoduse menit neco co funguje je proste kravina. Pokud chces tvrdit opak, ukaz nejakou firmu, ktera si to porizuje prave ted a neco novyho na tom implementuje.

[Bystroushaak]

Whoah, sir, whoah. Calm your nips.

Když už nic jiného, alespoň dokáže použít odstavce.

[honza]

2Martin a dalsi: rypanec do kapitalismu byl myslen abstrakteji, v souvislosti s duopolem WD a Seagate kde je videt jak globalizovany kapitalismus funguje hodne odlisne od predstavy idealni trzni konkurence ktera prirozene minimalizuje ceny... v pripade harddisku je totiz situace zoufala a jeste mnoho let bude a trh s tim nic neudela protoze naklady na vstup na trh jsou tak vysoke ze se zadna konkurence neobjevi, kdyz objevi bude rychle koupena, a regulacni organy jsou bezzube...a vse zaplati zakaznik. skoda slov.

[Lord Vetinari]

Je všeobecnou pravdou, že udržovat při životě něco, co je již fakticky blízko stavu klinické smrti, nebo by to evoluční proces nechal sám o sobě dávno „chcípnout“, nemá moc smysl.

Rocny obrat intelu z Itanii tvori 4 Miliardy usd/rok. Rocny obrat celeho AMD (gpu+cpu+ zvysok) je 6.5 Miliard USD/rok. Z toho logicky vyplyva ze amd je v stave klinickej smrti.

Kalifornský soud v Santa Claře tedy nyní rozhodl, že tato smlouva je pro Oracle závazná a musí ji nadále ctít. A to i přes skutečnost, že Intel sice ještě pár nových Itanií na trh uvede, ale pak nastane definitivní šmitec.

Citation needed. Ma autor clanku dokumenty od Intelu ze po Kittsone nic nebude, alebo taha exkrementy z konca svojho travacieho ustrojenstva?

[Martin]

A odkud máte informace o tom jak velký je obrat Intelu s Itanii? Podle té Wiki to vypadá, že v roce 2008 prodalo 95% systémů s Itanii HP, dohromady za 4.4 miliardy (celé systémy, ne jen procesory). Takže i v tomto roce toho na Intel muselo zbýt o dost méně než 4 miliardy. A o rok později už to bylo jen 3.5 miliardy, tak kdo ví jak je to teď.

Takže když už jste se nám tak pěkně rozohnil, tak by to taky chtělo nějakou citaci, aby to nevypadalo, že si také taháte cosi odkudsi...

[Lord Vetinari]

Napisal som obrat, nie zisk. Dve rozdielne veci, odporucam nastudovat.

[Käyttäjä 11133]

Jenže když je celý turn over pro Integrity řadu 4,4mld (a HP Integrity dělá 95 procent salesu Itanií) tak těžko turn over jen na procesory může být 4mld USD, protože to by pak znamenalo že ostatní části toho řešení (desky, paměti, FC HBA,...) mají cost blízko nule, což asi nebude pravda, že? I kdyby samotné CPU dělaly 70% celkové ceny, celý market je pak (4,4mld/95)*100 = 4,7mld, 75 procent je pak 3,2mld což je méně než ty 4 mld. co tvrdíš a navíc těch 75 procent je hooodně optimistických.

[Lazar]

Ale nemá jít o obrat Intelu, ale všech výrobců za dodané Itanium-based systémy(servery?) zákazníkům. I když je Itanium určitě nákladnou komponentou z celého řešení pravděpodobně bude činit pouze menší část z celkové ceny (obratu). Z celkového obratu této platformy tak bude mít Intel jen odpovídající část (menší?), s ohledem na neznámou nákladnost vývoje a výroby lze těžko odhadnout výsledný zisk/ztrátu Intelu.

[Martin]

A kde je ta citace? Že by jsme začali ztrácet pevnou půdu pod nohama a tak začínáme používat oblíbenou taktiku - zkusit odvést diskusi jinam? Pokud si dáte tu práci a moji odpověď přečtete, snad mi dáte za pravdu, že tam žádný problém s rozlišením obratu a zisku není.

[Lord Vetinari]

S tou zeminou nedufaj. Ak ta potesi zdroj je ars/IDF ( hej neni to web formatu abclinuxu ale paci sa mi viac):

zdroj

[Martin]

No vida. Takže z toho plyne, že buďto kecá Gartner Inc., nebo kecá pan Jon Stokes z Ars Techniky, nebo došlo mezi 2009 a 2011 k zásadnímu nárůstu tržeb za Itania. Já se tedy mohu jen domýšlet co z toho je pravda. Nicméně pokud by došlo k nějakému raketovému růstu prodeje Itania, myslím, že by se Intel postaral o to, abych o tom věděl. Takže podle mne je nejpravděpodobnější, že na tom IDF 2011 někde byl slajd s tím, že trh se serverama s Itaniem je 4 mld dolarů (což docela sedí s tím Gartner Inc.) a ten pán z toho udělal, že Intel z toho má ten obrat. Ale třeba se pletu.

[Lol Phirae]

na tom IDF 2011 někde byl slajd s tím, že trh se serverama s Itaniem je 4 mld dolarů (což docela sedí s tím Gartner Inc.) a ten pán z toho udělal, že Intel z toho má ten obrat.

Přesně, 4 mld. USD obratu za procesory Itanium je čirá utopie.

[Lazar]

Zajímavé je srovnání cen Itanií před pár lety a nyní. Ve výčetce benchmarku TPC-C (test z roku 2007) je uváděna cena 31500$ za osazené Itanium 1,6GHz, ark.intel.com nyní zmiňuje u nejdražšího Itania cenu pod 4000$.

http://c970058.r58.cf2.rackcdn.com/individual_results/HP/tpcc.hp.SD.es.082107.pdf

http://ark.intel.com/products/family/451

[nyan]

Me prijde ze Itanium trochu umele pridrzuje(val) u zivotu Intel tim, ze tomu pridal nejake HW featury, ktere nedal Xeon-um... a pro HPC, po vstupu nVidie, Itanium ztratilo smysl, takze jedine specialni zakaznici...

[Jiri]

Já si dovolím se také, přidat k zástupu kamenujících za špínu, kterou tu autor článku zplodil.

Pokud by se autor alespoň otravoval přečíst si rozsudek, tak by mu vše bylo jasné. V rozsudku je přímo zmíněné od kdy a proč má Oracle povinnost podporovat Itanium: Tj. po koupi Sunu Oraclem se sešlo vedení HP a Oracle a Oracle dal opakovaně záruku, že s podporou Itania dále počítá. V rozsudku je též zmíněno, že HP nebude Oracle za tuto podporu nikterak platit, protože i před touto zárukou byla podpora platformy bezplatná (HP zaplatilo pouze první implementaci, tuším $200mil). Tedy mimo jiné stejná pravidla jako při migrace na IBM PowerPC.

Verdikt soudu: http://www.scribd.com/doc/101776176/HP-v-Oracle-Proposed-Statement-of-Decision

Pro zájemce pak, aby pochopili pozadí této kauzy: http://www.theregister.co.uk/2012/05/23/hp_project_blackbird_redwood_hp_ux/

[loki]

Zkrátka Intel si přijde na své, HP to jistě nedělá jako charitu, ale Oracle to má nyní soudně nařízeno a pochopitelně připravuje odvolání. No řekněte sami, není kapitalismus skvělé zřízení? Skoro to připomíná model pronájmu jistých stíhaček jistou malou evropskou zemičkou

Nutil je snad nekdo danou smlouvu podepsat? Smluvni zavazky se musi plnit, to je axiom. Nic proti autorovi, ale po precteni citovane casti jsem musel prestat cist.

[Lazar]

Otázkou je, nakolik zmiňovaná smlouva je detailní. Zda neobsahuje pouze obecný závazek produktové podpory, či například termíny dostupnosti produktů. V případě její obecnosti se asi lze těžko jednostranně domoci například termínů uvedení, kvality či ceny služeb. Bez znalosti obsahu zmiňované smlouvy můžeme o dalším vývoji jen spekulovat.

[w4rr10r]

Nejsem si jist, nakolik je ten tvůj systém postavený nad takovým axiomem bezesporný.

[Jendа]

Bezrozpornost nelze obecně dokázat, ne? :) Takže bych doporučil příště rovnou nějaký spor najít.

Podle mě defaultně předpokládá věci jako že smlouva neplatí podepsána pod nátlakem atd.

[w4rr10r]

Např. můžou být dvě smlouvy v určité situaci proti sobě.

[Jendа]

Pak byla druhou smlouvou porušena ta první, ne? (race conditions zanedbáme)

[w4rr10r]

Zanedbání race conditions je chyba a stejně dojdeme k tomu, že nemusí být možné splnit "smlouvy se dodržovat musí".

[Jendа]

Pak tedy např.?

[Ivan]

Celej ten spor je "pouze" v osobni rovine. Je to reakce na sarady v top managementu HP a SAPu, ktere se udaly pred rokem. Jeste pred dvema lety byly HP a Oracle velci kamaradi a dokonce byl na HPcku zalozen appliance db server dodavany Oraclem - Exadata. Pak se ti bosove mezi sebou pohadali a navic Oracle koupil SUN. Oracle jde navic tak daleko, ze stale jeste podporuje HP-UX na PARISCu. Tyhle procesory uz ale HP skoro deset let nevyrabi.

Pro HP je to velka rana, protoze skoro 30% jejich enterprise serveru se dodava prave s Oraclem. Ted maji ale smulum protoze se zacali paktovat se SAPem a to jim Elisson nedovoli.

PS: Itanium ma jeste jednu "vyhodu". Nema v sobe itegrovany radic pameti. SGI NUMA architektura Altix pouziva prave Itanium. Kazdy procesor ma svuj radic, ktery mu zpristupnuje jeho "lokalni" RAM a navic jsou vsechny radice propojeny siti.

[faidron]

Tu aspon vidno kdo koho potrebuje. HP potrebuje Oracle, ale to nie je naopak. HP ma mrzutu buducnost. Co sa SAP tyka tomu je to jedno, ten si na svoje prachy pride stejne tak, otazne je ze ktory menezer z toho bude profitovat.

[kyytaM]

SAP a Oracle su momentalne vo vojnovom stave. ;)