[SFIJ]

Idézet: Atti - Dátum: 2005. nov. 25., péntek - 19:39

Egy kis HT:

Hyperthreading hurts server performance, say developers

magyar cikk

mindenki tudja es mar a kezdeti meresek is bizonyitottak, hogy a P4 vonal 12kiloszonyi I$ cache-e nevettsegesen keves. mivel az l1 I$ a core resze, a xeonokba is ez kerul(t) kiszallitasra. a HT jol jon a fhotoshopban, egyket rafinaltan megirt videokodoloban, de sql szerverek, web szerverek, file szerverek eseten hasznalata ellenjavalt. ezt mar nagyon reg ota tudjak a szakmaban.

[special]

RWT Bensley preview part II:

http://realworldtech...RWT112905011743

40-120%-os fölény a Noconával szemben.

[bogdan]

Idézet: special - Dátum: 2005. nov. 29., kedd - 14:03

RWT Bensley preview part II:

hm.. eleg fura egy teszt!

Idézet

We do not have an AMD K8 system for comparison, nor would it be a particularly insightful; a cutting edge K8 system will likely be slightly dated by the time that Bensley arrives in the first quarter of 2006. Rather than estimating where AMD will be in the future, we will instead compare Bensley with a known quantity

micsoda egy farizeus duma!! raadasul az egyiket elvetni, mert ki tudja mi lesz kesobb, es e helyett egy mai rendszerrel osszevetni.. csak en erzem, hogy ez ellentmondas? es hogy higyjem (hidjem? higgyem? hm..) el, hogy azert nem vetik ossze, mert nem kap ki csunyan?? ehh!

Idézet

The most likely explanation is that the algorithms used in these applications were designed only to scale to a certain point.

raadasul ezt a suta magyarazatot sem kene bevetni, ha lenne egy 2 utas DC Opteron osszevetesnek! ne talalgassanak, hanem vessek ossze!

**********************************************************
a teszt amugy erdekes, koszonjuk! erdekes, hogy rendering-et is tesztelnek, ugy tunik megis fontos ez a resz is. erdekes, hogy a SPEC-bol csak az egyiket teszteltek, ez viszont nagyon gyanus! fura az a kitetel is, hogy a HTT-t kapcsoljuk be, hiszen szerverrol van szo. (nem reg volt ugye errol szo..)

es erdekes, hogy a renderingben milyen szerenyen teljesitett. ha nem jogos a "rosszul megirt algoritmus" felvetes (es nekem fura lenne, ha ket kulonbozo program ugyanugy nem jo!) akkor az az erdekes eredmeny jon ki, hogy pont abban veszit a legtobbet az Intel, amiben eddig volt elonye az Opteronnal szemben.

(es mielott valaki szemelyes tamadasnak venne ezeket: csak velemeny, nem vita akar lenni.)

[hvuk]

Idézet: special - Dátum: 2005. nov. 29., kedd - 13:03

RWT Bensley preview part II:

http://realworldtech...RWT112905011743

40-120%-os fölény a Noconával szemben.

Érdekes teszt. Bennem is felmerült azért egy-két gondolat (meg az RWT fórumon is). Miért pont ezek a benchmarkok kerültek be ebbe a tezstbe? És miért olyan nagy az átfedés az elõzõ benchmarkkal (Techcnhannel.de)? A SUNGuard meg a Black Scholes benchmarkok finoman szólva is noname benchmarkok voltak, amíg az Intel nem közölt eredményeket velük kapcsolatban. SPECint/fp miért maradt ki? Miért a jbb az egyetlen adat/web szerver teszt? Miért a totál használhatatlan Pov-Ray benchmarkot közölték valamilyen iparági szempontból is érdekes benchmark helyett? Miért csak grafikonon közölték az értékeket és miért nem írták mellé a konkrét értékeket? Ez így olyan, mintha ovódásoknak készítették volna. "Látjatok gyerekek, az Intel bácsi legújabb gépe ilyen hosszú csíkot tud, a régi meg csak ilyen hosszút!".

Nem a teszt hitelességét kérdõjelezem meg, vagy degradálni akarom az eredményeket, mert ezek az adatok impresszívek (bár persze a Noconához képest nem nehéz jónak lenni ), csak gondoltam ismertetem a furcsaságokat.

Érdekes mellesleg, hogy az RWT ugyanúgy nem hallott róla, hogy rendering teszteket nem szabad betenni (fújj, csúnya rendering teszt, köpöd ki! - mondták nekik a speciális tanfolyamon ) és hótt lazán berakták. Azt mindenesetre leszûrtem, hogy az RWT semmivel sem készít jobb teszteket, mint a GamePC.

