Příspěvky

1156

Vývoj / Re:Arduino a knihovny

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

1157

Vývoj / Re:Arduino a knihovny

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

1158

Vývoj / Re:Arduino a knihovny

« kdy: 18. 03. 2021, 20:09:25 »

Nic zásadního, akorát je to jen (vlastní) podmnožina Go, hodně věcí z "plného" Go tam chybí. Nedávno jsem četl, že vývoj TinyGo začal finančně podporovat přímo Google, tak třeba to rychle vypilují. Bylo by fajn mít Go-style CSP i na MCU (o tom je celé vedlejší vlákno).

Co konkrétně zásadnějšího tam chybí? Nikdy jsem to nezkoumal, ten zmíněnej nedostatek driverů je pro moje osobní potřeby blocker.

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.

1159

Vývoj / Re:Arduino a knihovny

« kdy: 18. 03. 2021, 19:31:15 »

Takze nejaky to technology preview CSPcka by se asi pomoci async/await napsat dalo, ale asi jenom pro vybranej hardware a na moznost solidnejsiho pouziti je potreba si jeste nejakou chvilku pockat...

Rust má async/await docela použitelné. CSP by zvládnul hravě. Jo, bylo by fajn, kdyby se Rust na MCU víc prosadil, třeba na úkor (Micro)Pythonu (to asi nehrozí) nebo (Tiny)Go.

Zeptal bych se, co ti nejvíc chybí (vadí) u TinyGo pro reálnější (polo profi) nasazení? Pod pojmem polo profi myslím samo domo výroba pro vlastní potřebu, ale už s jakýmsi garantovaným výsledkem a dlouhodobějším provozem. A neberu do úvahy omezenou nabídku driverů.

Nic zásadního, akorát je to jen (vlastní) podmnožina Go, hodně věcí z "plného" Go tam chybí. Nedávno jsem četl, že vývoj TinyGo začal finančně podporovat přímo Google, tak třeba to rychle vypilují. Bylo by fajn mít Go-style CSP i na MCU (o tom je celé vedlejší vlákno).

1160

Vývoj / Re:Arduino a knihovny

« kdy: 18. 03. 2021, 13:51:56 »

Takze nejaky to technology preview CSPcka by se asi pomoci async/await napsat dalo, ale asi jenom pro vybranej hardware a na moznost solidnejsiho pouziti je potreba si jeste nejakou chvilku pockat...

Rust má async/await docela použitelné. CSP by zvládnul hravě. Jo, bylo by fajn, kdyby se Rust na MCU víc prosadil, třeba na úkor (Micro)Pythonu (to asi nehrozí) nebo (Tiny)Go.

1161

Vývoj / Re:CSP v embedded světě

« kdy: 17. 03. 2021, 21:50:08 »

Stylem to připomíná GCD.

Vykládám si to jako poctu

Nicméně co mi ještě vrtá hlavou, je, jaký datový typ přes ty kanály přenášet. Tady mám (void *), což je docela praktický, páč se tam dá protlačit v případě potřeby integer a za cenu pohlídání si případné alokace i cokoli přes pointer a velikost je předem známá, dá se alokovat staticky.

FreeRTOS má fronty udělaný přes makra tak, že se dá při vytvoření nastavit velikost přenášených dat, což je fajn, ale zas to kód znepřehledňuje. Implicitní kopírování by se mi líbilo víc než přenášení pointerů, ale nevím, jestli to za tu šarádu kolem stojí... Navíc chci kanály vytvářet dynamicky, což by to ještě komplikovalo... Nevím. Asi to nechám tak, jak to je, a doplním to nějakým hezkým alokátorem. Třeba https://github.com/pavel-kirienko/o1heap

Doporučuju používat objekty jako v CoreFoundation, bude to bezpečnější.

1162

Vývoj / Re:CSP v embedded světě

« kdy: 17. 03. 2021, 15:35:59 »

Takze jo, dneska byl pernej den, odreagovat jsem se potreboval, prvni trivialni verze je na svete 20B na task a 8B na kanal (to jenom kvuli zarovnani). Takze neco lehce pod tisic tasku na BluePillu

Implementaci si zatim necham pro sebe, podelim se jenom o main.

https://gist.github.com/mprymek/d1176be039c8f58e7d3ba4b3b7358e51

Stupidni, ale sviti to a hreje. A vo to go!

EDIT: P.S. cely to ma 282 radku

Stylem to připomíná GCD.

1163

Studium a uplatnění / Re:Přechod na magistra na FIT ČVUT

« kdy: 17. 03. 2021, 00:09:03 »

bych chtěl po absolutoriu na nějakých 10 let vypadnout za hranice, nejlépe někam do USA.

A proč teda nejít na MSc do zahraničí? Nemusí to být hned USA (tam je vzdělání pekelně drahé i pro místní), některé britské univerzity mají v USA akreditaci. Akorát po Brexitu budou pro většinu občanů EU dražší než doteď.

1164

Vývoj / Re:CSP v embedded světě

« kdy: 16. 03. 2021, 16:29:35 »

Tohle neovlivňuje negativně výkon, gorutiny jsou v poolu a hodně levné. A i kdyby ne, u síťové komunikace bys to nepoznal.

