Názory k článku
Komiks: programátor lážo-plážo

Namet na komiks jsem do redakce zaslal ja :)

Uprimnou soustrast ...

Obdivuju odvahu se k tomu přiznat ...

To bude asi ten specifický matfyzácký humor, který nikdo jiný nepochopí. :-D

Ja programuji i ve spanku. Ve spanku me napadaji ty nejlepsi algoritmy. Dokonce jsem ve spanku vymyslel radici algoritmus s linearni slozitosti. Bohuzel ho chapu ale jen ja, protoze mam poruchu osobnosti.

jo keď som programoval aj ja tak aj mňa v spánku napadla brutálna optimalizácia kódu ale mal som 13 a len som začínal v BASIC-u :)
Teraz už väčšinou neprogramujem(radšej) lebo som lenivý a bojím sa poruchy osobnosti...

To je fuk, hlavne jestli funguje. Proste ho napis. Nebo je ta porucha osobnosti ve skutecnosti porucha chapani slozitosti algoritmu? ;-)

Tohle psal falešný BLEK.

Né, tohle také psal falešný BLEK.

Nee tohle a to před tím psal taky falesnej BLEK. Ale asi už začínám mít taky poruchu osobnosti, když takhle kravím.

a tohle pro zmenu pise falsnej BLIK.

zachvili si zacnu myslet, ze zadnej pravej black neexistuje

Pravý BLEK. netřídí, protože má poruchu osobnosti

O(n log n) odhad pro obecné posloupnosti platí pro třídění pomocí porovnávání dvojic prvků.
Pokud si můžeme dovolit více, například adresovat (index v poli) integery, tak lze třídit i rychleji. Typické jsou případy kdy máme celá čísla z malého intervalu, pak lze použít třeba O(n) counting-sort.

A když jsou všechna čísla stejná, je to v O(1) no-need-sort. :-D

>Zial je dokazane, ze vseobecny sort nemoze byt lepsi ako O(N log N).

Ne, dolni hranici algoritmu je O(N), protoze vzdy musite prinejmensim zjistit, jestli jsou cisla opravdu serazena. Algoritmus s O(N) existuje, ja osobne znam dokonce dva - bohuzel jsou oba dva prakticky nerealizovatelne, protoze zatimco ten prvni je zalozne na kvanove mechanice, many-world intetrpretaci principu neurcitosti spojene s eliminaci nevhodnych skutecnosti (viz http://en.wikipedia.org/wiki/Bogosort#Quantum_Bogosort ), druhy zase potrebuje stroj casu schopny poslat informaci do minulosti (viz http://en.wikipedia.org/wiki/Time_loop_logic , jen by se misto delitele prvocila generovala permutace a misto testu delenim by se pouzila kontorla serazenosti).

U implementace pomoci specialniho hardware se da dokonce dostat k O(log N), ale vzhledem k jeji hardwarove slozitostoti je prakticka pouzitelnost mala, viz http://en.wikipedia.org/wiki/Sorting_network .

Máte v tom docela solidní guláš, mícháte složitost v modelech Turingova stroje, PRAMu s ruznými mírně řečeno nestandardními modely. ("dolni hranici algoritmu je O(N)" vs. "se da dokonce dostat k O(log N)" - jak to vysvětlíte)

Dokázáno je, že sekvenční program, který se z každého stavu může dostat jen do konečně mnoha dalších, a třídí posloupnost čísel, má složitost Omega(n log n), kde n je délka posloupnosti. To není nijak v rozporu s tím, že je to Omega(n), jak tvrdíte.

Jinak vytvořit třídící síť s O(n log n) komparátory a O(log n) hloubkou mi nepřijde až tak "fundamental problem" jak píšou na Wikipedii, a i použít by se to dalo (nad hardwarovou FFT se taky nikdo nepozastavuje).

A jak velké by to n u těch komparátorů bylo? U asymptotické složitosti snad jde o to, že ta složitost je stejná pro libovolně velké množství prvků.

n by bylo takové, jaké si předepíšete.

U asymptotické složitosti snad jde o to, že ta složitost je stejná pro libovolně velké množství prvků.

Ano. Ale nemusí být splněno jedním algoritmem/obvodem, viz neuniformní třídy složitosti.

V popsáném případě by šlo o to, že pro každé n umíme najít třídící síť s <f(n) komparátorama a <g(n) hloubkou, kde f(n) je O(n log n) a g(n) je O(log n).

To znám, jednou se mě zdálo o jedné krásné datové struktuře a zrovna v nejlepším se jsem musel probudit.

Me se na dnesek zdalo ze jsem jel na skejtu z kopce a najednou jsem tam hodil krasny slajd a byl to zuzo pocit. Jen ten slajd ve skutecnosti neumim. Nevite jak se to dela? Mam teorii ze clovek musi pouzit poradne rotaci tela, az pujdu skejtoat, musim to vyzkouset.

slnko ked je tak nizko uz nie je az take silne (inak by nemal ten typek taky super kontrast na monitore, ze z 10 metrov je vidiet pomaly kurzor) :)

Z vlastní zkušenosti vím, že v některých oblastech i když je slunce nízko, není na monitoru vidět ani ň

http://trn.php5.cz/krakonos/

turza je v prdeli, ale rekl me at to sem vam mamrdum prdnu ... peknou honku nulky ;P

prace kvapna, opet trapna

Drsný, ale výborný! :-) Technická: Bába je ponikelská (Poniklá je vesnice kousek jižně od Rokytnice n. J.) ...

radoby drsny, ale trapny. bohuzel

Ahoj. Ucastnil jsem se czechteku 2005 ciste ze zvedavosti. Jsem jiz radu let programatorem, nefetuji, nekourim. Priznavam ze obcas si dam sklenicku dobreho piti.
Prestoze mi je jasne, ze se tuto mou vypoved budete snazit jakkoli znehodnocovat, musim reagovat.

Bod 1. - policie nechtela technare vpustit na pozemek, jelikoz neexistovala prijezdova cesta. - tento bod si prosim zapamatujte.

