Vyplatí se učit C++?

[zboj]

1. Dělá se escape analýza a co nezdrhne, jde na stack (Go to tak dělá standardně, čímž dost ulehčuje svému (tracing) kolektoru).

Tohle JVM běžně dělají, myslím, že i Jikes RVM to umí - tj. očekával bych, že pokud to nevypnuli, tak to dělají.

2. Dělá se statická analýza nepotřebných Xrementů (X=ink|dek), ty se vyhodí. Tímto se ušetří nejvíc.

Pro haldu toto implementují (říká se tomu update coalescing) a stack vůbec nepočítají.

1. Jenže v JVM to funguje mizerně, viz můj kód výše v tomto threadu (.NET to má implementované slušně).
2. Ale coalescing je něco jiného.

[Reklama]

[Petr Novák]

Teda pánové, to nemáte na Silvestra lepší zábavu?

Ne, jsem "dobrý programátor", tedy aspoň podle kritéria uživatele Dobřety.

[Radek Miček]

1. Dělá se escape analýza a co nezdrhne, jde na stack (Go to tak dělá standardně, čímž dost ulehčuje svému (tracing) kolektoru).

Tohle JVM běžně dělají, myslím, že i Jikes RVM to umí - tj. očekával bych, že pokud to nevypnuli, tak to dělají.

2. Dělá se statická analýza nepotřebných Xrementů (X=ink|dek), ty se vyhodí. Tímto se ušetří nejvíc.

Pro haldu toto implementují (říká se tomu update coalescing) a stack vůbec nepočítají.

1. Jenže v JVM to funguje mizerně, viz můj kód výše v tomto threadu (.NET to má implementované slušně).
2. Ale coalescing je něco jiného.

1. To myslíte ten kód s vektorem a komplexními čísly?

2. Podle wiki:

A dramatic decrease in the overhead on counter updates was obtained by Levanoni and Petrank.[4][5] They introduce the update coalescing method which coalesces many of the redundant reference count updates. Consider a pointer that in a given interval of the execution is updated several times. It first points to an object O1, then to an object O2, and so forth until at the end of the interval it points to some object On. A reference counting algorithm would typically execute rc(O1)--, rc(O2)++, rc(O2)--, rc(O3)++, rc(O3)--, ..., rc(On)++. But most of these updates are redundant. In order to have the reference count properly evaluated at the end of the interval it is enough to perform rc(O1)-- and rc(On)++. The rest of the updates are redundant.

Což mi přijde jako to, co jste popsal.

[Ondřej Novák]

Teda pánové, to nemáte na Silvestra lepší zábavu? Ale když už, měl bych jen takový lama dotaz. Když je tedy C++ rychlejší než Java, jak na vývoj tak rychlost výsledné apky, jak tu dokazuje Zboj, proč se tedy tak hojně Java používá? Je to tím, že je pro ni více knihoven na vše možné, než pro C++ a tím pádem je vývoj na ni přeci jen rychlejší, nebo je Java jen takový omyl, takové Cimrmanovské "tudy ne, přátelé"? Jinak já mám Javu rád. Neptejte se proč, když máte něco/někoho rádi, nehledejte v tom logiku..

To já nevím, ale základem pokroku je, že lidé zkouší slepé uličky a často neexistuje univerzální pravda.

[zboj]

1. Dělá se escape analýza a co nezdrhne, jde na stack (Go to tak dělá standardně, čímž dost ulehčuje svému (tracing) kolektoru).

Tohle JVM běžně dělají, myslím, že i Jikes RVM to umí - tj. očekával bych, že pokud to nevypnuli, tak to dělají.

2. Dělá se statická analýza nepotřebných Xrementů (X=ink|dek), ty se vyhodí. Tímto se ušetří nejvíc.

Pro haldu toto implementují (říká se tomu update coalescing) a stack vůbec nepočítají.

1. Jenže v JVM to funguje mizerně, viz můj kód výše v tomto threadu (.NET to má implementované slušně).
2. Ale coalescing je něco jiného.

1. To myslíte ten kód s vektorem a komplexními čísly?

2. Podle wiki:

