XCHAOS: Je to ciste skolni uloha, ale ma spoustu fajn figlu. Jako treba jak to udelas aby to fungovalo na utf16 (tj. kazdej znak ma bud 8 nebo 16 bitu, podle flagu v nejvyssim bitu).
Nebo co udelas kdyz se to nevejde cely do pameti.

Pricemz pristup do out-of-core dat je dulezitej pro.. no skoro vsechno.
I kdyz klasictejsi otazka na tohle bejva na sort.. mas obrovsky mnozstvi dat na disku, nevejde se to do pameti, chces je seradit, jak to udelas?

(Dalsi dobra uloha je, ze mas obrovskej log, nekolik TB, a chces z nej random 10k pro nejaky statisticky zpracovani... jak vyberes 10k radek abys nemel zbytecny IO)

DAVIDOWITCH: tohle přece za mě zoptimalizuje kompilátor, riiiiiight? ;)

JANFROG: KEYMASTER: Jo.. byl tam strlen

for(int i = 0; i < strlen(str); ++i)
std::swap(str[i], str[strlen(str) - i - 1]);

(tj. nejenze to neprohodilo, ale mel tam to N^2 hned 2x)

JANFROG:
char* previous = malloc(1);
previous[0] = 0;
for(int i = 0; i < strlen(input); ++i) {
char* next = malloc(strlen(previous) + 2);
next[0] = input[i];
for(int j = 0; j < strlen(previous)+1; ++j) {
next[j+1] = previous[j];
}
previous = next;
}

Víc to naprasit nedokážu. Dealokace paměti vynechána z důvodu optimalizace, někde jsem četl že free je pomalý a všechna pamět se stejně uvolní po skončení programu.

WILD_A: Tak hlavne pointa je v tom, ze u HLL - pokud jeho VM za neco stoji - ani nemuzes vedet, co se skutecne provede dokud ten program nespustis nad konkretnima datama...takze IMHO ani nema cenu s tim nejak operovat...

DAVIDOWITCH: Ja to pochopil tak, ze by vykon mel byt bran v potaz, ne ze jde hlavne o vykon.
string reverse v N^2 je ovsem vic nez snaha zbytecne neoptimalizovat, to je presnej opak :)

Priznam se, ze kdyz pouzivam HLL jako python nebo lisp tak nevim jaky konkretne instrukce z toho jsou, ale ze zkusenosti vim co je rychlejsi. uspornejsi. Nevim jestli je potreba vedet na co se dany konstrukt JITne, nicmene vedet jak se dany konstrukt chova je rozhodne uzitecny a znat alespon hrubejs vnitrnosti jazyka a runtimu povazuju za podminku nutnou. Z meho okoli vim, ze treba garbage collector je pro velkou cast lidi cerna skrinka co neco magicky dela a moc nikdo nevi jak konkretne funguje, ani zaklady typu jestli je generacni a co to znamena.

Celkove clanek zajimavej, obzvlast snahou napravit mytus, ale ze by se vetsina snazila naucit assembler mi prijde nepravdepodobny, byt je to imo dobra zkusenost a souhlasim ze to dava smysl, ja se to kdysi naucil crackovanim her, SoftICE rulez :). I kdyz abych pravdu rekl, ze tak si myslim, ze vetsina nepotrebuje znat asm, ale znat runtime jazyka ktery pouzivaji, aby se vyhnuli aspon tem nejhorsim konstrukcim, vetsina aplikaci neni zamerena na vykon.

JANFROG: Tak clanek predpoklada ze lidi vedi. Respektive, prislo mi ze to ze se lidi neobtezuji vedet (a nemuzou potom spravne rozhodnout) povazuje za velkou chybu.
Tj. to ze nevybiraji "rychlejsi" je na stejny urovni jako ze vybiraji "rychlejsi", ale delaj to blbe. Oboje znamena ze nemaj dost znalosti na to optimalizovat.

XCHAOS: Z tveho komentare bych odvodil, ze si necetl ani prvni odstavce clanku...

DAVIDOWITCH: no ale některé z nás prostě baví optimalizovat. (ostatně, řada projektů ve světě free software vzniká dobrovolně, a ne na zakázku.. i když částečně je to mýtus a některé podstatné komponenty dnešních linuxových distribucí jsou původně komerční projekty, později abandonware uvolněný pod GPL...)

JANFROG: :-)))

A jeste jedna usmevna historka: doted si vzpominam, jak me muj "guru" sprdnul stylem: "Ach ne, hlavne zadny if-else. Kdyz uz nusis, tak jedine goto! :-) Kazdej jsme nejak zacinal :-)

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...