Na louku jsem se dostal v sobotu v 7:00 pres les, policie memu pruchodu(ani dalsim lidem a autum) nebranila, blokovala asfaltovou cestu, ktera vedla smerem k pronajatemu pozemku(zda vede az na pozemek jsem nevedel) a necinne prihlizela.

Tentyz den po poledni(cca 13:00) vytvorila policie hada opisujiciho hranice pronajateho pozemku. Stany a veci nachazejici se za hranici nicila, coz tak trochu chapu, ale urcite by se to dalo vyresit jinak. Po chvili se rozhodli, ze tuto akci rozezenou. Bohuzel jim pouziti vodnich del a slzneho plynu proti ucastnikum technoparty nebylo moc platne. Lide hada vytvoreneho z policistu obchazeli. Nekteri ucastnici(kolem 50 osob) zacali po policii hazet veci co nasli. Taktez z rad policie se nasla skupinka, ktera byla velmi brutalni a mlatila vse okolo sebe.

Osobne bych rekl, ze co se tyka nasili, bylo stejne z obou stran.
Tento policejni zatah prestal po 15hodine, jelikoz bylo videt, ze policie i v tak hojnem poctu nema sanci ucastniky vytlacit(Ti zfetovanci jak rikate byli chytrejsi nezli policie). Po celou dobu jsem se snazil dovolat znamemu, ktery byl v te dobe redaktorem TV Nova, aby tam poslali vrtulnik. Bohuzel telefonovani bylo blokovano. - Ne pretizeno jako o silvestru. Proste blokovano.
Proti slznemu plynu jsme pouzivali rukav namoceny ve vode, pres ktery jsme mohli dychat. Pred setmenim se policiste pripravili k dalsimu zatahu. Lide vytvorili hradbu z aut. Policiste pomalu krok po kroku dosli az k te hradbe a vyckavali. Soundsystemy vyzyvali ucastniky, aby si sedli na zem a sbirali odpadky. Nekteri poslechli.
Jakmile se setmelo zacalo peklo. Policiste nahazeli mezi ucastniky dymovnice. Uz jsme si rikali ze zas namocime rukavy, ale ono to nestipalo. A do toho salva obrovskeho mnozstvi jakehosi plynu, ktery byl mnohem silnejsi, nez slzny plyn pouzity predtim. Namocene rukavy nepomahali. Chtelo se vam zvracet, nemohli jste dychat a palil vas cely oblicej. Do toho se vynorili siluety policistu mlatici vse okolo. Ti co zustali sedet to odnesli nejvice. Dali jsme se na utek. Beh to byl opravdu jako o zivot. Kdyz nemuzete dychat tak se bezi opravdu spatne. V jednu chvili jsem to chtel vzdat at klidne zemru. Ale bezel jsem dal. Vybehl jsem z oblaku toho plynu a co nevidim.. asfaltova silnice(ad. 1) navazujici na pronajatou louku. Bezim tedy po ni(jako vetsina ucastniku) a na krizovatce vidim par policistu sledujicich jak vsichni vydesene bezi.

To je tak v rychlosti vse. Z toho co jsem tam videl a zazil jsem mel nejaky cas psychicke problemy. A nebyl jsem sam. Osobne si myslim, ze co se tyce agresivity, je to vyrovnane(ucastnici/policie). Ale na druhou stranu ty medialni lzi okolo..

Napriklad kdyz v pulce jizdy vlakem se me ptal muz jedouci z prace kam ze to jedem, kdyz pred chvili rikali v televizi, ze je ta akce zrusena.
Jakto ze na pozemek nevedla silnice, kdyz me po ni vyhnali?
Jak je mozne, ze byli blokovany telefony?
Jak je mozne ze prubeh zasahu nemohla natacet TV? Z jakeho duvodu? Z helikoptery by jim zadne nebezpeci nehrozilo.
Jak je mozne, ze vlak kterym jsem tam jel zastavil 15kilometru pred cilovou stanici(do ktere jsem mel radne zakoupeny listek) a dal proste nejel. Proc 200 lidi muselo jit v 1 rano pesky? Pri poruse by ceske drahy preci zaridili nahradni dopravu.
Proc si policiste zapisovali bezduvodne cislo meho obcanskeho prukazu?

Toto jsem zazil. Za touto vypovedi si stojim. A to jsem obycejny obcan platici dane(a ze to neni malo).

A prestoze jsem listopad 89 osobne nezazil, tak na zaklade znalosti, ktere jsem o nem nasbiral se opovazuji tyto dve udalosti srovnavat!

po cizim majetku???? kde jste to vzal proboha??? :)))))

JOJOO
TURZIN ZVEDNE TI NALADU!!!!
SUPR, TAK DLOHO JSEM SE ZAS NEZASMAL

asi se dam taky na techno kdyz vidim jak tam mrdaj jak tepli psi :D

+1 vyborny :-D

Od kdy se v Kerkonoších mluví moravsko-ostravsky? Východočech by vám něco jako "sa" nebo "Krakonoša" v životě neřekl! Ale holt napodobit východočeský dialekt je pro nerodilého mluvčího dost náročné, protože je to jediný dialekt, který je složitější, než spisovná čeština. To už holt chce mít fištrón.

BTW: východočeské retné V vyslovované spíš jako "u" se zapisuje písmenem W.

pico az napodobis hantec vole tak ti pogratuluju kokote ;))

Jenže v Krkonoších se nemluví hantecem.

Krom toho, hantec je jen taková nedomrdlá němčina.

Mě zaujaly ty průhledné bubliny. Tušíte někdo v čem se dají jednoduše vyrobit?

turza dela vsehcny remixy v gimpu ... podle me jen nastavis pruhlednost layeru a je to ...

Autor komixu se na to programování dívá moc pozitivně, jako by ten člověk s tím snad neměl problémy. Tento remix to popisuje z trochu jinak, nechybí ani porucha osobnosti hlavního hrdiny.

