Vlákno názorů k článku Modrá Twibright Ronja: výukový spoj na ČVUT od andy - No ono je ale fakt, že k programování...

A když jazyk, ve kterém to píšeš, ani nenaznačuje, do čeho se to vlastně zkompiluje, tak k čemu ti je vědět, že procesor vůbec nějaké registry má? K čemu ti je vědět něco o architektuře disků, když tvoje aplikace má rozhraní akorát tak přes webovou službu na databáze?

Zde se zasadne neshodneme. Tvrdim, ze pokud uzivatel db nevi, co pro db a jeji fungovani znamena, ze je ulozena zcasti v RAM a zcasti na disku a pri jakych radove velikostech a typech dotazu to s tim diskem priblizne co udela, tak hrozi s pravdepodobnosti dosti znacnou, ze zplodi naprosto strasnej a nepouzitelnej program. Kterejch bohuzel kolem sebe vidame vic a vic. "Webovejch aplikaci", ktery na strane prohlizece v JS sezerou 100% CPU a nedelaj *NIC*, nebo na strane serveru chroustaj primitivni vyhledani n minut, vidam dost kazdou chvili. Urcite neni neznalost HW jedinou a asi ani hlavni slabinou "programatoru", ale rekl bych, ze na tom obecnem praseni ma svuj podil.

Naopak se zcela shodneme v tom, ze delat optimalizaci na krev tam, kde to prinese napr. zneprehledneni kodu, aniz by byla dana optimalizace vyzadovana ucelem, je skodlive.

> Tvrdim, ze pokud uzivatel db nevi, co pro db a jeji fungovani znamena, ze je ulozena zcasti v RAM a zcasti na disku a pri jakych radove velikostech a typech dotazu to s tim diskem priblizne co udela, tak hrozi s pravdepodobnosti dosti znacnou, ze zplodi naprosto strasnej a nepouzitelnej program.

Jenže to penzum znalostí, o kterých by člověk "měl vědět" je dost triviální. Něco ve stylu "RAM je rychlejší než disk", "velké dotazy se nevejdou do RAM" a "na točivých discích je random přístup pomalý (a pokud je to virtualizovaný, tak je random pomalu všechno)". Pokud tohle člověk neví, tak má opravdu problém, ale zřejmě asi nějaký jiný. Mimochodem, dneska v cloudu máš službu s garantovanou výkonností (podívej se třeba, co nabízí DynamoDB) a tím to končí.

Ale co mu pomůže lokalita cache, jak vypadá south-bridge na PCI sběrnici, jak funguje segmentace paměti? Nebo třeba i něco high-level - jak vůbec funguje context-switch, jak jsou na konkrétním OS implementovány thready apod. Fakt si myslíš, že při programování nějakých - i netriviálních - webových nebo třeba mobilních aplikací - je něco z toho vůbec relevantní?

Jenže to penzum znalostí, o kterých by člověk "měl vědět" je dost triviální. Něco ve stylu (..)

No vida, tady uz se v zasade shodneme. Potiz je, ze ani aktivni povedomi o takoveto zakladni mnozine skutecnosti nekdy na tech programech neni videt.

Nebo třeba i něco high-level - jak vůbec funguje context-switch, jak jsou na konkrétním OS implementovány thready apod. Fakt si myslíš, že při programování nějakých - i netriviálních - webových nebo třeba mobilních aplikací - je něco z toho vůbec relevantní?

Ano, myslim, ze je to naprosto relevantni. Uz treba pri volbe, zda pole o deseti milionech polozek budu zpracovavat jednim vlaknem, dvema vlakny, nebo deseti miliony vlaken.

"No vida, tady uz se v zasade shodneme. Potiz je, ze ani aktivni povedomi o takoveto zakladni mnozine skutecnosti nekdy na tech programech neni videt."

Tak to mají asi trošku jiný problém....

