Názory k článku
Výuka programování – nástroje pro ilustraci činnosti mikroprocesoru

me uz prestaly bavit vysokourovnove javy, C#.
tak jsem se vrhnul na pic, attiny, atmega a assembler a C, clovek
ma pocit, ze se vratil do dob zx spectra, commodore, alfi:
http://www.merkurtoys.cz/vyrobky/plotrovy-zapisovac-alfi-z-merkuru%5B1%5D

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í. :)

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

Ano, ale to už jsou trochu specifické aplikace, a hádám (dle vašeho popisu) dost blízko hw...

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.

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

najlepsie tablety sa aj tak programuju v jave

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

Jen oprava výsledný kód byl pak 152 byte.

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.

Muzu vas uklidnit - tyto uvahy se objevily jiz po vzniku Cobolu a od te doby vzniklo mnoho milionu radku kodu v cistem asm a mozna jeste vice pomocnych funkci, ktere proste v asm vychazi nejlepe (ostatne ani Cecko nezvladne MMX, SSE atd.)

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) :-)

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

> Pro odhadování složitosti algoritmů není potřeba znát assembler a ani HW architekturu, to je zcela obecná matematická disciplína.

Jak uz jsem psal jinde, jak urcite slozitost
array[i]
kdyz vam nereknu na cem to pobezi?

Ale to je otázka jazyka a ne HW. (Teda, v na "rozumném" HW, možná existuje nějaký exotický HW, kde to tak není.)

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.

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.

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

S tím souhlasím, ale již se nepíšou celé aplikace v ASM, což se ještě před asi 10-ti lety dělo, takže jistý posun tady je.

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

ok, beru...

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.

O tom jsem psal už v tom příkladu s TC - proč to cpát do aplikací (pokud to nejsou nějaké systémové utility a i v jejich případech bych se snažil tomu co nejvíce vyhýbat)?

Sestru pozdravovat budou, ale tu fotku... to nechám čistě na ní :)

Tady nejde o sahání pod systém, ale pod překladač a to je sakra rozdíl.

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

Napadá mne třeba připad [za/de]šifrování datového záznamu. Jde to samozřejmě přímo v daném jazyce, ale v assembleru je to obvykle kratší, má to zanedbatelnou časovou režii a ten kdo assembler nezná, tak algoritmus šifrování nerozluští.

Dobře. A jak často narazíte (v uživatelských aplikacích) na požadavek přímo implementovat (de)šifrovací algoritmy, místo využití již existujících např. gpglib, nebo libcrypt (abychom nebyly jen v C, C++), které jsou už hotovy, odladěny a optimalizovány?

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.

Nějak se mi vytrácí o čem se tady vlastně dohadujeme. Jdu spát. Dobrou noc.

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

Tady nejde o to v čem se člověk vrtá, ale co jeho program dělá a od základních věcí jako CPU, RAM, cache, práce s HDD a podobně ho neodstíní žádný OS, ani žádný runtime. V assembleru se dneska skutečně nic psát nemusí, ale je nutno znát principy.

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

Co uděláte, když zjistíte, že vás koně neposlouchají ?

Vyměním kočího :)

Ale jak to souvisí se stavbou (získáním) povozu? Ovládnutí koně přece patří k řízení povozu. K používání OpenOffice taky nemusím ovládat Pýthon.... nebo ano?

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... :)

Kočí jste přece vy. A když vás vymění, přišel jste o práci. A oprávněně - nezvládnul jste spřežení.

A s programováním je to podobné - šéf se neptá jestli to jde napsat v céčku, šéf se ptá jestli to jde napsat.

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.

Zkoušel jsem navázat Assemblerem přímo na Karla. Prostě máte malého robota s daným jednoduchým strojovým kódem o pár instrukcích povětšinou odpovídajících základním primitivám Karla, akumulátorem, příznakovým registrem, 256 byty RAM, nějakým tím podmíněným skokem, zásobníkem od horní adresy...
Převod programů z Karla je pak celkem přímočarý, dělá to něco viditelného, instrukční sada je primitivní, ale ukazuje všechno podstatné, snadno se to ručně překládá a interpretuje atd.
Ideální by bylo mít toho robota postaveného fyzicky :-) A určitě by neuškodilo ukázat, jak se ten jednoduchý procesor sestaví z jednotlivých logických členů...

