Příspěvky

1216

Studium a uplatnění / Re:Z VUT FAST do IT

« kdy: 09. 01. 2016, 19:51:04 »

A pečlivě bych čekal, jestli zazní argument, že stačí učit teoretické základy a konkrétní programovací jazyk se už může doučit každej sám

Řeší se to tu pořád Pokud chceš mít na VŠ přes 5 % lidí, tak je to normální učňák, střední, cokoli a má smysl tam učit konkrétní věci a konkrétní aplikace. Je to dobrý nápad. Pokud ale má být VŠ pro špičkové lidi, kterým má něco přinést, tak tam konkrétní věci jsou jen ztrátou času. Samozřejmě to platí max pro pár procent lidí.

Teoreticky by měl takový rozdíl být mezi VŠ a VOŠ, ale všichni víme, že to je spíše MFF vs. zbytek VŠ a VOŠ (včetně Unicornu) je jen komedie.

1217

Vývoj / Re:Vyplatí se učit C++?

« kdy: 31. 12. 2015, 23:42:37 »

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í.

1218

Vývoj / Re:Vyplatí se učit C++?

« kdy: 31. 12. 2015, 23:09:18 »

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.

1219

Vývoj / Re:Vyplatí se učit C++?

« kdy: 31. 12. 2015, 22:45:10 »

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.

1220

Vývoj / Re:Vyplatí se učit C++?

« kdy: 31. 12. 2015, 22:43:02 »

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..

Všechny jazyky s VM jsou cimrmanovské "tudy ne"

1221

Vývoj / Re:Vyplatí se učit C++?

« kdy: 31. 12. 2015, 22:41:29 »

To vypadá jako objevení dvou kol. Stařičký NeXTstep měl flag single-/multithreaded. A OpenStep zavedl vláknově lokální autorelease pooly. Obé už je bohužel legacy technology.

Vsadim se, že každý mluví o něčem jiném. Jestli ten flag měl per object, pak možná, ale neberu to jako vymýšlení kola, spíš jako řešení problému. Autorelease pool se obávám, že je něco jiného. Log změn referencí si přestav jako dva statické buffery pointerů, do jednoho píšu pointery u kterých se zvýšila reference do druhého u kterých se snížila reference. Jakmile jeden z nich je přeplněn, pak s jedním zámkem aktualizuju všechny reference a buffery resetuju. Mělo by to doufám snížit množství LOCKů sběrnice. Změna reference by měla být stejně rychlá jako singlethread reference counting a přitom MT safe.

PS: nenárokuju si patent, určitě to už někdo vymyslel a používá, já řeším pouze určitý problém

Jasně, není to úplně to samé, autorelease pool je jen pro dekrementy a není to buffer, nýbrž spojový seznam. Ale podobnost není čistě náhodná

1222

Vývoj / Re:Vyplatí se učit C++?

« kdy: 31. 12. 2015, 22:18:52 »

Největší problém reference countingu je obecně sdílení jedné proměnné mezi jádry procesoru. Je třeba používat interlocked increment/decrement. Ve svém kódu jsem to řešil tím, že objekt si eviduje, zda je sdílený mezi vlákny nebo ne, a pokud ne, pak se použije normální přičítání, které je rychlejší. Ale když v tom člověk udělá chybu, pak crash.

Teď testuju jiný způsob, kdy místo počítání referencí loguju to thread-local bufferu seznam všech pointerů, kde se mění reference. Jakmile buffer dojde, vezmu globální zámek, projdu buffer, upravím všechny countery, ty které dosáhnou nuly uvolním, vrátím globální zámek. Totéž se udělá před ukončení threadu. Ale nemám ještě žádné testy. Mělo by to mít výhodu, že evidování referencí si provádí každý vlákno samo, nevýhodu, že uvolnění objektu může dojít mnohem později, jestli vůbec (když při běhu nedojde k naplnění bufferu a thread nikdy neskončí)