"Ano, myslim, ze je to naprosto relevantni. Uz treba pri volbe, zda pole o deseti milionech polozek budu zpracovavat jednim vlaknem, dvema vlakny, nebo deseti miliony vlaken."

Až na to, že pole o deseti milionech položek prostě většina programátorů zpracovávat nebude. Nepamatuju si, že bych kdy něco takového dělal. A veškeré informace, které k tomu potřebuju jsou "existují thready. Běží na více fyzických corech současně".

Až na to, že pole o deseti milionech položek prostě většina programátorů zpracovávat nebude. Nepamatuju si, že bych kdy něco takového dělal.

No ty mozna ne, ale normalni lidi zpracovavaji megapixelove obrazky nebo zvuky naprosto bezne. A jasne, nekomu staci prendat JPEG/MPEG z mista na misto, ale jinej treba potrebuje najit v nem xicht, dopravni znacku, rozpoznat slovo (abych zahral zrovna na dost aktualni struny tech nejproflaklejsich operaci).

A veškeré informace, které k tomu potřebuju jsou "existují thready. Běží na více fyzických corech současně".

Naprosto nedostatecne. Bez aspon velmi hrubeho, ramcoveho prehledu o tom, jaky jsou kvantitativni vlastnosti vlaken, nelze zvolit spravnej pristup.

> No ty mozna ne, ale normalni lidi zpracovavaji megapixelove obrazky nebo zvuky naprosto bezne. A jasne, nekomu staci prendat JPEG/MPEG z mista na misto, ale jinej treba potrebuje najit v nem xicht, dopravni znacku, rozpoznat slovo (abych zahral zrovna na dost aktualni struny tech nejproflaklejsich operaci).

???? Kolik procent programátorů tohle podle tebe dělá? 1%?

> Naprosto nedostatecne. Bez aspon velmi hrubeho, ramcoveho prehledu o tom, jaky jsou kvantitativni vlastnosti vlaken, nelze zvolit spravnej pristup.

Co to je "kvantitativní vlastnost vláken"? Jako že "kernel thread stojí hodně" a "user thread stojí málo"? A to je opět asi tak všechno, co je o tom potřeba vědět?

???? Kolik procent programátorů tohle podle tebe dělá? 1%?

To nevim, mezi programatory se bohuzel moc nepohybuju a ani nepracuju jako vedouci SW projektu ci personalista. Jestli je to 1% nebo 50%, to snad neni tak dulezity. Jsou to data a ulohy, ktere jsou dnes aktualni, je v nich cilej vyvoj a zasahuji spoustu oblasti od ciste spotrebni po skoro rekneme prumysl.

Pokud se bavime o programovani, nepredpokladam, ze by byl jakkoli zajimavej (ba toho slova vubec hodnej) nejakej obecnej LAMP lepic, opakujici desettisictou variantu tehoz bez jediny spetky invence. I kdyz je to mozna 99% "programovani".

Co to je "kvantitativní vlastnost vláken"? Jako že "kernel thread stojí hodně" a "user thread stojí málo"? A to je opět asi tak všechno, co je o tom potřeba vědět?

No tak treba aspon ramcovou predstavu, jak velikej je ten kontext nutnej pri prepnuti vlakna, procesu, kolik to asi stoji, kolik si toho muzu dovolit. V urovni cireho matematickeho idealismu bych si prece mohl udelat jedno vlakno (proces, terminologii VHDL) na kazdej datovej drat a spousta veci by se mi vyrazne zjednodusila,...

Pokud se bavime o programovani, nepredpokladam, ze by byl jakkoli zajimavej (ba toho slova vubec hodnej) nejakej obecnej LAMP lepic, opakujici desettisictou variantu tehoz bez jediny spetky invence. I kdyz je to mozna 99% "programovani".

