Budoucnost Rust v embedded světě

[r223]

Máme procesory, na kterých běží linux za jednotky dolarů...
Osobně si myslím, že čím dál víc věcí v embedded půjde směrem, že tam bude někaký relativně hi-level os (Zephyr nebo linux) a vlastní aplikace se bude lepit nad tím v něčem, na co zrovna půjdou sehnat lidi...
Těch aplikací, které vyžadují bezpečnost/čas zase tolik nakonec není.

To bude dost náročné testovat, protože tím si dovnitř zanesete obrovské množství kódu, o němž ani přesně nevíte, co dělá, z 90 % je to pro danou aplikaci nepotřebné a představuje to jen potenciální zdroj chyb a cest pro různé exploity. Je to zbytečný nárůst komplexity. Aplikací vyžadujících bezpečnost je spousta, pokud se člověk pohybuje třeba v tom průmyslu. A není-li to přímo bezpečnost, tak riziko finanční škody. Dost velkou motivací pro dodavatele SW do průmyslu by bylo, kdyby ve smlouvách standardně bylo ujednání, že když vinou chyby v SW dojde ke vzniku škod, tak to dodavatel komplet nahradí.

Jožko a co by poradil mne, který má vystudované umění a pak přírodovědu (earth science) a fušuje se ti do řemesla?
mám firmu na realtime analytiku pro embedded devices.  Jsem dost kvalifikován? Nestačí, že jsem schopen se s tebou bavit? Já uznávám specializace, ale ne zabedněnost. Jo a píšeme to v C, C++, Rust a OCaml/StandardML kdyby tě t zajímalo Univerzitu na to abys pohledal.

Zatím jsme se tu nijak odborně nebavili, jen tak obecně. Museli bychom se bavit o konkrétní věci. Žádnou vaši práci jsem neviděl, nejspíš jsem s vámi neměl tu čest v praxi se setkat. V čem píšete je celkem nicneříkající informace. Univerzitu na co? Pokud potřebujete univerzitu, aby vás tam naučili pracovat s vámi zmiňovanými jazyky, pak je něco špatně - to je přesně to, o čem jsem mluvil. Stačí znát obecné principy a postupy, které se více-méně od 60. let minulého století nemění. Snad všechno už tu od té doby v nějaké podobě bylo. S touto obecnou, vámi neuznávanou průpravou, zvládnete práci s nějakým konkrétním jazykem vcelku snadno. Pokud bychom oprášili ten zubařský příměr, tak je to jako práce s konkrétním materiálem nebo konkrétním nástrojem. Jenže ta podstata znalostí spočívá ve schopnosti posoudit vhodnost určitého materiálu, nástroje či postupu, umět správně diagnostikovat problém a v každém konkrétním případě umět stanovit vhodný další postup. Ne, protože jiný neznám, protože je s tím nejméně práce, nebo protože je to momentálně hype, ale protože je v daném případě optimální.
Opět z praxe - jestliže vás firma odbývá s tím, že na daném HW není možné určitou věc implementovat kvůli nedostatku paměti, a vy při nahlédnutí do programu zjistíte, že používají vnořená volání, místo aby to vyřešili pomocí stavového automatu, takže by stačila jedna stavová proměnná, jedno volání a hromada paměti by ještě zbyla, tak je asi něco špatně. Totéž jiný ekšpert - "nelze, pro daný úkol nedostatečný HW". Problém byl v tom, že místo aby kalibrační křivku implementoval pomocí interpolační tabulky a FXP aritmetiky, snažil se to realizovat přesně podle údajů z katalogu, tj. potřeboval FP knihovnu, aby mohl do programu prostě tupě opsat kalibrační vzorec. Nebo jiný "neřešitelný problém", tentokrát v assembleru - měřidlo dodává údaj ve formátu double, systém to potřebuje jako single... (btw - pomohlo by nějak dotyčným s řešením těchto problémů, kdyby používali Rust?)
A ne, řešením opravdu není použít silnější HW. Jednak to často nejde, průmyslový HW se nedá měnit jak ponožky, to jsou systémy, které mají spolehlivě a kontinuálně pracovat i desítky let a stojí to desítky, stovky milionů, a jednak neschopný vývojář vždycky dříve či později narazí na problém, na který mu daný HW nestačí, ale stačil by mu, kdyby nebyl neschopný.

