Vlákno názorů k článku Výuka programování – nástroje pro ilustraci činnosti mikroprocesoru od D.A.Tiger - Já si myslím, že znalost architektur počítačů a...
-
Já si myslím, že znalost architektur počítačů a assembleru je pořád do jisté míry aktuální. Hlavně pro vývoj operačních systémů, nebo programování strojových počítačů, tvorba kompilátorů... atpd. prostě pro LOW-LEVEL programování.
Na vyšší úrovni... řekl bych, že takové znalosti nejsou naprosto nutné, ale rozhodně ani k zahození. Ale i aplikační programátor by měl alespoň tušit, že jeho program přechroupává nějaký ten procesor, nebo mít alespoň mlhavé ponětí jak se data ukládají na disk, nebo v paměti - ono se tu a tam shodí. :)
-
Mfrd (neregistrovaný)
Assembler má veliký význam. Představte si aplikace např. v měření kde nemáte externí napájení (ani soláírní článek) a potřebujete aby zařízení fungovalo např. 10 let. Pakopravdu mnohdy počítáte každou zpracovanou instrukci. I když C překlady jsou docela dobře optimální, mnohdy můžete nějakou funkci upravit, tak aby byla vhodná pro dané zadání i když nebude univerzální a ušetřit mnoho hodinových cyklů a snížit spotřebu zařízení. Před 2 měsící jsem psal takovou aplikaci. Nejdříve měla 750 bytů, V současnosti má něco kolem 752 bytů.
-
predpokladam ze 2 bajty / mesiac je rychlost kodovania len v ostatnom case. predsa len, 750 mesiacov je nieco cez 60 rokov...
ale inak suhlasim s tym ze assembler ma velky vyznam, custom optimalizacia na strojove takty tiez. jemny problem vidim v tom ze takto treba pisat mizive promile aplikacii, absolutna vacsina moze byt sprasena vo visual basicu, na desktope sa spotreba az tak velmi neriesi.
-
Pavel TišnovskýZlatý podporovatelNa desktopu asi jeste ne (desktop je stejne mrtvy :-D), ale pokud nejaky vyrobce dejme tomu tabletu dokaze diky optimalizacim vytriskat o par hodin vice casu na ty stejne baterie (se stejnou kapacitou jako ma konkurence), je to teoreticky zisk v radech milionu.
-
Pavel TišnovskýZlatý podporovatel
ja jsem nemyslel ani tak programy v user space, ale drivery, dekodery videa apod. A samozrejme dnes nema moc smysl psat velke casti kodu v asm, ale treba interni smycky, kde benchmarky na *realnych* datech ukazou problem, se i dnes dost optimalizuji na vsech urovnich (uprava datovych struktur a dalsi hi-level optimalizace az po low-level veci).
-
Rax (neregistrovaný)
Znalost funkce procesoru, cache, ram, a podobně včetně assembleru a věcí kolem je pro profesionální programátory naprosto nutná a nevyhnutelná. Samozřejmě není třeba dneska psát aplikace v assembleru, ale je třeba znát principy.
Objevily se názory že po vzniku Javy a C# jsou tyto znalosti zbytečné, ale skončilo to katastrofou, přirovnal bych to asi jako ženská za volantem. -
Predrecnik chtel rict, ze ani tak nezalezi na tom, jestli to pobezi v asm rychleji a o kolik, ale spis jde o to, ze bez znalosti hw a asm tezko odhadnout slozitost operaci nad datovymi strukturami a z toho slozitost celych algoritmu. A to je misto, kde se usetri (nebo lze zkazit) vetsinou mnohem vic nez prepisovanim do asm. Samozrejme jsou vyjimky jako napr. ty MMX.
Cili muj zaver - jakmile se programator dostane k netrivialnim datovym strukturam a algoritmum, mel by znat o cem je hw a asm pod tim (aniz by v tom potreboval neco psat) :-)
-
Michal Kára (neregistrovaný)
Pro odhadování složitosti algoritmů není potřeba znát assembler a ani HW architekturu, to je zcela obecná matematická disciplína.
Může se stát, že člověk v praxi narazí na něco jako je ten problém popsaný níže, kde se projeví HW architektura (práce s cache). Ale to nebývá až tak časté, mnohem častěji se narazí na výkonové problémy v souvislosti s databází.
-
Prave o tom "rozumnem" HW mluvim. To cast programatoru tise predpoklada, druha cast tise ignoruje :-). V tomto pripade uplne staci, aby to bylo na nejake zalozni pasce...
Ale dobre, zkusim realnejsi priklad - kdysi se mi podarilo urychlit program asi na 30% tim, ze jsem jeden switch nahradil bitovymi operacemi. K tomu jsem tedy musel vedet, ze ve switchi se skace a cpu to neco stoji, jak vypada binarni reprezentace cisel atd. Troufam si tvrdit, ze zacatecnika bez predstavy toho, jak ten program vypada ve strojaku by ta uprava nenapadla. Muzem leda diskutovat jestli uz je to ten asm a hw, me pripada ze jo.
-
Michal Kára (neregistrovaný)
No, reálný příklad může být, že to pole může být v L2 cache, může být v hlavní paměti nebo taky může být odswapované na disku. Přístupová doba se v těch případech bude dost dramaticky lišit a přitom programátor často netuší / nemá vládu nad tím, který z těch případů to bude. Znát principy je fajn, jenže moderní počítače / OS jsou tak složité, že nám to často moc nepomůže, protože neznámých je prostě příliš mnoho.
Ad switch: No to je otázka, IMHO by stačilo vědět, že switch je vlastně jinak napsaný "if ... else if ... else if ..." a bitové operace taky nejsou jen otázkou strojáku. Člověk musí o programu přemýšlet, na tom se asi shodnem.
Pointa tady ale je, že pokud vezmu typické případy používání té Javy, tak v takovýhle "switchích" bude problém jen vyjímečně, mnohem spíš se dá program zrychlit tím, že se člověk podívá, jak planner pouští složitý DB dotaz a zkonstruuje ho trochu jinak, takže bude spouštěn optimálněji.
Tedy ne že by znalost HW / ASM vůbec nepomohla, ale hlavní problém je většinou jinde.
-
Pavel TišnovskýZlatý podporovatel
To urcite nelze obecne rict, zalezi na tom, jestli se indexuje od 0 do N nebo naopak (kdysi na pocitacich bez cache bylo vyhodnejsi citat k nule), jak procesor zarovnava data, kolik ho stoji prerovnani bajtu ve slove atd. jestli si prekladac da praci s prevodem na SIMD instrukce.... Bez alespon zakladni znalosti konkretniho HW to rict nejde (a ano, teoreticky to je O(n)).
-
Žena za volantem... Není snad více oblíbené a nepravdivé srovnání jako tohle. Mám takový dojem, že v dopravních nehodách (těch opravdu vážných) vedou muži. A navíc - jen pro zajímavost - moje sestra s jezdila pár let s kamionem. Je to zvláštní, ale je to tak. A co vím - tak za tu dobu neměla jediný přestupek, natož nehodu. Dokáže se s dvěma návěsy otočit na místech, kde se já se (s nadsázkou) stěží vymotám s kolem....
Ale zpět k assembleru. Nevím, jestli jsem se dobře vyjádřil, ale já netvrdím, že jsou zbytečné. A navíc, čím víc toho daný programátor zná a umí, tím určitě lépe pro něj.
S tím trochu souvisí i jiná věc - ono hodně podle mě záleží na charakteru toho co děláte. O tom, že určitá znalost principu je potřeba, jsem už psal. Může na nich záviset na nich třeba přenositelnost vašeho projektu. Ale zas na druhou stranu, drtivou většinu problémů by měl odstínit právě operační systém - který je zodpovědný za nízkoúrovňovou správu zdrojů počítače - a kompilátor. Nemělo by být nutné pokaždé sahat k assembleru - nejlépe vůbec.
Další věcí je to jak člověk k projektu přistupuje. Já jsem toho názoru, že by programy měly pracovat s tím, co jim poskytuje os, a nevrtat se ve věcech, které spadají pod jeho "kompetenci", nebo jeho součástí. A pokud je potřeba něco změnit, nebo dodělat, je mnohem lepší (pokud na to programátor má) to udělat na úrovni os (nebo daného prostředí, knihovny), než to cpát do aplikace, a tím rozšířit možnosti celého os rovnou pro všechny. (Příkladem budiž podpora některých zařízení v přímo v Total Commanderu, i když v prostředí jaké panuje na Widlích to do jisté míry chápu, ale nesouhlasím s tím)
-
K tem zenam za volantem - z vlastnich pozorovani bych rekl, ze kdyz uz se vyskytne jedinec, ktery neni schopen dosahnout kontroly nad vozidlem, pripadne zohlednit deni okolo, byva to spis zena. V tomto ohledu prirovnani docela sedi. Pro uplnost, muzi kontrolu nad vozidlem ztraci az s narustajici rychlosti... (cti jezdi jak prasata). Samozrejme to nevylucuje lemply muze a zenske superridicky a celkove to klise je ve sve jednoduchosti nekorektni. Vetsina lidi co znam ridi dobre bez ohledu na chromozomy.
-
phr (neregistrovaný)
Assembler se hodí v případech, kdy člověk nesahá "pod systém", ale chce naprogramovat něco, co neumí příkazy nebo knihovny zvoleného překladače. Příkladem toho budiž třeba TurboPascal, pomocí InLine Assembleru se daly udělat věci, nad nimiž laik žasl a odborník se divil :-)
A i v assembleru se dá psát čistě, zrovna tak jako se ve vyšším jazyce dají napsat pěkně prasácké konstrukce.Pozdravujte sestru a zveřejněte její fotografii, ať vidíme jak vypadá kamioňačka.
-
Pokud vím otázka byla položena obecně, a i když používám jako příklad věci týkající se os (líp se mi to vysvětluje), myslím to obecně. Ale dobře, a v čem je ten diametrální rozdíl? Principiální hledisko se mi zdá stejné - je-li nutné často sahat k nízkoúrovňovým implementacím, pak překladač (nebo jeho knihovny) asi někde selhává....
Ano, mohou nastat případy, kdy je potřeba / nezbytné sáhnout k assembleru. To jsem přiznal už na začátku. Ale prostě se mi nezdá, že by při dnešní úrovni kompilátorů a operačních systémů (pokud vím tyto dvě věci musí jít ruku v ruce) bylo nutné aby každý programátor ovládal assembler....
-
phr (neregistrovaný)
Optimalizovány přepsáním do asm :)
Knihovny jsou OK, pokud dělají to co potřebuju. Když ne, musím si je přiohnout a přijdu o optimalizaci nebo ... musím napsat knihovnu vlastní a tu zoptimalizovat. Chcete tvrdit, že už existují knihovny na všechno ? A jakou vlastně máte jistotu, že v knihovně není chyba, bezpečnostní díra nebo backdoor ?
Nechci psát celé programy v assembleru, ale jeho znalost se někdy prostě hodí a nemusí to být zrovna systémové programování.
-
"Optimalizovány přepsáním do asm :)"
Ale tím pádem umožnili využít těch výhod i těm kteří tak dobře asm neovládají - nebo vůbec. A o tom celou dobu píšu, tak by to - podle mého názoru - mělo být..."Nechci psát celé programy v assembleru, ale jeho znalost se někdy prostě hodí a nemusí to být zrovna systémové programování."
Dobře, já jsem jen přesvědčen o tom, že na vyšších úrovních jsou to tak řídké a specifické případy, že prostě není nutné, aby každý programátor asm ovládal. A když je už ovládá, jenom dobře. V principu nemusíme být v opozici, jen trochu jiný přístup, úhel pohledu...K těm knihovnám : Nechci v žádném případě tvrdit, že existují knihovny úplně na vše. Jenže kolik z těch co existují reálně znáte? A použijete? Všechny? Nechci Vás v žádném případě podceňovat, ani se vás dotknout, ale obávám se, že asi ne. A právě proto, že jich je tolik, snižuje se rapidně množina problémů, které je nutno
implementovat v asm (ale znovu opakuji - nezmizela)...Ano mohou obsahovat backdoory, chyby, díry, ale to může obsahovat vše. od os, kompilátoru, runtime, až po... hotové léta používané aplikace. (Konec konců, základní programátorská poučka říká, že každý kód musí obsahovat, alespoň jednu chybu... :). Máme je proto všechny raději reimplementovat? To asi není ta správná cesta.
-
JS (neregistrovaný)
Podle me je znalost assembleru jako takova k nicemu. Ja soucasny x86 assembler neovladam, ale ovladam mainframe assembler (protoze ho potrebuji k praci) a sveho casu jsem ovladal assembler x86 (na 286) a assembler z80. A to prave ukazuje, proc je to k nicemu.
Pokud dnes assembler nepotrebujete, nema smysl se ho ucit. Procesory (i kompatibilni) se dost lisi. Asi by nemelo vyznam dnes prepisovat C do assembleru pro 286, prestoze je to take x86. Takze tahle znalost je mi k nicemu. A kdyz bych nahodou pro nejakou aplikaci assembler potreboval, muzu se ho naucit (ale s vedomim, ze za par let to bude v podstate nepouzitelne diky zmene architektury).
Na druhou stranu, clovek by mel znat alespon jeden druh assembleru, aby si osahal ty koncepty (co je pamet, registry, ukazatele, reprezentace dat a tak dal - s timhle podle me zkusenosti mivaji lide, co znaji jen vyssi jazyk, problemy).
-
Nemyslím, že by to byla úplně pravda. Vezměme si jako příklad tedy operační paměť : alokaci, dealokaci, stránkování a swapování stránek provádí a řídí operační systém. Lze to samozřejmě do jisté míry korigovat. viz např. C++ knihovna Loki a její alokátor paměti pro malé objekty, ale ani v tomto případě se nejedná o asm (celý alokátor je napsaný v C++ a ve výsledku přetěžuje operátory new a delete), ale o znalost principů fungování těchto operací na úrovni operačního systému, vysvětlitelnou, pochopitelnou a proveditelnou bez jediné řádky assembleru.
Ke koňskému spřežení se můžete dostat několika způsoby :
1) Zjistíte, zda není nějaké na blízku k mání
2) Seženete si povoz, dva tažné koně a zapřáhnete celé spřežení.
3) Nakoupíte si kola, oj, dřevěnou bednu, desky, kožené popruhy a koně. Stlučete dohromady vůz, nasadíte kola, zapřáhnete koně...
4) Začnete kácet les, zabijete nějakou tu krávu, vyčiníte kůže, nařežete klády, sešijete postroj na koně ....Stejní to máte i s tvorbou např. desktopových aplikací - já většinou nejdřív začínám bodem 1. K bodu 4 jsem se ještě nikdy nedostal. Mimochodem, k tomu aby jste mohl ovládat końské spřežení, potřebujete vědět jak se klíží desky ve vozu, nebo loukotě v kolech? nebo jak se činí kůže? Určitě je to dobré a může se to hodit, ale myslím, že určitě ne stoprocentně nutné....
-
Promiňte, v záplavě myšlenek jsem nechtěně uhnul z tématu, a blbě zakončil myšlenku - tím Vás asi zmátl.
V těch posledních větách s koňským spřežením jsem chtěl vlastně říci, že z předchozích bodů vyplývá, že když chcete koňské spřežení, ještě to nutně neznamená, že musíte umět kácet stromy, porážet krávy a zpracovávat kůže, aby jste si jej mohl pořídit / postavit.
Co se týče ovládání koní, je to předpoklad pro řízení spřežení asi jako u uživatele Writeru se předpokládá, že umí číst a psát... :)
-
Aha, máte na mysli, kdy kůň prostě nechce táhnout, a nejde jej k tomu nijak donutit? Tak ho prostě vypřáhnu a pošlu rovnou cestou do salámu (říká se tomu znovupoužitelnost kódu ;) a nahradím jej jiným (no rozhodně ho nebudu tvořit já, na to fakt nemám :-D ). Do takové situace jsem se už dostal taky. A taky se mi už párkrát stalo, že ten "kůň" na mě kašlal jen proto, že jsem správně nepochopil jak s ním mám zacházet :)
Jinak kočím je v tomto případě uživatel. Já jsem ten kdo obstarává spřežení. A ano, tomu kdo si u mě objedná koňský povoz je šumák, jestli si káru objednám u bednáře, nebo kvůli tomu vykácím půlku Šumavy a stluču to do posledního prkýnka sám... i když taky to nebývá pravidlem.