Jasně, takže co třeba takové věci, jako je třeba psaní škálovatelných aplikací - třeba a la whatsup. Jeden počítač ti prostě nestačí, takže v konečném důsledku tam máš lidi, kteří řeší, jak vůbec napsat distribuovanou infrastrukturu, která je schopna škálovat. Ti, kteří tohle dělají, nemusí o HW vědět vůbec nic. Nemusí znát, co to je CPU cache, rozdíl mezi točivými a SSD disky, nemusí vůbec znát assembler. Naopak se musí orientovat v takových srandách, jako je PAXOS, distribuované hodiny a podobné čistě teoretické záležitosti. Máš pocit, že to není "to správné programování"?

No tak treba aspon ramcovou predstavu, jak velikej je ten kontext nutnej pri prepnuti vlakna, procesu, kolik to asi stoji, kolik si toho muzu dovolit. V urovni cireho matematickeho idealismu bych si prece mohl udelat jedno vlakno (proces, terminologii VHDL) na kazdej datovej drat a spousta veci by se mi vyrazne zjednodusila,...

Ano, a pokud programuju v nějakém high-level jazyce, tak to přesně takhle udělám. Režie kontext-switche tam totiž není o moc větší, než když budu ten dispatch budu dělat "manuálněů.

Jasně, takže co třeba takové věci, jako je třeba psaní škálovatelných aplikací - třeba a la whatsup. Jeden počítač ti prostě nestačí, takže v konečném důsledku tam máš lidi, kteří řeší, jak vůbec napsat distribuovanou infrastrukturu, která je schopna škálovat. Ti, kteří tohle dělají, nemusí o HW vědět vůbec nic. Nemusí znát, co to je CPU cache, rozdíl mezi točivými a SSD disky, nemusí vůbec znát assembler. Naopak se musí orientovat v takových srandách, jako je PAXOS, distribuované hodiny a podobné čistě teoretické záležitosti. Máš pocit, že to není "to správné programování"?

Urcite je to to spravne programovani. A narozdil od tebe jsem presvedcen, ze to nemuzou konkurenceschopne napsat lidi, co vedi kulovy o pod tim lezicich vrstvach -- vcetne aspon naprosto zakladnich charakteristik HW uplne dole. Jinak totiz nevznikne Whatsup, ale Facebook (mysleno urovni programovani, ne funkcionalitou).

Ano, a pokud programuju v nějakém high-level jazyce, tak to přesně takhle udělám. Režie kontext-switche tam totiž není o moc větší, než když budu ten dispatch budu dělat "manuálněů.

No vidis, to je prece spravne (pomineme-li nepresnost vyjadreni). Udelas to tak a vis, ze je to OK, protoze mas predstavu o tom, co se s tim programem po prekladu *zhruba* stane. Kdybys to nevedel, tak bys mel v nejakejch konkretnich prikladech treba stesti, ze to chodi dobre, v jinejch bys byl Indem, co zere 400% CPU, aniz by program fungoval dle prani usera.

Urcite je to to spravne programovani. A narozdil od tebe jsem presvedcen, ze to nemuzou konkurenceschopne napsat lidi, co vedi kulovy o pod tim lezicich vrstvach -- vcetne aspon naprosto zakladnich charakteristik HW uplne dole. Jinak totiz nevznikne Whatsup, ale Facebook (mysleno urovni programovani, ne funkcionalitou).

Ty vážně myslíš, že znalost HW způsobí, že to nebudu psát v PHP, ale v Erlangu a nebudou si bastlit distribuované algoritmy na koleně, ale použiju nějaké existující a dokázané protokoly? Mimochodem, spam-filtr na facebooku je docela pěkná ukázka toho, jak se to má dělat. Výsledkem jejich snažení je mimo jiné třeba tahle knihovna: haxl Co potřebuju vědět za charakteristiky HW, abych něco takového napsal?

Ty vážně myslíš, že znalost HW způsobí, že to nebudu psát v PHP, ale v Erlangu a nebudou si bastlit distribuované algoritmy na koleně, ale použiju nějaké existující a dokázané protokoly?

