DAVIDOWITCH: Zajimavy cteni. Necetl jsem to dukladne, s radou veci souhlasim, ale jsou tam i veci, se kteryma nesouhlasim. Napr. ze programator (v HLL) by mel vybirat se dvou semanticky ekvivalentnich konstrukci ty "rychlejsi". Moje zkusenost je, ze spousta "programatoru" to "dela", v zasade ale spatne, protoze netusi co se dole deje (resp si mysli, ze tusi). Typicke priklady co jsem mel tu cest videt/slyset:
* hlavne nevytvarejte zbytecne objekty, zbytecne to zatezuje GC, kdyz uz, znovu pouzijte existujici!
* hlavne ne vyjimky, jsou pomale!
* nikdy nepouzivejte konkatenaci stringu, vzdycky jen pres stringbuffer!

a podobne perly ;-)

ANT_39: tohle tema je hlavne otazka osobnich preferenci a ja osobne uprednostnuju aby kod pokud mozno neschovaval slozitosti coz imo pretezovani operatoru dela, akceptoval jsemto do nejaky miry, nicmene pokud se jedna o specifickou tridu takmam radsi jasny volani funkce at mne to tukne do oka driv nez rozjedu profiler. Jasny, ze muzu tuhle debatu vzdycky smest tim, ze profiler mi odhali vsechno nebo, ze kdyz koukmu na ten asm tak mi to ukaze pravdu, ale kdyz je to kasny z kodu tak anijedno delat nemusim a usetril jsem si praci. Takze za mme je to nepretezovat pokud to neni jasny nebo se to nechova obvyklym, ocekavanym zpusobem.

JANFROG: Jasny, a jo, tvoje aproximace rozhodne dava smysl.

A ja tu prihodim clanek na tema optimalizace, je to hezky cteni:
The Fallacy of Premature Optimization
http://ubiquity.acm.org/article.cfm?id=1513451

DAVIDOWITCH: Ja vim ze to vis. Jen jsem chtel poukazat na to, ze v instrukcich je trosku nesmysl dneska pocitat.

I kdyz, musim se priznat, ja to sam delam :-) Kdyz generuji / pisu kod, obvykle jen pocitam pocet taken-jumpu ve fast path + kouknu na efektivitu vyuziti cache. V mem konkretnim pripade je to docela dobra aproximace...

JANFROG: Vim. Jen sem rozvadel napad ze [] v C je lepsi protoze trva jen instrukci. To ze mnohem vic zalezi na tom jestli mas to kam tim [] pristupujes v cache nebo ne nez na tom pres kolik instrukci spocitas presnou adresu je trochu soucasti pointy. (A ja bych asi vytahl ze spojaky jsou na ten pristup kor blby, protoze nepouzivaj datovou lokalitu.. ale to uz tu nekolikrat bylo)

WILD_A: Tak jestli se ten celek tvaril jako kontejner... IMHO je fakt jedno, jestli je to get, at, operator[] nebo co, stejne z nazvu tu cenu toho volani presne nepoznas, a profiler se zmast nenecha. Konzistence ma IMHO vetsi vahu, nez anotovat jmeno funkce podle toho, jak je implementovana.

Jestli ten double lookup o kterym mluvis byl opravnenej je samozrejme uplne jina otazka. Mohl, nemusel.

WILD_A: Potrebujes par instrukci abys spocital adresu a pak udelal ten load. (A jo, myslim tim RISC instrukce, ze ma x86 zbesily instrukce co nejenze natahnout z pameti dany bazi a offsetem do registru, ale jeste ti vycistej boty.. to vim a neprijde mi to az tak zajimavy)

DAVIDOWITCH: Nedokaze nacist data z pole do registru? nebo jsem te spatbne pochopil?

ANT_39: No ono to brikule jsou, to mas pravdu, ale v dnesni dobe mne to neprekvapi, viz STL kontejnery, ja se tomu osobne vyhybam to delat takhle, ale realita kolem mne je jaka je. Nicmene konkretni brikule co jsem videl a resil bylo nejdrive vyhledani daneho prvku v jinem STL kontejneru, nacteni dalsiho indexu do jineho kontejneru a z nej vytazeni finalniho udaje ... jako bylo to cely spatne, to nerozporuju, ale vypadalo to na prvni pohled naprosto elegantni a optimalni kod :)

