Arduino a knihovny

[Mirek Prýmek]

Nemá to plnou podporu deferu a map třeba. Taky tam nejde recover, to by se zrovna na MCU hodilo. Největší problém je ale IMHO přítomnost GC, na MCU bych si rád alokaci paměti řídil sám, nebo aspoň přesně věděl, co se děje pod pokličkou.

Hm, to je zvláštní, zrovna defer bych nečekal, že bude těžký implementovat. GC jsem myslel, že to nemá. S ním to imho moc nedává smysl. S gočkovým GC jsme si užili trochu WTF momentů i na serveru, na MCU bych to fakt viděl nerad.

[Reklama]

[Idris]

Nemá to plnou podporu deferu a map třeba. Taky tam nejde recover, to by se zrovna na MCU hodilo. Největší problém je ale IMHO přítomnost GC, na MCU bych si rád alokaci paměti řídil sám, nebo aspoň přesně věděl, co se děje pod pokličkou.

Hm, to je zvláštní, zrovna defer bych nečekal, že bude těžký implementovat. GC jsem myslel, že to nemá. S ním to imho moc nedává smysl. S gočkovým GC jsme si užili trochu WTF momentů i na serveru, na MCU bych to fakt viděl nerad.

Jakých momentů? GC v Go šlape jako hodinky. TinyGo je kompletní přepis pro MCU a s "normálním" Go má společnou jen syntax. Nicméně mark-and-sweep GC jsem tam taky nečekal.

[Mirek Prýmek]

Jakých momentů? GC v Go šlape jako hodinky.

Přesný detaily už si nepamatuju, ale tak prostě GC, no...

Myslím, že prvotní příčina byla v tom, že GC neuvolňuje paměť dokud má pocit, že "paměti je dost", takže když máš stroj, na kterým ti běží kontejnery, tak žere paměti víc než kolik by reálně potřeboval, protože v tom společným "poolu paměti" je jí pořád "dost". Něco takovýho to bylo, ale dohadovat se o to nebudu, prostě si pamatuju, že jsme si s pamětí v Go nějak lámali hlavu, vypadalo to jako memory leak a mohl za to GC.

EDIT: P.S. Celý to až moc nápadně připomínalo šťourání se v GC Javy, takže od té doby už jsem i ohledně toho gočkovýho GC poněkud vlažnější...

[Idris]

Jakých momentů? GC v Go šlape jako hodinky.

Přesný detaily už si nepamatuju, ale tak prostě GC, no...

Myslím, že prvotní příčina byla v tom, že GC neuvolňuje paměť dokud má pocit, že "paměti je dost", takže když máš stroj, na kterým ti běží kontejnery, tak žere paměti víc než kolik by reálně potřeboval, protože v tom společným "poolu paměti" je jí pořád "dost". Něco takovýho to bylo, ale dohadovat se o to nebudu, prostě si pamatuju, že jsme si s pamětí v Go nějak lámali hlavu, vypadalo to jako memory leak a mohl za to GC.

EDIT: P.S. Celý to až moc nápadně připomínalo šťourání se v GC Javy, takže od té doby už jsem i ohledně toho gočkovýho GC poněkud vlažnější...

Takhle funguje každý GC (pokud nějak drasticky nesnížíš GOGC). Nicméně právě správa paměti se mi líbí na Rustu, žádný GC, všechno hezky na zásobníku nebo explicitně v krabicích. Pro MCU jako dělané.

[Mirek Prýmek]

Takhle funguje každý GC (pokud nějak drasticky nesnížíš GOGC).

Nepamatuju si, že bysme tohle řešili s Pythonem.

Nicméně právě správa paměti se mi líbí na Rustu, žádný GC, všechno hezky na zásobníku nebo explicitně v krabicích. Pro MCU jako dělané.

Jo.

[Reklama]

[Idris]

Takhle funguje každý GC (pokud nějak drasticky nesnížíš GOGC).

Nepamatuju si, že bysme tohle řešili s Pythonem.

Python nemá klasický GC. Nebo se něco měnilo?

[Mirek Prýmek]

Python nemá klasický GC. Nebo se něco měnilo?

Vůbec nevím, co má nebo nemá Python, ale vím, že paměť nějak hlídá a tyhle brikule nedělá

[Jakub Štech]

Python má normální refcounting, paměť se uvolní v destruktoru poslední reference, která na něj ukazuje. Garbage collector se spouští periodicky jen aby našel a zlikvidoval cyklické závislosti jinak už zahozených (out of scope) objektů, tzn. když nemáte závislostní graf jak rodokmen Habsburků, tak GC nic nedělá a správa paměti je hezky deterministická.

[Idris]

Python nemá klasický GC. Nebo se něco měnilo?

Vůbec nevím, co má nebo nemá Python, ale vím, že paměť nějak hlídá a tyhle brikule nedělá

