Érdekes teszt érdekes eredményekkel. Csak MMX-re is kíváncsi vagyok, hogy 3DNow! nélkül hogy boldogulna a proci. Szerintem az MMX, SSE bőven elég lenne a prociknak, a többit meg optimalizálják ezekre a kódokra, vagy egyáltalán: optimalizáljanak. Amikor a sok fejlesztő lusta jól megírni a szoftvert, akkor nem a hardvert kéne az optimalizálatlan progikhoz igazítani, mert ettől nem fognak jobb belátásra térni a programozók. Inkább fordítva kellene tenni. Legfrissebb példám az 18 Wheels of Steel: Extreme Trucker nevű játék, amelyik egy belépőszintű videokártyán is gond nélkül kellene fusson (akár élsimítással is), de egy 8800 GTS-en is szaggat néha, a Fraps 2 és 85 között ugrál elég random módon. De van még jópár hasonló játék/program, ami elég szarul lett megírva.

Tanulságos.Azt gondoltam volna, hogy valamennyire skálázódott az egyre újjabb utasításkészletek teljesítménynövelő hatása.

A 3 test probléma nem megoldható.

Valószínűleg más programoknál jobban előjön a hatása, nem gondolom, hogy mindegyiket a videókódolásra hegyezték ki.

Köszönjük a cikket!

Remélem sikerült meggyőzni vele pár kétkedőt, hogy van kihatása a teljesítményre a SIMD utasításkészleteknek. De szerintem jó lett volna külön is kipróbálni az MMX és a 3DNow! hatását. ( Az MMX integer, a 3DNow! lebegőpontos utasításokat takar. )

Valamint nem jön be az ezer utasítás link.

[ Szerkesztve ]

Köszönjük, érdekes írás. Szerintem fontos, hogy újabb ilyen kiterjesztések kerűljenek a procikba, ha nem is várható jelentős előny tőlük egyből.

Manapság egy előnye van ha nem vagy szegény, színvonalasabb ellenségeid lehetnek

A tesztet ki akarom egesziteni, csak keresnem kell valamit, ami hajlando lefordulni minimum 4 modon: i386, mmx, sse, sse2

Metalfan: Nincs teljesen igazad. Az teny, hogy csak lapatoljak a kodot a programozok. Az optimalizacioval nem sokat torodnek, de a compilereknek pont ez lenne a dolga. A gcc-t en csak feluletesen ismerem, csak 1-2 tucat kapcsolojat hasznalom a nehany tucat/tucatbol. Ajanlom figyelmedbe a -O1, O2, O3, illetve --build=i386-linux-gnu kapcsolokat. P4-re optimalizalva peldaul a hosszu pipeline-hoz igazodva "kibontja" a folosleges ciklusokat. A kevesbb ugrasnak hala gyorsabb lesz a kod, ugyanakkor nagyobb is. Viszont a compiler sem mindenhato, azt is emberek irjak es az ujabb es ujabb kiterjesztesek nem teszik konnyuve a dolgukat.

Akosf: link javitva. Sajnos nem fordult le magaban csak MMX-el a libavcodec.

https://frescho.hu

ssh-val is kiprobaltam. Nincs ertelme boviteni a bejegzyest. i386 eseten 89.1MB/s a file atviteli sebesseg, MMX-el 95.8, sse2-vel 96.6. A ket veglet kozott kb 10% van. Mivel lenne erdemes meg tesztelni?

https://frescho.hu

Szerintem valamiféle fraktál generátorral lehetne jól lemérni, hogy melyik utasításkészlet mennyit is jelent. De sajnos nem ismerek ilyen programot. Meg az is igaz, hogy a kézzel optimalizált verziók lennének a legalkalmasabbak az összehasonlításra. Különben a fordító "képességei" erősen befolyásolnák az eredményt.

[ Szerkesztve ]

Povray-t akartam, de nem fordul le rendesen par CPU beallitassal.

https://frescho.hu