Popis návrhu jednoduchého procesoru a SoC je třeba zde

Jan Gray, Gray Research LLC
Building a RISC CPU and System-on-a-Chip in an FPGA
http://www.fpgacpu.org/papers/xsoc-series-drafts.pdf
http://www.fpgacpu.org/xsoc/cc.html
http://www.fpgacpu.org/papers/index.html

Pokud vyvíjíte software pro embedded systémy na holém železe,
tak je dobré vědět, co se tam děje :-)

co na tu fyzickou stavbu pouzit Lego, ale namisto hlavni kostky z Mindstorms pouzit vlastni bastl treba s PICem?

lego kostka NXT v sobe myslim obsahuje nejakou atmegu.
takze to jde nahradit vlastnim bastlem nebo arduinem apod.
oni v kostce uz maji vyresene pekne napajeni, konektory, usb atd.

Diky za informaci, to jsem nevedel a mel jsem "ridici" kostku za cernou skrinku s proprietarni technologii.

jeste jsem se chtel Pavle zeptat, co pouzivas za svaba pro tu implementaci "virtualniho" CPU?

Počkej, já se k fyzické realizaci ještě ani zdaleka nedostal :-) Ale kdyby jo, mám pár at90usb162, tak bych použil asi ten. Otázka je, jak vyřešit značky. Už jen aby ten robůtek nemusel nosit zásobu na zaplnění celého města (zvlášť pokud se na jednom poli povolí více značek) :-)

* mohl by vozit fixku a malovat znacky na (papirovou) plochu
* znacky by nebyly fyzicky na plose, ale jen virtualni a robotek karel
by po prijezdu ke znacce rozsvitil svoji diodu
* roboticka by mohla byt i hraci plocha, matice diod prekrytych plexisklem,
roboticka hraci plocha by spinala LEDky/znacky ve spolupraci s robotem karlem

druhá a třetí možnost mě napadly. Hezkou implementaci s fixkou má třeba tahle realizace Turingova stroje: http://www.youtube.com/watch?v=E3keLeMwfHY.

vdaka za skvely clanok! .. od vas som snad este nevidel ani clanok, ktory by nestal za precitanie.

k ankete ohladne assembleru: samozrejme, ze ma zmysel znalost assembleru a architektur. mozno nie pre kazdeho programatora .. ale .. nie je programator ako programator.

ten turinguv stroj s fixkou ma dobre reseni, ze se to pise na foliovy
pas takze to lze i mazat.

Aha, ja myslel, ze uz mas neco zbastleno. Ja jsem prave (po par dotazech od znamych) premyslel, co na vyuku low-level programovani pouzit a kupodivu mi to porad vychazi na PICy (ale ty maji "divnej" assembler) nebo na starou dobrou 8051, kde jsou sice taky pro zacatecnika prapodivne instrukce, ale je ten zaklad je dobre pochopitelny.

jako dlouholety programator vyssich jazyku, ale zacatecnik v hw a mikrokontrolerech jsem zkusil nejprve PIC16 a tedka ATMEL TINY13 a musim
rict, ze se mi atmely zdaji lepsi a pohodlnejsi.

-i pro malinkaty tiny jde delat v C, mam dojem, ze C pro PIC je az od PIC18.
-v linuxu mam avr-gcc a avrdude, nepotrebuju windowsi mplab.

Ja myslim ze znalost neni nutna.

Jsem typicky javista, rekneme JEE java, muzete mi konkretne rict,
kde znalost asm a pocitacove architektury je NEZBYTNA a vedla by
k fail projektu v jave?