A dramatic decrease in the overhead on counter updates was obtained by Levanoni and Petrank.[4][5] They introduce the update coalescing method which coalesces many of the redundant reference count updates. Consider a pointer that in a given interval of the execution is updated several times. It first points to an object O1, then to an object O2, and so forth until at the end of the interval it points to some object On. A reference counting algorithm would typically execute rc(O1)--, rc(O2)++, rc(O2)--, rc(O3)++, rc(O3)--, ..., rc(On)++. But most of these updates are redundant. In order to have the reference count properly evaluated at the end of the interval it is enough to perform rc(O1)-- and rc(On)++. The rest of the updates are redundant.

Což mi přijde jako to, co jste popsal.

1. Ano. I když se vyhodí ten vector, Java alokuje na haldě (což nechápu).
2. Tak to jsem to asi popsal špatně, páč to je něco úplně jiného. To slučování (coalescing) eliminuje mezikroky bez efektu, zůstane první a poslední. Já mluvil o elision, tedy nezůstane nic. Typicky když předávám objekt stackem nahoru a vím, že nakonec zanikne, dělám jen alokaci a pak free, žádné RC. Terminologií tracing GC dělám jen sweep. Což je rychlejší. Zastánci generačních GC tvrdí, že takových objektů je většina. A pokud takový objekt někam zdrhá (escape), i tak ušetřím jednu atomickou RC operaci.

[Reklama]

[Radek Miček]

To slučování (coalescing) eliminuje mezikroky bez efektu, zůstane první a poslední. Já mluvil o elision, tedy nezůstane nic. Typicky když předávám objekt stackem nahoru a vím, že nakonec zanikne, dělám jen alokaci a pak free, žádné RC.

Aha, díky. V tom článku reference ze stacku úplně ignorují a pro reference z heapu dělají pouze to slučování - nikoliv elision - tj. ten jejich výsledek by zřejmě šel vylepšit (pokud by použili nějakou lepší statickou analýzu).

[zboj]

To slučování (coalescing) eliminuje mezikroky bez efektu, zůstane první a poslední. Já mluvil o elision, tedy nezůstane nic. Typicky když předávám objekt stackem nahoru a vím, že nakonec zanikne, dělám jen alokaci a pak free, žádné RC.

Aha, díky. V tom článku reference ze stacku úplně ignorují a pro reference z heapu dělají pouze to slučování - nikoliv elision - tj. ten jejich výsledek by zřejmě šel vylepšit (pokud by použili nějakou lepší statickou analýzu).

Přesně to si myslím taky. A úplně obecně, domnívám se, že ať už je o 10% rychlejší RC nebo tracing GC, v běžné aplikaci krátkodobé objekty žijí na zásobníku a ty ostatní se vytvoří, dají do nějaké kolekce a pak jen čtou (což opět nezatíží GC ani RC). Čili nakonec se rozdíl v rychlosti nijak viditelně neprojeví.

[JS]

Moc nechapu, o cem se tu hadate - nekde jsem cetl clanek, ze tracing a reference counting jsou navzajem dualni (analogicke) pristupy, a tudiz pro ne existuji stejne optimalizace, a u obou lze dosahnout stejnych vysledku za stejnych kompromisu.

[čumil]

Moc nechapu, o cem se tu hadate - nekde jsem cetl clanek, ze tracing a reference counting jsou navzajem dualni (analogicke) pristupy, a tudiz pro ne existuji stejne optimalizace, a u obou lze dosahnout stejnych vysledku za stejnych kompromisu.

To je ovšem velmi mylné. Jde udělat hybridní GC kombinující oba přístupy, ale stejné optimalizace opravdu nemohou mít. Jako zdroj základních informací nechť poslouží wiki, tam se můžeš o kopě různých optimalizací dočíst. Přičemž pouze jedna z nich vyžaduje statickou analýzu, ty ostatní sou záležitostí běhu. Jako příklad uvedu slučování operací na counterem, pozdržování provedení operací nad counterem, RC bez nutnosti atomických INC a DEC v paralelním prostředí, RC v provedení pro distribuované systémy. Je toho prostě strašná kopa, ale záměrně všichni RC opomíjejí a omlacují všem okolo benchmarky s naivním RC. Je to na stejné úrovni jako dokazovat že tracing GC je pomalí na příkladu naivního mark & sweep ...

Jediný místo kde se RC dnes více používají sou realtime systémy, protože tam je prostě latence kritická.

Další výhoda RC je velmi snadná hardwarová akcelerace. U tracing řešení by to šlo také udělat, bylo by to ale mnohem více složitější ( == dražší procesor)

[JS]

To je ovšem velmi mylné.