WILD_A: Prekvapuje me, ze pristup do hashe a do mapy nepovazujes za brikule. To je o rad horsi, z hlediska slozitosti kodu, nez prostej pristup do pole. Co se v tom pripade jako brikule kvalifikuje?

XCHAOS: Jo, dela, precti si neco o SSA.

Ale pokud mas vlevo treba prave tu indexaci, a prirazujes do toho z pameti a ne z aritmeticky jednotky, tak uz to nedas. Pokud jen mas nejakou matiku a do promennych ukladas mezivysledky, tak to je vesmes cely jen asignovani registru (ala to co dela procesor kvuli out-of-order exekuci, kde ma vyrazne vic fyzickejch nez logickejch registru a prejmenovava si je jak zrovna potrebuje)

DAVIDOWITCH: no, pokud mu přiřazovaná hodnota zbyde v registru, tak podle mě dokáže. dokonce, pokud v rámci optimalizace je přiřazováno do proměnné uložené v registru (buď explicitně vyžádáno klíčovým slovem "register" nebo nějak zoptimalizováno) , tak výraz vpravo od rovnítka mohl compiler zpracovat tak, že následná operace přiřazení spotřebuje 0 instrukcí :-) (ale toto tvrdím bez jakékoliv záruky, že nějaký compiler skutečně takovou optimalizaci dělá, teda...)

XCHAOS: Procesor vetsinou nedokaze prirazeni/indexovani jednou operaci na registrech ani v cistem C.

XCHAOS: Na pole fixni velikosti zapomen :-D
Jenak je to uplne burta, kdyz uz to mas na heapu (a na stack se to nevejde ani omylem), a druhak by to predpokladalo ze aplikace bezi v prave jednom rozliseni, coz nebezi.

WILD_A: no, obávám se, že v éře, kdy myší už ani nemusíš klikat, aby nastal nějaký ten onMouseOver() event, budeme mít problém vysvětlil většině, proč se nám nelíbí, že věci jako přiřazení nebo indexování pole neměly dělat nic, co by procesor nedokázal provést jedinou instrukcí zpracovávající hodnoty v registrech...

ANT_39: No pokud se tam dejou brikule, tak mi to na miste neprijde, jelikoz to budi dojem, ze to je jen index a ocekavam tam maximalne nejakej strom nebo hash a ono je to pak cely slozitejsi. Ja mam rad kdyz kod ukazuje co dela, takze pokud delam brikule tak dam kontejner.brikule(x) at je to videt.

Ale je to jen muj postoj vzhledem ke zkusenostem, ktery jsem udelal, mluvim teda ted konkretne o C++.

(-1 od id REDGUY, pro velký úspěch...)

ANT_39: ... to znamená, že má pocit, že se to děje magicky samo a nic to nestojí :-)

WILD_A: Zrovna pretezovani [] u kontejneru, * a -> u chytrejch ukazatelu, atp. dava taky dobrej smysl. Jestli se kvuli tomu musi delat brikule, tak holt musi. Stejne by se delaly, at to nazves at nebo operator[], akorat ted ma klient pristup do toho kontejneru pomoci intuitivni syntaxe.

WILD_A: jenže ono nejde dát do jazyka nějakou feature jen k tomu, aby si matematici mohli definovat vektory a matice a doufat, že jí někdo nezneužije jinak...

takže purismus a minimalismus C je svazující a omezující (pro mě je C ideální jazyk, kdybych zase někdy programoval panáčka, co běhá po místnostech se souřadnicemi x a y a sbírá konečný předem známý počet předmětů, apod. :-), jenže jakýkoliv jiný vyšší jazyk umožní, aby "cokoliv znamenalo cokoliv"

+ a += v Pythonu je lepší než drátem do oka. Sjednocení (řetězení) a aritmetické sčítání ale není to samé. stejně tak ale PHP/Perl tečka koliduje min. s desetinou tečkou a voláním metody objektu. konkatenace si zaslouží vlastní operátor, který matematici nemají

(a jestli nebudu líný, tak vám předvedu brzo svoje řešení :-) sice trochu gcc only, ale elegantní :-)