Rad bych aby mi tu nekdo ukazal ze ano (abych nemel dojem ze
semestry na skole byly jen intelektualni exkurz), nicmene z toho
co mam zatim za sebou jako programator my tyhle znalosti prisli
spis "do supliku".

Pokud nehodlate vymyslet novy jazyk, programovat superoptimalizovane
moduly, casti operacniho systemu pripadne grafiku, tak moc prostoru pro tyhle
znalosti nevidim, bohuzel.

A byla nutná celá ta vejška? Tesař taky moc nevyužije stavárnu.

Tak ono to nutne nemusi vest k "fail" jak vy rikate. Spis to bude tak, ze nahodou to dopadne docela dobre.

Kdyz to prezenu, tak bez znalosti architektury nejste ani schopen rict, jakou slozitost ma
int i = array[k];

Blize realite bude, ze nejaky select do DB nebudete poustet v nejvnitrnejsim cyklu, protoze vite, ze to ma nejakou odezvu prave diky tomu, ze mate poneti o tom jak to beha uvnitr. Stejne tak vselijake pristupy na disk, aktivni cekani apod. Uz jsem se setkal s programy, ktere by autor napsal jinak kdyby tusil jak to chodi uvnitr, a to nebyly zadne lowlevel veci. Mozna si to jen neuvedomujete, ale delate rozhodnuti na zaklade te znalosti kazdy den...

Napriklad, aby ste vedeli, ako napisat zakladne veci tak, aby netrvali zbytocne dlhsie, ako by mali. Tu je maly priklad:

Tu su dve, skoro uplne totozne implementacie algoritmu Floyd–Warshall v jave:

class fw1 {
  public static void main(String args[])
  {
    int i,j,k,N=1000;
    int [][] pole = new int[N][N];
    for(i=0;i<N;i++){
      for(j=0;j<N;j++){
        pole[i][j]=(i*(N-j))%5000;
      }
    }
    for(i=0;i<N;i++){
      for(j=0;j<N;j++){
        for(k=0;k<N;k++){
          pole[i][j]=Math.min(pole[i][j],pole[i][k]+pole[k][j]);
        }
      }
    }
  }
}

a

class fw2 {
  public static void main(String args[])
  {
    int i,j,k,N=1000;
    int [][] pole = new int[N][N];
    for(i=0;i<N;i++){
      for(j=0;j<N;j++){
        pole[i][j]=(i*(N-j))%5000;
      }
    }

    for(k=0;k<N;k++){
      for(i=0;i<N;i++){
        for(j=0;j<N;j++){
          pole[i][j]=Math.min(pole[i][j],pole[i][k]+pole[k][j]);
        }
      }
    }
  }
}

Mozete si vsimnut, ze sa odlisuju len poradim vnorenia cyklov (prvy ma poradie i,j,k a druhy k,i,j). Teraz skuste, bez kompilacie a nasledneho spustenia odhadnut, ako budu na tom casovo tieto dve implementacie.

Vysledok prezradim:

[bwpow@brum ~]$ time java fw1
25.72user 0.00system 0:25.73elapsed 99%CPU (0avgtext+0avgdata 57216maxresident)k
0inputs+64outputs (0major+3851mi­nor)pagefaults 0swaps

[bwpow@brum ~]$ time java fw2
12.78user 0.02system 0:12.81elapsed 99%CPU (0avgtext+0avgdata 57104maxresident)k
0inputs+64outputs (0major+3844mi­nor)pagefaults 0swaps


A teraz skuste nad tym porozmyslat, preco je to tak.

Muze to byt tim ze c-like programy (java inclusive) ukladaji pole linearne do pameti.

Do pameti se vejde jen cast vetsiho multi-dim pole.Pokud je ukladani linearni potom ma smysl zafixovat nejvyssi index a iterovat nad nizsimy indexy.

Diky tomu v pameti zustane delsi dobu stejmy blok dat a nebude se muset neustale do pameti nahravat blok jiny tj. v nejhorsim pripade pri kazde i*j iteraci (cca, ono se tam par bloku vejde).

Ve fortranu by to neplatilo, neuklada pole "linearne".