http://www.jikos.cz/~mikulas/komix/OOPS.GIF

taky dobry :D

vysvetli mi niekto pointu? mne to vobec nepride vtipne tak neviem mozno som ja divny

Možná máš poruchu osobnosti :-)

mozna nemas poruchu osobnosti :)

chlapi kua sak sa dohodnite nech viem nacom som :)

nemas, jinak bys to chapal

Nech si hovori kto chce co chce, ale vidim ze uz ste vsetci po prazdninach, lebo tak malo prispevkov v takuto dobu tu este nebolo.

Inak pekne, skor by som to zakoncil s tym, ze ved na to nemozes vidiet bez toho dodatku naslepo, myslim, ze by pointa bola lepsia. Ale kvitujem, pekne!

Postava na obrazku ma zrejme poruchu osobnosti a proto nepodleha modnim trendum a nekoupil si tedy notebook s extralesklym displejem (jake jsou ted caste). Proto muze programovat i na slunicku.

Prijde mi to, ze vyse uvedena diskuse by byla v mnoha bodech bezpredmetna, kdyby jeji ucastnici meli zkusenost s resenim problemu, kdy potrebuji doopravdy velmi precizne vyuzit dostupny vykon procesoru.

Netvrdim nic konkretniho, chapu smysl prekladacu, ale nektere vyse uvedene nazory dle meho nazoru jasne ukazuji, ze jejich pisatel sice zna pekne teorii, ale nikoliv uz praxi.

Pardon, samozrejme vyse uvedene patri k tomu threadu co je a timto prispevkem ...

Ano programovat spamati sa da, ale uz je to nuda.
Programovanie je prave o tom aby sa stale nieco tvorilo a muselo nad tym dumat.
Preto vznikaju frameworky.

Které sežerou 100MB na Hello world :-) , o potřebném výkonu nemluvě .

To je protoze jsme na zacatku, a neumime poradne donutit pocitac, aby za nas optimalizoval. Kdyz vysel prvni kompilator, take neoptimalizoval. Trvalo nejmene 30 let (mozna 40), nez se dalo tvrdit, ze C je rychlejsi nez assembler. Podobne to casem bude i s temi frameworky - zoptimalizuji vam program tak dokonale, ze budete mit velky problem, abyste to podobne rychle napsal v ruce. Bude to ale chvili trvat, jde o silne netrivialni zalezitost. Mam osobni projekt, ktery ma neco podobneho za cil.

Tak až C bude rychlejší, než dobře napsaný assembler, dejte mi vědět :-)

Proboha, už z podstaty a principu nemůže nikdy nic v rychlosti předstihnout dobře napsaný ruční assembler/stroják. Rychlost kompilátorů se může pouze blížit k rychlosti assembleru/strojáku, ale nikdy, skutečně nikdy nemůže být rychlejší. A to hlavně proto, že všechny kompilátory nakonec vedou ke kódu prováděnému ve strojáku, tak jak by ho mohly předstihnout?

Pokud máte dostatek času, pak vždycky nakonec assembler vyhraje nad jakýmkoli kompilátorem.

Jediné, co předpokládáte jsou horší podmínky pro toho, kdo píše assembler. Asi tak jako kdybyste zůdvodňovat, že želva je rychlejší, než olympijský běžec zatížený 200 kg koulí na noze a měl byste pravdu. Takže souhlasím, assembler zatížený špatnými podmínkami bude rychlejší, než kompilátor stejně analogicky jako želva bude rychlejší, než olympijský běžec.

oprava: "assembler zatížený špatnými podmínkami bude rychlejší" - má být samozřejmě pomalejší

Problem je v tom "pokud mate dostatek casu". To v realite nikdy neplati a proto se v praxi pouziva C a frameworky.

K tomu memu tvrzeni, ze "C je rychlejsi nez assembler". Samozrejme (jak by soudny clovek chapal) to znamena ve vetsine pripadu (pro vetsinu vyvojaru, pro vetsinu casu co je k dispozici, pro vetsinu algoritmu).

Jasne ze muzete vzdycky napsat lepsi assembler, ale to de facto znamena objevit novou optimalizaci, kterou kompilator jeste nezna. Na druhou stranu, napsat to rucne v assembleru znamena provadet rucne spoustu optimalizaci, ktere uz kompilator umi (treba takovou alokaci registru). Drive nebo pozdeji dojde k tomu, ze to prvni se proste nevyplati (protoze vetsina optimalizaci na urovni assembleru uz byla objevena a vlozena do kompilatoru, nebo je program prilis slozity na to, abyste se schopnosti optimalizovat neco kompilatorem vyrovnal)

Napriklad takova optimalni alokace registru, navic intra-proceduralne, by vam asi dala pekne zabrat. Proto dnes uz nikdo nealokuje registry rucne, je to proste nuda a navic malokdy dosahnete lepsiho vysledku nez kompilator, co si na to proste obarvi graf.

Postupem doby vsechny implementacni detaily, co dnes resi programator rucne (napr. alokaci pameti, casem i volbu algoritmu a datovych struktur), bude schopen delat kompilator a daleko lepe. To je pokrok.

Optimální alokací registrů - abych rozšířil Vaše vzdělání - se rozumí něco co procesor neumí. A to je optimalizování dlouhých úseků kódu tak, aby se co nejvíce využilo ukládání dat v registrech a co nejméně bylo potřeba mít data v paměti, třeba na zásobníku, případně v jiných datových úložištích, než jsou registry a paměť.

Tohle z procesoru nevykřešete ani kdybyste ho na kolenou prosili, protože optimální rozložení dat v programu a umístění dat do různých úložišť není věcí procesoru.