[SFIJ]

Idézet: RealWorldtech

Fortunately, Intel was kind enough to provide us with a Bensley platform development kit (PDK) for benchmarking purposes.

ugyanmar gyerekek nem tunik fel nektek, hogy ez nem teszt, hanem fizetett kereskedelmi hirdetes? Ezt Tom bacsi vitte a csucsra: product vendorkent minel jobban megkented annal jobban elhuzott a te productod a mezonytol Ha a zintelnek telleg van utos cucca akkor submittal egy rendes gepet egy spec-re, vagy lefuttat es kozol egy "felhivatalos" spec-et.

Szerkesztette: SFIJ 2005. 11. 29. 16:39 -kor

[bogdan]

Idézet: hvuk - Dátum: 2005. nov. 29., kedd - 17:08

(meg az RWT fórumon is).

azt hogy erem el ennel a cikknel? (bena, hogy nincs a cikk mellol belinkelve. igy a 21. szazadban??) szerk: megtalaltam. azert az elso (es egyetlen?) hozzaszolas nagyon kemeny! ugy gondoltam bemasolom ide okulaskeppen, hogy folyik az ilyen vita a "nagyon" kozott..

Idézet: Armand Hirt

SunGuard was also used in the previously published Tecchannel.de Bensley benchmark (as were Cinebench and POV_Ray), and you explain that the Block-Scholes computational Kernel was also provided by Intel.

What motivated you in this choice of applications? From reading the article, I get the impression that the system came together with Intel-recommended benchmarks, that you installed and ran. Is that what happened? Was SPECjbb2005 also part of the "package"? And finally, was the availability of the system explicitely tied to the release of those benchmark figures? Or were you free to choose any benchmark?

Idézet: hvuk

Miért a totál használhatatlan Pov-Ray benchmarkot közölték valamilyen iparági szempontból is érdekes benchmark helyett?

d n.r baratommal mar folytattunk errol vitat, es o mint hozzaerto is kifejtette, hogy marhasag a Pov-Ray-t benchmarkolni. egyfelol ezt elfogadom, masfelol azert van elonye is: mint nyilt program azonnal portolva van mindenhova (masik 64 bites renderelo van? nem tudom, ezert kerdezem, de sokaig nem volt!), raadasul meg operacios rendszerek kozotti osszevetesre is jo. azaz nem iparagi szabvany, de osszevetesre szerintem megfelel. (es kizartnak tartom, hogy 2 thread felett ne skalazodna jol pont ezert!!)

Idézet

Miért csak grafikonon közölték az értékeket és miért nem írták mellé a konkrét értékeket?

nem szep, de azert leolvashatoak az ertekek. ennyire ne kekeckedjunk mar! (mondom en.. )

Idézet

Érdekes mellesleg, hogy az RWT ugyanúgy nem hallott róla, hogy rendering teszteket nem szabad betenni

amiota special-al vitaztam errol, az SGI honlapjan lattam, hogy van egy koztes kategoria (se nem WS se nem szerver), amikor kifejezetten digital context creation-ra hoznak letre cluster szeru architekturakat, es deskside meretu (azaz nagy, de iroasztal melleti gep) dobozokban aruljak. ennek az iranynak egyebkent sok hive van (Orion-Transmeta lehetett az egyik elso, de sokan kovetik), az utolso billgejc, a SC-on tartott beszedevel. igy egyaltalan nem meglepo, ha ilyeneket is merunk ezeken.

Idézet

Azt mindenesetre leszûrtem, hogy az RWT semmivel sem készít jobb teszteket, mint a GamePC.

ha a hozzaszolas elet elvesszuk, azt hiszem ez igy teljes mertekig korrekt!

**************************************************
SFIJ: persze, van ilyen, de az a szep mesterseg, ha meg az ilyenekbol is tud az ember hasznos infokat kihuzni. ha nem abbol, amit olvas, akkor abbol, amit elhallgatnak.

Szerkesztette: bogdan 2005. 11. 29. 16:52 -kor

[bogdan]

"gyerekek", gyongyszemre leltem! elozmeny: egy cikkhez valaki elso hozzaszolaskent szereny negativ kritikat fejt ki. egy masik forumozo nehezmenyezi, hogy a negativ velemenyehez kepes volt regisztralni. a cikk irojanak a reakcioja:

Idézet: special - Dátum: 2003. dec. 17., szerda - 17:58

Szerintem jó, hogy beregelt, és elmondta a véleményét, még ha nem is értünk vele egyet. A különbözõ álláspontokat megismerni kell, nem üldözni.

   