K fail vede už samotné používání Javy, protože samotní autoři Javy z vysoka kašlou na to co se v PC skutečně děje, je jim to prokazatelně úplně jedno a je to hlavní důvod proč si Java nezískala větší oblibu mimo hračky, přestože se jí už 15 let prorokuje nehynoucí sláva.
Nicméně i v Javě se dají například využít možnosti 2/3/4-channel řadiče paměti, když se ví jak na to.

> ... je to hlavní důvod proč si Java nezískala větší oblibu mimo hračky ...

Prosím, řekněte, že jste to myslel jako vtip, prosím...

> Java nezískala větší oblibu

Tim myslite jeden z nejpouzivanejsich jazyku pro OSS projekty, dlouhodobne prvni v tiobe indexu, primarni na nejprodavanejsich smartphonech a v podstate standard v enterprise?

vzdycky me fascinovali lidi kteri umi mluvit o necem cemu vubec nerozumi

Nejde přímo o znalost programování v asm, ale o to, jakým způsobem vás to naučí myslet. Projeví se to zejména při optimalizacích, ať už na výkon, nebo na paměť. Při projektovém developmentu se s tím asi často nesetkáte (proč optimalizovat tam, kde se každých pár měsíců začíná od nuly :)), to spíš při produktovém - tj. firma má nějaký (netriviální) produkt, který se několik let vyvíjí a prodává, má spoustu funkcí a musí se držet kvalita.

Aneb: Dokážete v Javě napsat XML parser, který naparsuje 100MB docx z Wordu do objektové struktury podobné DOMu (tj. elementy, atributy, parent-children atd. - aby se to dalo komfortně editovat, žádné read only!) a přitom tato objektová struktura nezabírá v paměti ani těch 100MB?
(uvědomte si, že char má 2 bajty, takže jenom jako tupý String by to zabralo 200MB...)

Jde to :) ... i když to asi není typická úloha "komerčního" JEE devu.

budu uvazovat nahlas jak to asi udelat.

docx je xml, slova se v textu jiste opakuji takze by sel pouzit slovnik mapujici slova na kratsi datovy typ.

to by bylo mozna nejvetsi uspora pameti.

Taky bych rekl, nejak podobne, i kdyz Javu nepouzivam. Ja v tom nevidim moc problem - proste slovnik jednotlivych tagu, a kazdy pocatecni tag se nahradi pointerem na strukturu s informaci o nem, a pak na data (DOM je v podstate strom). Nevim uplne jak resit mixed content, ale nejlepsi je asi zvlast tabulka tagu a jejich index do retezce (ktere by se samozrejme ukladaly jako UTF-8, jak je zvykem v normalnim svete). XML je tak ukecane, ze tuhle ulohu by zvladlo i dite.

myslel jsem nejen slovnik/tabulku tagu, ale udelat pri nacitani dokumentu do pameti domu i analyzu textu na opakujici se slova, mozna snad i casti vet a vlozit je do slovniku taky.

a ted me napadlo, ze i pokud by se ve stromove strukture nejaky podstrom taky opakoval, ze by se taky mohl vrazit do slovniku a misto podstromu by se vlozil uzel odkazujici na ten slovnik.

Ano, základní nápad je slovník, který mapuje String na int. Cestou je pak ještě několik pitfalls:
a) jak ten slovník udělat? HashMapou určitě ne...
b) když má Element dva fieldy typu int, je lepší je sloučit do jednoho typu long (na x86_64 to zabere polovinu místa kvůli zarovnávání) - k tomu potřebujete bitové posuny a maskování - v asm denní chleba, ale spousta javistů operátor >> snad ani nezná a hexa konstantu v maskování považuje za HTML barvu :)
c) opravdu musí mít Element reference na všechny childreny? Jedna reference stojí 8 bajtů... (opět na x86_64)

asm učí člověka "smyslu pro bajty". Díky mu za to! Jeden pitomej bajt může být i docela složitá datová struktura :)

