Vlákno názorů k článku Scheme: kostlivec ve skřini nebo nehasnoucí hvězda? od respect - Jen poznamka k rychlosti jazyku: 1) hodne zalezi na...
-
Článek je starý, nové názory již nelze přidávat.
-
respect (neregistrovaný)Jen poznamka k rychlosti jazyku:
1) hodne zalezi na konkretni uloze
2) hodne zalezi na na efektivite napsaneho programu
3) hodne zalezi na pouzitych knihovnach
---
Obecne se daji jazyky rozdelit do 3 skupin a uvadim jen vyhody nevyhody tykajici se performance:
kompilovane na stroji vyvojare:
+ rychly start u uzivatele
- nutne mit stejny kod s podporou MMX/SSE/AV i bez ni (pokud compiler vubec doda jejich podporu)
- velka roztristenost dat kvuli nahodne alokaci => vysoka spotreba cache, vysoky cache miss
bezici ve VM - JIT (mluvim o Jave, o ktere toho vim nejvic, ale bude platit i +/- pro ostatni):
+ optimalizace na velikost cache
+ vyuziti vsech instrukci procesoru dostupnych v dobe tvorby VM
+ alokace na heapu zarucuje lokalitu dat => mala spotreba cache, skoro nulovy cache miss
- nutnost nacteni VM pred programem => pomaly start
- garbage collection
interpretovane:
- nemaji zadnou performance vyhodu (aspon si nemuzu zadnou uvedomit)
---
zpet k performance prvnich 2 reseni:
1) aritmeticke operace jsou prakticky stejne rychle (logicky, protoze vysledny kod JIT i bezneho compileru je prakticky stejny)
2) cena cache miss je obrovska (2-4 cykly pri pristupu do cache vs. stovky-tisice cyklu pri pristupu do RAM)
3) velke mnozstvi vytvarenych objektu (treba v iteraci) neprospiva Java a spol. kvuli GC
4) systemy s GC maji obecne vetsi spotrebu pameti
5) JVM je prozatim dost neoptimalni, jen JDK 6 prinesla zrychleni cca. 20% a chybi podpora alokace objektu na stacku (ktera by mela pomoct s bodem 3)
6) casto se pri testech srovnavaji nesrovnatelne veci: srovnavani 8-bit stringu v C versus. srovnavani 16-bit Unicode retezcu s ohledem na lokalizaci v Jave (jan aby byl clovek obezretny)
7) dnesni JIT pouzivaji hodne agresivni strategie na optimalizaci - dynamicky inlining/deinlining apod.
8) pokud udelate test v jehoz prubehu se bude nacitat nova trida (napriklad poprve pouzijete tridu MyVector az uvnitr mereneho useku), tak v JIT do testu zapocitate i nacitani teto tridy, ktera se ale realne nacita jen 1x za cely zivot programu a tutiz neni pro vykon smerodatna
Snazil jsem se udelat fakt jenom hodne rychly prulet vecma k zamysleni a rozhodne se nejedna o nic uplneho, tak prosim nekamenovat. Nemam rad kecy typu X je rychlejsi nez Y, protoze to nic nerika o podminkach a konkretnim ukolu. Navic +- 10% vykonu je dnes absolutne irelevantni zalezitost. Daleko markantnejsi dopady maji pouzite algoritmy nez to jestli se jedna o C-family/Java/Python.
Zbyva dodat, ze JIT zatim ceka jeste dlouha evoluce (v podstate je jeste na zacatku), zatimco klasicke compilery uz jsou dlouhodobe doladovane k maximalnimu vykonu a uz narazi na hranici svych moznosti.
Dobre je si o tom neco precist (doporucuju Google), rychle jsem nasel jen tohle: http://www.idiom.com/~zilla/Computer/javaCbenchmark.html -
I/O (neregistrovaný)Z tohoto komentáře mám pocit, že jeho autor má o běhu programu na nižší úrovni jen velmi mlhavé a nedostatečné vědomosti. Některé poznámky mi připadají naprosto "mimo":
"nutne mit stejny kod s podporou MMX/SSE/AV i bez ni (pokud compiler vubec doda jejich podporu)" - co je tím přesně myšleno? Jaký stejný kód, stejný kde?
"velka roztristenost dat kvuli nahodne alokaci => vysoka spotreba cache, vysoky cache miss" - prosím??? Co tím myslíte přesně?
"alokace na heapu zarucuje lokalitu dat => mala spotreba cache, skoro nulovy cache miss" - cože???
"optimalizace na velikost cache" - jaké cache?
V podstatě vůbec nevím, co chcete říct a o čem to vlastně mluvíte a to se programováním - jak v Assembleru, tak v C - zabývám skoro 20 let. A mám takový pocit, že to není mou neznalostí, ale tím, že to co tvrdíte nemá ani hlavu, ani patu - asi jako když v béčkovém sci-fi se snaží někdo působit rádoby odborně.
"vyuziti vsech instrukci procesoru dostupnych v dobe tvorby VM" - to samo o sobě naprosto o ničem nevypovídá. Výkon programu v daném případě stojí a padá s bytekódem a je celkem lhostejné, jak je tento kód interpretován VM. Speciální instrukce už nemohou vůbec nic zachránit.
"cena cache miss je obrovska (2-4 cykly pri pristupu do cache vs. stovky-tisice cyklu pri pristupu do RAM)" - to obecně vůbec neplatí - omezujete se na jednu architekturu a ani na té to obecně není pravda.
"nesni JIT pouzivaji hodne agresivni strategie na optimalizaci - dynamicky inlining/deinlining apod." - co je na tom jako agresívního? To je ta nejprimitivnější optimalizace a často je sporné, jde-li vůbec o optimalizaci nebo naopak.
"Navic +- 10% vykonu je dnes absolutne irelevantni zalezitost" - pokud je myšlen celý program, tak budiž. Pokud by se to týkalo nějakého vnitřního podprogramu, tak i těch 10% je moc. -
respect (neregistrovaný)prectete si prispevek, na ktery jsem dal na konci link a odkazy, na ktere se odkazuje ... je tam pomerne dobre popsany rozdil mezi JIT a zkompilovanym kodem a nema cenu, abych to prerikaval ... nemam silu odpovidat na otazky, ktere vysvetluji co je to cache procesoru, co je cache miss apod.
jeden citat za vsechny: "Výkon programu v daném případě stojí a padá s bytekódem a je celkem lhostejné, jak je tento kód interpretován VM" ... v JIT neni nic interpretovano, vse je kompilovano Just-In-Time do strojovych instrukci pri class loadingu => zde se byte-code nahrazuje nativnimi instrukcemi procesoru (vcetne SSE/AV) a zalezi ja implementaci JIT jak moc jich vyuzije -
Rejpal (neregistrovaný)Přihřeju polívčičku panu Ponkrácovi a zarejpu si: "1) Pointers make optimization hard" je pitomost, protože to je již osm let vyřešený problém. Aliasing nikdo neignoroval, při psaní pořádného kódu se s ním musí počítat (resp. musí se počítat s tím, že se mu musí zabránit), a není to až takový problém. :-) GC lze používat i v C a C++, pravda, s jistými omezeními (precizní GC e-e), ale libGC tu je celé věky. Program, který tráví 25-30 % v malloc() a free() by spíš zasloužil popravu autora, na jemně granulární práci s paměti tyhle funkce fakt nebudou (zvášť v příchutích glibc a msvcrt) a obecně se to ví. A pokud JITované programy jsou rychlejší než předkompilované, tak kompilátor odvedl špatnou práci. ;-) Z principu totiž není omezeno, co může před dodáním programu uživateli provést. Čehož využívá třeba právě Stalin ;-), ale i MLton a další.
-
respect (neregistrovaný)Chtel bych videt, jak se teda v C poprali s pointerem, ktery se muze toulat, kde se mu zlibi.
"A pokud JITované programy jsou rychlejší než předkompilované, tak kompilátor odvedl špatnou práci." ... neni pravda, JIT ma navic informaci, ktere kompilator na pocitaci u vyvojare mit nemuze - kompletni popis hw, na kterem bezi
vidite to treba uz na tom, ze program v bytecode nemusite kompilovat pro kazdu platformu zvlast - az JIT vi, na jake instrukce ma byte-code prevest
napriklad: program v C pro Intel spusteny na PowerPC - cas dokonceni: nikdy, kdezto program pro JIT pobezi v pohode (pokud pro PowerPC je dana VM)
rekl bych ze podobne (samozrejme s mene drastickymi nasledky) je to v ramci jedne architektury ... napriklad program v C byste musel kompilovat do nekolika variant s/bez podbory pro SSE1-4/MMX/x64/AltiVec, nebo tam udelat rozhodovaci logiku, ktera si vybere vetev s instrukcemi podporovanymi procesorem ... nemyslim, ze je to idelani pristup (i kdyz to udela kompilator automaticky) ... navic prichod novych instrukci znamena rekompilaci toho programu v C jeho vyrobcem (pokud nemate tu moznost sam), kdezto u JIT staci nova VM a vsechny programy hned hezky bezi s podporou vseho noveho
nerikam, ze soucasne VM vyuzivaji vsech moznosti jak optimalizovat kod ... ocividne jsou teprve na zacatku a podle me je v nich jeste hodne potencialu ... vzdy tam bude rezie pri spusteni programu, ale jaky je cas spousteni a nasledneho pouzivani programu? -
... (neregistrovaný)
Chtel bych videt, jak se teda v C poprali s pointerem, ktery se muze toulat, kde se mu zlibi.
Zavedli pointery, které se nemohou toulat, kde se jim zlíbí. :-)
-
respect (neregistrovaný)hezka odpoved :) ... dekuju
jde videt, ze si autori restrict byli narozdil od nekterych zdejsich diskutujicich vedomi tohoto performance problemu C ... dva problemy (kdyz opomenu ostatni vyhrady, ktere proti C mam) vidim v tom:
1) tenhle pristup vyzaduje "prepsani"+rekompilaci stavajicich aplikaci
2) je dalsi vec, nad kterou musi programator premyslet
... ale C uz od zakladu zmenit nejde, to uz by nebylo C ... ironii, je ze kdyz jsem zacinal v C++, tak jsem pointery videl jako velice elegantni a dobre reseni :) -
Rejpal (neregistrovaný)
To je sice všechno moc pěkný, ale víte, jak dlouho trvá běh kvalitního kompilátoru? Na ten bych si tedy po spuštění JITu počkal pěkně dlouho. Tím nechci říct, že výkon JVM nemůže být přijatelný, obzvlášť na serverech. Na klientech to ale bude mírně horší, a co hůř, u většího kusu SW typu OpenOffice, IDE a podobně opravdu nebudu chtít, aby se až po jejím spuštění u mně začal VM rozhlížet, co s tím molochem jako provede. Použití Javy na desktopových aplikacích je ospravedlnitelé možná tam, kde aplikaci používá maximálně pár desítek nebo stovek lidí. Jinak bych ale trpěl výčitkami z toho, že jednu a tutéž věc, kterou bych mohl provést jeden stroj jednou, dělají tisíce strojů...a znovu a znovu při každém spuštění. A nemotejte do toho "specializované instrukce", tím javisté straší před spaním své C++ děti. Takové věci jako flow analysis a profile-based inlining (ale i další) jsou naprosto nezávislé na ISA, a trvají mnohem déle než rozhodnutí, co použiju za instrukce (a to i v případě, že to ovlivní věší část kompilace, protože to rozhodnutí je samo o sobě velmi krátké - mám, použiju, nemám, nepoužiju - když se provede dřív, prostě se bude provádět jiná větev kompilačního řetězce, ale trvat bude s velkou pravděpodobností stejně, ostatně Java stejně nevektorizuje, IIRC). Používat Javu je velmi neekologické. Java causes global warming! Hug a tree, use C++! ;-)vidite to treba uz na tom, ze program v bytecode nemusite kompilovat pro kazdu platformu zvlast - az JIT vi, na jake instrukce ma byte-code prevest napriklad: program v C pro Intel spusteny na PowerPC - cas dokonceni: nikdy, kdezto program pro JIT pobezi v pohode (pokud pro PowerPC je dana VM)
rekl bych ze podobne (samozrejme s mene drastickymi nasledky) je to v ramci jedne architektury ... napriklad program v C byste musel kompilovat do nekolika variant s/bez podbory pro SSE1-4/MMX/x64/AltiVec, nebo tam udelat rozhodovaci logiku, ktera si vybere vetev s instrukcemi podporovanymi procesorem ... nemyslim, ze je to idelani pristup (i kdyz to udela kompilator automaticky) ... navic prichod novych instrukci znamena rekompilaci toho programu v C jeho vyrobcem (pokud nemate tu moznost sam), kdezto u JIT staci nova VM a vsechny programy hned hezky bezi s podporou vseho noveho
-
Ondrej 'SanTiago' Zajicek (neregistrovaný)Ono by slo vyhody JIT kompileru a tradicni kompilace spojit. Vse, co lze udelat v compile-time, by se udelalo v compile-time a kod by se prelozil do nejakeho mezikodu, ktery by obsahoval i informace ze staticke analyzy. JIT compiler by pak uz jen doladil detaily. Pro tohle by se ale chtelo vzdat portabilniho bytecode, aby se format mezikodu mohl vyvijet, kdyz by spolu s obema kompilatory.
-
respect (neregistrovaný)1) Preklad do byte-code je kompilace, pri ktere se uz neco dela? Prvni stupen optimalizace je zde. Ale zde toho jeste prilis udelat nejde, protoze jeste vse zustava platformne nezavisle.
2) Vsechny tridy v java.* package se cachuji zkompilovane, jakmile se jakykoliv program v Jave poprve spusti (novinka v 1.5) a jakykoliv dalsi program uz nekompiluje znovu pokud se nezmeni procesor, neupdatuje java apod.
3) Ten dynamicky inlining/deinling ve VM apod. co jsem tu zminoval a nekdo se mi smal, ze to existuje davno, prave umoznuje iteracni kompilaci kodu - nejdriv zkompilujete rychle, kdyz se kod casto pouziva udela se to znovu. Aplikace rychle nabehne a kdyz bezi dele vykon se zvedne.
4) Specializovane instrukce opravdu hodne pomahaji pri specifickych ukolech i v Jave. Jejich vykon se diametralne lisi od beznych. neni to strasak ale fakt.
5) To, ze se kompiluje na kazdem stroji znovu je dan za cross-platformost ... kdyz uzivatel Java aplikace bude prechazet z Win/Intel na Linux/PPC aspon nebude muset brecet, ze mu tam ta aplikace nejede
6) Jinak obecne s principem proc delat veci pokazde, kdyz je muzete udelat jednou souhlasim:
- proc muset testovat pri kazdem pristupu v C do pameti jestli neni pointer mimo vyhrazenou pamet? (kdyz Java tohle zajistuje uz na urovni jazyka)
- proc prepinat mezi uzivatelskym a privilegovanym rezimem? (kdyz budete mit bezpecnost na urovni jazyka)
- proc pri kazde instrukci delat predikci vetveni v kodu, resit out-of-oreder vykonavani instrukci, resit forwarding, resit jak musite pozastavit pipeline? (kdyz vsechny tyhle informace muze vyrobit JIT jednou pri kompilaci pri nacteni tridy)
- proc resit preemtivni multitasking a to jestli proces prepnete v idealni chvili? (kdyz vam JIT bude schopen tahle mista najit pri kompilaci a pridat instrukce na vzdani se procesoroveho casu a preemtivni reseni bude pouzivat jen jako doplnek)
... no a tyhle otazky si polozili i jini a proto treba existuji prototypy OS, ktere uz nepouzivaji C ... JNode, JX, Singularity apod.
PS: velka cast spotreby (ekologie) procesoru pripada prave na optimalizaci kodu za behu, protoze non-JIT kompilator neni schopen dodat optimalni kod pro dany procesor ... napriklad Itanium hodne sazelo na JIT a cela architektura je postavena na tom, ze procesor opravdu pocita a neresi optimalizaci ... bohuzel soucasne OS a spousta utilit toho potencialu nedokazi vyuzit -
Rejpal (neregistrovaný)
1) Preklad do byte-code je kompilace, pri ktere se uz neco dela? Prvni stupen optimalizace je zde. Ale zde toho jeste prilis udelat nejde, protoze jeste vse zustava platformne nezavisle.
Překlad do bytecode je v případě Javy naprosto triviální. Tam nejde nic "optimalizovat".2) Vsechny tridy v java.* package se cachuji zkompilovane, jakmile se jakykoliv program v Jave poprve spusti (novinka v 1.5) a jakykoliv dalsi program uz nekompiluje znovu pokud se nezmeni procesor, neupdatuje java apod.
Mohu vědět, kde? Ono to není tak triviální, dynamicky zrekompilované třídy už z principu jsou dost špatně recyklovatelné. Hromada informací při generování takového kódu vyletí komínem. Mně osobně to trošku připomnělo arabská písmena, která závisejí na kontextu - když jedno vytrhnu, napasovat ho můžu v podstatě jen mezi stejná písmenka jinde. Smysl by mělo dumpnout celý kód jednoho procesu, ale ani to by nebylo extra praktické. Zvlášť v případe agresivního inliningu (o jehož užitečnosti bych i vedl spory, stačí se podívat na forthovské procesory) může být docela problematické zrecyklovat rt.jar třídy z jedné aplikace v aplikaci druhé.3) Ten dynamicky inlining/deinling ve VM apod. co jsem tu zminoval a nekdo se mi smal, ze to existuje davno, prave umoznuje iteracni kompilaci kodu - nejdriv zkompilujete rychle, kdyz se kod casto pouziva udela se to znovu. Aplikace rychle nabehne a kdyz bezi dele vykon se zvedne.
Totéž umí profile-based kompilace jazyků typu ML a třeba i to C++. Až na to, že se ta aplikace spustí téměř optimální hned po načtení z disku. Pokud bych mohl z JITu něco vytěžit, tak nejspíš jen u hodně dlouho běžící serverové aplikace za značně se měnících podmínek (oproti prvotní profilaci), a ještě je otázka, jak velký ten marginální nárůst výkonu bude. Abych to řekl jinak: Microsoft .NET nepoužívá JIT - nebo přinejmenším po spuštění aplikace se už kód nemění, tj. nepoužívá rekompilaci. A přesto je výkon víceméně srovnatelný - někde lepší, někde horší... Na Javě se projevuje, že do ní byly napumpované desítky a stovky miliónů dolarů, takže pokud má velice dobrý serverový výkon, tak to bude tím R&D, mnohem spíš, než tím, že R&D vyprodukovalo ausgerechnet HotSpot.4) Specializovane instrukce opravdu hodne pomahaji pri specifickych ukolech i v Jave. Jejich vykon se diametralne lisi od beznych. neni to strasak ale fakt.
Já vím, že to je fakt. Ale ten kód někdo musí napsat, a JVM to nebude. :-) Specializované instrukce bohužel vyžadují ponořit se do assembleru nebo intrinzik, nebo na daný úkol napsat knihovnu (ale ručně). To druhé funguje i v Javě, to první v Javě nejde a součaný JIT kompilátor Javy to prostě neumí. To není strašák, ale fakt. ;-) Specializované instrukce jsou velice dobrý důvod, proč se naučit aspoň trošku assembler. Třeba tu manhattanskou metriku přes PSADBW si budu muset napsat sám, vygeneruje ji za mě JIT z for cyklu? ;-)5) To, ze se kompiluje na kazdem stroji znovu je dan za cross-platformost ... kdyz uzivatel Java aplikace bude prechazet z Win/Intel na Linux/PPC aspon nebude muset brecet, ze mu tam ta aplikace nejede
Ehm...to je spíš problém dodavatele. Znám spoustu těžce nahraditelných javovských aplikací, které jinde než na Windows nepoběží, přestože jsou psány v Javě. Ba co víc - třeba MultiTerm Extract funguje nejen pouze na Windows, ale pouze s jednou konkrétní verzí JVM, a nemůžu mít v systému nic jiného. To já už radši aplikaci v C++, která nebude blokovat ostatní svými požadavky na runtime. Samozřejmě, Java může investice potřebné k zajištění přenositelnosti snížit, ale obávám se, že se tenhle aspekt poněkdu přeceňuje. C++ například úspěšně běhá na mnohem více platformách než HotSpot.6) Jinak obecne s principem proc delat veci pokazde, kdyz je muzete udelat jednou souhlasim: - proc muset testovat pri kazdem pristupu v C do pameti jestli neni pointer mimo vyhrazenou pamet? (kdyz Java tohle zajistuje uz na urovni jazyka)
Jistě, proto se to při každém přístupu netestuje ani v C. ;-) Tohle mě má překvapit?- proc prepinat mezi uzivatelskym a privilegovanym rezimem? (kdyz budete mit bezpecnost na urovni jazyka)
Co to je tady "bezpečnost"? Stahování kódu z webových stránek ponechme stranou, Vy si vážně myslíte, že musím chránit počítač před aplikacemi, které si sám nainstaluji? (Digitálně podepsanými mými kolegy?) SW bariéru jsem schopen zajistit kdekoliv.- proc pri kazde instrukci delat predikci vetveni v kodu, resit out-of-oreder vykonavani instrukci, resit forwarding, resit jak musite pozastavit pipeline? (kdyz vsechny tyhle informace muze vyrobit JIT jednou pri kompilaci pri nacteni tridy)
Nechci Vám brát iluze, ale tohle za nás na většině architektur řeší procesor, a tam, kde to neřeší procesor, tam to vygeneruje kompilátor sám, a je úplně jedno, jestli před spuštěním aplikace nebo po něm.- proc resit preemtivni multitasking a to jestli proces prepnete v idealni chvili? (kdyz vam JIT bude schopen tahle mista najit pri kompilaci a pridat instrukce na vzdani se procesoroveho casu a preemtivni reseni bude pouzivat jen jako doplnek)
Proč tohle nemůže řešit AOT kompilátor?... no a tyhle otazky si polozili i jini a proto treba existuji prototypy OS, ktere uz nepouzivaji C ... JNode, JX, Singularity apod.
Díky, já radši House OS. ;-) Tenhle koncept je fajn, ale přinásí základní problém - restrikci jazyka. Zeptejte se na tohle profesora Tanenbauma, co vám na to řekne. ;-) Pokud mi budete argumentovat abstraktním bezpečným mezikódem, pak Vás musím informovat: Žádný univerzální neexistuje. Alespoň ne takový, který by byl použitelný pro všechny jazyky, a já chci počítač jako univerzální nástroj, ne jako javovský telefon na kterém běhá jen Java. Hardwarová kontrola je neinvazivní a v podstatě bezproblémová.PS: velka cast spotreby (ekologie) procesoru pripada prave na optimalizaci kodu za behu, protoze non-JIT kompilator neni schopen dodat optimalni kod pro dany procesor ...
Non-JIT kompilátor sice nemá všechny informace, které může mít JIT, ale vynášet tak silné tvrzení, že marginální výhoda JITu přebije AOT kompilaci natolik, že má smysl ji podstupovat znovu a znovu, to je opravdu odvážné. Chápu výhody JITu například u Smalltalku, to je systém, u kterého AOT nepřipadá v úvahu, ale Java není Smalltalk, ta je dynamická asi tak, jako pyramida na tekutých píscích.napriklad Itanium hodne sazelo na JIT a cela architektura je postavena na tom, ze procesor opravdu pocita a neresi optimalizaci ... bohuzel soucasne OS a spousta utilit toho potencialu nedokazi vyuzit
Ne, Itanium sázelo na VLIW. To je velmi starý koncept, který s JIT opravdu nemá nic společného, bohužel. -
respect (neregistrovaný)1) neni pravda, ze se neda udelat nic, ale dela se lemi malo (sam jsem to psal)
2) nevim kde si je uklada, ale vzhledem k tomu, ze i za behu obsahuje Java informace dulezite pro inlining/deinlining neni problem i takhle zkompilovanou tridu znovu zmenit ... mozna jste prehledl, ze jen zkompilovane tridy z java.* package se ukladaji zkompilovane ... je to z hlediska principu, protoze tridy v tehle package muze zavest jen sama JVM (mimo jine kvuli bezpecnosti), ostatni tridy muze zavadet i vlastni kod vyvojare - tutiz Java neni schopna rict, jestli se trida neaktualizovala, a nevi jestli muze pouzit zkompilovanou verzi
3) chtel bych videt dynamicky inlining/deinlining v C++ ... kdy se napriklad pri nacteni nove tridy zjisti, ze je to potomek tridy jejiz metody jsou nekde inlinovane a vsude kde je tahle metoda inlinovana se musi vyextrahovat a nahradit jinym kodem podporujicim i novou tridu ... v C++ je proste jen staticky inlining
4) ad generovani specialnich instrukci: do toho na jake instrukce prevati co, ktera implementace JVM ... je jich hodne a ja do nich nevidim ... ale principialne neni problem
5) zalezi na dodavateli - najdou se bile i cerne ovce ... vyhoda je, ze pokud v jave neni vazba na nativni kod (C/C++), a nepouzivaji se knihovny sunu v JVM (jako ze je to krajne nedoporucene a kazde IDE vas na to upozorni), tak je vse bez problemu ... C/C++ vyzaduje nekdy znacnou snahu vyvojare navic, aby byl program na vice platforem ... to, ze C++ bezi vsude je sice hezke, ale jde o to, aby programy bezely vsude
6)
testovani: OS musi testovat, zda se nenachazite mimo vyhrazenou pamet - jinak riskujete stack-overflow bezpecnostni chyby
prepinani rezimu: myslim prepinani na urovni procesoru, kdy se prepina na moznost delat privilegovane operace (naprikald alokace pamesi), ktere muze delat jen OS ... tohle je _extremne_ draha operace a probiha relativne casto ... vy si to pletete s nejakym prepinanim mezi rootem/uzivatelem
preemtivni multitasking: protoze u programu zkompilovanym JIT (bezicim na vasem pocitaci) muzete verit, ze se toho casu program vzda ... u programu dodaneho treti stranou nemuzete spolehat na to, ze tam takove body jsou nachystane
ad jen java OS: muze na takovem zarizeni jet jakykoliv jazyk, ktery se da prelozit do bytecode (dnes jsou to python, ruby, groovy, ...) ... byte-code je turing-complete, takze v tom napisete opravdu co budete chtit ... vyhoda je, ze ale nemuzete provest zadnou operaci, ktera by narusila chod systemu, zasahovala mimo svou pamet apod. ... silne doporucuju si o language-level-security systemech aspon neco precist, nez o tom clovek zacne mluvit
optimalizace kodu za behu: rozdil je opravdu podstatny, JIT ma mnoho informaci o usporadani pipeline procesoru:
- vi jak poskladat instrukce za sebe, tak aby je procesor nemusel prehazovat
- vi jak dlouho bude cekat na vyslednou hodnotu nejake instukce, takze mezi ni a instrukci, ktera hodnotu pouziva uz muze sam vlozit neco dalsiho
- neni potreba, aby procesor uchovaval tabulku skoku, prtoze JIT vi kam se bude s nejvetsi pravdepodobnosti skakat
- ...
ad hw controla: neinvazivni, bezproblemova ... ale neodchyti vse a vzdycky (viz stack-overflow), je pomala (dela se porad a znovu), zvysuje komplexitu procesoru a zere cca 1/4 - 1/3 celkove spotreby procesoru u modernich modelu ... asm, C/C++/C# apod. jsou jazyky, ktere vyzaduji slozitejsi architekturu procesoru
ad Itanium: tak to o Itaniu skoro nic nevite, ano mimo jine pouziva i VLIW, ale to je jen jedna z novych features -
Rejpal (neregistrovaný)
"velka roztristenost dat kvuli nahodne alokaci => vysoka spotreba cache, vysoky cache miss" - prosím??? Co tím myslíte přesně? "alokace na heapu zarucuje lokalitu dat => mala spotreba cache, skoro nulovy cache miss" - cože??? "optimalizace na velikost cache" - jaké cache?
Mám pocit, že možná mluví o alignmentu dat vůči cache lines, ale to je problematika poněkud složitější, než aby se daly dělat takovéhle paušální soudy. Kromě toho, mám pocit, že statisticky (přístupy) horký je hlavně zásobník a v GC-supported runtimech také nursery/eden/nultá generace (každý tomu říká jinak :-)), ale tam je to kompaktní už z principu. Přijde mi, že obecném případě tyhle věci téměř némá smysl řešit, protože determinismus tady jde do kytek."nesni JIT pouzivaji hodne agresivni strategie na optimalizaci - dynamicky inlining/deinlining apod." - co je na tom jako agresívního? To je ta nejprimitivnější optimalizace a často je sporné, jde-li vůbec o optimalizaci nebo naopak.
To bylo asi agresivní v dobách Selfu 93. ;-) Dneska by to už člověk celkem čekal. -
Ondrej \\\'SanTiago\\\' Zajicek (neregistrovaný)> "Navic +- 10% vykonu je dnes absolutne irelevantni zalezitost" - pokud je myšlen celý program, tak budiž. Pokud by se to týkalo nějakého vnitřního podprogramu, tak i těch 10% je moc.
To je docela divne tvrzeni. Pokud bydes mit 10% spomaleni klicove vnitrni smycky v nejakem podprogramu, tak to za normalnich okolnosti nezpomali cely program o vice nez 10%. Pokud tedy tolerujes zpomaleni celeho programu o 10%, tak klidne muzes tolerovat zpomaleni vyznamnych programu o 10% -
respect (neregistrovaný)jak jsem psal ... zalezi vic na pouzitych algoritmech nez na jazyce ... jestlize mate 10% vyhodu diky jazyku a implementacne jej 3x zpomalite, tak vam nepomuze sebelepsi jazyk ... je to myslene v tomhle kontextu
rychlost C/C++ vs. Java se lisi test od testu a neni jasny vitez na vsechno -
Ondrej 'SanTiago' Zajicek (neregistrovaný)> kompilovane na stroji vyvojare:
> - velka roztristenost dat kvuli nahodne alokaci => vysoka spotreba cache, vysoky cache miss
>
> bezici ve VM - JIT (mluvim o Jave, o ktere toho vim nejvic, ale bude platit i +/- pro ostatni):
> + alokace na heapu zarucuje lokalitu dat => mala spotreba cache, skoro nulovy cache miss
Tohle vicemene nesouvisi s tim, zda je jazyk klasicky kompilovany, JIT kompilovany ci interpretovany, ale s tim, zda a jaky ma garbage collector (a obecne spravu pameti). Neni problem mit klasicky kompilovany jazyk, ktery ma haldu kompaktujici garbage collector. -
respect (neregistrovaný)doporucuju si precist clanek, na ktery jsem dal odkaz a z nej vedouci reference ... je to tam vysvetleno podrobneji a nema smysl to opakovat
ale obecne ma zasadni vliv jestli mate 3 objekty v jednom bloku cache (jedno cteni z RAM + placnu 1kB spotreba cache) ... 3 objekty ve 3 blocich cache (3 cteni z RAM + 3kB spotreba cache + spousta hlusiny v cache nesouvisejici s behem programu) ... cisla se samozrejme lisi platforma od platformy ... velikost bloku, zpozdeni pameti -
abyssal (neregistrovaný)Prave moze (zavisi co sa mysli "vyznamny"). Viz napr.: Vertical profiling: understanding the behavior of object-priented applications, http://www-plan.cs.colorado.edu/diwan/vertical-prof-oopsla.pdf
Je to o nastroji, ktory zistuje, kde presne nastava zadrhel (na rozlicnych urovniach od JVM, kernelu, garbage collectoru atd) -
respect (neregistrovaný)Ano, to je pravda ... trochu jsem zde promichal 2 veci
je to spis srovnani alokace pomoci malloc, ktera si zada po systemu pamet a dostane ji na "nahodne" pozici, ktera vubec neodpovida potrebam lokality dat s alokaci na halde typickou pro Javu
samozrejme muzete mit v C impelmentovanou stejnou funkcionalitu rucne -
Kvakor (neregistrovaný)To, ze z pohledu virtualniho stroje je halda souvisla, nemusi vubec znamenat, ze je souvisla fyzicky, tj. z pohledu cache. Klidne muze byt silene fragmentovana, ale MMU v CPU to pred virtualnim strojem schova. Tazke ono to s tou lokalitou zas neni tak horke, jak to vypada. spse jde o to, ze data, ktera jsou potreba zaroven, budou pokud mozno blizko sebe (tj. napr. v jedne strance pameti), aby se zbytecne nezaplacaval cache a aby se nemusely neustale dotahovat polozky pro TBL.
A je pravda, ze v C se tohle da udelat take, sam jsem parkrat pouzil. Staci jen vsechny male veci alokovat na zasobniku (pres alloca(), ale pozor na podteceni/preteceni) a vsechny velke veci delat pres mmap() (tedy, alespon v Linuxu, *BSD a podobnych unixech).
Halda se uplne obejde, free() neni treba (mimo funkci, co sami o sobe alokuji pamet), protoze zasobnik je uvolnen automaticky po ukoncieni prislusne funkce a na mapovne oblasti je munmap(). U nammap()ovanych oblasti mate navic prehled zajisteny samotnym systemem (viz napr. /proc/<PID>/maps v Linuxu), takze v pripade potreby neni problem je zkontrolovat a v pripade nouze ty nepotrebne uvolnit.
Ani v jednom pripade nedochazi k fragmentaci, alespon te logicke (te fyzicke, jak uz jsem rekl, se ze strany aplikaci vyhnout neda, to musi delat system). A pokud se vam nechce delat mmap()ovani rucne, tak minimalne v glibc jde malloc() donutit k tomu, aby pouzival mmap() misto sbrk() i male kusy pameti. -
respect (neregistrovaný)ano, to jak je halda souvisla zalezi na tom jak ji JVM a system pod ni alokuje ... ale JVM o pamet zada ve velkych blocich (radu MB - jde nastavit) a sama si pamet uvnitr spravuje ... je predpoklad, ze OS pri jednorazove alokaci JVM poskytne souvislou pamet
ad zbytek: proc to delat rucne, kdyz to JVM za me udela automaticky a spolehliveji a ja nemusim premyslet nad tim, kde a jak pamet alokovat?
