Rozhovor s Donaldem Knuthem (diskuse)

[Michal Fecko]

Pekný rozhovor, zaujimavý emeritný profesor...

[Kyosuke]

Hehe, tak mě napadlo Cimrmanovo "Náčelníku, tady na pólu se nemusíme oslovovat celými tituly. Říkej mi jenom učitel." (Nebo jak že to bylo. )

[Michal Fecko]

Náčelník: Ten Varel je jak sedmiletý dítě! (k učiteli) Václave, prosím tě, ty jako pomocnej učitel mu to snad budeš umět vysvětlit!
Učitel.: Náčelníku, já myslím, že tady na severu se nemusíme oslovovat plnými tituly. Stačí, když mi budeš říkat učitel.
Náčelník: Dobře. Tak to Varlovi vysvětli.

[Jiří Jakeš]

Ještě jsi mohl jednu Poustkovu větu

[Xerces]

Náčelníku, já myslím, že tady na drsném severu .... Dobře bratře učiteli. Tak to tady Varlovi vysvětli.

a ta požadovaná další věta je ...

Varle!

Jinak díky za odkaz na článek. Rád si čtu takové rozhovory.

[alblaho]

Mám rád rozhovory s takovými makáči.

Zaujaly mě ty vícejaderné procesory. Je to prostě jen z nouze ctnost - neschopnost šponovat frekvenci. Obecné programy se pro to dělají fakt blbě a bude nás z toho muset vytáhnout implicitně paralelní prostředí ala transakční paměť v Haskellu

Jo ta pan profesor taky používá Ubuntu

[zoul]

Zaujaly mě ty vícejaderné procesory. Je to prostě jen z nouze ctnost - neschopnost šponovat frekvenci.

To mě taky zaujalo. Netvrdím, že bych uživil nějakých osm procesorů, ale dvě až čtyři jádra by se mi šikly. Používám sice většinou jen jednu aplikaci, ale často se stává, že na pozadí běží nějaký jiný proces a zbytečně zpomaluje. A řekl bych, že i kdyby se nemělo začít programovat vyloženě paralelně, většina aplikací by si časem cestu na dvě tři jádra našla. (Bez mučení se ovšem přiznávám, že tomuhle téměř nerozumím.)

[alblaho]

Já mám v notebooku dvoujádro a to je super - když měřím benchmark, můžu si ještě brouzdat po webu.

Jasně že více jader se hodí. Ale nejde to takhle škálovat nafurt (kromě speciálních úkolů jako třeba multimédia a lámání šifer). Do deseti jader na nějakou mazanou počítačovou hru si představit dovedu.

[adam]

Ja by som si vedel predstaviť aj stotisíc jadier. Alebo aj viac. Potom by sa mohli písať skutočné masívne paralelné programy. Napríklad ako kombinácia Actor Modelu a OOP: Každý jeden objekt by bol Actor a každé volanie metódy IPC. Koniec koncov, cely vesmír vrátane našich mozgov funguje masívne paralelne, takže by sa programy viacej priblížili viacej realite.

Celé je to ale len taká moja romantická predstava, ktorá sa nezakladá na žiadnom serióznom vedeckom výskume. Napokok ja sa v tejto téme až tak nevyznám, takže je celkom možné že trepem nezmysly

[xm]

Ta tvoje romantická představa není vůbec špatná. Lidský mozek skutečně funguje jako masivně paralelní počítač.

[Luboš Doležel (Doli)]

Já mám ze své hlavy pocit, že má 1 univerzální jádro a pak hromadu koprocesorů na automatizované úlohy.

[Jirka]

Já zase ze svojí, že se mi rozbila datová sběrnice, koprocesor vyhořel a IP registr se čas od času neinkrementuje.

[adam]

Presne ten pocit som mal aj ja dnes ráno, keď som sa zobudil po včerajšom koncerte Morcheeby a následnej "after party" Našťastie tá moja je vybavená nejakými samoopravnými mechanizmami a už sa to pomaly fixuje...

[alblaho]

Tak zaprvé: actor model ti bude houby platný, pokud úloha sama bude sekvenční. Prostě na sebe budou čekat.

A o tom, jestli je mozek spíše paralelní nebo sériový se vedou sálodlouhé diskuze. Jistě, zvládáme pár věcí zároveň, ale samotné přemýšlení je spíš sériové.