Rád bych Vás seznámil se sladkým tajemstvím, že rychlost kódu je určována mnohem složitějšími faktory, než jen pouhou alokací registrů. O tom neni sporu. Zejmena je urcovana vyberem datovych struktur a algoritmu, ktera v soucasne dobe predmetem optimalizaci temer vubec neni. Coz je podle me chyba, a nepochybne cesta do budoucna. A nehledě na to, že si na to sice může obarvit graf, ale pořád je omezený tím, že kód píše člověk omezenými prostředky C, které nezohledňují specifika toho kterého procesoru, dále, že kompilátor musí dodržovat nějaké své konvence (i registrové - například, že třeba do ecx/rcx předá vždy adresu instance objektu) atd. a pak to celé s těmito omezeními teprve překládá. Kvalitni kompilator specifika procesoru zohledni. Je pravda, ze paralelne probiha i vyvoj procesoru, takze nelze absolutne drzet krok. Ale kompilatory se neustale zlepsuji a zahrnuji stale vice optimalizaci, a ten trend bude pokracovat. Uvádíte tam i věci, které jsou matematicky dokázané, že nejdou automatem udělat. Toho jsem si velmi dobre vedom. Ale to ze nejdou obecne udelat neznamena, ze se tomu nelze na 99% (a vic) procent priblizit. A to se take stane.

"Kvalitni kompilator specifika procesoru zohledni."

No a jsme tam, kde jsme byli u assembleru, tedy "není dostatek času a financí na vývoj kompilátoru". Je absolutní utopie, že kompilátor bude dobře optimalizovat na každý model procesoru, nebo na všechny budoucí řady. Právě z důvodu toho, že dobrou optimalizaci na každý model nikdo nezaplatí.

"Ale kompilatory se neustale zlepsuji a zahrnuji stale vice optimalizaci, a ten trend bude pokracovat."

Přičemž zrychlení, které tím kompilátor získává je čím dál nepatrnější. Každý další optimalizační krok stojí 10x tolik nákladů, než předchozí a zrychlí 10x méně, než předchozí krok. A dnes se hraje v podstatě o velmi drobounké zisky v rychlosti kompilovaného kódu.

"Ale to ze nejdou obecne udelat neznamena, ze se tomu nelze na 99% (a vic) procent priblizit. A to se take stane."

Jo jo, a já se stanu ředitelem zeměkoule, budu mít asi tak 3000 miliard dolarů jmění, vlastnit osm naftových polí, mít harém největších koček co existují, a vlastnit dvacet obřích továren a síť supermarketů - asi tak stejně pravděpodobné.

Jen jedna otázka: tušíte vůbec aspoň rámcově, jak funguje kompilátor a automatická optimalizace?

Odpověď je nasnadě - pokud byste tušil, musel byste připustit, že pan Ponkrác má naprostou pravdu. Takže - už z principu automaticky generovaný (slovo "kompilovaný" je mnohem přesnější) kód NIKDY, opakuji NIKDY nemůže být lepší, než člověkem optimalizovaný program v assembleru!!! Alespoň do té doby, než se z kompilátoru stane myslící bytost. Pokud by vám někdo tvrdil opak, nevěřte mu.

Mimochodem co píšete o optimalizacích je naprostá hovadina. Je vidět, že tomu absolutně nerozumíte. Proto mne docela zaráží, že se pouštíte do takové debaty. Když něčemu nerozumím, tak raději mlčím a nejdřív si o tom něco sestuduji. V tomto případě byste ale musel studovat několik let. Jen pro vaši informaci - asi byste byl hodně překvapen, jak primitivní v porovnání s uvažováním člověka jsou ty nejsofistikovanější metody optimalizace i jen blbé alokace registrů!

Nejzásadnější překážkou veškerých optimalizací je to, že program obecně nikdy nepochopí smysl jiného programu. Člověk ano. Optimalizátor v překladači bude vždycky provádět jen DÍLČÍ optimalizace. Obvykle se jedná o optimalizace automaticky generovaného kódu, který by bez těchto optimalizací nebyl průměrný, ale do očí bijícím způsobem neefektivní.

Takže více studujte odborné prameny a méně reklamní materiály firem prodávajících překladače.

Odpověď je nasnadě - pokud byste tušil, musel byste připustit, že pan Ponkrác má naprostou pravdu. Takže - už z principu automaticky generovaný (slovo "kompilovaný" je mnohem přesnější) kód NIKDY, opakuji NIKDY nemůže být lepší, než člověkem optimalizovaný program v assembleru!!! Alespoň do té doby, než se z kompilátoru stane myslící bytost.
Ja ale nerikam, ze pocitac vygeneruje vsechen kod. Ja srovnavam prelozeny kod v C s kodem v assembleru. To co delate v assembleru navic je napr. alokace registru. A od jiste urovne slozitosti budete mit problem udelat ji lepe nez to za vas spocita stroj.
Nejzásadnější překážkou veškerých optimalizací je to, že program obecně nikdy nepochopí smysl jiného programu. Člověk ano. Optimalizátor v překladači bude vždycky provádět jen DÍLČÍ optimalizace.
Prekladac bude vzdy provadet optimalizace, ktere do nej vlozi clovek. S tim souhlasim. Ale muze je udelat milionkrat rychleji, na mnohonasobne vetsich problemech, a bez jakekoli unavy.
Vy se domnivate, ze v tom, ze program nepochopi smysl jineho programu je nejaky zasadni problem. S tim nemohu souhlasit. Chape snad Google vsechny stranky na internetu? Jak je pak mozne, ze vam na hledani vraci relevantni vysledky? Moje myslenka (ktera je predmetem meho zajmu) spociva na podobnem principu, ktery umoznuje, ze lze optimalizovat daleko vyssi uroven nez dnes, a to aniz bych musel ten smysl znat. Neni to slozity princip - nepochybne ho jiz objevil nebo objevi i nekdo jiny.

> od jiste urovne slozitosti budete mit problem udelat ji lepe nez to za vas spocita stroj