persze ez volt az elso cikke, es had gratulaljak utolag is hozza, tenyleg nagyon jo! (atolvasva kis pontositas: termeszetesen az ujabb cikkek is jok!)

[d n . r]

Idézet: bogdan - Dátum: 2005. nov. 29., kedd - 17:39

masik 64 bites renderelo van? nem tudom, ezert kerdezem, de sokaig nem volt!

Van, és már _régóta_, ráadásul a lehetõ legprofesszionálisabb (küldtem már régebben róla levelet is)

Mental Ray a neve (pár éve már integráns része a Maya-nak is, a 3dsmaxnak is), persze a 64bit egyelõre csak linux-on (és fogalmam sincs, hogy akkor miért nem ezzel tesztelnek, még akkor _sem_, amikor kimondottan 64bites tesztrõl van szó, és linuxról - nem egy példát láttam már erre)

(sõt, IA-64es verzió is van, ott ráadásul emlékeim szerint Windows-ra is )

És nyilván a Pixar Renderman is az, csak az nem érdekelt akkor annyira, és nem néztem utána.

(A filmes munkáknál kb. 90%ban ezt a két programot használják, de ezt LY tudná megmondani)

És bár az év végére már több windows-os 3dsmax renderelõplugint is ígértek 64 bitesnek - egyelõre nem tudok róla, hogy ez megtörtént volna.

PS: én továbbra sem tulajdonítok túl nagy jelentõséget a Pov-raynek.

Mellesleg emlékeim szerint a Pov-rayben _nem_ a Xeon szokott domborítani, hanem az Opteron.

[SFIJ]

dn. r kartács. Brazil? Shake?

[bogdan]

mivel itt x86-64 windows alatt teszteltek, egyertelmuen erre a platformra kerdeztem ra. (bar koszonom a tajekoztatast.) igy viszont nem meglepo, hogy x86-64 windows alatt a Pov_Ray-el tesztelnek, ugye? (mivel az meg mindig ismertebb program a laikusok szemeben, mint a "Pixar Renderman", amirol en eletemben eloszor hallok. itt talan reprezentalom a laikus olvasokozonseget )

****************************
latom SFIJ is bekapcsolodott.. en (szakmaja miatt) ebben a kerdesben d n.r velemenyet kell, hogy elfogadjam, es kivancsian varom a valaszt!

[d n . r]

Idézet: bogdan - Dátum: 2005. nov. 30., szerda - 0:56

igy viszont nem meglepo, hogy x86-64 windows alatt a Pov_Ray-el tesztelnek, ugye? (mivel az meg mindig ismertebb program a laikusok szemeben, mint a "Pixar Renderman", amirol en eletemben eloszor hallok. itt talan reprezentalom a laikus olvasokozonseget )

Ettõl még ugyanúgy meglepõ.
_Számomra_ inkább teszteljenek 32 bites verzióval, mint valamivel, aminek számomra semmi relevanciája.

Másrészt a Pixar-ról azért remélem hallotál már...
Na az össes filmjük ezzel készült (és még egy jó csomó más)

És bocs, de épp arról ment az érvelés, hogy igenis relevánsak egy szerver/workstation tesztben a renderer-programok. Hidd el, _akiknek_ relevánsak, azok hallottak a mental ray-rõl és a rendermanrõl.

* * * *

A brazil az egyik plug-in, amirõl úgy tudom, lesz az idén 64bites verzió win-re (a v-ray meg a másik)

A shake viszont tudtommal nem renderelõ program, hanem kompozitáló (de nem használtam még)

Szerkesztette: d n . r 2005. 11. 30. 09:26 -kor

[bogdan]

nagyon erdekes velemenycsere alakult ki a RWT foruman a fenti cikkel kapcsolatban. pro es kontra is erdekes velemenyek vannak, es bar nekem az az erzesem, hogy a szerzo azert kicsit sumakol (meg ne kovezzetek, ez nem vad, csak erzes, de hat az alap kerdesre, hogy pontosan milyen tesztet is tanacsolt futtatni az Intel csak nem valaszolt.. bar lehet, hogy hamarosan megteszi), mindenkeppen erdemes elolvasni!

(egyebkent csak engem idegesit, hogy minden egyes 2 soros hozzaszolashoz egy uj lapot kell megnyitni?? )

a konkluzio azert remenytkelto az itteni vitankhoz is:

Idézet: David Kanter

Look for some new Benchmark Examiner articles in the future...

