Arduino a knihovny

Re:Arduino a knihovny
« Odpověď #105 kdy: 18. 03. 2021, 21:48:02 »
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.


Idris

  • *****
  • 1 260
    • Zobrazit profil
    • E-mail
Re:Arduino a knihovny
« Odpověď #106 kdy: 18. 03. 2021, 22:11:40 »
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.

Re:Arduino a knihovny
« Odpověď #107 kdy: 18. 03. 2021, 22:36:09 »
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ší...
« Poslední změna: 18. 03. 2021, 22:38:34 od Mirek Prýmek »

Idris

  • *****
  • 1 260
    • Zobrazit profil
    • E-mail
Re:Arduino a knihovny
« Odpověď #108 kdy: 18. 03. 2021, 23:19:45 »
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é.

Re:Arduino a knihovny
« Odpověď #109 kdy: 18. 03. 2021, 23:22:02 »
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.


Idris

  • *****
  • 1 260
    • Zobrazit profil
    • E-mail
Re:Arduino a knihovny
« Odpověď #110 kdy: 18. 03. 2021, 23:24:27 »
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?

Re:Arduino a knihovny
« Odpověď #111 kdy: 18. 03. 2021, 23:25:48 »
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á :)

Re:Arduino a knihovny
« Odpověď #112 kdy: 18. 03. 2021, 23:29:35 »
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

  • *****
  • 1 260
    • Zobrazit profil
    • E-mail
Re:Arduino a knihovny
« Odpověď #113 kdy: 18. 03. 2021, 23:29:48 »
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.

Re:Arduino a knihovny
« Odpověď #114 kdy: 18. 03. 2021, 23:31:09 »
Když napíšu, že se tracing GC chová
Tos neudělal. Ale fakt to nechci řešit.

Re:Arduino a knihovny
« Odpověď #115 kdy: 19. 03. 2021, 16:33:29 »
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í:
Citace
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

  • *****
  • 1 260
    • Zobrazit profil
    • E-mail
Re:Arduino a knihovny
« Odpověď #116 kdy: 19. 03. 2021, 18:31:24 »
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í:
Citace
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).