Muhehe, hezka ukazka obraceni smeru operatoru ⇒, potazmo ⊆. Nekdy tez zvano zenska logika.

Mimochodem, spam-filtr na facebooku je docela pěkná ukázka toho, jak se to má dělat.

Pokud se ta firma hrabe z nekdejsiho nebo stavajiciho hnoje a jeji kultura se zlepsuje, je to urcite pro uzivatele i neuzivatele FB dobra zprava.

Výsledkem jejich snažení je mimo jiné třeba tahle knihovna: haxl Co potřebuju vědět za charakteristiky HW, abych něco takového napsal?

Bohuzel neHaskelluju (a ano, mrzi me to), tak to nejsem s to docenit. Nicmene souhlasim s tim, ze existuji algoritmy, jejichz prakticka ci v asymptotickem smyslu optimalni podoba je na HW do znacne miry nezavisla (uplne taky ne, viz zminka o tom, vuci jakemu n se vubec O(f(n)) pocta). A jiste, existuji ulohy, kde je bud trivialne zajisteno, ze na stiru s prostredky nebudu, nebo mi postaci povsechne povedomi ("kolik mam cca RAM"). Jak moc je mozno nestarat se o realnej dopad behu Haxlu z pohledu tvurce, zel, nejsem kompetentni posoudit.

A narozdil od tebe jsem presvedcen, ze to nemuzou konkurenceschopne napsat lidi, co vedi kulovy o pod tim lezicich vrstvach -- vcetne aspon naprosto zakladnich charakteristik HW uplne dole.
Muhehe, hezka ukazka obraceni smeru operatoru ⇒, potazmo ⊆.

Já nemám jediný důvod se domnívat, že programátoři navhující a píšící ten systém messagingu vůbec tuší něco o tom, na jakém to vůbec běží HW. Někdo to tam stavěl, tak ten "někdo" o tom HW asi něco ví. Ale třeba jinak: spousta věcí dneska běží v cloudu. Ja absolutně nemám tuchy, na jakém HW to tam běží. Takže kvůli tomu nejsem schopnej něco napsat, když vím kulový co pod tím leží?

Bohuzel neHaskelluju (a ano, mrzi me to), tak to nejsem s to docenit. Nicmene souhlasim s tim, ze existuji algoritmy, jejichz prakticka ci v asymptotickem smyslu optimalni podoba je na HW do znacne miry nezavisla (uplne taky ne, viz zminka o tom, vuci jakemu n se vubec O(f(n)) pocta). A jiste, existuji ulohy, kde je bud trivialne zajisteno, ze na stiru s prostredky nebudu, nebo mi postaci povsechne povedomi ("kolik mam cca RAM").

Ta knihovna není vůbec o tom, aby něco asymptoticky optimalizovala. Ta knihovna je od toho, aby transparentním a jednoduchým způsobem umožnila paralelizovat kód psaný uživateli. On v ní dokonce asi není ani žádný "algoritmus", u kterého by mělo smysl ho nějak "optimalizovat". Celé to je o tom dát uživatelům do ruky nástroj, pomocí kterého budou psát korektní a dobře paralelizovaný kód. A to je taky programování, a fakt docela zajímavé - a netriviální. A ten, kdo tohle psal, fakt nemusel vědět vůbec nic o HW, na kterém to poběží. A věř, že to byl dost dobrý programátor.

Naopak se musí orientovat v takových srandách, jako je PAXOS, distribuované hodiny a podobné čistě teoretické záležitosti.

Hele, ja nemuzu odolat: zrovna timhle prikladem jsi me moc potesil. Sice jsem nedelal nic v PAXOSu (mych redundantnich systemu bylo celkove dost malo a kdyz, tak byly realizovany naprosto stupidne a tesne vazane a zadna slozitost se tam nekonala a bylo to hodne low-level), zato docela aktivne pracuju s distribuovanyma hodinama a to jak na urovni HW nejHWovatejsiho (a sice analogoveho), az po "čistě teoretické záležitosti", jako odvodit matematicky ciste, kolik je v danem uzlu nejlepsi odhad casu. A tvrdim, ze znalost toho HW se fakt hodi.

