Ha teljesítmény kell, akkor ...

Programozás

event-based programmingot használok
15% (37 szavazat)
threadeket használok
28% (71 szavazat)
a kettő keverékét használom
29% (74 szavazat)
egyéb, leírom hozzászólásban
27% (69 szavazat)
Összes szavazat: 251

( dj | 2011. 05. 11., sze – 16:13 )

Már van 4- egyéb, leírom a hozzászólásban- szavazat, de hozzászólás egy sem :) Most akkor mi van?
Egyébként ha több teljesítmény kell, akkor több memória, erősebb proci, jobb vga szemlélet nagyon gáz? :) Mert van egy pár ilyen program, ahol az "egy egyszerű lekérdezés 15 percig fut, ez normális?" kérdésre a supportos kolléga a fenti válaszok egyikét adja.

( emberk | 2011. 05. 11., sze – 16:22 )

A matek modulokat többnyire thread-elem, mert ott más mód nem nagyon van. Vagy egyszerre többet indítok ugyanabból a programból, ha több eredmény is kell. Feladat függvénye.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Igen de én nem hálózattal foglalkozok. Numerkus matematika a fő profilom, és a kérdésből nem derült ki, hogy mire vonatkozik. Nekem a teljesítmény általában egy eredméyben nílvánul meg. El nem tudtam képzelni, hogy eseményvezérléssel hogyan tudok pl egy integrált gyorsabban megoldani.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Persze, igaz. Csak az ember kapásból a saját dolgaira vonatkoztat. De a kérdésfeltevés ettől függetlenül szerintem túl általános. Mivel az én munkámmal eseményvezérléssel továbbra sem tudom elképzelni, hogy ha pl 1 szálon fut egy dolog, akkor hogyan lehet tempót nyerni. Többnyier betöltök egy mátrixot(sokszor az is komplex) a memóriába és azon csillió sajnos az esetek 99%-ban egymásra épülő művelet, majd az eredményt kiirom egy file-ba. Ami mondjuk egy png-kép.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

pl egy hosszú, sok zárójeles egyenletet lehet rakni event queue-ba , így a zárójeles tagok párhuzamosan elkezdhetnek futni, majd amint egy felsőbb szint alatti zárójeles egyenlet feloldásra került, eseményt küld, amint beérkezik az összes esemény az adott felsőbb szintű ágba, feloldja az alatta lévő eseményláncot. Így dinamikusan lehet kihasználni a sok processzoros környezetet egy egyenlet esetében.
Akár komplett interpretert is lehet írni ilyen célra (sőt, van is).
A lényeg hogy egy fa struktúra szerint automatikusan lebontja az egyenletet a lehető legoptimálisabban (pl mindig kihasználva a 4 magot)

Értem. Ilyet még nem csináltam. Ötletesnek tűnik. Általában én a líneárasan független vektortér pozitív tulajdonságát szoktam kihasználni, miszerint vektorokra bontom a mátrixot, így az egyes vektorokat egyesével thread-ba pakolom, és hajrá. Amint elkészült egy szál kapja a következő vektort. De ezek szerint ez is mehet event queue-ba. Az eredmény ugyanaz lesz. valamit szoktam olyan huncutságot is csinálni, ha van elég memória, és úgyis sok eredmény kell, akkor nem vacakolok a thread irkálással (sokkal gyorsabban megírom a primitív kódot alapon nyerek ídőt), hanem annyi külön programot indítok, ahány mag van, ha leáltt egy program a script indítja a következőt. Gyakran ez utóbbai a leggyorsabb. De ezt a sokzárójeles egyenletet megoldót ki fogom próbálni. Most pont lesz egy ilyen, ahol konvolúciót kell számolnom, egy borzasztóan hülye komplex függvény s egy digitális hologram (ami ugye megint csak egy komplex függvény) kölcsönhatásánál.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Nem csak zárójelesre jó, csak példaként hoztam fel, hogy a zárójelek a fa egy-egy ágai, majd az eventeket böngészve nézi, hogy az adott zárójelben lévő egyéb ágaknak van-e már eredménye, ha van, akkor ő is végrehajtja a megfelelő műveleteket. Mivel mindenki egy-egy esemény, egy ütemező figyelgeti hogy kinek milyen függősége van, így végigpörgeti magát a fán. (pont ezért lehet jól skálázni több magos rendszereken, mivel ha az ember kellően sok tagra bontja, akkor mindig lehet úgy hajtani akár egy 64 magos gépet is, hogy ameddig van elég feloldani kívánt művelet, az összes mag pörögjön).