Co jsem tím vším chtěl @flv říct: naprostou pravdu má Kyrill o pár příspěvků výš: člověk se podle těch znalostí rozhoduje každý den, třeba i neuvědoměle. Proto by se měl starat o to, aby ty znalosti za něco stály. Mnoho C/C++ geeků nemá Javu ráda, protože se domnívají, že by spousta javistů v "přímém střetu" s bajty a memory managementem neobstála. V tom se bohužel nemýlí, je to tak. Tak situaci ještě nezhoršujme tím, že na to budeme kašlat záměrně.

"Mnoho C/C++ geeků nemá Javu ráda, protože se domnívají, že by spousta javistů v "přímém střetu" s bajty a memory managementem neobstála. " No a teď kacířská otázka: Proč je to (obecně *) špatně?

*) samozřejmě existují případy, kdy je přímá kontrola nad memory managementem nebo minimální paměťová náročnost opravdu potřeba, ale já se ptám, proč by to mělo být potřeba univerzálně

To není kacířská otázka, to je úplně normální otázka :)
Protože cesta člověka změní. 95% věcí, co jste se naučil ve všech školách, můžete klidně zapomenout, přesto je dobře, že jste tam chodil. Mezi "kdysi vědět, pak zapomenout, protože nepotřebovat" a "nikdy nevědět" je velký rozdíl (který se samozřejmě těžko měří).
Můj názor je, že když si někdo zvykne na větší disciplínu při zacházení se zdroji, bude z něj lepší programátor i v jazycích nebo prostředích, které některé zdroje spravují automaticky. Java udělala na začátku velkou chybu, když se tak tvrdě vymezila vůči "zastaralému C++", protože to tak akorát nakrklo spoustu lidí, přitom všichni vždycky věděli, že je to něco za něco. Stalo se i to, že takto marketovaný jazyk přitáhl spoustu lidí, kteří na to řemeslo vlastně nemají. Ale měří se to obtížně, to já vím, navíc je to silně taženo poptávkou. Jen ta pověst je pak taková nějaká horší.

Nic ve zlem, ale me ty tri poznamky prijdou silene.. Proc to delate v Jave, kdyz musite obchazet to, co v C zaridite daleko snaz? (Krome toho x86_64; ale snazit se obejit 8 bajtovych pointeru pouzivani integeru mi pripada take jako sileny napad; mozna by bylo spis na miste zauvazovat, zda preci jen nejak nelze pouzit 32-bitove pointery, pokud je to takovy problem - o cemz pochybuji; nebo proste to vzit jako tradeoff a nakoupit 2x tolik pameti).

(A element reference na vsechny deti nepotrebuje, staci odkaz na prvni a na dalsi.)

To je asi jedna z mych vytek vysokourovnovym jazykum. Ted jsem delal neco s unmanaged memory v C#. Oproti Ccku to byl porod (marshall data z a do unmanaged haldy) a neefektivni, a ne ze by mi hrozilo min chyb.

(ty integery tam nejsou primárně jako náhrada pointerů, ale to není podstatné)

Proč v Javě? Zejména kvůli integraci se zbytkem aplikace, která je celá v Javě. Dělat se s takovou věcí v C a používat JNI by bylo ještě mnohem šílenější, alespoň pro mě (posledních pár let jsem v C nedělal a nikdo tady kolem mě taky ne). Java má opravdu spoustu výhod... a taky pár nevýhod, které se někdy dají umně obejít. Zda je to šílené záleží na úhlu pohledu - a taky na prahu bolesti :)

my jsme ve skole pouzivali na hrubou predstavu o cpu tohle: http://introcs.cs.princeton.edu/xtoy/ (http://introcs.cs.princeton.edu/java/52toy/)