Jsou lidi, co ji nemaji, a tem se deji zajimave veci, napriklad rozkmitany NTP. Zazil jsem, v realnem nasazeni v prumyslu.

Měl jsem na mysli vektorové hodiny a podobný distribuovaný srandy.... ale třeba konkrétně k tomuhle: https://aphyr.com/tags/jepsen
A teď mi zkus vysvětlit, k čemu se mi v tomhle hodí znalost HW. Předpokládám, že jako dostatečnou znalost HW asi nemyslíš "sítě jsou nespolehlivé".

Co potřebuješ znát je rozhraní, nad kterým pracuješ. "Jak to funguje" pod tím rozhraním může být drtivé většině lidí ukradené. Pokud zrovna neděláš nějaké relativně triviální performance-oriented věci, tak pro tebe může být assembler a všechno kolem CPU sprosté slovy. U složitějších věcí to stejně nebudeš schopnej zorganizovat rozumně, případně se ti nebude chtít vylézt s třeba dost high-level jazyka, ve kterém to píšeš. Jako je hezké psát něco o cache-locality, ale když v tom jazyce nemáš možnost ty alokace ovlivnit, nebo provádíš optimalizace nad nějakým větším grafem, který nejde nějak rozumně reprezentovat kompaktněji, tak je ti celá tahle teorie na nic.

Měl jsem na mysli vektorové hodiny a podobný distribuovaný srandy...

No to jsem pochopil. Znalost chovani hodin (tj. HW) mi dokaze rict, jaky drifty a jaky chyby muzu cekat a jak s tim nalozit, s masterem, bez mastera,...

třeba konkrétně k tomuhle: https://aphyr.com/tags/jepsen
A teď mi zkus vysvětlit, k čemu se mi v tomhle hodí znalost HW. Předpokládám, že jako dostatečnou znalost HW asi nemyslíš "sítě jsou nespolehlivé".

Urcite se bude hodit vedet, jake druhy nespolehlivosti ta sit ma. Tj. treba, ktery vrstvy a konkretni protokoly si muzou dovolit prehazet zpravy, duplikovat, nedorucit, pokazit obsah zpravy (zamena bajtu za jiny) a jaka je toho pravdepodobnost. Co se deje v krizovejch a chybnejch situacich, jestli to nejak ovlivni, kdyz je v ceste VPN apod. Jak funguje fragmentace a udrzovani spojeni...

A nechod na me s tim, ze zaslani zpravy je vysokourovnova operace. Jinak ti smele navrhnu, ze zalohovani databaze na vzdalenej stroj provedeme atomickou operaci server2.db = server1.db a ahoj. Je to prece formalne v poradku, ne?

No to jsem pochopil. Znalost chovani hodin (tj. HW) mi dokaze rict, jaky drifty a jaky chyby muzu cekat a jak s tim nalozit, s masterem, bez mastera,...

Ehhh.... ne, tohle jsem myslel: https://en.wikipedia.org/wiki/Vector_clock - A vector clock is an algorithm for generating a partial ordering of events in a distributed system and detecting causality violations. To nemá s hodinama nic společného....

Urcite se bude hodit vedet, jake druhy nespolehlivosti ta sit ma. Tj. treba, ktery vrstvy a konkretni protokoly si muzou dovolit prehazet zpravy, duplikovat, nedorucit, pokazit obsah zpravy (zamena bajtu za jiny) a jaka je toho pravdepodobnost. Co se deje v krizovejch a chybnejch situacich, jestli to nejak ovlivni, kdyz je v ceste VPN apod. Jak funguje fragmentace a udrzovani spojeni...