Dnes je HW mnohem levnější, než čas vývojáře.... use case, kde se vyplatí na krev optimalizovat bude jen a jen ubývat. Tím neříkám, že nebudou, ale postupně se více a více funkcionality bude psát ve vyšších jazycích.

[Reklama]

[anonacct]

Já pravě vidím pravý opak - čás vývojáře je nic pokud je schopný optimalizovat.

Pokud píšeš aplikaci pro desktop, tak čas vývojáře je velký náklad, pokud pro servery, kde jich budeš potřebovat tisíce, tak jakákoliv optimalizace může ušetřit miliony (v USD). Čas vývojáře byl drahý než přišel cloud.

[Jožka Niemand]

Dnes je HW mnohem levnější, než čas vývojáře.... use case, kde se vyplatí na krev optimalizovat bude jen a jen ubývat. Tím neříkám, že nebudou, ale postupně se více a více funkcionality bude psát ve vyšších jazycích.

Tohle do jisté míry platí na desktopu a na smartphonech. Ale tady se bavíme o embedded a průmyslových aplikacích, kde je situace dost odlišná. Navíc u těch příkladů nešlo o žádnou optimalizaci na krev. Tam šlo o to, jestli to píše někdo, kdo používá hlavu, nebo blbec.
Já osobně bych s tou neustále omílanou mantrou o levném HW a drahém času vývojáře byl opatrnější. Kdyby se posčítal zbytečně promrhaný výkon na všech zařízeních, na nichž ten neefektivní SW pracuje, tak bychom dost pravděpodobně zjistili, že ušetřený čas vývojářů nás vyšel zatraceně draho. Nehledě na to, že čas to zabere právě těm nedoukům, kteří jsou v lepším případě nuceni objevovat Ameriku, zatímco profesionál by to vysypal z rukávu na první dobrou. V horším případě prohlásí problém za neřešitelný.

[r223]

Dnes je HW mnohem levnější, než čas vývojáře.... use case, kde se vyplatí na krev optimalizovat bude jen a jen ubývat. Tím neříkám, že nebudou, ale postupně se více a více funkcionality bude psát ve vyšších jazycích.

Tohle do jisté míry platí na desktopu a na smartphonech. Ale tady se bavíme o embedded a průmyslových aplikacích, kde je situace dost odlišná. Navíc u těch příkladů nešlo o žádnou optimalizaci na krev. Tam šlo o to, jestli to píše někdo, kdo používá hlavu, nebo blbec.
Já osobně bych s tou neustále omílanou mantrou o levném HW a drahém času vývojáře byl opatrnější. Kdyby se posčítal zbytečně promrhaný výkon na všech zařízeních, na nichž ten neefektivní SW pracuje, tak bychom dost pravděpodobně zjistili, že ušetřený čas vývojářů nás vyšel zatraceně draho. Nehledě na to, že čas to zabere právě těm nedoukům, kteří jsou v lepším případě nuceni objevovat Ameriku, zatímco profesionál by to vysypal z rukávu na první dobrou. V horším případě prohlásí problém za neřešitelný.

Ale ono se to děje přirozeně. Dneska už nikdo nebude stavět nové zařízení na nějakém 8051. My se teď třeba rozhodli opustit v produktech už poměrně staré stm32f4 ve prospěch stm32h7.... výkon, paměť a možnosti se zvýší několikrát, a při tom bude levnější (starým čipům roste cena). Už na těch f4 máme micropython, aby se jednoduché operace nad daty, co zákazníci chtěli custom, mohli od firmware oddělit a nemuselo se to udržovat....
Bývala k tomu nativní konfigurační aplikace, dneska je v tom web, protože ty procesory mají výkonu dost.
A to spíš propaguju ten konzervativnější přístup, spousta věcí už se tlačí k linuxu...

[BoneFlute]

zatímco profesionál by to vysypal z rukávu

Tady se občas objeví tato a podobná představa.

Uvědomujete si doufám, že ono těch profesionálů a těch, co umí dobře programovat je čím dál tím méně? Že sice máte pravdu, že dobrý vývojář žádný Rust nepotřebuje (ne, není to pravda), ale je to to samé, jako když by jste hladovému Somálci poradil, ať se nají.

Kdyby se posčítal zbytečně promrhaný výkon na všech zařízeních, na nichž ten neefektivní SW pracuje, tak bychom dost pravděpodobně zjistili, že ušetřený čas vývojářů nás vyšel zatraceně draho.