To vypadá jako objevení dvou kol. Stařičký NeXTstep měl flag single-/multithreaded. A OpenStep zavedl vláknově lokální autorelease pooly. Obé už je bohužel legacy technology.

1223

Vývoj / Re:Vyplatí se učit C++?

« kdy: 31. 12. 2015, 21:46:16 »

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.

V tom článku pochopitelně porovnávají ty nejlepší implementace RC (k roku 2013) a výkon není stejný.

Pokud znáte nějaký novější článek, kde už RC dohnalo tracing kolektory, tak můžete dát odkaz.

Článek ne, ale zdroják překladače ObjC. Když to shrnu:
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).
2. Dělá se statická analýza nepotřebných Xrementů (X=ink|dek), ty se vyhodí. Tímto se ušetří nejvíc.
3. Runtime optimalizace na stacku eliminuje Xrementy. Doporučuji vyhledat autoreleaseReturnValue a retainAutoreleasedReturnValue. Tímto se optimalizuje předávání objektů po stacku nahoru (po stacku dolů se triviálně nic aktualizovat nemusí).

Autoři onoho článku trochu zaspali dobu, deferred RC je přes dvacet let stará technika určená pro algebraické datové struktury. A o statické analýze asi nikdy neslyšeli.

Stačí si napsat kód vytvářející hodně objektů v cyklu a něco s nimi dělat. Neoptimalizovaný překlad do LLVM IR má na polovině řádků aktualizaci čítače referencí. To by opravdu zdržovalo (a právě odtud pramení ten nešťastný mýtus, že RC je pomalé). Po optimalizaci nebude aktualizace skoro nikde, jen u přiřazení do nějakého vnějšího objektu, typicky kolekce.

1224

Vývoj / Re:Vyplatí se učit C++?

« kdy: 31. 12. 2015, 21:23:17 »

V širším kontextu se ukazuje, že jazyky s VM jsou slepou uličkou vývoje a připravily nás o celou jednu dekádu.

Microsoft už na to asi přišel, protože v jeho novém jazyce Cx pro WinRT je GC nahrazen počítáním referencí, kompiluje se do strojového kódu a hlavní API je stařičký COM.

Počítání referencí bývá obecně pomalejší než tracing GC. Viz třeba Taking Off the Gloves with Reference Counting Immix.

Nicméně Microsoft kromě RyuJITu pracuje i na projektu LLILC (LLVM based MSIL Compiler).

Ten článek je nádherná názorná ukázka, proč nedělat věci složitě, když to jde mnohem jednodušeji. Pro RC připadá v úvahu několik úrovní optimalizace a i bez "deferred RC" a podobných podivností lze dosáhnout téměř úplné eliminace. Což ovšem neznamená, že to tak každá implementace má (např. Swift má co dohánět). Je to hodně low-level magie, ale celkem poučná (když to člověk pochopí).

1225

Vývoj / Re:Vyplatí se učit C++?

« kdy: 31. 12. 2015, 21:10:06 »

No oni klasické GC navíc defragmentují paměť. Je to možné hlavně proto, že mají pod kontrolou všechny pointery. Měl jsem v C++ napsaný jednoduchý GC který dynamicky udržoval kostru v grafech referencí a tedy fungoval i s cykly (spouštěl se, jen když někdo zrušil referenci, která byla označena jako kostra grafu, a tehdy se snažil sestavit novou kostru a uvolnit všechny objekty, které se ocitly z kostry nedosažitelné), ale nepřišlo mi, že by byl rychlejší. Ony to totiž zdržují zejména alokace, tedy hledání volného místa ve fragmentované paměti a dealokace, tedy update tabulky volného místa.

V čistem C++ nejde moc dobře pod rukama programu defragmentovat paměť. Díky existenci raw pointerů nemám jistotu, že s pamětí zrovna někdo nepracuje (a i přes chytré ukazatele se raw pointery používaji, takovým nejtypičtějším raw pointerem je this)

To je sice pravda, ale týká se to jen konzervativních GC. Ty asi nebyly myšleny (protože je jasné, že jsou pomalejší).