Jak jste na to přišel? Jakou metodu výpočtu optimální alokace máte konkrétně na mysli? Automaticky se můžete pokusit o nějaké optimalizace pouze v rámci toho, co je napsáno v daném vyšším jazyku. To je pro optimalizátor alfou omegou, hranicí, za kterou principiálně jít nemůže. Narozdíl od člověka - kouknu na kód, vidím, že tak jak to je to je nepohodlné, tak změním sémantiku té části programu, změním činnost podprogramů, změním pořadí jejich volání. Tohle se zkrátka spočítat nedá (a dá se dokázat, že se to spočítat nedá). Lidská bytost v podstatě dělá peephole optimalizaci a umí to dělat perfektně. O překladačích se dá říct pravý opak.
Mimo to nechápu, proč sem zavlékáte problém velkých programů. Otázka stojí, zda kompilátor vyprodukuje kód na úrovni kódu napsaného člověkem. Odpověď zní nikoli. Otázka, zda-li se to vyplatí a jak dlouho by to člověku trvalo je jinou otázkou. Bavíme se tu o kvalitativních, nikoli kvantitativních otázkách.

> Prekladac bude vzdy provadet optimalizace, ktere do nej vlozi clovek.

Právě. Jenže to bude vždy silně omezená množina jednoduchých postupů aplikovatelných na silně omezenou množinu případů. Alespoň v porovnání s možnostmi lidského mozku.

> Chape snad Google vsechny stranky na internetu?
To jste si docela naběhl... A teď si zkuste představit, že byste chtěl po googlu, aby vám na základě hesel, jež mu zadáte, sestavil recept na dort. Ne aby ho našel, ale sestavil na základě vašich přání a dílčích informací, které má k dispozici. Něco jako "Chci třívrstvý ořechový dort s máslovým krémem a jahodami vážící jedno kilo" a on mi vyplivnul "Budeš potřebovat x gramů másla, mouky, vody, mléka, cukru.... 1. vezmi mouku, smíchej s tím, tím a tím, vypracuj těsto, pak přidej tohle..." Co myslíte, co by pro takový automat bylo jednodušší - jednoduché recepty, nebo naopak ty komplikované, které se údajně už nevyplatí psát rovnou? Jahodový puding nebo nadívaný kapoun se švestkovou omáčkou, jablky a pomeranči? Protože přesně to se chce po kompilátoru! Stejně mu budu muset popsat, jak se dělá švestková omáčka a on k tomu bude moct použít jen poměrně omezenou množinu z toho, co mu nabízí vybavení kuchyně - povařenou zeleninu bude muset rozmixovat, protože ho nedonutím k tomu, aby použil cedník a místo toho ji propasíroval, protože mu někdy někdo napsal, že cedník se používá na oddělení tekutiny od pevné hmoty v podobě heterogenní směsi a jinak ho použít nedokáže.
Dovedu si představit, že by bylo možné takový automat použít v závodní jídelně, kde se neočekává nic extra k jídlu, prostě jen k zasycení žaludku, přičemž spotřeba prostředků kuchyně by byla veliká (potřebuji bílky - M vajec, žloutky se vyhodí, potřebuji žloutky - N vajec, bílky se vyhodí, potřebuji rybí maso - odřezky se vyhodí, potřebuji rybí polévku - vezme se další ryba a udělá se z ní kotel polévky, jehož 2/3 se vyleje...). Tvrdit, že výsledek takového podniku může konkurovat práci šéfkuchaře by mohl opravdu jen člověk, který snad v životě nepozřel normální jídlo a nikdy nebyl u toho, jak se takové jídlo připravuje. Jediný důvod by byl, že šéfkuchař je tak drahý, že se mi vyplatí rezignovat na chuť a raději obětovat více surovin a energie nevalnému, ale stravitelnému výsledku. Nic to ovšem nebude měnit na faktu, že šéfkuchař bude vždycky lepší.

> Neni to slozity princip - nepochybne ho jiz objevil nebo objevi i nekdo jiny.
Principů jak optimalizovat je mnoho a každého, kdo někdy psal vlastní překladač, napadnou i myšlenky, o kterých se nikde nic nedočte. Ale všechno to má stále stejný problém - jsou to jen optimalizace dílčích problémů. Žádný algoritmus vám kód bubblesortu nezoptimalizuje na quicksort. Zatím to zvládá jen člověk a mám pocit, že ještě dlouho mu tohle výsadní postavení žádný stroj neohrozí.

> Automaticky se můžete pokusit o nějaké optimalizace pouze v rámci toho, co je napsáno v daném vyšším jazyku.

To je pravda. A proto je take (podle me) vyssi abstrakce nezbytna pro lepsi optimalizace.

>Otázka stojí, zda kompilátor vyprodukuje kód na úrovni kódu napsaného člověkem.

To zdaleka nemusi. Muze vyprodukovat uplne jiny druh kodu, staci, kdyz bude rychlejsi. Podobne jako sachove programy resi stejny problem uplne jinym zpusobem.

>Ale všechno to má stále stejný problém - jsou to jen optimalizace dílčích problémů. Žádný algoritmus vám kód bubblesortu nezoptimalizuje na quicksort.

Problem je, ze se na to divate prilis primocare. Tim argumentem s Googlem jsem chtel naznacit, ze vsichni cekali (v dobe Altavisty), ze nebudeme schopni udelat relevantni vyhledavac, pokud neporozumime psanemu textu. A Google na to sel necekane jinak - zacal sledovat odkazy. Podobne je to i s tim sortem. To, ze ve skutecnosti musime vyresit tento problem, si myslite vy. Ja si myslim, ze tento problem lze obejit, podobne, jako ho obesel Google. Je reseni Google dokonale? Ne. Ale je prakticky postacujici? Ano.

No, asi nema smysl se moc dal hadat. Vy proste na vyznamny pokrok v tomto smeru neverite, ja ano (a mam pro to dobry duvod).

Znam 3 assemblery. V jednom delam denne, takze moc dobre vim, jake je to zoufalstvi, kdyz musite rucne programovat/optimalizovat neco, co dnes bezne umi kompilator.

Jinak je to zvlastni, jak jste si tolik jisti, ze neco neni mozne, a pritom se me ani nezeptate na podrobnosti. Ne ze bych je tu chtel sirit (ve skutecnosti bych moc rad, ale dal jsem si zavazek), ale ta nafoukanost je zarazejici.