LMGTFY - clanek http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon04Unified.pdf jsem jen prohledl, ale nemam duvod tomu neverit. Asi bude lepsi hadat se primo s autorem. ;-)

[petron]

nejdete si zalozit nove vlakno na rozoberqnie c++ a javy?

PS: stastny Novy rok a nech na roote byva viac konstruktivnych debat

[Radek Miček]

Moc nechapu, o cem se tu hadate - nekde jsem cetl clanek, ze tracing a reference counting jsou navzajem dualni (analogicke) pristupy, a tudiz pro ne existuji stejne optimalizace, a u obou lze dosahnout stejnych vysledku za stejnych kompromisu.

Četl jsem jen abstrakt toho článku. Ale IMO to, že jsou duální ještě neznamená, že na běžných programech jeden nebude lepší než ten druhý.

[kozzi]

Nechci bejt pedant, ale počítaní referencí JE GC ...

Ano i ne, je samozrejme pravda ze RC je GC, ale je velmi normalni pouzivat pojmy RC a GC jako dva pristupy ke sprave pameti. A ja osobne to uznavam, protoze kazdy vi co je tim mysleno.

A to že je pomalejší je podobná blbost jako to že to není GC. Když naivní implementaci RC porovnáváš s super hyper generačním tracing GC, je jasný kdo vyhraje. Když ale misto naivni implementace RC použiješ nějakou silně optimalizovanou implementaci, a že takový sou, vykon bude stejný, s tím rozdílem že RC bude mít minimální latenci.

To neni pravda, nezalezi jen na samotne implmentaci RC a GC ale i zejmena na typu ulohy. Jsou prace, ktere ukazuji ze i RC muze mit horsi latency nez GC. Osobne si myslim ze nelze prohlasit ani RC ani GC jako vyteze. S tim rozdilem ze GC nabyzi par veci navic, takze pro to jej casto preferuji.

[kozzi]

Teda pánové, to nemáte na Silvestra lepší zábavu? Ale když už, měl bych jen takový lama dotaz. Když je tedy C++ rychlejší než Java, jak na vývoj tak rychlost výsledné apky, jak tu dokazuje Zboj, proč se tedy tak hojně Java používá? Je to tím, že je pro ni více knihoven na vše možné, než pro C++ a tím pádem je vývoj na ni přeci jen rychlejší, nebo je Java jen takový omyl, takové Cimrmanovské "tudy ne, přátelé"? Jinak já mám Javu rád. Neptejte se proč, když máte něco/někoho rádi, nehledejte v tom logiku..

Duvod proc je Java tak rozsirena je ze je podobna C++, ale ma podle me mnohem lepsi krivku uceni, to znamena ze se ji clovek snadneji nauci a je v ni "produktivnejsi" mnohem rychleji. Stejne plati i pro PHP.

[čumil]

Nechci bejt pedant, ale počítaní referencí JE GC ...

Ano i ne, je samozrejme pravda ze RC je GC, ale je velmi normalni pouzivat pojmy RC a GC jako dva pristupy ke sprave pameti. A ja osobne to uznavam, protoze kazdy vi co je tim mysleno.

A to že je pomalejší je podobná blbost jako to že to není GC. Když naivní implementaci RC porovnáváš s super hyper generačním tracing GC, je jasný kdo vyhraje. Když ale misto naivni implementace RC použiješ nějakou silně optimalizovanou implementaci, a že takový sou, vykon bude stejný, s tím rozdílem že RC bude mít minimální latenci.

To neni pravda, nezalezi jen na samotne implmentaci RC a GC ale i zejmena na typu ulohy. Jsou prace, ktere ukazuji ze i RC muze mit horsi latency nez GC. Osobne si myslim ze nelze prohlasit ani RC ani GC jako vyteze. S tim rozdilem ze GC nabyzi par veci navic, takze pro to jej casto preferuji.

Nepochybuju že takové úlohy se najdou, budou ale asi stejně vzácné jako věrný holky ... takže nic co je třeba brát vážněji v úvahu.

Tracing GC maj obvykle nursery, to ale mohou mít i RC GC, takže co se týče kousků který umí jsou na tom silně podobně (stejně).

Říkat GC a RC a přitom myslet pod GC tracing GC a pod RC RC GC je dost blbost. Nepochybuju žě ty chápeš co říkáš, plno idiotů kolem tebe ale tak bystrých nemusí být a poté tě můžou překvapit sračkama na styl: ten jazyk nemá GC, používá pouze RC ...