1226

Vývoj / Re:Vyplatí se učit C++?

« kdy: 31. 12. 2015, 21:08:10 »

Nechci bejt pedant, ale počítaní referencí JE GC ... 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.

Jak jsem psal, dobrá statická analýza zrychlí RC natolik, že si člověk overheadu správy paměti ani nevšimne. Latence je samozřejmě nižší a hlavně se hodně snižuje "high water mark". Ideální pro embedded apod. Jinak GC je i žádný úklid paměti, jak se lze (se vší vážností) dočíst na Wikipedii. To jen tak pro usmání. Jinak já taky občas zapomenu napsat "tracing" a píšu jen "GC". Snad si přesto rozumíme.

1227

Vývoj / Re:Vyplatí se učit C++?

« kdy: 31. 12. 2015, 21:03:39 »

To jo, ale to RC v podání MS je docela tragédie. Ono celé WinRT je dost podivné, knihovny jsou nativní, ale s overheadem se volají z .NET nebo dokonce JS. Už aby byl na Windows Swift

Já jsem měl právě pocit, že WinRT jde udělat krom .NET i nativně v Cx nebo v C++ a pak je to normální binární EXE volající DLL a COM, jako hra pro DirectX. Je to ale jen pocit. Přiznám ale, že jsem to zatím prakticky neověřoval a možná ani nebudu. Protože po hrubém prostudování API jsem došel k závěru, že pro mou aplikaci stačí Win32 + DirectX s targetováním Windows 7 a speciální port pro Windows 8 nic extra nepřinese.

Jen upřesním, že žádné Cx neexistuje, jen C++/CX, což je C++ s rozšířenou syntaxí z C++/CLI. Jinak ano, překládá se do nativního kódu.

1228

Vývoj / Re:Vyplatí se učit C++?

« kdy: 31. 12. 2015, 21:01:04 »

Nechci bejt pedant, ale počítaní referencí JE GC ... 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.

jistě, správně mělo být něco jako "tracing GC"

1229

Vývoj / Re:Vyplatí se učit C++?

« kdy: 31. 12. 2015, 21:00:12 »

V širším kontextu se ukazuje, že jazyky s VM jsou slepou uličkou vývoje a připravily nás o celou jednu dekádu.

Microsoft už na to asi přišel, protože v jeho novém jazyce Cx pro WinRT je GC nahrazen počítáním referencí, kompiluje se do strojového kódu a hlavní API je stařičký COM.

Počítání referencí bývá obecně pomalejší než tracing GC. Viz třeba Taking Off the Gloves with Reference Counting Immix.

Nicméně Microsoft kromě RyuJITu pracuje i na projektu LLILC (LLVM based MSIL Compiler).

Je pravda, že ve WinRT je RC pomalé (a nejen RC), až je skoro nepoužitelné. Rychlé RC vyžaduje především velmi dobrou statickou analýzu kódu. Některé implementace mají i runtime optimalizaci (inspekce stacku), ale statická analýza (tj. v čase překladu) je základ.

(P.S. GC je rychlostí řádově srovnatelné s RC jen tehdy, má-li k dispozici cca. 4x více paměti, jinak výkon rapidně klesá. Nemusí to být vždy problém, ale třeba na RPi...)

1230

Vývoj / Re:Vyplatí se učit C++?

« kdy: 31. 12. 2015, 20:22:13 »

V širším kontextu se ukazuje, že jazyky s VM jsou slepou uličkou vývoje a připravily nás o celou jednu dekádu.

Microsoft už na to asi přišel, protože v jeho novém jazyce Cx pro WinRT je GC nahrazen počítáním referencí, kompiluje se do strojového kódu a hlavní API je stařičký COM.

To jo, ale to RC v podání MS je docela tragédie. Ono celé WinRT je dost podivné, knihovny jsou nativní, ale s overheadem se volají z .NET nebo dokonce JS. Už aby byl na Windows Swift