Programuješ Matrix? Hlavně pozor aby si neuvědomil svojí jedinečnost :-D

Zdravim, docela by me zajimal Vas projekt, protoze me uz davno napadlo neco podobneho, ale jeste jsem nemel cas pustit se do praktickeho experimentovani. Muzete se mi (pokud budete chtit) ozvat na weird.m (zavinuta-ryba) centrum (v-TLD) cz

V podstatě máš pravdu - cokoli z vyššího jazyka jde (teoreticky) napsat v assembleru. Ale jen teoreticky: psát většinu dnešních programů v ASM je nad lidské síly, nejen že by to trvalo "dlouho", ale bylo by to prakticky nemožné, protože jeden člověk nemůže takovou složitost obsáhnout a zároveň je problém rozdělit práci mezi víc lidí tak, abychom dosáhly vysněného vysokého stupně optimalizace. Nemluvě o tom, že některé vyšší jazyky optimalizují kód za chodu - a umožňují tak dosáhnout lepších výsledků, než by dosáhl největší guru-programátor v assembleru (ten by takový program během svého života ani nedokázal napsat). Důležitá je hospodárnost (a TCO) - je nesmyslné promrhat tisíce člověkodnů a získat za to 0,00001% výkonu navíc.

"No tak pokud by to nešlo i prakticky, tak by to asi nešlo vůbec, nemyslíte?"
Teoreticky můžeš navrhnout moderní raketoplán jen s logaritmickým pravítkem, tužkou a papírem. Ale prakticky? Jde o to, že po dosažení "určitého stupně složitosti" člověk už nezvládá, nedokáže všechny informace obsáhnout, a počítač má pak navrch.*

"Vy jste žena mluvící za skupinu žen?"
Překlep, stane se. Chybí ti argumenty, že se uchyluješ k tomuto?

"Můžete jmenovat? Včetně stručného popisu metod, kterými tak činí?"
Viz např. Java a Just-in-time compilation.

Pokud se ti povede přepsat program o velikosti OpenOffice do assembleru tak, že bude rychlejší než 0,00001% a stihneš během jednoho lidského života, tak jsi fakt machr. :-) Nehospodárné to samozřejmě je, ale v mnoha případech taky nemožné, viz výše ta příliš vysoká složitost. Neříkám, že tu není místo pro programátory v assembleru, i dnes se pro ně najde nějaké využití, ale je to (oprávněně) okrajová záležitost.

"Je rozhodně hospodárnější zaměstnat k programování laseru na operaci očí zdatného programátora"
"Zdatný programátor" je méně než pět průměrných programátorů, deset testerů a dobře čitelný programovací jazyk a dobrá metodika vývoje. U kritických aplikací (peníze, zdraví...) si nikdo nedovolí riskovat byznis nebo lidské životy tím, že by svěřil projekt do rukou nějakému namyšlenému "guru" programátorovi, ale radši se obětuje trochu toho výkonu** a píše se radši v jazyku, který se dá dobře ladit, testovat a rozvíjet.


*) jasně, počítač není inteligentní bytost, ale v tomhle případě to nevadí.
**) HW je dnes oproti ostatním výdajům celkem malá položka.

> po dosažení "určitého stupně složitosti" člověk už nezvládá
To je sice hezké, ale žádný problém se neřeší v celku, i ten sebesložitější problém je dekomponován a faktorizován na mnohem menší celky, které jsou již zvládnutelné. A tento rozklad komplexního složitého problému na jednotlivé subproblémy kupodivu nedělá počítač, ale člověk. Krom toho, i ten raketoplán můžete udělat s logaritmickým pravítkem, počítač se nepoužil kvůli tomu, že by konstrukce raketoplánu byla člověkem nezvládnutelná, ale jen kvůli tomu, aby na něm bylo možné rychle provést celkem primitivní, ale pro člověka úmorné výpočty.

> Viz např. Java a Just-in-time compilation.
To je pouze mechanismus na dílčí vylepšení jinak obecně celkem nevalných výsledků interpretovaných jazyků. Lisp to de facto obsahuje už někdy od 60. let a např. Forth to nepotřebuje. Když připomenu, že by dle tebe tato věc měla umožňovat "dosáhnout lepších výsledků, než by dosáhl největší guru-programátor v assembleru," nemohu se ubránit smíchu.

> Pokud se ti povede přepsat program o velikosti OpenOffice do assembleru tak, že bude rychlejší než 0,00001%
Proč by to mělo být nemožné? V assembleru se v historii psaly mnohem větší projekty, než je OpenOffice. Neexistuje žádný problém, který by byl tak komplikovaný, že by nešel napsat v assembleru člověkem. Vždycky se nakonec dostanete na úroveň rutin čítajících několik desítek až stovek instrukcí a ty zvládnutelné jsou. Navíc tuto diskusi nevyprovokovala poznámka o tom, že by assembler byl lepší nástroj k vývoji, ale o tom, že dnešní překladače produkují kód, který je lepší než ručně psaný. Což je volovina. Já netvrdím, že by bylo lepší psát rozsáhlé projekty v assembleru.

> "Zdatný programátor" je méně než pět průměrných programátorů, deset testerů a dobře čitelný programovací jazyk a dobrá metodika vývoje
Na to jsi přišel jak? Sackman už v roce 1968 na základě empirických studií ukázal, že dobrý programátor je 10x produktivnější, než průměrný. Je až komické sledovat, jak se v poslední době spousta firem vydala po cestě, která už byla před desítkami let ukázána jako špatná. No ale "mladí dynamičtí" manažeři vědí všechno lépe, že... Taky tomu odpovídají ty výsledky. Pokud bychom porovnali současný software s tím před 20-30 lety v tom smyslu, že bychom ohodnotili jeho užitečnost a podělili schopnostmi železa, na němž běží, vyjde ten současný jako totální propadák.
A pokud jde o ty "kritické" aplikace - zde konkrétně finance, tak už jsem měl tu čest nahlédnout pod pokličku... Internetovému bankovnictví se od těch dob raději vyhýbám a taky už je mi jasné, kam mizí ty všeliké různé poplatky za pojistky a za vedení účtu. Ani ve státní sféře se tak nemrhá penězi! BTW doporučuji několikaměsíční stáž např. v Unicornu, aby člověk viděl, jak se dá patlat software ve stylu "jak Pejsek s Kočičkou vařili dort."