Kdysi dávno v nějakém zvláštním pohnutí mysli to koupil šéfík jakožto prostředek výpočetní techniky a nás mladé techniky mohli omejvat, protože co s tím, když už jsme měli onačejší stroje z disketami. Naštěstí se po čase vyskytlo zadání - na jednom místním zdravotnickém oddělení potřebovali signalizaci na přivolávání personálu. Takže jsme nechali elektrikáře po baráku natahat čtyřžilové kabely, ty jsme spojili do hvězdy, ke každé posteli přišla krabička s jednoduchým sériovým kodérem a na sesternu kisna s touhle hračkou, zdrojem a reproduktorem, displej jsme vyhodili a místo něj dali pořádné sedmisegmentovky, aby bylo vidět číslo postele a pokoje.
Brzy na nás sestry začaly koukat s nenávistnými pohledy, protože akustický signál se sice nechal vypnout na sesterně, ale zobrazená žádost se dala smazat až na pokoji. Navíc si zařízení pamatovalo nevyřízené požadavky (co se do kila vešlo), takže primář nebo vrchní sestra měli přehled, jak se personál fláká.
Fungovalo to spolehlivě několik let i když se na procesoru made in Piešťany nedala udržet ruka a nepřijít listopad 1989, tak to funguje dodnes.

Takze ve vysledku jste udelali funkcni a blbuvzdorne zarizeni, ktere delalo presne to co melo a navic diky sve jednoduchosti neobsahovalo dnes tak oblibena kurvitka. Zajimave je, ze prave tyto systemy vydrzi v provozu fungovat k plne spokojenosti nekdy i desitky let, zatimco "moderni technologie" okolo se treba za stejnou dobu 3x obmeni.

Problém je v tom, že kdo by dnes chtěl dělat něco takovéhleho, tak by se bez kurvítek neuzivil :-(

No jedno kurvitko by v tom zarizeni bylo jaksi implicitne - podle EU norem se pouziva pajka bez olova, takze vlastne kazde nove elektricke zarizeni (s plosnakem) ma o dost kratsi zivotnost nez by treba odpovidala zivotnosti soucastek (jeste me napadaji vysychajici kondenzatory asi odnekud z Asie).

No v kazdem pripade moje stare "olovnate" Atarko i 486 stale pracuje k plne spokojenosti :-)

Dnes by to nebylo tak jednoduché. Muselo by to mít padesát všemožných atestů, každý za desítky tisíc... Dělat přístroje pro zdravotnictví je sice dobrý byznys, ale musíte mít docela velký kapitál do začátku a známosti v ředitelstvích těch zdravotnických zařízení. Jinak bez šance.

se znalosti HW, architektury procesoru a assembleru si pak muzete dovolit naprogramovat specialitky, jako napr. Tetris v 256 bajtech kodu !
o tom se Javistum, VBasicarum, C#pistum ani nezda :-)

JJ doteď vzpomínám na hry uložené v boot sektoru diskety :-)

Mozna by se dalo programovani ucit na tomhle:

http://www.eloraam.com/?p=145

Az tam Eloraam dopise ty univerzalni assemblery, zacne to byt zajimave. :-)

Hehe, 6502 ve "voxelech", jste muj clovek :-)

Já začínal s asm Z80 na didaktiku M, na škole jsme měli 8051 a taky nějaké automaty od Toshiby myslím. Programovalo se to graficky - navrhovala se schémata zapojení. Dělali jsme tak třeba křižovatku. Hodně se mi to líbilo, ale osud mně zavál jinam a teď hlavně optimalizuji SQL dotazy.

Neví někdo, co to bylo za automaty?

Muzu se zeptat, na jake to bylo skole?

Na elektroprumce v Brne jsme (jako "pocitacnicka trida") pouzivali to ve sve podstate genialni :-) PMI-80 a potom nejaky bastl s 8048 a 8051 (jmeno uz si nepamatuju, ale byl to vlastne bezny vyvojovy kit se seriovym portem pripojenym k PC). Nektere dalsi obory jeste mely analogove pocitace, ale to me minulo.

Bylo to na elektro průmyslovce v Havířově. V prváku jsem ještě zažil jednu učebnu s PC XT ze Slušovic. V druhé učebně byly 286 s win 3.11. Když jsem končil, tak už byly všude 486. To byl rok 1996.