Blog
Skip to end of metadata
Go to start of metadata

A DevX portálon a népszerű MythBusters sorozathoz híven körüljárták a több magból álló gépek teljesítményét, illetve teljesítményproblémáit. Első körben körüljárják az "Alkalmazásom lassú, de megmenti Moore törvénye" című mítoszt, amelyet sok fejlesztő használ mentségképp. Moore törvénye nagyjából azt mondja ki, hogy másfél évente megduplázódik az elektronikai berendezések sebessége. A fejlesztők pedig erősen támaszkodtak erre a folyamatra: egy három év alatt kifejlesztett programot úgy tervezhették meg, hogy a jelenleginél négyszer gyorsabb rendszeren fog futni, s erre igen sok példát találunk a játékfejlesztők háza táján, ahol gyakran túltervezik a játékok hardverigényét. Sajnos Moore törvénye irányt váltott, a gyártók nem tudnak könnyedén frekvenciát növelni, egy-két évvel ezelőtt megjelentek a többmagos processzorok, amelyek pont azonos órajelen dolgoztak, mint a tavalyi széria, csak több mag figyelt a lapkán... és az egy szálra megírt programunk csúfosan lassú lesz.

Gyakori kijelentés, hogy "Az Application Server majd skálázza a programom", amely szintén egy mítosz, s a Java Enterprise kiadása óta makacsul tartja magát a fejlesztők körében. Azonban az alkalmazás szerver csak akkor képes megfelelően skálázni a programunkat, ha azt úgy írjuk meg. Ha nem a célnak megfelelően írjuk meg, akkor egy olyan programokból álló halmazt kapunk, amelyek egymás lábába harapva próbálnak szóhoz jutni: az értékes processzoridőt pedig üzenetek továbbítására és lock-ok feloldására váró szálak közötti váltásra pazaroljuk.

Ha az AS mégse válna be, akkor a fejlesztők előkapják a cilinderből "A cluster majd megoldja a problémát" felíratú nyulat... sokszor hiába. A processzorok számát növelve az egyes processzorok hasznos teljesítménye jelentősen csökkenhet. A csökkenés mértékét Amdahl törvénye írja le, a mellékelt ábra szerint, aholis a szekvenciálisan (más szóval egy atomi műveletként) végrehajtott kód aránya szerint jelentősen romolhat a cluster teljesítménye. Már 1% ilyen kód esetén is 100 processzornál 50 processzor felesleges.

Ha a fejlesztők főnöke is ismeri a fenti tényeket, akkor a fejlesztők még mindig mondhatják, hogy "A párhuzamos rendszerekre nehéz fejleszteni", dehát ez is mítosz. Egyszerűen csak ismerni kell pár fogalmat (deadlock starvation, stb)... és minden szépen a helyére kerül. :)

      
      
Page viewed times

4 Comments

  1. Na ja, de mai napig pangás van a jó többszálas java programozást betanító könyvekből / kurzusokból. S attól, hogy elolvassa az ember Doug Lea concurrency utilityjeinek leírását, még nem fogja tudni őket rendesen használni. Nem is beszélve arról a kevés vagy hiánycikk ingyenes teljesítményelemző programokból, amelyek segíthetnének a többszálas kódunk elemzésében. Ja, és ami a legfontosabb: tutorial, ami megmutatja hogy kell az algoritmusokat párhuzamosítani - és nem csak a szinte sosem használt fibonacci algoritmusra.

  2. Nekem pár hete jött meg az amazonról a Java Concurrency in Practice c. könyv. Amennyit idáig beleolvasgattam, nem rossz...

    http://www.javaconcurrencyinpractice.com/

    1. Az ilyen konyvekbol kellene free verzio is, hogy ezek a mitoszok minel hamarabb felszivodhassanak.

  3. En oszinten szolva csak azt tudom mondani amit tanultam nem is olyan reg, sot inkabb idezek:

    Valóban, Amdahl törvénye csak azt mondja, hogy ha van egy rögzített méretű feladatunk, akkor egyre több processzort „rádobva” az elérhető gyorsulás korlátozott. A valós alkalmazási körülményeket jobban leíró érveléssel állt elő Gustafson 1988-ban, ő kiindulási alapnak azt választotta, hogy a felhasználók bizonyos időt hajlandók áldozni a program futtatására. Akkora méretü feladatot választanak, ami még kivárható időn belül megoldható, vagyis a párhuzamos futási időt kell adottnak tekinteni, nem a probléma méretét

    Ezek szerint az Amdahl törvénye nem tekinthető mérvadónak, akit tovabbi részletekre kiváncsi annak ajánlom a wikit ;-)

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))