Jak to Josh Bloch myslel nevim, ale ze & muze byt rychlejsi nez && me neprekvapuje. Pri pouziti & procesor muze vyhodnocovat operandy paralelne, zatimco u && musi pockat, jak dopadne vyhodnoceni prvniho operandu. Takze pokud jsou operandy nezavisle a procesor vicejadrovy, tak to bude mozna i docela caste.
Z. -- Zdenek Tronicek FIT CTU in Prague Robert Novotny napsal(a): > 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. >> > >