A jak byste to chtěl sčítat? Toto není pravda. Tohle nikoho nebolí.

Víte kolik afričanů by se mohlo napít z potůčku, který mi teče za barákem? Ho nechávám téct úplně zbytečně. Pěkně drahý potůček.

[Reklama]

[Martin Sivák]

Tohle do jisté míry platí na desktopu a na smartphonech. Ale tady se bavíme o embedded a průmyslových aplikacích, kde je situace dost odlišná. Navíc u těch příkladů nešlo o žádnou optimalizaci na krev. Tam šlo o to, jestli to píše někdo, kdo používá hlavu, nebo blbec.

..


Kdyby se posčítal zbytečně promrhaný výkon na všech zařízeních, na nichž ten neefektivní SW pracuje, tak bychom dost pravděpodobně zjistili, že ušetřený čas vývojářů nás vyšel zatraceně draho.

Embedded zahrnuje masově vyráběné jednorázové hračky i kusovou výrobu pro konkrétní speciální případ (třeba satelity). Nemůžete obojí hodit do stejného pytle, protože ty firmy optimalizují na úplně jiné metriky.

Můžete optimalizovat na určitou kombinaci

čas do nasazení - rychle něco vyrobit a získat trh, optimalizace se dělají dodatečně nebo vůbec, trošku vyšší cena hardware může být bohatě kompenzována náskokem před konkurencí.

cena podpory - optimalizace se opět dělají málo nebo vůbec, protože požadavky zákazníka se často mění a je potřeba umět rychle reagovat, proto je dneska většina věcí software-defined-něco. Software se upgraduje snáz, než hardware.

Oproti tomu můžete taky optimalizovat na druhý protipól

náklady na vývoj - absolutně co nejnižší cena za kus - levné cpu, levný vývoj, protože spotřební elektronika a nulová podpora

Ani jedno z toho nevyžaduje optimalizaci a super schopného génia, který zná všechny kličky.


Dokonale spolehlivý software je potřeba pro místa, kde se nedá dělat servis nebo musíte garantovat dekádu provozu bez problémů a certifikace. Letectví, vesmír, lékařství... o trošku méně automotive, možná těžaři a nebezpečné průmyslové provozy.

Ale pořád to nemusí být optimalizovaný software, naopak, může být výhodnější napsat jednodušší software (super loop s minimem podmínek) a "matematicky" dokázat jeho spolehlivost než ladit každou ztracenou mikrosekundu nebo pár byte paměti (za spolehlivost se platí a dražší čip se už v té ceně ztratí).

Když děláme real time, tak průmysl ani nepotřebuje lepší RTT, než zhruba milisekundu. Telekomunikace jsou horší, ti chtějí max desítky mikrosekund.

Absolutní optimalizaci dělají tak možná filmová a herní studia, která potřebují nacpat novou hru s lepšími efekty na existující hardware nebo konzoli. Případně ten film vyrenderovat dřív než lidi ztratí zájem. A i ti si ten 3D engine koupí a dodělají detaily, protože je to levnější.


Takže ne, optimalizace výkonu a zabraného místa dávno není prioritou, pokud nejsou speciální požadavky. Typicky je mnohem důležitější cena vývoje (včetně platu vývojářů), čas pro nasazení a efektivita podpory a oprav na místě.

[r223]

naopak, může být výhodnější napsat jednodušší software (super loop s minimem podmínek) a "matematicky" dokázat jeho spolehlivost než ladit každou ztracenou mikrosekundu nebo pár byte paměti (za spolehlivost se platí a dražší čip se už v té ceně ztratí).

Ano, to se běžně dělá, i v tom space segmentu. Casto se vlastní algorimus dela necem typu simulink nebo nejaký podobný nástroj a pak se to jen nějakou formou vkládá do už ověřeného prostředí.
Efektivní to není ani náhodou, ale dá se to dobře testovat (nekdy včetně formální verifikace).

[Jožka Niemand]

Víte kolik afričanů by se mohlo napít z potůčku, který mi teče za barákem? Ho nechávám téct úplně zbytečně. Pěkně drahý potůček.

