[HWSW]

Megbüntette nagyzolásáért az Oracle-t a Transaction Porcessing Performance Council, mely iparágilag elfogadott szerverteljesítmény-teszteket dolgoz ki és felügyeli az eredményeket.
http://www.hwsw.hu/h...parc-power.html' target='_blank'>http://www.hwsw.hu/h...parc-power.html

[dtracer]

"Tekintve, hogy a TPC-C egy kifejezetten I/O limitált feladat, ahol a diszkalrendszer mûveleti sebessége és a rendszerben található sávszélességek határozzák meg a teljesítményt, a Sunnak és az Oracle-nek négyszer annyi maggal és szállal jó eséllyel sikerülhet megvernie az IBM-et."

Akkor az I/O-korlátos (ugye így, magyarul) feladat hoz minél több CPU kell?

[Poetro]

Ha I/O korlátos akkor a proci sebessége azért annyit nem számít, amíg nem lesz újra CPU limitált a feladat.

[special]

@dtracer: jogos kifogás, nem elég világos, van benne gondolati ugrás. kiegészítem ennek megfelelõen.

[bogdan]

"Tekintve, hogy a TPC-C egy kifejezetten I/O limitált feladat, ahol a diszkalrendszer mûveleti sebessége és a rendszerben realizálható sávszélességek határozzák meg a teljesítményt, a  Sunnak és az Oracle-nek négyszer annyi maggal és szállal eséllyel sikerülhet megvernie az IBM-et a magasabb mûveleti párhuzamosság révén."

ez tovabbra sem stimmel. mit is ertesz "muveleti parhuzamossag" alatt? ha vegrehajtasi muveletet, akkor az irrelevans. ha io muveletet, az meg mitol valtozna szignifikansan tobb szal eseten?

[special]

@bogdan: i/o és memória. attól változik meg szignifikánsan, hogy minél több szálad van, annál több egyidejû I/O és memóriamûveletet tudsz kezelni, jelen esetben az egyidejûleg végrehajtott tranzakciók száma, és rajtuk keresztül a konkurens I/O és memóriamûveletek száma ugrik meg. ha nem fogy el az effektív sávszélesség vagy nem szaturálódnak ezek a buszok az egyidejû (kint lévõ, outstanding) mûveletekkel, akkor a rendszer párhuzamosságának fokozása hasznos.

ha vesszük a niagarát, akkor szerint érthetõ, mirõl beszélek, mikor azt mondom, hogy I/O és memórialimitált környezetben teljesít jól a sok maggal és szállal, mégpedig azért, mert megnöveli a I/O és memória mûveletvégzési párhuzamosságot, így javítja ezen alrendszerek kihasználtságát.

de most jövök rá, hogy mi is lehet a gond. az I/O- és memórialimit alatt késleltetést értettem, pedig kézenfekvõ, hogy sávszélesség is lehetne. reszelem még.

[bogdan]

csakhogy ha io limitalt, az pont azt jelenti, hogy szaturalodik. ergo nem nyersz vele. (igen, jogos, hogy a savszelesseg szaturacio es a latency nem jar egyutt, de ha io limitalt, az mar a savszelesseg telitettseget jelzi, onnan mar nem segit a tobb muvelet. valojaban ha szamitaslimitalt a kornyezet, ott segithet a parhuzamossag az io muveletekben.)

a niagara valoban io es memorialimitalt kornyezetben teljesit jol, de nem io es memoriamuveletekben, hanem szamitasi muveletekben, mert a tobb szal a cache-bol dolgozik. nem kene szerintem idekeverni.

ergo szerintem tovabbra is hibas, amit irsz sajnos.

Szerkesztette: bogdan 2009. 10. 02. 10:24 -kor