*************************************
d n.r: most latom, hogy az egesz teszt 32 bites windows-on fut, ugyhogy a cikkbeli "POV-Ray 3.7 is a beta version that adds SMP, SMT and x86-64 support to version 3.6" mondat eleg felrevezeto. igy tenyleg nem ertem, miert nem valami elfogadhatobbal teszteltek. (amugy meg hiaba ismerek egy ceget -- Pixar --, abbol meg miert kovetkezne, hogy ismerem a programjukat?)

[hvuk]

Idézet: bogdan - Dátum: 2005. nov. 30., szerda - 12:49

(egyebkent csak engem idegesit, hogy minden egyes 2 soros hozzaszolashoz egy uj lapot kell megnyitni?? )

Igen, vannak ilyen hülye fórumok, amik így mûködnek, elõnyük, hogy jól látszik, hogy ki mire válaszolt, hátrányuk, hogy baromi lassan olvasható. Szerintem is zavaró, jó lenne, ha lenne olyan opció, hogy az egész thread egyben olvasható legyen.

Idézet

d n.r: most latom, hogy az egesz teszt 32 bites windows-on fut, ugyhogy a cikkbeli "POV-Ray 3.7 is a beta version that adds SMP, SMT and x86-64 support to version 3.6" mondat eleg felrevezeto. igy tenyleg nem ertem, miert nem valami elfogadhatobbal teszteltek. (amugy meg hiaba ismerek egy ceget -- Pixar --, abbol meg miert kovetkezne, hogy ismerem a programjukat?)

Bocsi, de totál irreleváns, hogy te mit ismersz, a lényeg, hogy az iparban használt progikkal teszteljenek. A POV nem ilyen, azt tudtommal gyakorlatilag senki sem használja. Épp ezért a renderelõ szoftverek teljesítményének mérésére nem igazán alkalmas. Ráadásul eddigi verzió nem tudták az SSE2-t meg a 64 bitet, így még a processzor teljesítményének mérésére sem volt igazán alkalmas.

[bogdan]

Idézet: hvuk - Dátum: 2005. nov. 30., szerda - 14:16

Bocsi, de totál irreleváns, hogy te mit ismersz, a lényeg, hogy az iparban használt progikkal teszteljenek.

vegulis en is azt irtam, hogy jobb lenne, ha azzal tesztelnenek, nem?

Idézet

A POV nem ilyen, azt tudtommal gyakorlatilag senki sem használja. Épp ezért a renderelõ szoftverek teljesítményének mérésére nem igazán alkalmas.

felhivnam a figyelmedet, hogy ez egy hibas logikai kovetkeztetes! (ami persze nem zarja ki, hogy igaz legyen, am en nem igy gondolom: szerintem arra, hogy egy adott platform valtoztatasa, amirol itt is volt szo, hogyan befolyasolja a renderelok teljesitmenyet meg jo lehet.)

Idézet

Ráadásul eddigi verzió nem tudták az SSE2-t meg a 64 bitet

a 64 bitet mar regesreg ota tudja! ja, hogy csak a unix-os verzio? de hat nem is volt 64 bites windows akkor.. ugy meg minek? az sse tamogatasokat nem tudom, azt nem talalom a honlapon.

[SFIJ]

Idézet: hvuk - Dátum: 2005. nov. 30., szerda - 13:16

Ráadásul eddigi verzió nem tudták az SSE2-t meg a 64 bitet, így még a processzor teljesítményének mérésére sem volt igazán alkalmas.

IEEE1080 64-bites lebegopottyos aritmetikat hasznalt mindig is a POW. Ez a mostani "64" bitesseg kicsit csaloka. mar i387-ota a lebegopottyos matek proci 64-bites valosokkal szamol. sot, van egy 80 bites BCD modja is .

[bogdan]

Idézet: SFIJ - Dátum: 2005. nov. 30., szerda - 15:38

IEEE1080 64-bites lebegopottyos aritmetikat hasznalt mindig is a POW. Ez a mostani "64" bitesseg kicsit csaloka. mar i387-ota a lebegopottyos matek proci 64-bites valosokkal szamol. sot, van egy 80 bites BCD modja is .

ÖÖÖÖ... biztos, hogy a 64 bites operacios rendszerek altal tamogatott 64 bites binarisokrol beszelsz Te is? 

[SFIJ]

Idézet: bogdan - Dátum: 2005. nov. 30., szerda - 15:05

ÖÖÖÖ... biztos, hogy a 64 bites operacios rendszerek altal tamogatott 64 bites binarisokrol beszelsz Te is? 

