Tak oni pred tou ulohou mnohdy stoji kazdy den, ale vetsinou se to obejde nakupem silnejsiho zeleza. To ovsem (pravdepodobne) uz nebude vzdycky mozny, protoze se cim dal tim vic tlaci na snizovani spotreby a i pres snahu vyrobcu cipu se ta spotreba neda moc stlacit dolu. Nemluvim ani o tom, jakou paseku dela rozsirovani DRAM, ktere jsou strasne pomaly v porovnani s CPU - spatna skalovatelnost cele technologie PC.
Ahoj zpátky do roku 2012.
Mám tady 2 zajímavé příklady.
- Měli jsme upravit nějaký kód kolem UMTS. A jelikož to posílalo XML, tak to bylo fakt triviální a nechali jsme to udělat jednoho juniora. Na nejlevnějším HW to běží jako z praku, takže co řešit?
-A naopak jsme měli upravit nějaké maličké ELFko u jednoho mobilního operátora. Bylo vidět, že to dělal někdo, kdo byl fakt dobrý. Problém byl, že jenom se v tom vyznat a upravit to stálo pár desítek hodin hodně zkušeného (a drahého) kolegy. Jestli bude ještě v budoucnu nějaký požadavek na další úpravu (a tenhle kolega už nebude poblíž), tak si budu rvát vlasy, že jsem to raději nenechat napsat někoho jiného úplně znova. Vyšlo by to levněji.
Tož tak.
Někdy mám pocit, že lidi, co v roce 2012 psali specializované aplikace, které měly běžet na jednom nebo několika strojích, nechápali, kolik stojí hodina jejich práce a kolik stojí použít výkonnější HW.
Ahoj z roku 2012.
Tohle znáš? http://catb.org/jargon/html/story-of-mel.html
(Chtěl jsem se podepsat Minulost... :-D)
Myslím, že současné programátory trochu podcenujete. Co třeba programátoři mobilních telefonů (a mám na mysli opravdu telefony, ne smartphony)? Nebo poloautomatických linek (např. balících, nebo pájecích strojů) atpd.? Ti všichni si musí vystačit s docela omezenými systémovými prostředky, a nemohou se spolehnout na to, že si je uživatel případně rozšíří, nebo updatuje...
No tak ne že by neexistovali. Ale je jich málo. A pokud jde o mobily a podobná zařízení - právě zde bych řekl, že jsou docela velké rezervy v tom, co se píše a v tom, co by napsat šlo. Jako celoživotní embedded vývojář jsem potkal už spoustu kódu pro různá podobná zařízení a musím říci, že ani v této oblasti se už s vývojem nikdo příliš nes...piplá. Zrovna ta malá zařízení jsou obvykle založena na technologiích, které se dají obsáhnout v jedné hlavě, na procesorech, u nichž je "ruční" optimalisace v Assembleru stále vysoko nad schopnostmi překladačů (jednak kvůli tomu, že instrukční sady jsou jednoduché a přímočaré, dále kvůli tomu, že ty překladače rozhodně svými kvalitami v generování kódu nevynikají), takže využít by se dala mnohem lépe. Ale je to jako se vším - pokud není tlak ze strany poptávky, tak to pochopitelně nemá cenu dělat.
Pokud se v oblasti embedded systemu jeste optimalizovalo, tak prave probiha revoluce. S nastupem levnych ARM procesoru (treba STM32Fxxx, atd) nebude treba setrit ani v teto oblasti; urcite nebude treba optimalizovat tak brutalne, jako v minulosti, kdy se pouzivali 8-bitove MCU a psalo se prevazne v asembleru. Jedine ceho se tem malym ARM MCU nedostava je SRAM, te je stale relativne male mnozstvi, typicky kolem 4kB, ale jsou dostupne i MCU s 64kB, pripadne i vice...
Lidska prace je draha, HW je levny... ;-)
Nic ve zlém, ale doplnil bych k tomu "...řekl by laik." :-)
Ve skutečnosti to tak jednoduché vůbec není. Levné ARMy tu jsou už dávno a 64 KB SRAMky na čipu není nic neobvyklého. Jenže situace vypadá úplně jinak, máte-li vyvinout zařízení na baterie a počítáte každý ušetřený miliampér, případně nějaký jednoduchý modul, stovky nichž budou viset na nějaké sběrnici, z níž také mají být napájeny.
A v neposlední řadě - komplexnost a složitost těch nadupanějších procesorů nepřidává zrovna na spolehlivosti. Roste počet řídících registrů, jež je třeba správně a ve vhodných okamžicích nastavit, množství kódu, který prostě C&P ze vzorových příkladů výrobce nebo připojíte z jejich knihoven, přičemž o bezchybnosti, resp. robustnosti toho kódu není radno si dělat nějaké přehnané iluze. Kousnutí se nějakého čidla ve výrobní lince pak není jen otázkou tlačítka RESET jako u PC, ale snadno spočitatelných finančních ztrát.
Vývoj embedded aplikací má prostě svá specifika. ;-)
Urcite se pro nektere aplikace, kdy se ma treba vyrobit jen nekolik desitek-stovek kusu, pouzivaji i vykonnejsi MCU nez by bylo striktne nutne. To je skutecne jedno a lidska prace zde ma vetsi cenu resp. dopad na cenu vyrobku.
Ale je spousta aplikaci, u nichz se pocita kazda usetrena koruna (nebo spis juan :-) a kazdy watt prikonu - to je ostatne jeden z duvodu, proc se i dnes setkavame napriklad s jednoduchymi 6ti a 8mi pinovymi PICy s par bajty RAM. Tam kde je zapotrebi jen nejaka komunikace s cidlem a rozhodovani na zaklade tabulky atd. nic slozitejsiho netreba.
to neni zas takova pravda, uz roky bezi (ci skomira) minigame compo pro 8 bitove masiny a jsou tam kategorie 1, 2 a 4 KB. krome jednoduchych hricek se ucastnil i klon Civilizace a par dalsich velmi zajimavych kousku.
nemluve o demoscene (a bavime se tu prakticky o vsech platformach od vcs 2600 po moderni PC), kde je docela oblibena kategorie 1KB a 4KB intro a kolikrat je opravdu neuveritelne, co se do pameti vejde.
priklad 256B demo raycastingu implicitnej plochy na PC (autor studoval FEI STU v Bratislave v dobach Pentii III):
http://pouet.net/prod.php?which=4659