Prochazeni cyklu od zadu, pouzivani plneho vyhodnoceni, chran nas buh tehle pidi optimalizaci! Kdybych timhle za rok usetril treba 1000$ za vykonovy cas, kolik bych musel utratit na odstraneni defektu, ktere by temito optimalizacemi vznikly? Jak hodne by se prodlouzila doba nutna k porozumeni kodu, ktery je plny tehle pofidernich hacku. Problem dnesnich aplikaci je v tom, ze nedokazi zpracovani uloh paralelizovat, ale ne na urovni instrukci, ale celku. Jakou vykonostni prinos ziskate tim, ze budete optimalizovat na urovni instrukci a jakou na urovni celku? To je v dnesni dobe vicejadrovych a multi CPU pocitacu mnohem zasadnejsi.
Misto studia tehle pidi optimalizaci bych doporucil podivat se na http://en.wikipedia.org/wiki/Amdahl's_law a v Jave konkretne na fork/join http://blog.quibb.org/2010/03/jsr-166-the-java-forkjoin-framework/. 2010/8/3 Robert Novotny <robert.novo...@upjs.sk>: > Mna napr. zaujala poznamka z keynotu Josha Blocha z terajsieho Java > Language Summitu: > > In some circumstances it turns out that & is faster than && in Java, because > a && will short curcuit, which means it will branch. The single ampersand > will always execute both sides, which means the CPU can pipeline both of > them to execute at the same time. > > Ale originalna prezentacia nie je este k dispozicii, takze nie je mi celkom > jasne, ako sa to myslelo. > > RN > > > On 2. 8. 2010 20:57, Ondra Medek wrote: >>> >>> Takze >>> kdyz se nekomu podari "mikrooptimalizace" typu "prochazeni pole odzadu je >>> rychlejsi", v dalsim buildu JDK uz to nemusi fungovat. >> >> Ja bych jen doplnil konkretne k teto "optimalizaci": ono to nemusi byt >> rychlejsi vzdy. Zalezi, nejen na JVM, ale i jaka data se prochazi, >> typu cache a procesoru, a mozna dalsich faktorech. Tedy zrovna tato >> optimalizace je IMHO obecne naprosto zbytecna.(Mne osobne se lepe ctou >> for cykly od 1 do N.) Dobra je leda tak pro nejaky konkretni pripad, >> kde se opravdu nameri zrychleni. Tim nechci spoustet flame na tema >> rychlost prochazeni pole. Jen chci uvezt konkretni pripad, kdy je >> takova mikrooptimalizace zbytecna. >> >> Zpatky k tomu "instanceof": pouziva se to hojne v equals metodach, >> tedy bych se o rychlost nebal. Pravdepodobne se v kazde aplikaci vola >> tolikrat, ze nejake dalsi pridani uz nema vyznam. (kdyby to byla >> nejaka brzda, tak by se jiste nasel nekdo, kdy by se snazil equals >> implementovat jinak). >> >> P.S. pro Otu: ja jsem take z HPC sveta. >> > > -- S pozdravem Roman "Dagi" Pichlik /* http://dagblog.cz/ Blog pro kodery */