az AMD64/EMT64 ujdonsaga az integer 64 bitesseg es a 64 bites virtualis cimtartomany. ami a lebegopontossagot illeti abban mar 1985 ota (i386) 64/80 bites az IA32. egy raytracer mindig is lebegopontos szamitasokat vegez, gyakorlatice semmit nem profital a mostani "64" bitessegbol - hacsak azt nem, hogy bizonyos esetekben (egyszeru setup, nem tul bonyolult vilagitas) SSE implementaciok is elkepzelhetoek, amik meg 32 bitesek akar IA32 akar AMD64 akar EMT64 ISA-t hasznalsz. A standard 4k-s moziformatum is lazan kezelheto 32 bites cimzessel.   Esetleges gyorsulast AMD64/EMt64 esetileg az extra 8 XMM regiszter megjelenese hozhat.

[bogdan]

igen, ezek nagy vonalakban eddig is vilagosak voltak (de sosem art egy kicsit reszletesebb ismetles). en amugy csak hvuk felvetesere valaszoltam, aki kifogasolta a 64 bites binarisok nem-megletet. hogy ezt miert tette, azt Tole kerdezd.

az SSE-k egyebkent tenyleg csak 32 bitesek? mert olyat talaltam a honlapon, hogy a 3DNow-ot nem tamogatja, es nem is fogja, mert az nem dupla pontossagu, okelme meg mindig abban szamol. egyebkent ha az SSEx 32 bites, akkor megeri vele szamolni? (van 4x gyorsabb, mint a sima fpu?)

[SFIJ]

Idézet: bogdan - Dátum: 2005. nov. 30., szerda - 15:20

igen, ezek nagy vonalakban eddig is vilagosak voltak (de sosem art egy kicsit reszletesebb ismetles). en amugy csak hvuk felvetesere valaszoltam, aki kifogasolta a 64 bites binarisok nem-megletet. hogy ezt miert tette, azt Tole kerdezd.

az SSE-k egyebkent tenyleg csak 32 bitesek? mert olyat talaltam a honlapon, hogy a 3DNow-ot nem tamogatja, es nem is fogja, mert az nem dupla pontossagu, okelme meg mindig abban szamol. egyebkent ha az SSEx 32 bites, akkor megeri vele szamolni? (van 4x gyorsabb, mint a sima fpu?)

az SSE vektorutasitasokat kezel. a 64 bites FPU regisztert (XMM) particionalhatod 2x32, 4x16, vagy 8x8 meretre igy 2 regiszter szorzasakor rendre 2, 4, 8 szorzas hajtodik vegre egy idoben. persze, hogy megeri vele szamolni. ha tudsz a feladat szempontjabol kielegito pontossagu float/integer aritmetikat csinalni akkor 2x, 4x, 8x-ra gyorsithatod a muveletvegzest. azert "multimedia extension" mert a nagy pontossagu mernoki gyakorlat szempontjabol nem kielegito a pontossag. de videogame/DVD/mp3 lejatszasara ellenben tokeletes.

a 3dnow-nak van egy olyan limitacioja, hogy nem hasznalhatod egy idoben az XMM es az FP regiszter file-t. Az SSE eseteben nincs ilyen korlatozas, egyszerre hasznalhatod az RPN szemantikaju FP regiszter file-t es az XMM regisztereket.

Fontos latni, hogy nem "gyorsabb" mint a sima FPU, hanem arraol van szo, hogy a pontossagot bealdozva, az FPU VEi felszeletelhetoek diszjunkt reszekre, igy egyidoben dupla, 4x, 8x annyi szamitas vegezheto el, igaz megkotesekkel(egynemu muveletek)

Szerkesztette: SFIJ 2005. 11. 30. 16:03 -kor

[hvuk]

Idézet: SFIJ - Dátum: 2005. nov. 30., szerda - 14:38

IEEE1080 64-bites lebegopottyos aritmetikat hasznalt mindig is a POW. Ez a mostani "64" bitesseg kicsit csaloka. mar i387-ota a lebegopottyos matek proci 64-bites valosokkal szamol. sot, van egy 80 bites BCD modja is .

Ezt én is tudtam, de nem erre gondoltam a 64 bitesség alatt, hanem az extra regiszterekre, amiket persze késõbb te is írtál. Nyilván az SSE2-tõl várható a legnagyobb gyorsulás, a plussz regiszterektõl már kevesebb.

Szerintem az SSE2 különben 2 64 bites lebegõpontos számot tud kezelni egyszerre, 4 32 bitest, nem pedig 2 32 bitest, mint ahogy te írtad. NEm tudom, hogy ez szorzás esetén is igaz, +/- esetén biztos az. De jó eséllyel szorzásra is igaz.

Upd: most látom, hogy te SSE-rõl beszélsz, én meg SSE2-rõl beszélek.

Szerkesztette: hvuk 2005. 11. 30. 16:33 -kor