Jazyk podobný C#

Bla

Re:Jazyk podobný C#
« Odpověď #30 kdy: 18. 01. 2014, 10:38:29 »
Galgonek dokážeš tento svůj fábul podložit nějakým jiným argumentem než ocucaným prstem?


tany

Re:Jazyk podobný C#
« Odpověď #31 kdy: 18. 01. 2014, 10:40:06 »
Proboha uz zase tenhle bunk o Jave rychlejsi nez C? Tohle muze napsat jedine clovek co vubec netusi jak funguje pocitac...

To právě není tak jisté. JIT kompilátor může mít třeba k dispozici informace, které C kompilátor nemá, a díky tomu může být pak rychlejší.

=== nahrazení skillu optimalizací kompilátorem. Jdeme lepit v Jave :) (nic proti Jave, to je proti lepicum trid)

Jakub Galgonek

Re:Jazyk podobný C#
« Odpověď #32 kdy: 18. 01. 2014, 11:33:38 »
Galgonek dokážeš tento svůj fábul podložit nějakým jiným argumentem než ocucaným prstem?

Na tohle nejsem expert, ale moderním precesorům například docela vadí skoky. V kódu je často obsaženo hodně ifů, které jen ošetřují anomální případy, která takřka nikdy nenastanou. Pokud JIT kompilátor zjistí, že v 95% případů je nějaká podmínka vždy true, tak prostě ten kousek kódu přeloží tak, že se v těch 95% případů vůbec skákat nebude. Překladač C ale takovéto informace nemá (minimálně ne v takové kvalitě) k dispozici. Takže to je jedna z možností, kde má JIT teoretickou šanci být lepší.

Jakub Galgonek

Re:Jazyk podobný C#
« Odpověď #33 kdy: 18. 01. 2014, 12:05:44 »
=== nahrazení skillu optimalizací kompilátorem.

Tak vývoj sem spěje. Například dnes už skoro nikdo z nás nenapíše v asembleru kód, který by byl rychlejší než ten, co si napíšeme v C a necháme přeložit. Dnešní procesory už jsou prostě příliš složité.

Re:Jazyk podobný C#
« Odpověď #34 kdy: 18. 01. 2014, 12:07:26 »
nahrazení skillu optimalizací kompilátorem
To jako že by si programátor ke každému uživateli sedl, pozoroval způsob jeho práce, a pak by mu program překompiloval na míru? Teoreticky je to možné… Ale proč to dělat, když do kompilátor zvládne lépe a nesrovnatelně levněji?


Pavel Tisnovsky

Re:Jazyk podobný C#
« Odpověď #35 kdy: 18. 01. 2014, 12:49:07 »
Já vím, že pro linuxáka je to urážka něco takového vytahovat, ale co takhle jazyk

C++

Ono na tom kupodivu neni C++ v open source projektech tak spatne, jak to nekdy muze (hlavne v diskuzich :-) vypadat. Tady je pekne videt, jak se C, C++ i Java pekne srovnaly na nejakych 10% commitu u sledovanych projektu:

http://www.ohloh.net/languages/compare?measure=commits&percent=true&l0=cpp&l1=c&l3=java&l4=java&commit=Update

(Btw. kdyz uz jsi tady v diskusi - jak vlastne byly portovany Brany Skeldalu na Android? Prepis z C++ do Javy nebo jsou tam porad nativni casti kodu?)

Bla

Re:Jazyk podobný C#
« Odpověď #36 kdy: 18. 01. 2014, 17:59:02 »
Galgonek dokážeš tento svůj fábul podložit nějakým jiným argumentem než ocucaným prstem?

Na tohle nejsem expert, ale moderním precesorům například docela vadí skoky. V kódu je často obsaženo hodně ifů, které jen ošetřují anomální případy, která takřka nikdy nenastanou. Pokud JIT kompilátor zjistí, že v 95% případů je nějaká podmínka vždy true, tak prostě ten kousek kódu přeloží tak, že se v těch 95% případů vůbec skákat nebude. Překladač C ale takovéto informace nemá (minimálně ne v takové kvalitě) k dispozici. Takže to je jedna z možností, kde má JIT teoretickou šanci být lepší.

