Vlákno názorů k článku Výuka programování – nástroje pro ilustraci činnosti mikroprocesoru od flv - Ja myslim ze znalost neni nutna. Jsem typicky javista,...
-
flv (neregistrovaný)
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. -
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+3851minor)pagefaults 0swaps
[bwpow@brum ~]$ time java fw2
12.78user 0.02system 0:12.81elapsed 99%CPU (0avgtext+0avgdata 57104maxresident)k
0inputs+64outputs (0major+3844minor)pagefaults 0swaps
A teraz skuste nad tym porozmyslat, preco je to tak.
-
flv (neregistrovaný)
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".
-
Rax (neregistrovaný)
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. -
kert (neregistrovaný)
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.
-
JS (neregistrovaný)
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.
-
afgdsyv (neregistrovaný)
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.
-
kert (neregistrovaný)
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ě.
-
Michal Kára (neregistrovaný)
"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ě
-
kert (neregistrovaný)
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ší. -
JS (neregistrovaný)
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.
-
kert (neregistrovaný)
(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 :)