No... vlastně vůbec ne. Když to je postavené nad TCP protokol, tak z hlediska chování podle toho CAP v podstatě řešíš akorát "chodí/nechodí/cho­dí pomalu". O HW pod tím nepotřebuješ vědět vůbec nic.

A nechod na me s tim, ze zaslani zpravy je vysokourovnova operace. Jinak ti smele navrhnu, ze zalohovani databaze na vzdalenej stroj provedeme atomickou operaci server2.db = server1.db a ahoj. Je to prece formalne v poradku, ne?

No...... jo. A jako v čem je problém? Přes 2-PC se to asi celkem v pohodě dá implementovat?

Optimalizovat "prilis" na HW je urcite v obecnych pripadech zle, pokud nejde opravdu o specifickou aplikaci.

Jeden priklad "pravdy o optimalizaci kodu co platily loni jsou uz dnes totalne mimo" by byl? (Pokud nemas na mysli pravdu, co platila o optimalizaci kodu pred 30 lety [tam bych se nehadal], ale skutecne loni, nebo aspon pred 5 lety.)

Sekvenční vs. random čtení z disků. Existence SSD způsobila, že spousta optimalizací ztratila smysl.

Uznavam, ze SSD se chova jinak a ma svoje ctnosti a vady odlisne od magnetickeho disku.

Nicmene sekvencni cteni oproti ad hoc ma porad hodne navrch, protoze ten SSD je porad pripojen komunikacnim rozhranim disku a ne mapovan jako pamet. Muzeme se samozrejme bavit o tom, zda je tenhle anachronismus dobre ;-) (Uprimne: myslim si, ze celej koncept deleni pameti na feritovou a bubnovou je prezitek a tesim se na OS a jazyky, kde bude tento rozdil smyt. Doziju-li se.)

Jo. Spousta lidí dneska dává mnohaterové databáze na SSD pole, protože to prostě stejně nebyli schopni zoptimalizovat tak, aby to běželi na točivých discích a nemuseli tam mít 300 točivých disků, kdy z každého používali 30%. A ano, v momentě, kdy to dáš na SSD, tak prostě spousta optimalizací na sekvenční čtení přestane mít smysl a můžeš tu databázi dělat jinak.

Blbě se dá dělat všechno, ale bohužel někdy zjistíš, že prostě ten random přístup rychle potřebuješ. Jeden tenhle starter brick má 150.000IOPS a 40TB. Random. Nemáš pocit, že tím pádem se můžeš na veškeré sequential vs. random optimalizace vybodnout a jít dělat něco smysluplnějšího?

Existence SSD způsobila, že najednou spousta jiných optimalizací zase začala smysl dávat (zápis jediného bitu vede k nutnosti _přesunu_ celého bloku atd.).

Ehm, a jak že to je na točivém hard-disku? Že bychom třeba porovnali rychlost seeku a přepisu jednoho 512-bytového sektoru s přesunem jednoho 4K bloku? Že by to pořád bylo na SSD tak asi 10-a vícekrát rychlejší?

To je argument? takze nasazenim 10x rychlejsi (skutecne?) technologie jsi problem zprovodil ze sveta? Tak to neni zapotrebi uz nic resit - zere to RAM? dokoupime, nestiha HDD? poridime SDD, nestiha SDD? hmm vono se neco najde. Ja si tedy dovolim tvrdit, ze problem lokality dat je dneska vsudypritomny, od cache pres disky, RAIDy az po distribuovana reseni a vzdycky bude zapotrebi nekdo, kdo vi jak to funguje o jeden ci vic levelu niz.

Ano, to je argument. V diskovém poli s rychlými HDD se počítá 200IOPS na disk (většinou spíš míň). Takže 300 disků * 200 = 6000IOPS. Když potřebuješ 6000 IOPS na přístup třeba k 1TB databázi, jeden disk má třeba 300GB, tak se ti tam točí spousta zbytečných disků.

