( uid_6201 | 2022. 10. 02., v – 09:10 )

Az attól függ. Beágyazott procis cuccoknál van olyan szempont is, hogy
  - adott a vas, már le van gyártva a spéci perifériákkal rendelkező célhardver (akár egy előző projekt kapcsán).
  - adott az aktuális feladat
  - szoftvertempó és szoftverméret az egyetlen változó, amivel az előző kettő feltételbe kell illeszkedned.
Persze van olyan is, hogy "lehetetlen", akkor a feladaton is faragtatni kell VAGY közös erővel meggyőzni a vezetést egy újabb, korszerűbb hardverre való újratervezésről, ami nem kis költségnövekedést okoz.

Véleményem szerint ahol a másfeles lassulásszorzó már problémát okoz, akkor ott valami okból igencsak alul lett méretezve a hardver. Ez azért gáz, mert egy eredetileg nem tervezett pluszfunkció, netán erőforrásigényben 20..30%-kal félrekalkulált funkció esetére sincs optimalizálási (spórolási) mozgástered. Egyszer egy ilyenbe csúnyán belefutottam én is, a célhardver skálázásra ott sem volt lehetőség és a szoftverből sem lehetett kipaszírozni már több megspórolást.
A legsarkalatosabb, amivel találkoztam egy svájci cég kapcsán történt, ahol kiemelt szempont volt a mikrovezérlőn is néhány cent megtakarítása, mert olcsó lakossági kütyü milliós példányszámban gyártandó szériájáról volt szó. Itt volt az, hogy a programban utólag byte-okat kellett megtakarítani, hogy beleférjen a legutolsó funkció is a flash-be. Egyébként éppen a flash méret az, ami nem szokott szűk keresztmetszet lenni. RAM mennyisége és a CPU számítási teljesítménye a gyakrabb korlát.

Szóval nem fekete-fehér a téma. Másik véglet, a felhős környezet, ahol megszokott, hogy sebaj, indítunk egy újabb példányt. Áramkörbe beágyazott CPU-knál ez nem járható. Az egy másik kérdés, hogy felhős megoldásoknál is érdemes (lenne) a kifejlesztett szoftver által biztosított szolgáltatás várható futamidejére egy TCO becslést csinálni és megvizsgálni, hogy nem érné-e meg több szoftverfejlesztés és kevesebb X évre fizetett futásidejű költség.