[xm]

Samotný proces přemýšlení je sice spíše sériový, ale fungování mozku jako takového je pokud vím masivně paralelní (tzn. jedná se o masivně paralelní počítač, přemýšlení je jen jeden běžící proces ).

[Filip Jirsák]

přemýšlení je jen jeden běžící proces

Upřesnil bych to na maximálně jeden běžící proces. Takhle by to mohlo vypadat, že jde o právě jeden proces, a to byste některým moc fandil

[pc2005]

Co lidé se schizofrenií?

[Jirka P]

Dve jadra

[JS]

No nevim, vetsina procesu, co ja mam na pozadi, je I/O bound (indexovani, kopirovani dat, p2p klient apod.), takze tam by mi dalsi jadro nepomohlo. Jinak pouzivam jen jedno jadro, je to ekologictejsi.

[moira]

Ekologictejsi? V jakem smyslu?

[nooneanymore]

Říkat, že vícejaderné procesory jsou z nouze ctnost a že je to projev neschopnosti šponovat frekvenci je poněkud zjednodušené. To je jako říkat, že vypravovat dva autobusy na ZOO v Troji během půlhodiny je z nouze ctnost, neboli projev neschopnosti štosovat cestující v autobuse do vrstev. Zkrátka se již pomalu, ale jistě šineme vstříc fyzikálním hranicím možného.

[alblaho]

Ale s tím rozdílem, že výrobci procesorů nám říkají "se čtyřmi jádry budete pracovat rychleji!". Zatímco pravda zní: "rychlejší jádro už neumíme, ale zato vám jich dáme víc!"

[Michal Kubeček]

Ale ona ta práce v mnoha případech rychlejší je. A v mnoha dalších by být mohla, ale aplikace bohužel není napsaná tak, aby toho využila. Typickým příkladem je POV-Ray - raytracing se škáluje prakticky lineárně, ale přesto je venku teprve beta od verze 3.7, která umí víc procesorů využít. Z dalších, na které jsem narazil, namátkou třeba John-the-Ripper nebo applydeltaiso.

Takže považuji za naprosto přirozené, že v okamžiku, kdy není únosné dále zvyšovat frekvenci dřívějším tempem, se výrobci procesorů zaměří na jiné způsoby zvyšování výkonu. Stejně jako v okamžiku, kdy přestalo být únosné, aby dále rostla stejným tempem frekvence systémové sběrnice, začaly procesory běhat interně na vyšší frekvenci, než na jaké komunikovaly s okolím - a tehdy (486DX2) se na tento trik veřejnost také dívala s nedůvěrou.

[stativ]

Zrovna testuji Luxrender a ten má dokonce možnost přidávat/odebírat vlákna za běhu. Bohužel nemám vícejádro.

[Michal Kubeček]

Ona i ta beta od POV-Raye funguje pěkně. Zkoušel jsem si na ní renderovat Glass Demo a skutečně se to renderovalo 25 hodin při spotřebě procesorového času 100 hodin. Jen je to v tom beta stádiu nějak dlouho, začíná mi to trochu připomínat legendární Firebird 1.5… :-)

[alblaho]

POV-Ray rozhodně není typický příklad, je to naopak velmi speciální úloha, co lze paralelizovat. A kdyby takové byly všechny, tak je no problém.

A jasně, že přidávání jader je v této situaci "přirozené", jenže to má tu nevýhodu, že to neumí zrychlit všechny aplikace, ale jen některé.

[Michal Fecko]

Ale nastastie su tu uz naznaky vyuzivania viacerych jadier aj inymi typmi programov.

[Kyosuke]

Škoda že od objevení p7zipu nemám potřebu používat bzip2.

[Michal Kubeček]

POV-Ray rozhodně není typický příklad, je to naopak velmi speciální úloha, co lze paralelizovat. A kdyby takové byly všechny, tak je no problém.

POV-Ray jsem uváděl hlavně jako příklad programu, který je pro paralelizaci v podstatě ideálním kandidátem, a přesto to ještě nedávno neuměl (budeme-li brát oficiální release, tak neumí dodnes). Pak je tu ještě řada takových, které by to potřebovaly "jako prase drbání", ale neumějí a ani se s tím nepočítá.