> většina dnešních programů by v assembleru napsat nešla

Ale šla. S přehledem. Že si to dnešní "programátoři" nedovedou představit neznamená, že by to nešlo.

> Proboha, už z podstaty a principu nemůže nikdy nic v rychlosti předstihnout dobře napsaný ruční assembler/stroják.

Predpokladejme, ze programator napise jeden program, ten se postupem casu distribuuje mnoha uzivatelum a uzivatel si ho prelozi a pouziva.

Pak optimalni program v C muze byt klidne rychlejsi nez optimalni program v assembleru
(optimalnim myslim takovy program, ktery ze vsech programu resicich danou ulohu ma nejmensi prumer doby behu (pres danou mnozinu uzivatelu)). Proste proto, ze kod v C se muze prelozit do ruznych kodu ve strojaku podle toho, jakou ma uzivatel variantu procesoru. Programator v assembleru muze sice pripravit vic variant, ale netusi, jake prijdou nove varianty daneho procesoru v budoucnu a jak na nich bude vypadat optimalni strojak.

"Pak optimalni program v C muze byt klidne rychlejsi nez optimalni program v assembleru"

Nemůže - protože za podmínek, které jste popsal není psán v assembleru optimálně. Tudíž to co říkáte je protimluv.

Jinak běžné kompilátory moc optimální nebývají - například gcc i při nejlepší optimalizaci vygeneruje kód, kde je ještě neskutečně obrovská rezerva k optimalizaci. On gcc optimalizuje obecně hodně špatně, není naprosto žádný problém ho překonat v asm, i když to hodně flákáte. Důkazem může být, že si vezměte jak strašně moc dokáže třeba Intel kompilátor urychlit rychlost kódu oproti gcc. A nejenom Intel, třeba Microsoftí kompilátor dokáže rychlostně zvednout rychlost běžně o třetinu oproti gcc kompilátoru.

Při optimalizaci na nové procesory jasně vede assemblerista. Kompilátory naprosto netuší, jak vycucat z C kódu různé vektorové optimalizace, paralelní zpracování apod.. Céčko nemá konstrukce na to říct kompilátoru - hele teď chci dělat v zásadě paralelní operaci na datech, využij toho k optimalizaci. Takže kompilátor to většinou nepozná. Zatímco dnešní assemblerista třeba na x86 při vhodných úlohách nahoní rychlost použitím SIMD instrukcí, a dalšího.

Je naprostá pitomost, aby optimálně (používám Vaše slovo) napsaný kód v assembleru a optimálně v C neskončil vítězstvím assembleru. A ač optimalizátory v kompilátorech jsou dnes dost dobré, stále mají obrovské rezervy, jsou to jen automaty.

Zbylé úvahy co by kdyby jsou na nic. Pokud Vám na tom bude zkrátka záležet a uděláte optimální a co nejlepší kód v assembleru, a totéž v C, tak zkrátka C bude často až několikanásobně pomalejší. U gcc se nemusíme bavit o nových procesorech, rychlostní zisk dobrého asm kódu bude tak obrovský (řádově ve stovkách procent), že těch pár procent co získá gcc využitím možností novějších modelů někdy v budoucnu nestojí za řeč. U Intelovského kompilátoru už pravda musí assemblerista hodně zabrat, aby obhájil titul rychlostního vítěze, ale pokud assemblerista umí, tak neprohraje.

> Nemůže - protože za podmínek, které jste popsal není psán v assembleru optimálně. Tudíž to co říkáte je protimluv.

To je pravda, nenapsal jsem to vhodne. V dobe psani programu jeste neni zafixovana mnozina uzivatelu a tedy ktery program bude optimalni - to zavisi na pozdejsim vyvoji (jake se objevi procesory a kompilatory). Ale tipuji, ze u programu v assembleru budou ty rozdily mezi potencialne optimalnimi (optimalnimi v ruznych vetvich budouciho vyvoje) vyrazne vetsi, nez u programu v C.

> Při optimalizaci na nové procesory jasně vede assemblerista.

Assemblerista (a programovani v assembleru) mozna ano, ale assemblerovy program ne - ten uz je jednou napsan a nemuze tedy byt prizpusoben novemu prostredi. Zatimco jiz jednou napsany program v C muze byt prelozen pro novy procesor.

> Je naprostá pitomost, aby optimálně (používám Vaše slovo) napsaný kód v assembleru a optimálně v C neskončil vítězstvím assembleru.

Pokud odhledneme od absolutni optimality a budeme brat v potaz pouze realne situace -

Co treba takovy kod napsany nekdy v roce 1983 pro 286ky? Pochybuji, ze by ho nekdo napsal rovnou tak, aby bylo mozne pouzit na Pentiich (az by se pozdeji objevily) obe pipeliny. Zatimco kod napsany v te dobe by nemel byt problem prelozit modernim kompilatorem a ten sice nemusi udelat zadne jo chytre optimalizace, ale aspon by mohl dodrzet pravidla pro vhodne rozmisteni instrukci pro dany (novy) procesor.

> aby bylo mozne pouzit na Pentiich (az by se pozdeji objevily) obe pipeliny.

Vypadlo me tam slovo: aby bylo mozne pouzit na Pentiich efektivne obe pipeliny.

Jednou jsem s assembleristou závodil. Nepoužil jsem žádný rychlý jazyk a stejně jsem vyhrál o několik délek. Zatímco on optimalizoval kód, mě se zatím povedlo vylepšit algoritmus ...