Jeden tenhle brick má 150.000 iops. Paradigm-shift?

300 * 200 = 60.000.... už je trochu pozdě...

Tim jsi dosel jen k tomu, ze jsi pro tvoji ulohu pouzil sofistikovany HW, ve kterem uz nekdo povolanejsi ty low-level algoritmy nacvakal. Jinak to neni posun paradigmatu, ale pouziti odlisne technologie, kterym obecne NEZMIZELA potreba v pripade potreby optimalizaci na urcity typ storage, pouze zmizela vam. Ostatne to muzu posunout dal a tvrdit, ze pro pitomy 1TB bude levnejsi a rychlejsi pouzit in-memory DB. A na druhe strane spektra jsou porad aplikace, kde mas miliony pasek a roboty, co je on demand vymenuji :)

Otázka zněla na příklad, zda zmizela potřeba pro určité optimalizace. Ano, zmizela - vzhledem k cenám SSD a paměti obecně prostě pro spoustu úloh fakt nemusím sekvenční vs. random přístupy řešit. Navíc, vzhledem k tomu, že dneska všechno běží na virtuálech, tak je velmi často i sekvenční přístup vlastně dost random. Stejnou úlohu prostě budu dneska řešit úplně jinak než před 5 lety.

Za pár krejcarů to není, ale zkus si porovnat cenu diskového pole s 300 disky, kdy z každého disku používáš jen určité procento vs. nějaká SSD technologie. Když vyžaduješ vysoké IOPSy, tak tě ty SSD vyjdou levnějc - ještě si přidej náklady na chlazení. Zkus se třeba podívat, jak bys třeba řešil s disky přístup k 400GB databázi, kde bys potřeboval 20.000 IOPS před 5 lety? Asi by ses snažil hodně optimalizovat, abys tam nemusel rvát naddimenzované diskové pole. Jak bys to řešil dneska? V podstatě to narveš do paměti a budeš optimalizovat něco úplně jiného, než je sekvenční čtení z disků.

Možná má robotron na mysli případ, kdy bylo potřeba dva osmibitové byte složit do 16-ti bitového čísla

int concat16(int h, int l)
{
  return (h<<8)|l;
}

Student zcela správě podle svých vysokoúrovňových znalostí vyhledal kombinaci operací, která vedla ke správnému výsledku

int concat16(int h, int l)
{
  char s[20];
  snprintf(s,sizeof(s)-1,"%02x%02x",h,l);
  s[sizeof(s)-1] = 0;
  return strtol(s,NULL,16);
}

Ovšem takovýto vysokoúrovňový přístup by v medicíně znamenal, že jsme všichni již od narození mrtví, protože zavázání pupeční šňůry by trvalo dva dny a případná transfúze týden.

Ano, tenhle priklad studentiho uvazovani jsem mel na mysli. Zel byl behem casu zmrsen ucinkem tiche posty pri refreshi moji neuronove site temer k nepoznani.

Tak ale s cache souvisi i to, jestli ctes pole (nebo bitmapu) po radcich ci po sloupcich, a to je operace, ktera je v mnoha jazycich precizne popsana (stejne jako zpusob ulozeni prvku). Jinak prohozeni cteni po radcich/sloupcich bude mit hodne velkej vliv, a to i na ostatni aplikace (kterym nebudes tak casto vyhazovat cache line).

Lidi, programujete taky něco jiného než násobení matic a rozpoznávání objektů?

Pouze lopata nedokaze svoje trapny ulohy prevest na sekvenci nasobeni matic a rozpoznavani objektu. Jen tak dojde k optimalnimu rozvrzeni zdroju, aneb, jste pitomci.

S ohledem na to, jak bazírují na detailní znalosti právě toho svého počítače, by možná byla zajímavá i otázka "programujete taky něco, co si spouští i jiní lidé?"