A jasně, že přidávání jader je v této situaci "přirozené", jenže to má tu nevýhodu, že to neumí zrychlit všechny aplikace, ale jen některé.

To je samozřejmě pravda. Ale budeme-li se bavit o CPU-intensive aplikacích, tam je IMHO procento těch, které by dokázaly z vícejádrových procesorů těžit, nezanedbatelné. U běžných desktopových aplikací to tak sice většinou moc není, ale tam většinou problém stejně není v rychlosti procesoru, roli hraje spíš disk nebo sběrnice (s PCI-E už moc ne). Takže tvrdím, že vícejádrové procesory přínosem jsou, zvlášť když můžete mít čtyřjádro za 2274 Kč nebo - bojíte-li se té medializované chyby - tříjádro za 2499 Kč a ceny levnějších dvoujádrových modelů jsou prakticky na úrovni jednojádrových.

[Ondrej 'SanTiago' Zajicek]

POV-Ray rozhodně není typický příklad, je to naopak velmi speciální úloha, co lze paralelizovat. A kdyby takové byly všechny, tak je no problém.

No IMHO se ulohy daji rozdelit do dvou kategorii - V prvni kategorii jsou ulohy, ktere je mozne implementovat tak, aby byly dost rychle na prakticky vsech soucasny PC. V druhe kategorii jsou ulohy, ktere vyzaduji obrovsky vypocetni vykon a jsou dobre paralelizovatelne. Osobne me nenapada nic, co by bylo znacne vypocetne narocne a spatne se to paralelizovalo.

[Kyosuke]

Tak napiš paralelní verzi Stalina.

[Filip Jirsák]

Já bych řekl, že i ty příklady uváděné Knuthem jsou taková z nouze ctnost. Ano, desktopové aplikace jsou typicky jednovláknové (a pokud je tam víc vláken, je to většinou pro to, aby dlouhotrvající operace nezablokovala GUI – a k čekání na to, až uživatel pohne myší, opravdu není další procesor potřeba). Ovšem typicky na počítači neběží pouze jeden proces (GUI aplikace na popředí), ale těch procesů je tam spousta. Jednak tam určitě běží nějaké jádro, v unix-like systémech nějaký X-server, těch GUI aplikací tam má člověk několik (jedna třeba na pozadí přehrává hudbu)… A to nemluvím o serveru, tam se aplikace samozřejmě vícevláknově normálně programují (a někdy je s tím dost legrace). Takže Knuth má pravdu v tom, že dnešní desktopové aplikace většinou nejsou navrženy, aby využily vícejádrové procesory nebo víc procesorů, ovšem z toho ještě neplyne, že jsou na desktopu vícejádra k ničemu.

[deda.jabko]

on je pruser hlavne v tom, ze programatori nejsou navrzeni, aby psali vicevlaknove aplikace. do nedavna k tomu nebyl duvod, protoze na to nebylo zelezo a kdyz uz se neco psalo, tak to nebylo zrovna nejtrivialnejsi. ke vsemu lidske uvazovani je spis sekvencni a kdyz se k tomu vezme naprosto zoufaly aparat pro paralelizaci, ktery poskytuji dnesni main-streamove programovaci jazyky, tak muzeme byt vlastne radi, ze nejake programy bezi paralelne. jak uz nekdo psal vyse... jako reseni se rysuji takove veci jako implicitne paralelni behove prostredi nebo zaclaneni STM do jazyka.

[xm]

Jak jenom rýsuje? Třeba takový Erlang už je tu docela dlouho

[Kyosuke]

STM je lepší než nějaký Erlang...

[deda.jabko]

a co teprve STM + Scheme = jazyk budoucnosti jiz dnes... ;-]

[deda.jabko]

tak to jsem cekal... kdo ho vytahne jako prvni... erlang je zajimavy... ale ma nektere vlastnosti, ktere mainstreamovi programatori nezkousnou... krome toho, ze ten jazyk je ,,jiny''... tak mu chybi treba stav... coz je sice uzasna featura, diky ktere jdou delat dalsi uzasne veci, ale ze by v tom programovali soucasni ,,taky programatori'' to se predpokladat neda...

[Tom.š Ze.le.in]

Ale on psal, že mluví o využití pro práci, ne o zábavě.

[Filip Jirsák]