Je vidět, že o tom víš prd a vaříš jen z vody. Není skok jako skok, jsou short a far jumpy, mezi nimi je zásadní rozdíl a moderní procesory si už řadu let dokáží poradit s predikcí skoků velmi dobře, nastuduj si to například zde http://www.agner.org/optimize/microarchitecture.pdf Velmi nás unavuje číst tvé nekompetentní příspěvky psané stylem: "Něco napíšu, protože myslím, že dnes z palce vycucám něco fakt zázračného!".

Jakub Galgonek

Re:Jazyk podobný C#
« Odpověď #37 kdy: 18. 01. 2014, 18:11:52 »
[...]

Přečti si ještě jednou, co jsem tu jako první napsal, zamysli se nad sebou a začni se chovat slušně.

noef

  • *****
  • 897
    • Zobrazit profil
    • E-mail
Re:Jazyk podobný C#
« Odpověď #38 kdy: 18. 01. 2014, 18:13:24 »
Na tohle nejsem expert, ale moderním precesorům například docela vadí skoky. V kódu je často obsaženo hodně ifů, které jen ošetřují anomální případy, která takřka nikdy nenastanou. Pokud JIT kompilátor zjistí, že v 95% případů je nějaká podmínka vždy true, tak prostě ten kousek kódu přeloží tak, že se v těch 95% případů vůbec skákat nebude. Překladač C ale takovéto informace nemá (minimálně ne v takové kvalitě) k dispozici. Takže to je jedna z možností, kde má JIT teoretickou šanci být lepší.

Je vidět, že o tom víš prd a vaříš jen z vody. Není skok jako skok, jsou short a far jumpy, mezi nimi je zásadní rozdíl a moderní procesory si už řadu let dokáží poradit s predikcí skoků velmi dobře, nastuduj si to například zde http://www.agner.org/optimize/microarchitecture.pdf Velmi nás unavuje číst tvé nekompetentní příspěvky psané stylem: "Něco napíšu, protože myslím, že dnes z palce vycucám něco fakt zázračného!".

No nevim. Sice moderni procesory maji hodne slozite resene predikce a pomerne upsesne, to ale neznamena ze to nejde lepe (prediktory rozhodne nejsou 100% a za kazde selhani se plati cim dal draz). A prece jen JIT ma lepsi moznosti hlubsi analyzy kodu (asi za cenu urcite pocatecni rezie?), nez co si muze dovolit analyzovat procesor na urovni hw (co vim, tak se nic takoveho nedeje, protoze je to slozite a drahe [detekce hotspotu a nasledna optimalizace]).

Bla

Re:Jazyk podobný C#
« Odpověď #39 kdy: 18. 01. 2014, 18:37:11 »
noef

JIT v podání Java má už z principu své práce značnou režii, přemýšlení o kódu totiž stojí nějaký strojový čas!!! stejně tak jako iterace objekty s průzkumem a validací referencí. Jak třeba v java zakážeš provádění interuptů? Udělej si jednoduchý pokus, spusť si program, který bude používat n*5 vláken, kde n je definováno jako počet logických procesorů a každé vlákno měří čas od minulého spuštění kódu.
Hlavní vlákna by měla podávat konstantní výsledky, ale nebudou, čas bude kolísat, protože se tam motají další vlákna.
Přes java concurent locks se dostaneš na lepší hodnoty, ale ani náhodou na hodnoty dobré, rozhodně se nedá spolehnout, že reakce na událost přijde řekněme v předem přesně definované době. Zkus si to!

Galgonek

Správná odpověď na mojí výtku by byla: ,,Omlouvám se, mám kecavku a rád troluju, ale pokusím se mluvit jen k věcem, kterým rozumím." nikoliv "Chovej se slušně!"
Chováš se jako dítě a když tě napomenu, říkáš mi, abych se choval slušně, chovám se slušně, nemůžu za to, že žvaníš blbosti.

Jakub Galgonek

Re:Jazyk podobný C#
« Odpověď #40 kdy: 18. 01. 2014, 18:58:55 »
Správná odpověď na mojí výtku by byla: ,,Omlouvám se, mám kecavku a rád troluju, ale pokusím se mluvit jen k věcem, kterým rozumím." nikoliv "Chovej se slušně!"
Chováš se jako dítě a když tě napomenu, říkáš mi, abych se choval slušně, chovám se slušně, nemůžu za to, že žvaníš blbosti.