Az nginx-et pont ezért hoztam példának, mert ott a megoldandó zárójelek helyett az adatok kiküldése és fogadása, feldolgozása viszi az időt, ami esetünkben teljesen lényegtelen, mivel ebben az esetben csak annyi a lényeges, hogy processzor időt igényel mind.

Értem, értem. Csak a zárójelezéses példád pont beletrafált az egyik melómba. Mindent amit részben függetelen elemi modulok sokaságára lehet bontani, és a műveleti sorrendet betartani, lehet így megoldani.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

( uid_15426 | 2011. 05. 11., sze – 16:53 )

Megintcsak rossz kerdes :) Termeszetesen feladattol fugg.

Ha pl. elolvassatok ezt : http://www.cs.bris.ac.uk/Teaching/Resources/COMS35101/resources/berkele… , akkor latszik, hogy hol nem jok a threadek. Az event-driven programming meg ugye akkor jo, ha elore nem lathato esemenyek vannak, ami mondjuk egy renderelesi feladatnal kevesbe fordulnak elo :)

----------------------
while (!sleep) sheep++;

( nihilist | 2011. 05. 11., sze – 17:00 )

Aszinkron végrehajtás, threadek (nem a végtelenségig) és queue-k.

( sibidiba | 2011. 05. 11., sze – 17:01 )

Egyéb: Az adott feladatnak, környezetnek, tipikus használati eseteknek megfelelő modellre törekszem, mint mindig.

(Az ökölszabályok nem sokat segítenek.)

--
The Net is indeed vast and infinite...
http://gablog.eu

( uid_194 | 2011. 05. 11., sze – 17:26 )

Distributed, threaded event-based programmingot hasznalok, redundanciaval es web-scale megoldasokkal otvozve.
</buzzword-bingo>

--
|8]

( DieHappy | 2011. 05. 11., sze – 17:47 )

Thread, abbol is csak a legegyszerubb megoldasok. Nem akarom tulbonyolitani a programomat, mert be kell valljam, orulok, hogy mukodik, es eddig ertem is, hogy mit csinal (egyelore pontosan azt, amit szeretnek :P).

( gabor v | 2011. 05. 11., sze – 18:29 )

Először is profile-olok és megkeresem a bottleneck-et. (Szépen magyarul.)

( madtone11 | 2011. 05. 11., sze – 20:48 )

Hogy egy professzoromat idézzem: "A hardver nem kerül pénzbe." :)
Nyilvánvalóan ezt nem úgy kell értelmezni, hogy ész nélkül lehet az erőforrásokat pazarolni, de néha a legjobb megoldás a hardverfejlesztés.

Idézek a keddi newtech meetupról: a szoftver a király! Új hardvert tolni a cuccos alá, és ezzel elérni talán 50-60%-os gyorsulást, vagy normálisan megírni, és optimalizálni, és ezzel adott esetben elérni 8-10-szeres gyorsulást nagyon nem mindegy. ;)
A hardver persze olcsóbb, mint egy jó mérnök fizetése, ez tény. :)
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Valahol, egy másik szavazás kapcsán pár hete erre is fény derült. Ott egyik fórumtársunk azt írta hogy őt kifejezetten idegesíti a jobb oldalon lévő szavazóbox ha nincs kitöltve.
Van ilyen is...
- - - - - - - - - - - - - - - - - - - - - - - - -
- - -> Kérjük a humoros aláírást itt elhelyezni. <- - -

Akkor a kérdés rosszul van feltéve, mert CSAK és KIZÁRÓLAG teljesítményről volt szó.

Most egy webszerver nyilván nagy teljesítményt ad le. De egy atombomba, földrengés vagy részecske szimuláció nagyobb teljesítményt igényel, már ha még ebben az évszázadban akarsz legalább részeredményeket látni.

Általában ezeket multi-threades alkalmazásokkal számolják.

--
GPLv3-as hozzászólás.

( 2Geza | 2011. 05. 12., cs – 13:36 )

Ha teljesítmény kell, akkor teljesítményre optimalizálok. Elég sok módja van :-).

( kubi | 2011. 05. 12., cs – 19:39 )

Jol leirom az otletet, aztan majd implementalja valaki.