Za prvé, to psal ohledně webového prohlížeče. Za druhé – vezměme si jako práci třeba takové programování. K tomu používá programátor IDE, kde poběží jedno vlákno pro GUI, druhé vlákno pro parsování aktuálního kódu, v tom samém vlákně nebo ještě v dalším může běžet doplňování kódu. Vedle toho má programátor spuštěn internetový prohlížeč s dokumentací – jedno vlákno pro GUI, jedno pro renderování webové stránky, další pro JavaScript. To celé běží na nějakém kernelu a spolupracuje s X-serverem. A to nepočítám spuštěný kontext pro program, který vývojář programuje (aplikační server, databáze…).

Ostatně i Knuth když programuje v emacsu a programoval by v textovém režimu, pořád může využít více jader při kompilaci programu, což je zrovna úloha, která se paralelizuje sama od sebe.

[Tom.š Ze.le.in]

Z textu:

From the opposite point of view, I do grant that web browsing probably will get better with multicores. I’ve been talking about my technical work, however, not recreation.

Jinak, moderní překladače paralelizují překlad třeba Cčka v jednom souboru? (já opravdu nevím, já se ptám). Protože jestli to je na úrovni make -j, tak při Knuthově stylu to zřejmě moc nepomůže.

[Filip Jirsák]

Moderní překladače možná ano, ale nevím, zda i gcc Já měl na mysli make -j – vzhledem k tomu, že Knuth pravděpodobně píše program pro větších částech, mělo by mu make -j pomoci, ne? Tedy pokud vůbec používá make. Každopádně pokud je Knuth jediný, kdo vícejádrové procesory nevyužije, je asi docela dobré pro ostatní ty vícejádrové procesory vyrábět.

[Tom.š Ze.le.in]

Ony jsou taky možná dvě různé věci překlad programu z (cizího, překopírovaného) zdrojáku a opakované překládání projektu na kterém pracuju (změny na malém počtu míst). A třeba TeX je v podstatě jeden soubor.

[Lukáš Zapletal]

Big R3SP3CT.

[Messa]

Literate programming zní docela zajímavě, slyšel jsem o tom poprvé. Neví někdo, zda je to o moc jiné (lepší) než dokumentování kódu komentáři a doxy?

[Kyosuke]

IMHO to je o dost lepší. Vyjedeš z toho i knihu, kterou si člověk může přečíst, a ví, jak to funguje jako celek. Takové ambice javadoc, doxygen a spol. nikdy neměly. Na druhou stranu, samozřejmě výhodnost či nevýhodnost asi závisí na charakteru programu. U sbírky funkcí zdokumentuješ funkce, u programu, který dělá něco konkrétního, zdokumentuješ, co dělá celý.

[Tom.š Ze.le.in]

Popravdě řečeno, docela jsem s tím kdysi (už to je tak deset let?) experimentoval, a přijde mi, že velká část funkcionality je pro některé jazyky užitečnější než pro jiné. Omezení na ukládání řetězců v Pascalu jsou už asi pasé, a to že můžu definovat sekci která se pak vloží do jiné sekce (čímž se zpřehlední text) je zbytečné, pokud má cílový jazyk rozumné funkce (a makra). Přeskupování kódu taky není až tak užitečné, pokud si v jazyce můžu psát funkce v pořadí v jakém chci.

Asi hlavní problém je to, že pokud člověk experimentuje a mění kód za běhu, tak udržet to synchronní je dost těžké. Rovněž tak bývá velká část programu nudná administrativa nebo (zase v závislosti na jazyku) částečně opakjovaný kód, kterou je skoro zbytečné rozsáhleji komentovat (i když Knuthovi se daří i to).

Otázkou taky je cílový formatter. TeX je fajn, ale kdo si dnes bude svůj kód tisknout jako knihu? Pak je tu HTML, ale to zase není tak hezké. A psát to tak, aby to šlo do obého (což některé LP tooly umožňovaly) je při jakémkoliv složitějším formátování docela opruz.

Jinými slovy: v C jsem si použití představit uměl, v Lispu už méně, respektive nepotřeboval jsem naprostou většinu toho, co LP nabízí. A pokud zůstane jen formátování komentářů v TeXu a přepis kódu do \tt, tak už to nemá s tím původním moc společného.