No tak pokud by to tak bylo, tak to ma knihovna udelat sama a neprezentovat mi nejaky ujety bufferovy API s ujetym nastavovanim timeoutu

https://www.embedded.com/build-a-super-simple-tasker/

Ten clanek je pekne napsany, diky! Akorat teda nevim, proc je ten konec tak ukousnuty

To mě vede k dotazu: Preemptivní přepínání tam neplánuješ?

1165

Vývoj / Re:CSP v embedded světě

« kdy: 16. 03. 2021, 15:52:00 »

Mně dorazilo v pátek Původně jsem ho ani kupovat nechtěl, ale pak jsem podlehl, že si ho aspoň zkusím. Aspoň to PIO bude zajímavý vyzkoušet.

První extra nemilý překvapení bylo, že se to nedá programovat pomocí ST-Linku. Takže doporučuju kupovat nejmíň po dvou kusech a z jednoho si udělat programátor.

Jo, mám dvě. Teď nemám moc čas, ale po večerech si budu hrát. Viva assembly

1166

Vývoj / Re:CSP v embedded světě

« kdy: 16. 03. 2021, 15:49:16 »

Je to tradeoff.

No dyť. To jsem právě říkal: k tomu net.Conn jsou možná implementační důvody, ale z koncepčního hlediska je ta dvojkolejnost otrava jako prase. A ani z hlediska výkonu to pak není příjemný, když u serveru musíš mít extra goroutinu pro každý spojení jenom proto, aby z net.Conn četla a posílala ti to kanálem. Nebo nemusíš, ale zas to má jiné otravné důsledky...

Tohle neovlivňuje negativně výkon, gorutiny jsou v poolu a hodně levné. A i kdyby ne, u síťové komunikace bys to nepoznal. Jen musíš mít pro ni zásobník, což na serveru nevadí, ale na embedded by mohlo, i když bude malinký.

1167

Vývoj / Re:CSP v embedded světě

« kdy: 16. 03. 2021, 15:12:48 »

aby to "svítilo a hřálo", jak říká klasik

Dnes mi dorazilo Pico, hřát asi nebude, ale svítit určitě Jdu oprášit ARM32 asembler

1168

Vývoj / Re:CSP v embedded světě

« kdy: 16. 03. 2021, 14:44:08 »

To není o kanálech, ale o tom, že komunikace přelézá určité hranice (síť). V embedded by to taky nešlo použít třeba pro I2C, to bych CSP nezazlíval, prostě se musí použít jiný mechanismus. Musím kouknout, jak to má Rust, tam bývají zajímavá řešení.

Mozna z hlediska implementace. Ale z hlediska koncepcniho to s tim nema co delat.

Tak si to představ tak, že kanály jsou jednoduše základní stavební prvky (něco jako asembler) a nad nimi si můžeš postavit linky. Udělat síťové kanály není tak těžké, když budou mít stejnou sémantiku, můžeš skrýt zavírání kanálů pod vlastní vrstvou vyšší úrovně. Takhle se dříve řešily i jiné věci (distribuované objekty, proxy) a byly s tím problémy (třeba se správou paměti) právě proto, že chtěli udržet jednotnou koncepci nezávislou na implementaci. Je to tradeoff. Osobně upřednostňuju jednodušší věci, žádné rádobyužitečné peudovýmysly v runtimu nechci, složitost patří do compile timu (hezký příklad je Rust, velesložitý překladač s borrow checkerem a výsledný kód je pak triviální). Ale určitě se rád inspiruju tvou inovativní implementací, až ji napíšeš

1169

Vývoj / Re:CSP v embedded světě

« kdy: 16. 03. 2021, 14:29:09 »

Context není dělaný pro net.Conn. Jistě by to šlo přes síťové kanály, které ovšem zatím nikdo nenapsal (vlastně napsal a pak zahodil, to vyjde nastejno).

No prave. To reseni se zaviranim kanalu je elegantni jenom v pripade, ze komunikujes vyhradne pomoci kanalu. Jakmile mas i jiny komunikacni prostredky, tak to neni elegantni, ale haze ti to jenom klacky pod nohy.

Je to využití scheduleru. Pro embedded se mi to nezdá špatné, můžeš si tam sice přidat linky, ale proč, když už to scheduler umí jinak a šetříš každý bajt.

Jasne. Jak rikam, pokud budes mit jenom kanaly a nic jinyho, bude to super.

Anebo by se jeste dalo uvazovat nad tim, ze by kanaly byly zaroven linky. To by asi taky slo, ale bylo by narocnejsi promyslet, jestli by to bylo rozumny za vsech situaci.

To není o kanálech, ale o tom, že komunikace přelézá určité hranice (síť). V embedded by to taky nešlo použít třeba pro I2C, to bych CSP nezazlíval, prostě se musí použít jiný mechanismus. Musím kouknout, jak to má Rust, tam bývají zajímavá řešení.

1170

Vývoj / Re:CSP v embedded světě

« kdy: 16. 03. 2021, 14:13:18 »

Mně tohle zavírání kanálů přijde spíš jako jejich zneužití.

Je to využití scheduleru. Pro embedded se mi to nezdá špatné, můžeš si tam sice přidat linky, ale proč, když už to scheduler umí jinak a šetříš každý bajt.