Systém IBM pro sálové počítače byl psán ještě v assembleru. Za dvacet let se v postatě nezměnil a nakonec zastaral natolik, že IBM s radostí sáhla po Linuxu. Protože provést v něm nějakou zmenu bylo v podstatě nemožné, natož ho dále rozvíjet.
Je jenom málo programů, ve kterých není potřeba provádět změny. A povětšinou bleskurychle. Řekl bych, že je to kritérium mnohem důležitější, než rychlost běhu - alespoň ve většině případů. Protože spousta programů simuluje nějaké reálné procesy a realita se bohužel neustále mění.

Daleko víc, než nedostatečně optimalizující kompilátory mi vadí nabubřelé systémy, které se po většinu času věnují sami sobě a na uživatelův program si pomalu nenajdou čas. A tam už ani ten assembler nepomůže ...

Aha, proto se dnes ty nejlepší audiozesilovače stavějí zase s elektronkami... Proto se ty nejpřesnější lineární zesilovače pro měřící techniku sestavují opět z tranzistorů... Proto se kvalitní A/D převodníky znovu stavějí odděleně od DSP procesorů, přestože před deseti lety se začaly integrovat na jeden chip.

Akorát si pletete dojmy a pojmy. Nevěřím tomu, že by zastánci diskrétních součástek tvrdili, že jejich řešení je lacinější a rychlejší. Že je ale v mnoha případech lepší a integrovanými obvody nenahraditelné, to je prosím fakt. Takže nevím, o jaké prohře mluvíte. Naopak bych tvrdil, že lidi, co si mysleli, že integráče všechno vyřeší, zažili dost studené vystřízlivění ze své bláhovosti.

Ani bych neřekl. Naopak si dovolím tvrdit, že procento využití integrovaných obvodů kulminovalo tak před deseti lety, pak se snížilo kvůli např. mnou vyjmenovaným oblastem.

Ano a počítač nemůže nikdy porazit člověka ve hře v šachy. :-D Vycházíte z naprosto neodůvodněného předpokladu, že ten ručně napsaný kód v assembleru je nejlepší možný. Kdyby tomu tak vždy bylo, dalo by se tvrdit, že se kompilátor může maximálně člověku vyrovnat. Ale jelikož člověk, jak víme, není dokonalý, může se časem klidně stát, že lidi prostě už nebudou mít šanci být v průměru lepší než kompilátor.

To se může stát jedině v případě, že bude soutěžit kompilátor a blb, tedy průměrný současný lepič kódu.

Stejně jako počítač může porazit v šachách pouze mladšího žáka na úrovni maximálně okresního přeboru. ;-)

A že jste si vybral zrovna šachy? Mají k problematice kompilátorů nějaký relevantní vztah? Proč si nevyberete k porovnávání třeba hru GO? V níž jsou i nejlepší algoritmy celkem s přehledem drceny průměrným hráčem. Ne že by to mělo ke kompilátorům nějaký větší vztah, než šachy, jen tím chci naznačit, že srovnáváte hrušky a jablka.

Šachy jsem si vybral jako ukázku úspěšného proniknutí počítačů do oblasti, která byla donedávna doménou nejlepších lidských mozků. Proč by tedy nemohl vzniknout podobně dobrý kompilátor nebo podstatě lepší počítačový hráč Go (ten asi spíš na bázi neuronové sítě než jako algoritmus)?

No jo, jenže ikdyž se to na první pohled nezdá, i ty šachy jsou v podstatě spíš hra o paměti - a tam je počítač silný v kramflecích.
Jistě že by eventuálně takový algoritmus mohl vzniknout a jsem přesvědčen, že i s neuronovými sítěmi se v této oblasti experimentovalo. Otázkou je, jak velká by ta síť musela být... aby nemusela být tak velká, jako ta lidská :-)

Ono stačí, aby ten kód byl formálně verifikovatelný a už je na tom počítač lépe než assemblerista, protože opět jde jen o dokonalou paměť.

C nemuze byt rychlejsi nez assembler protoze se do assembleru kompiluje.

Gratuluji - treti clovek, co nepochopil pointu.

Samozrejme, ze C teoreticky nemuze byt rychlejsi nez assembler. Ale v praxi, pokud mate urcite konkretni programatory, a konkretni omezeny cas, to rychlejsi byt muze. V realite nikdy nestojite pred problemem "mam neomezeny pocet programatoru s neomezenou inteligenci, a nekonecne casu, v jakem jazyce a frameworku to napisu?"

Reagoval jsem na namitku, ze frameworky se nevyplati kvuli rychlosti vysledneho programu. Drive se kvuli rychlosti nevyplatilo C proti assembleru. Ale dnes, pokud stojite pred rozhodnutim zda pouzit assembler nebo C, na konkretnim projektu (i za predpokladu, ze jsou programatori schopni dobre obojiho), muze se vam velmi snadno stat, ze program v C bude ve vysledku rychlejsi. Protoze kolektivni znalost a schopnost analyzy obsazena v kompilatoru je daleko mohutnejsi, nez znalost a inteligence, byt solidni, tech nekolika programatoru. A totez nas ceka i s frameworky, ale zatim je to hudba budoucnosti.

Je to podobne asi jako tvrdit, ze pocitac nikdy nemuze porazit cloveka v sachu.

Jinými slovy - programátoři jsou rok od roku blbější. S tím souhlasím. Bohužel je to tak. 90% lidí, kteří sami sebe dnes nazývají "IT experty" by si za časů, kdy jsem začínal já, ani neškrtlo. Patrně by jim byla doporučena nějaká manuální práce, na niž by svým intelektem dosahovali lépe.

supr

on je povoln.e.j e nebo to byl jinej nas spoluzak ;)

Na tekk nejezdím, protože mám poruchu osobnosti a techno mě emocionálně nevzrušuje.

kurna dobry jak cip

To jsou zase zbytečné hádky, žádná ze stran neuzná žádný argument protistrany, protože je přesvědčena o své pravdě.

Ale pravda je někde venku...

Pravda je, že jsem psychopat...