Naprostý souhlas.
Musím ovšem přiznat, že takhle jsem se na to nedíval vždycky.
Tak před 15 lety jsem se bavil vědeckými výpočty v C++. V jistém období
jsem se skutečně seriózně zabýval tím, jak rychlá bude která konstrukce
a co by se tedy mělo používat. Dokonce jsem tentýž kód nechal na zkoušku
přeložit několika různými překladači, u některých jsem zkusil i více
různých nastavení, a viděl jsem opravdu značný rozptyl. Navíc tehdy
překladače procházely vcelku překotnými inovacemi. Chvíli jsem o tom
přemýšlel, něco si o tom přečetl, a usoudil jsem, že to je prostě hrozně
složité a proměnlivé.
_Naštěstí_ jsem zrovna tehdy začal řešit otázku předání projektu
kolegovi a začal jsem se na kód dívat tak trochu jeho očima. Rázem mi
bylo jasné, že utápím svůj čas ve věcech, které nikoho nevytrhnou, ale
zato můžou jiným významně komplikovat život. To jsem si začal připadat
jako mizerný úředník, což nikdy nebyla moje aspirace.
Od té doby programuji čím dál objektověji a optimalizací se zabývám, jen
když je s rychlostí opravdový reálný problém. V takovém případě je ale
nutné předělat návrh, nikoli detaily implementace.
maxipes
Dne 3.8.2010 11:39, Roman Pichlík napsal:
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/.