Přirovnání s potůčkem kulhá na všechny čtyři. Lepší přirovnání by spíš bylo s kohoutky, do kterých se nevyplatí dávat těsnění, protože je to moc práce, když vody je přece dost, takže nebude vadit, když si větší či menší čůrek pitné vody z každého kohoutku poteče jen tak nazdařbůh do kanálu. Ale zároveň všude do mě budou tlačit, ať šetřím vodou, nesprchuji se moc dlouho a omezovat velikost kbelíků.
To, že aplikace na mobilní bankovnictví by se ani nevešla na můj první harddisk a z deseti spuštění se tak jednou kousne, mi opravdu nepřipadá jako uspokojivý stav věcí.

[BoneFlute]

mi opravdu nepřipadá jako uspokojivý stav věcí.

To je vám ke cti (ve skutečnosti s vámi do určité míry souzním), ale to je asi tak to jediné pozitivní, co se na tom dá najít.

Rovnice je jednou daná, a nemá smysl být nešťastný, že byste chtěl, aby dávala jiné výsledky.

[Jožka Niemand]

mi opravdu nepřipadá jako uspokojivý stav věcí.

To je vám ke cti (ve skutečnosti s vámi do určité míry souzním), ale to je asi tak to jediné pozitivní, co se na tom dá najít.

Rovnice je jednou daná, a nemá smysl být nešťastný, že byste chtěl, aby dávala jiné výsledky.

No jo, to je ovšem zase takový ten přístup jak zpíval Werich, "tohle člověk nezmění, to je bóží řízení..."
Na běžných zařízeních mě to zase tak netrápí, i když ve světle zákazů žárovek, omezování výkonů vysavačů, varných konvic, připojování víček k PET lahvím, zákazům brček a uchošťourů atp. mě překvapuje, že tohle nikdo neřeší. Ale trápí mě to v tom průmyslu, kdy nároky kladené na řídící a automatické kontrolní systémy se kvůli úsporám na zaměstnancích, snaze tlačit všechno na hranu, a v energetice navíc ještě připojováním mikrozdrojů, neustále zvyšují, ale jejich kvalita a spolehlivost neustále klesá. Prostě nejsem ten typický lumík, co nadšeně kráčí do propasti s davem ostatních. A i kdyby mě ten dav nakonec ušlapal, můžu si říci-aspoň jsem zkusil se proti tomu postavit. Stavět se na odpor hlouposti je podle mě morální povinnost každého rozumného člověka.

[krouziciorel]

Dokonale spolehlivý software je potřeba pro místa, kde se nedá dělat servis nebo musíte garantovat dekádu provozu bez problémů a certifikace. Letectví, vesmír, lékařství... o trošku méně automotive, možná těžaři a nebezpečné průmyslové provozy.

Ale pořád to nemusí být optimalizovaný software, naopak, může být výhodnější napsat jednodušší software (super loop s minimem podmínek) a "matematicky" dokázat jeho spolehlivost než ladit každou ztracenou mikrosekundu nebo pár byte paměti (za spolehlivost se platí a dražší čip se už v té ceně ztratí).

Tato oblast mě zajímá a reaguji na informaci o matematickém dokázání spolehlivosti. Mám velmi rád programovací jazyk Ada, kde se právě pro toto prokázání používá nástroj Spark. Dle dokumentace od Adacore jej však nelze využít pro C/C++/Rust, cituji: "Kódu psanému v C/C++ nebo Rustu se SPARK použít nedá –⁠ nejvýš můžete ze SPARKu volat funkce napsané v C a těm pak důvěřovat nebo je testovat klasickými postupy, ale matematický důkaz vlastností pro ně SPARK nevede.". Umělá chytrost mi nabízí možnosti Frama-C + ACSL/WP, CBMC pro C++ nebo Prusti pro Rust, využíváte některou z nich?

[r223]

Víte kolik afričanů by se mohlo napít z potůčku, který mi teče za barákem? Ho nechávám téct úplně zbytečně. Pěkně drahý potůček.

Přirovnání s potůčkem kulhá na všechny čtyři. Lepší přirovnání by spíš bylo s kohoutky, do kterých se nevyplatí dávat těsnění, protože je to moc práce, když vody je přece dost, takže nebude vadit, když si větší či menší čůrek pitné vody z každého kohoutku poteče jen tak nazdařbůh do kanálu. Ale zároveň všude do mě budou tlačit, ať šetřím vodou, nesprchuji se moc dlouho a omezovat velikost kbelíků.
To, že aplikace na mobilní bankovnictví by se ani nevešla na můj první harddisk a z deseti spuštění se tak jednou kousne, mi opravdu nepřipadá jako uspokojivý stav věcí.