Protože počítá reference. Když napíšu, že se tracing GC chová jako v Go obecně, tak nemůžeš argumentovat něčím, co má počítání referencí, to je zjevně irelevantní (Python má i mark-and-sweep jen pro cykly, jako zadní vrátka, což ovšem na věci nic nemění)

[edit] P.S. Kolega mě předběhl s vysvětlením.

[Mirek Prýmek]

Když napíšu, že se tracing GC chová

Tos neudělal. Ale fakt to nechci řešit.

[ivoszz]

Ty argumenty mi nepříjdou dvakrát přesvědčivé, myslel jsem, že to bude silnější. Navíc lecos z toho už asi neplatí nebo nebude platit v blízké budoucnosti. Například u defer, dokumentace tvrdí:

The defer keyword is almost entirely supported, with the exception of deferring some builtin functions.

Navíc i když zpřehledňuje kód, dá se bez něj docela dobře žít.

Recover osobně nepoužívám, takže mi taky nechybí, net není a nebude v dohledné době podporován, takže to mne taky neomezuje. Externí síťová knihovna recover nepoužívá. Problémem je map, ani ne tak to omezení typů, ale co jsem četl, tak jeho neoptimalizovanost v některých případech. Chtěl bych věřit, že tohle se brzy spraví.

GC mi připadá, že není tak hrozný jak bylo prezentováno. Zaprvé jde vypnout (jinak by to na malých AVR ani nejelo) a s příchodem čipů s větší pamětí to není kritické. Je jasné, že na alokace člověk musí myslet, ale to platí i když to píše v C. Zadáním gc=none lze navíc trasovat místa, kde se alokuje paměť a jestli s tím nejde něco udělat. RT byl vždy vyšší dívčí a člověk musí myslet na věci, které jinde řešit nemusí. A co se týče zmiňovaného Pythonu, ve zdrojových kódech autoři píší, že se silně inspirovali GC z MicroPythonu.

Co se týče knihoven driverů, kupodivu jsem zatím nenarazil. Osobně to zatím jako velký problém nevidím. V projektech, které plánuji, těch používaných zařízení zase tolik není a přepsat případně driver z C do Go nevidím jako zásadní problém (největší může být s časováním). Zvláště poté, co jsem viděl jaká zvěrstva tam jsou občas páchána, takže bych to musel stejně upravovat. Navíc mi i myšlenka naprototypovat to rychle v Go a pak to případně přepsat do C, pokud je potřeba, připadá jako zajímavá.

Nejsem naivní a je mi jasné, že určitě někde narazím, ale zatím to zkusím dál. Pro kontext ještě jednou doplním, že se primárně bavím o CortexM.

[Idris]

Ty argumenty mi nepříjdou dvakrát přesvědčivé, myslel jsem, že to bude silnější. Navíc lecos z toho už asi neplatí nebo nebude platit v blízké budoucnosti. Například u defer, dokumentace tvrdí:

The defer keyword is almost entirely supported, with the exception of deferring some builtin functions.

Navíc i když zpřehledňuje kód, dá se bez něj docela dobře žít.

Recover osobně nepoužívám, takže mi taky nechybí, net není a nebude v dohledné době podporován, takže to mne taky neomezuje. Externí síťová knihovna recover nepoužívá. Problémem je map, ani ne tak to omezení typů, ale co jsem četl, tak jeho neoptimalizovanost v některých případech. Chtěl bych věřit, že tohle se brzy spraví.

GC mi připadá, že není tak hrozný jak bylo prezentováno. Zaprvé jde vypnout (jinak by to na malých AVR ani nejelo) a s příchodem čipů s větší pamětí to není kritické. Je jasné, že na alokace člověk musí myslet, ale to platí i když to píše v C. Zadáním gc=none lze navíc trasovat místa, kde se alokuje paměť a jestli s tím nejde něco udělat. RT byl vždy vyšší dívčí a člověk musí myslet na věci, které jinde řešit nemusí. A co se týče zmiňovaného Pythonu, ve zdrojových kódech autoři píší, že se silně inspirovali GC z MicroPythonu.

Co se týče knihoven driverů, kupodivu jsem zatím nenarazil. Osobně to zatím jako velký problém nevidím. V projektech, které plánuji, těch používaných zařízení zase tolik není a přepsat případně driver z C do Go nevidím jako zásadní problém (největší může být s časováním). Zvláště poté, co jsem viděl jaká zvěrstva tam jsou občas páchána, takže bych to musel stejně upravovat. Navíc mi i myšlenka naprototypovat to rychle v Go a pak to případně přepsat do C, pokud je potřeba, připadá jako zajímavá.

Nejsem naivní a je mi jasné, že určitě někde narazím, ale zatím to zkusím dál. Pro kontext ještě jednou doplním, že se primárně bavím o CortexM.

Jo, výhled je pozitivní, určitě to postupně vylepší. Go by bylo pro MCU ideální jazyk, kdyby se podařilo nějak eliminovat GC (což je jednodušší, než se může zdát).