Nepsal jsem, jak věci jsou a že to vím jistě. Pouze jsem naznačil, že by mohly být i jinak. Fajn, procesor má branch prediction, ale ta má své meze, například rozpozná jen určité patterny, je to tak? Co když JIT (který může rozpoznávat složitější patterny) uspořádá skoky tak, aby vytvářely pattern, který procesor pozná? Nevím, zda to dělá a ani to netvrdím. Každopádně zatím jsi tu neukázal nic, co by nějak dokázalo či naznačilo, že informace získané při konkrétním běhu programu nelze použít k jeho optimalizaci, neboť informace získané staticky z kódu a dynamicku procesorem stačí.

Takže ještě jednou a jasně, nikdy jsem netvrdil, že Java je jistě rychlejší než C. Jen jsem říkal, že nelze tak jednoznačně tvrdit, že to nemůže být (za určitých podmínek) pravda.

Re:Jazyk podobný C#
« Odpověď #41 kdy: 18. 01. 2014, 19:07:02 »
Ona to zdaleka neni jenom predikce skoku. Devirtualizace metod, odstraneni nepotrebnych zamku, vyhozeni nedosazitelneho kodu...

Re:Jazyk podobný C#
« Odpověď #42 kdy: 18. 01. 2014, 19:11:45 »
Přes java concurent locks se dostaneš na lepší hodnoty, ale ani náhodou na hodnoty dobré, rozhodně se nedá spolehnout, že reakce na událost přijde řekněme v předem přesně definované době. Zkus si to!

Vsak taky, kdyz chces v Jave (a nejspis i cemkoli jinem) psat low latency aplikaci, abys mel zajistene reakce do urcite doby, tak nenasekas 5*n threadu a nepustis si je nadivoko.

Poslechni si, jak se to dela:
http://www.dagblog.cz/2013/12/cz-podcast-90-psani-low-latency.html

Mr. Curious

Re:Jazyk podobný C#
« Odpověď #43 kdy: 18. 01. 2014, 19:39:54 »
http://stackoverflow.com/questions/2684364/why-arent-programs-written-in-assembly-more-often

Hellо, I am a compiler.

I just scanned thousands of lines of code while you were reading this sentence. I browsed through millions of possibilities of optimizing a single line of yours using hundreds of different optimization techniques based on a vast amount of academic research that you would spend years getting at. I won't feel any embarrassment, not even a slight ick, when I convert a three-line loop to thousands of instructions just to make it faster. I have no shame to go to great lengths of optimization or to do the dirtiest tricks. And if you don't want me to, maybe for a day or two, I'll behave and do it the way you like. I can transform the methods I'm using whenever you want, without even changing a single line of your code. I can even show you how your code would look in assembly, on different processor architectures and different operating systems and in different assembly conventions if you'd like. Yes, all in seconds. Because, you know, I can; and you know, you can't.

P.S. Oh, by the way you weren't using half of the code you wrote. I did you a favor and threw it away.

Re:Jazyk podobný C#
« Odpověď #44 kdy: 18. 01. 2014, 20:11:43 »
Ve žvanění blbostí jste tu momentálně přeborníkem vy. Když JIT nějaký kód přeloží do nativního, tak už nad ním dál nepřemýšlí a ten kód běží stejně rychle, jako by vylezl z jiného kompilátoru. Zrovna predikce větvení je věc, ve které se kompilátory snaží procesorům pomoci - aby se procesor trefil správně, protože když se netrefí, je to drahé. JIT logicky může mít víc informací a může tedy přeložit kód tak, aby byl procesor úspěšnější. Vybrat si jeden okrajový případ z miliard používanějších a dokazovat na něm něco, co nijak nesouvisí s tématem diskuse, to taky nebyla šťastná volba.

Ono vůbec měřit rychlost aplikace tím, jak rychle procesor přežvejká nějaký kus kódu, je dnes úplně mimo. V drtivé většině použití to závisí na něčem úplně jiném. V tom zbytku, tam, kde záleží na výpočetním výkonu, zase ve velkém množství případů vůbec nejde o to, co počítá CPU, ale jak efektivní je specializovaný kód pouštěný třeba na GPU. A vtom malinkém zbytečku jsou pak specializované jednoúčelové aplikace, kde opravdu záleží na rychlosti provádění kousku nativního kódu.