Úplně běžná věc, se kterou si většina svět neláme hlavu.
Třeba v US se staví levné a jednoduché domy, kdy třeba na jihu pak jede 24/7 klimatizace, a na jednovrstvém okně máte většinu času rozdíl teplot klidně 20K. A nikoho to nesere, domy jsou levné a střední třídě dostupné, a energie taky (0.13 USD KWh koncově, už 30 let, tzn. inflací stále zlevňuje). Roční spotřeba takového domu je 30-40MWh, ale všichni jsou s tím spokojení. Ani FVE se nedelá, i když by se výkon časově kryl s maximem spotřeby.
Tohle je prostě jen Evropské brečení, jinde jsou větší pragmatici.

[r223]

Dokonale spolehlivý software je potřeba pro místa, kde se nedá dělat servis nebo musíte garantovat dekádu provozu bez problémů a certifikace. Letectví, vesmír, lékařství... o trošku méně automotive, možná těžaři a nebezpečné průmyslové provozy.

Ale pořád to nemusí být optimalizovaný software, naopak, může být výhodnější napsat jednodušší software (super loop s minimem podmínek) a "matematicky" dokázat jeho spolehlivost než ladit každou ztracenou mikrosekundu nebo pár byte paměti (za spolehlivost se platí a dražší čip se už v té ceně ztratí).

Tato oblast mě zajímá a reaguji na informaci o matematickém dokázání spolehlivosti. Mám velmi rád programovací jazyk Ada, kde se právě pro toto prokázání používá nástroj Spark. Dle dokumentace od Adacore jej však nelze využít pro C/C++/Rust, cituji: "Kódu psanému v C/C++ nebo Rustu se SPARK použít nedá –⁠ nejvýš můžete ze SPARKu volat funkce napsané v C a těm pak důvěřovat nebo je testovat klasickými postupy, ale matematický důkaz vlastností pro ně SPARK nevede.". Umělá chytrost mi nabízí možnosti Frama-C + ACSL/WP, CBMC pro C++ nebo Prusti pro Rust, využíváte některou z nich?

Já používám formální analýzu výjímečně a vlastně pouze v FPGA designech, v místech, kde se řeší střet více hodinových domén.... většinou nad VHDL, což je de fakto ADA.

[r223]

Já pravě vidím pravý opak - čás vývojáře je nic pokud je schopný optimalizovat.

Pokud píšeš aplikaci pro desktop, tak čas vývojáře je velký náklad, pokud pro servery, kde jich budeš potřebovat tisíce, tak jakákoliv optimalizace může ušetřit miliony (v USD). Čas vývojáře byl drahý než přišel cloud.

Tohle, a možná ještě nějaký hlubší lowpower jsou jediné aplikace, kde jsem se setkal s tím, že to někdo ocení...
Jo, AVX-2  v asm, to byla zábava Ale smysl to mělo zatím přesně jednou.

[BoneFlute]

mi opravdu nepřipadá jako uspokojivý stav věcí.

To je vám ke cti (ve skutečnosti s vámi do určité míry souzním), ale to je asi tak to jediné pozitivní, co se na tom dá najít.

Rovnice je jednou daná, a nemá smysl být nešťastný, že byste chtěl, aby dávala jiné výsledky.

No jo, to je ovšem zase takový ten přístup jak zpíval Werich, "tohle člověk nezmění, to je bóží řízení..."
...
A i kdyby mě ten dav nakonec ušlapal, můžu si říci-aspoň jsem zkusil se proti tomu postavit. Stavět se na odpor hlouposti je podle mě morální povinnost každého rozumného člověka.

To si nerozumíme. To není v tom, že je to boží řízení. To je v tom, že vy neumíte počítat. Já vám opravdu nezaplatím x $ za to, abyste vy měl pocit, že je to správně.

Možná ještě příklad:

Já když budu chtít vytvořit projekt, a budu poptávat vývojáře, tak vyrazím dveře s vývojářem, který mi bude tvrdit, že v C to napíše lépe, ekonomičtěji, než to by to napsal nědo jiný v Rustu. Když vím, že ten C vývojář bude desetkrát dražší, zatímco to Rust programátor to udělá líp, i když bude méně zkušenej, a výsledný kód bude měně optimální, což se mi do ceny nepromítne.