BGAFC Vendégkönyv

Σ: 1 post

saxus (statz)

#9, Agyfasz (419)

2714 | #1bce | ^ | Idézet | Mon, 16 Apr 2012 00:06:38 +02

84.3.*.*

*.catv.pool.telekom.hu

TCH írta/wrote:
tudtommal prímet úgy keresünk, hogy a gyökéig elosztjuk minden számmal és ha nincs maradék nélküli, akkor prím, so no tömbök.)

Vannak jobb módszerek is, pl. tesztelési módszerek, amely adott valószínűség mellett mondja meg, hogy prím-e vagy sem. Az osztogatásos módszer elég favágó módszer. Fejből meg nem mondom mi az algoritmus neve, majd megkeresem.

Egyébként menedzselt nyevleknél arra jöttem rá, hogy NAGYON nem érdemes előre optimalizálni. Először a feladatot triviálisan megoldó kódot érdemes megírni (természetesen, az adatstruktúrákat értelmesen kell megtervezni), majd utána, ha valahol nem stimmel valami, akkor szigorúan profileing után (mert valószínűleg hamarább hoz ki elvi hibát) benchmarkolni. Miután a jittereket (és a sima statikus fordítókat is egyre okosítják -) felkészítik arra, amit tipikusan írnak az emberek, így egy-egy mikrooptimalizációval sokszor sokkal-sokkal többet árt az ember.

http://tothviktor.wordpress.com/2011/08/22/mikro-optimalizacio-i/
http://tothviktor.wordpress.com/2011/08/23/if-vs-switch/

További érdekességek:

http://tothviktor.wordpress.com/2011/08/27/stringinternal/
http://tothviktor.wordpress.com/2011/12/13/jitter_inlining/

Külön kiemelném, a stringekkel foglalkozó cikket, amely jól bemutatja, hogy miért nem feltétlen szabad hinni a régi ökölszabályoknak. (Erre tudnám hozni példának azt, amikor múltkor az FSZEK-ben mászkáltam, aztán belefutottam egy "Hatékony .NET" című könycbe. Belelapoztam, majd mikor megláttam azt a fejezetet, ahol azt fejtegetik, hogy ne használjunk propertyket, hanem mindig az adattagot publikáljuk ki inkább, tettem is vissza a könyvet a polcra. Ezeket ugyanis, mind a Java, mind a .NET jól kioptimalizálja én meg nem vagyok hajlandó feláldozni azt a biztonságot, amit nyújt - főleg egy többtagú csapat esetén - pl. egy private setter. Ugyanis, aki csak a kódot látja, az nem feltétlen fog tudni arról, hogy azt nem kellene csak úgy írkálni, hanem mondjuk van rá SetLofasz() metódus.

(És akkor még nem beszéltünk a processzornak a mindenféle optimalizációs trükkje, ami mikroarchitektúránként változik.)

Java esetén egyébként nem tudom mi a helyzet, de a tapasztalatom az, hogy ott is lehet gyors dolgot fejleszteni, csak akarni kell. Persze, ott is keresztbe lehet tenni a JIT-ternek meg van pár dolgom, amiben van fenntartásom a nyelvvel. Viszont a tapasztalat az, hogy sok esetben egyszerűen nem éri meg az a plusz időráfordítás, amely a gyorsabb kód fejlesztéséhez kell. Java HotSwap meg <333333 (igazán átemelhetnék a .NET-be is, infrastruktúra igazából félig adott lenne hozzá).

A különféle C fordítók rigolyái meg önmagában egy érdekes témakör.