[SFIJ]

Idézet: bogdan - Dátum: 2005. nov. 24., csütörtök - 16:56

hvuk: az OGL-nel elfelejted, hogy a WS piacon elegge erosen jelen van, es a bovulo Linux (gyengen, de ugyancsak kezd jelen lenni a WS-eken) sem a DX-et tamogatja. a profi videokartyakhoz nem is biztos, hogy van DX-es driver! de majd egy hozzabberto kifejti, hogy a profi szinten mennyire fontos az OGL, es levalthatja-e a DX.

Az OSX 10.4.3 ota OGL-lel rendereli a desktopot.

[SFIJ]

Idézet: bogdan - Dátum: 2005. nov. 24., csütörtök - 16:56

8 ) vegul miert mondtam "mersekelt" novekedesnek a +70% YoY bevetelt? nos mert egy uj rendszerrol van szo, ami, ha tenyleg olyan klafa, akkor terjed mint futotuz. mondjuk az Opteron ilyen (pedig mennyivel kemenyebb kuzdelme van, mint az Itaniumnak, akinek huszan soprik elo az utat!). o 100% feletti novekedest mutat, raadasul mind bevetelbe, mind eladott rendszerek szamaban, ami egy sokkal egeszsegesebb piaci strukturara utal. (bar mint irtam nem ertek a kozgazdasaghoz, megis ez az erzesem.)

ha elfogadjuk, hogy az itanium csakis kizarolag a hajend ligaban jatszik, akkor az a 70% szvsz nagyonis jo. a hajend liga lomha es lassu. kisertetiesen hasonloan mint a konzolbiznicben 5 eves ciklusokat fut. szal az itanicnak 2007-2008-ben kene valami nagyot villantania. Namost ehhez kell(ene) nekik a Foxton meg mondjuk egy integralt FB-DIMM IMC legalabb.. ambator. mivel anand szepen levezeti hogy az x86 utasitas feleakkora meretu mint egy IA64-es, tovabba IA64-en egyszerre 3 slotot kell hajytani, ez azt jelenti, hogy az IA64 memsavszel igenenye egy X86-nak kb a 6szorosa. Mivel jelenleg a kapalpacs jol elvan 3.2GByte/s-kel (a dualbankbol 1 core keveset profital), ez nekem ugy hangzik, hogy az itanicnak elkoll 18.6-19GByte/s memsavszel. Az FB-DIMM 16-ot tud, tehat ez is keves, bar lenyegesen jobb, mint a mostani FSB400-as buli. Ellenben a RAMBUS XDR 25GByte/s-t tud. Barmennyire is utaljuk, ugy erzem jobb valasztas mint az FB-DIMM mert legyen inkabb 6GByte/s headroom egy rencerben mint 4GByte/s bottleneck

[bogdan]

Idézet: SFIJ - Dátum: 2005. nov. 24., csütörtök - 19:08

ha elfogadjuk, hogy az itanium csakis kizarolag a hajend ligaban jatszik, akkor az a 70% szvsz nagyonis jo. a hajend liga lomha es lassu.

nos lehet, hogy igazad van. en azt a ket feltetelt vettem figyelembe, hogy uj, terjedo termek (ugye masodik evben tud mindenki ezer szazalekokat produkalni!), illetve hogy mestersegesen tisztitjak nekije a palyat. de abban is sok igazsag van, amit mondasz!

Idézet

ambator. mivel anand szepen levezeti hogy az x86 utasitas feleakkora meretu mint egy IA64-es, tovabba IA64-en egyszerre 3 slotot kell hajytani, ez azt jelenti, hogy az IA64 memsavszel igenenye egy X86-nak kb a 6szorosa.

szerintem ezt elszamoltad! egyfelol az a 3 slot nagyon ritkan tud telitodni (ugye ez a platform egyik tyukszeme..) igy maris a 6 helyett mar 4-5x-osrol beszelhetsz csak. de a szorzas muvelet sem stimmel szerintem!! ugyanis az, hogy az Itanium lassabban ketyeg, de egy kettyenes alatt 3 utasitast is feldolgoz ugyan miert okozna 3x-os szorzot ? utasitasonkenti savszelessegrol beszelhetunk, mert ugyananyi feladathoz meg igy is ketszerakkora instruction adat szukseges, nem veletlenul lenne az uj Itaniumnak dedikalt i-L2 cache-e! tehat szerintem maradjunk a 2x-es szorzonal, vagy vitazzunk!

****************************************************************************
es az FB-DIMM ugyan 16GB/s-et tudhat, de komolyan gondolod, hogy ezen egy single core Itanium kap majd helyet??

[SFIJ]

Idézet: bogdan - Dátum: 2005. nov. 24., csütörtök - 18:35

szerintem ezt elszamoltad! egyfelol az a 3 slot nagyon ritkan tud telitodni (ugye ez a platform egyik tyukszeme..) igy maris a 6 helyett mar 4-5x-osrol beszelhetsz csak. de a szorzas muvelet sem stimmel szerintem!! ugyanis az, hogy az Itanium lassabban ketyeg, de egy kettyenes alatt 3 utasitast is feldolgoz ugyan miert okozna 3x-os szorzot ? utasitasonkenti savszelessegrol beszelhetunk, mert ugyananyi feladathoz meg igy is ketszerakkora instruction adat szukseges, nem veletlenul lenne az uj Itaniumnak dedikalt i-L2 cache-e! tehat szerintem maradjunk a 2x-es szorzonal, vagy vitazzunk!

****************************************************************************
es az FB-DIMM ugyan 16GB/s-et tudhat, de komolyan gondolod, hogy ezen egy single core Itanium kap majd helyet??

mint azt mar az elozmenyekben lathattad en nagyon konzervativan szamolom a memsavszelt. abbol indulok hogy ami tuti hogy megvan az a biztos. ha efelett optimakolassal van nyereseg, akkor orulunk. A 3 slot meg tud telitodni, siman. A most a foxton matt csuszo itanic CMT-t hasznalt volna, magyaran ha 2 slot teli van, akkor szepen bevalogat a harmadik slotba valamit. Lenyeg: az itanic akkor jar csucson ha mind a 6 futoszalagja megy. szal tervezzunk csak arra, hogy jarjon egyszerre a 3 slot. A problemat jelenleg a 3-6-9 megas L3$-sel orvosoljak ami egy iszonyat nagy pazarlas.
Ha azt nezem, hogy egy single core tipus megkapva az FB-DIMM vagy az XDR IMC-t nagyot tud homoritani akkor visszaszerezheto a ws es a blade szerver pozicio. Gondoljunk arra, hogy az L3$ esetleg teljesen elis hagyhato ezaltal. Ekkor a gyartas olcsobba/gazdasagosabba is valhat mint a P4/Dothan vonale. Egy ilyen szituban az itanic volume processzorra valhat, elkezd befele dolni a penz, nagysagrendekkel jobban mint jelenleg, van tapasztalat van penz, lehet javitani a termekvonal gyartastechnologiajan.

[bogdan]

Idézet: SFIJ - Dátum: 2005. nov. 24., csütörtök - 21:09

Lenyeg: az itanic akkor jar csucson ha mind a 6 futoszalagja megy. szal tervezzunk csak arra, hogy jarjon egyszerre a 3 slot.

rendben, tervezzunk arra. de hogy jon ki Neked ebbol a 6x-os savszelesseg? komolyan kerdezem, mert en sehogy sem latom..

raadasul a savszelesseg az adatoknal lep be a kepbe (van egyaltalan olyan program, ahol az utasitasoknak kell a savszelesseg??), igy azt osszehozni az utasitasok szamaval es hosszaval nekem gaz.. sehogy sem ertem :confused:

[SFIJ]

Idézet: bogdan - Dátum: 2005. nov. 24., csütörtök - 20:35

rendben, tervezzunk arra. de hogy jon ki Neked ebbol a 6x-os savszelesseg? komolyan kerdezem, mert en sehogy sem latom..

raadasul a savszelesseg az adatoknal lep be a kepbe (van egyaltalan olyan program, ahol az utasitasoknak kell a savszelesseg??), igy azt osszehozni az utasitasok szamaval es hosszaval nekem gaz.. sehogy sem ertem :confused:

az itanic pl egy ilyen arch, ahol az utasitasoknak is kell a savszel. de az SSE2/3 optimized x86 kod is ilyen, vagyis loop unrolling, branch-ek/jumpok szama minimalizalva.

a 6x egyszeruen jon ki:
- az ISA atlagosan fele olyan kompakt.
- a cpu optimalisan egyszerre 3 threadet futtat (3 slot)

[bogdan]

sehogy se jo ez!! 

Idézet: SFIJ - Dátum: 2005. nov. 24., csütörtök - 22:05

az itanic pl egy ilyen arch, ahol az utasitasoknak is kell a savszel. de az SSE2/3 optimized x86 kod is ilyen, vagyis loop unrolling, branch-ek/jumpok szama minimalizalva.

ertem en, hogy kell a savszel, de mekkora? nezzuk paraszti esszel: mekkora az adat/utasitas forgalom? ha nem tudjuk pontosan, akkor semmit sem tudunk! es mi az, hogy sse-nek kell utasitas savszel? en azt hittem, hogy ezek peldaul steaming jellegu dolgokat esznek legtobbszor: nyomom bele az wav-ot, es kopi ki az mp3-at. ami pici program, de kell ala a sok adat. meg aztan ha igy lenne, amit mondasz, akkor nem lehetne, hogy a Celeronok ugyanugy teljesitsenek ezekben mint a nagyobb cache-u Pentiumok. mert ugye a program nagyobb resze ferne be a cache-be, es igy gyorsabb lehetne. hogy van ez?

Idézet

a 6x egyszeruen jon ki:
- az ISA atlagosan fele olyan kompakt.
- a cpu optimalisan egyszerre 3 threadet futtat (3 slot)

most komolyan azt vezeted le, hogy megmondod egy processzor altal megkivant adatsavszelesseget a MHz nelkul? talan ha egy clock aranyt beraknal..

(en errol beszeltem, amikor adott feladat merteket hasonlitottam ossze..)

tenyleg nem ertem. egyik reszet sem. segitseg!

Szerkesztette: bogdan 2005. 11. 24. 21:53 -kor

[SFIJ]

Idézet: bogdan - Dátum: 2005. nov. 24., csütörtök - 21:20

sehogy se jo ez!! 
ertem en, hogy kell a savszel, de mekkora? nezzuk paraszti esszel: mekkora az adat/utasitas forgalom? ha nem tudjuk pontosan, akkor semmit sem tudunk! es mi az, hogy sse-nek kell utasitas savszel? en azt hittem, hogy ezek peldaul steaming jellegu dolgokat esznek legtobbszor: nyomom bele az wav-ot, es kopi ki az mp3-at. ami pici program, de kell ala a sok adat. meg aztan ha igy lenne, amit mondasz, akkor nem lehetne, hogy a Celeronok ugyanugy teljesitsenek ezekben mint a nagyobb cache-u Pentiumok. mert ugye a program nagyobb resze ferne be a cache-be, es igy gyorsabb lehetne. hogy van ez?

az SSE optimized annyit tesz, hogy streaming a kod is, nemcsak az adat. a lenyeg az, hogy az adott memsavszelbol VE korlatos mukodest erjunk el. es ez akkoris megteheto ha az algoritmus noh dacu nem fer be teljes egeszeben az insturction cache-be. ha a lame enkodert nezed, annak kodszegmense garantaltan nem fer be se egy P4 se egy athlon(64) cache-ebe. azt se feledd el, hogy a P4-nek iszonyat hosszu, 20 mely pipe-je van. ha van egy branch miss, akkor a pipe stall-ba megy flush-olni kell, mejd lehet ujra tolteni. Ez akar 20 clock.

Idézet: bogdan - Dátum: 2005. nov. 24., csütörtök - 21:20

most komolyan azt vezeted le, hogy megmondod egy processzor altal megkivant adatsavszelesseget a MHz nelkul? talan ha egy clock aranyt beraknal..

(en errol beszeltem, amikor adott feladat merteket hasonlitottam ossze..)

tenyleg nem ertem. egyik reszet sem. segitseg!

Nem ertem mifele MHz-ekre gondolsz. special szepen demozta hogy 1.5M->3M->6M->9M L3$ eseten milyen szepen novoget itanicon a specint2000. Ez annyit tesz, hogy a cucc sulyosan memsavszel korlatos. az itanic PC3200, 64bit DDR stilusu RAM-okbol foz jelenleg. A tesztekbol tudjuk, hogy ekkora savszelesseg egy athlon64-nek eleg, mert a dual channelre populalva a teljesitmeny csak 6-8%-ot no. az itanic szuk keresztmetszete a membusz, ez lathato. spekulative, jo mernoki hasra vevegig gondoltom, hogy miert szuk a memsavszel (fele olyan tomorsegu ISA, raadasul 3 thread) ebbol jo mernoki hasra aszondom, hogy az itanic memsavszelet 6x-ozva a szuk keresztmetszet eltunik. teheat ismerunk egy rendszert, athlon64, amin latszik, hogy nincsenek memsavszel problemak. latjuk, hogy itaniumon vannak, mikozben a memsavszel a 754 labu athlon64-gyel lenyegileg azonos. vegig gondloljuk az okokat, adunk egy becslest.  Nem mertem Milyen MHz-eket keresel es foleg azt nem, hogy minek keresed a MHz-eit... 

Szerkesztette: SFIJ 2005. 11. 24. 22:29 -kor

[hvuk]

Idézet: SFIJ - Dátum: 2005. nov. 24., csütörtök - 21:05

a 6x egyszeruen jon ki:
- az ISA atlagosan fele olyan kompakt.
- a cpu optimalisan egyszerre 3 threadet futtat (3 slot)

Itt azért érzek egy kis zavart az Erõben. Nem 3 threadet futtat, hanem 3 utasítást kódol egy utasítással. De egyszerre max. 6 utasítást tud kinyomni (ezt írtad is). A gond ott van a számítással, hogy az Opteron meg 3-at tud, nem poedig 1-et, ahogy implicite felteszed (a 3x szorzó miatt), ha tehát az Itanium 3-at tud, az Opteron meg 2-õt (jobb és könnyebb optimalizáció miatt), akkor a szorzó máris csak 2x-es, illetve összességében 4x-es a 6x helyett.

[bogdan]

Idézet: SFIJ - Dátum: 2005. nov. 24., csütörtök - 23:13

ha a lame enkodert nezed, annak kodszegmense garantaltan nem fer be se egy P4 cache-ebe.

mernoki hassal ha a program futasa nem gyorsul attol, hogy nagyobb cache-t rakok ala, akkor az egyfelol azert van, mert az adatokat csak egyszer olvassa be (es igy is van a steaming jellegu munkaknal mint a hang/mozi kodolas), es a programkod, ami a munkat vegzi gyakorlatilag befer a cache-be, es nagyon ritkan kell azt frissiteni.

marpedig ezeknel a feladatoknal (videokodolas tuti, azt magam is mertem) a nagyobb cache max +5%-ot dob.. nos, hol a hasfajas?

Idézet

Nem ertem mifele MHz-ekre gondolsz.

hat azt latom..

Idézet

Ez annyit tesz, hogy a cucc sulyosan memsavszel korlatos.

idaig tokeletesen egyetertunk!!! a kerdes, hogy mennyire!

Idézet

A tesztekbol tudjuk, hogy ekkora savszelesseg egy athlon64-nek eleg,

ezen sincs vita. tehat eddig azt tudjuk, hogy (It sav.szel.ig)>(A64 sav.szel.ig.).

Idézet

jo mernoki hasra vevegig gondoltom, hogy miert szuk a memsavszel (fele olyan tomorsegu ISA, raadasul 3 thread)

de itt mar szar kerul a palacsintaba!! ezzel ugyanis kihoztad, hogy barmelyik Itaniumnak 6x-os a savszelessegigenye, mint barmelyik A64-nek (single core persze). erre mar hasfajast kapsz, az tuti. (100GHz-es A64 szemben a 25Hz-es Itaniummal?? vagy forditva??)

a savszel ugyanis nem a clock-onkenti feldolgozott/szallitott adat (es utasitas), hanem a masodpercenkent feldolgozott/szallitott adat (es utasitas)! nem Gbyte/clock, hanem GByte/s a savszelesseg merteke. (hogy allsz a dimenzioszamitassal?) tehat amig nem viszed bele a kepletedbe azt, hogy masodpercenkent hany utasitast hajt vegre az a szerencsetlen processzor, addig a savszelessegrol nem tudsz nyilatkozni. tehat jon a MHz..

*******************
ja igen, nem zavar, hogy a multkor szepen megmutattad, hogy a sustained bandwith micsoda, itt meg theoretical peak bandwidth-thal szamolsz mindig. engem igen! 

*******************

Idézet: hvuk - Dátum: 2005. nov. 24., csütörtök - 23:31

az Opteron meg 3-at tud, nem poedig 1-et

bocs, de szerintem ez nem idevalo. ugyanis az adatbuszon jovo adatok mennyiseget ossze kell parositanod a feldolgozo kepesseggel. mi meg SFIJvel (ha jol ertem) ott tartunk, hogy a processzor barmit feldolgoz, a kerdes, hogy mennyi adatot kap. azaz savszelesseget szamolunk. (a 3 slot ugye azt jelenti, hogy egyszerre ennyi utasitast nyal be 128 biten!)

[SFIJ]

Idézet: bogdan - Dátum: 2005. nov. 24., csütörtök - 23:08

marpedig ezeknel a feladatoknal (videokodolas tuti, azt magam is mertem) a nagyobb cache max +5%-ot dob.. nos, hol a hasfajas?

khmm. mit mertel, bocs? IPP/EPI referencia mpeg2 encoderrel itanium 2 eseten, SPR transzkodolasa, 2pass, mpeg2-to-mpeg2

Mad3M: 189 min
mad6M: 147 min
Mad9M: 102 min.

szerintem beszédes a dolog.

Idézet: bogdan - Dátum: 2005. nov. 24., csütörtök - 23:08

ja igen, nem zavar, hogy a multkor szepen megmutattad, hogy a sustained bandwith micsoda, itt meg theoretical peak bandwidth-thal szamolsz mindig. engem igen!

azzal számolok amivel lehet és publikus. hogy ez nem olyan kewl meg hiteles mintha "sisoft sandrás" számokat nyögnék be hát sorry.

Szerkesztette: SFIJ 2005. 11. 25. 01:25 -kor

[bogdan]

Idézet: SFIJ - Dátum: 2005. nov. 24., csütörtök - 22:05

ahol az utasitasoknak is kell a savszel. de az SSE2/3 optimized x86 kod is ilyen

Idézet: SFIJ - Dátum: 2005. nov. 24., csütörtök - 23:13

ha a lame enkodert nezed, annak kodszegmense garantaltan nem fer be se egy P4 se

Idézet: SFIJ - Dátum: 2005. nov. 25., péntek - 1:50

khmm. mit mertel, bocs? IPP/EPI referencia mpeg2 encoderrel itanium 2 eseten, SPR transzkodolasa, 2pass, mpeg2-to-mpeg2

szep csusztatas!
en a P4-et a Celeronnal hasonlitottam ossze, es mp3, divix tomoritesekrol irok! google elso talalat legvege -- vannak programok,amik szeretik az L2 cache-t, es vannak indiferensek is:

Idézet

  1. DivX 5.1.1 prefers NetBurst core (Pentium 4 / Celeron), is not indifferent to a large cache, the memory bandwidth is not that influential.
2. XviD 1.0 beta 2 (not the latest version) fancies all AMD processors, sometimes reacts to memory bandwidth and L2 cache size.
3. Windows Media Video 9 VCM is almost indifferent to the cache size, improves performance with Hyper-Threading, and fancies AMD K8 core (either due to the SSE2 or due to the integrated memory controller; probably both factors are important).
4. Mainconcept MPEG Encoder 1.4 / MPEG1 slows down with Hyper-Threading enabled, doesn't depend much on the cache size and likes the K8 core much (probably for its K7+SSE2 because it's not sensitive to the memory bandwidth).
5. Mainconcept MPEG Encoder 1.4 / MPEG2 benefits a lot from Hyper-Threading, is not that sensitive to the NetBurst core (even without Hyper-Threading). Note how the preferences change regarding the format.
6. Canopus ProCoder 1.25 is indifferent to Hyper-Threading but very sensitive to cache size; architecture and memory bandwidth are not that important.
7. Cinema Craft Encoder SP 2.67 prefers a large cache and the NetBurst architecture, with the latter being more vital. It doesn't benefit much from Hyper-Threading, as well as from memory bandwidth.

azaz vannak SSE optimalizalt programok, amik biztos, hogy belefernek a cache-be nagyreszt. a tobbirol ugye nem tudhatjuk, hogy adatmozgatas miatt, vagy a kod miatt kell-e a cache. a kerdes ugye tisztan az volt, hogy az SSE jellegu adatfeldolgozas milyen adat es milyen utasitas savszelesseget kivan. en azt fejtegettem, hogy tudtommal ezek ritkan kivannak sok utasitassavszelesseget, es megmutattam, hogy ezekbol tobb biztos, hogy befer akar a Celeron 128k-s L2 cache-ebe is. tehat azt, hogy allitasod altalanosan (legfelul) nem lehet igaz.

azaz visszaterve a temara, egyenlore ketelkedem benne, hogy az Itaniumnak az utasitasok miatt kellene savszeleseg.
*******************************************************************
a masik "MHz kerdes"-re viszont nem reagaltal..

[SFIJ]

Idézet: hvuk - Dátum: 2005. nov. 24., csütörtök - 22:31

Itt azért érzek egy kis zavart az Erõben. Nem 3 threadet futtat, hanem 3 utasítást kódol egy utasítással. De egyszerre max. 6 utasítást tud kinyomni (ezt írtad is). A gond ott van a számítással, hogy az Opteron meg 3-at tud, nem poedig 1-et, ahogy implicite felteszed (a 3x szorzó miatt), ha tehát az Itanium 3-at tud, az Opteron meg 2-õt (jobb és könnyebb optimalizáció miatt), akkor a szorzó máris csak 2x-es, illetve összességében 4x-es a 6x helyett.

ez igaz, hogy a vlóság a 2x-4x körlül lesz, de a fenomenológikus modellben 3 threadet nyalábolsz össze egy epic pack-ké és erre van duplikálva a pipe. illetve tud még olyat az új csoda majd, hogy ha van 2 darab 2/3-ra töltött pakk akkor MT elven be tud szúrni mégegyy 2/3-ra töltött pakkot

Végeztem egy durva, felcsõbecslést a teoretikus sávszéligényre ami re 18-19GByte/s jött ki. annyit mondtam hogy ennek tutinak elégnek kell lennie. ma ehelyett van 3.2.

most mindenki kekeckedik hogy wazz ezígy nem jó mert bû meg bá hát akkor fogjatok meg itanicokat és mérjétek meg a teoretikus sévszélességüket, aztán vegyünk egy jó nagy stuffot ami még a 9 megás kesbe se fér bele. mérjönk máffeles hármas hatos meg kilences madisonon exec time-ot és ennyi adatból mondható egy predikció.

nem állítom hogy nem tévedek a számításaimmal 30-40%-ot legalább, de akkor jó, keressetek hozzá íRAMtípust ami garantálja azt a 12.5GByte/s sustainedet

[SFIJ]

Idézet: bogdan - Dátum: 2005. nov. 25., péntek - 1:26

azaz vannak SSE optimalizalt programok, amik biztos, hogy belefernek a cache-be nagyreszt. a tobbirol ugye nem tudhatjuk, hogy adatmozgatas miatt, vagy a kod miatt kell-e a cache.

és ezek a megállapításaid amik helyesek nagyjából bár a belefér a "kesbe" helyett ezesetben jóminõségû streaming kódot értek, mikoris az éppen aktuális feldolgozási lépcsõ valóban belefér de a kód már rafináltan prefetcheli a köv stage-et.
de a lényeg az, hogy különbözõ X86 architektúrák vislekedése és x86 optimalizáslási célfügvények eredményei az adott x86 architektúrákon mégis milyen relevációt nyújtanak egy, az x86-tól teljesen eltérõ szemantika és belsõ mûködési elv (itanium) viselkedésérõl? És a kérdés valahol ez, nem pedig az a reframing amerre mozdultál hogy fogást végy És a válasz az, hogy sacc/kb nem sokat. árcsak azért se, mert az itnaium in-order, és a branch prediction helyett a branch hinting aprioritásos. Ez a 2 dolog, az OoO és a BP adja a jelen X86-ot nagy teljesítményét. Az Itaniumnak meg egyik sem sajátja. Tehát a beidézett tesztjeidbõl semmi sem következik, nagyjából az itaniumra nézvést. hacsak az nem, hogy itániumra is lehet instruction cahe variáns meg invariáns programot írni.

Egyvalamin azért gondolkozz el. Az itanicon az utasításszavak hossza 128bit, és akkoris ennyi hacsak 1 slot-ot populálsz, nem pedig 3-at. Az X86-on a medián 22 bit. Egy 512 bites cacheline esetén az itanic betõlt worst case 4, jó esetben 12 utasítást. Az X86 átlagosan 23 utasítást tõlt be ennyibe. ha azt akarod, hogy az itanic tutira nyerjen, akkor 6c bandwith kell. ha aszondjuk hogy megeléxünk permanensen töltött 2 slottal akkor 3x akkora bandwith kell... ja és most kekecni lehet, de a processzorba csak akkor kerül adat, ha azt egy utasítás behozza

Idézet: bogdan

Idézet: me

    
Nem ertem mifele MHz-ekre gondolsz.

    
hat azt latom..

mivel csípõs kedvedben vagy hagy csípjek vissza. Az adasávszélességet nem "MHz"-ben mérjük

Szerkesztette: SFIJ 2005. 11. 25. 03:04 -kor

[bogdan]

Idézet: SFIJ - Dátum: 2005. nov. 25., péntek - 3:41

az adott x86 architektúrákon mégis milyen relevációt nyújtanak egy, az x86-tól teljesen eltérõ szemantika és belsõ mûködési elv (itanium) viselkedésérõl?

lassuk lepesrol lepesre:
1) en szolok, hogy nekem gaz, hogy a savszelessegigenyt csak az utasitasok savszelessege alapjan szamolod, es csodalkozom, hogy van-e olyan alkalmazas, ami tenyleg erzekeny erre.
2) Te azt allitod, hogy persze, az Itanium pont ilyen, mint ahogy az SSE is.
3) en kifejtem, hogy tudtommal az SSE nem ilyen, es megmutatom, hogy boven vannak olyan esetek, amikor meg a Celeron 128k cache-be is belefer (nagyon keves lapozassal persze) az utasitasresz.
4) erre Te megkerdezed, hogy mi koze a temahoz?

nos termeszetesen attol, hogy az SSE nem ilyen, attol meg az Itanium lehet ilyen. ezt nem cafoltam, en az analogiadra mutattam ra, hogy az nem all. (minimum, hogy nem altalanossagban!) nincs ezzel gond, nem mukodik, oszt kesz. viszont azt meg meg kene mutatnod, hogy az Itanium tenyleg utasitasokra ehezik nagyon sokszor! az, hogy vannak alkalmazasok, ahol a sok cache segit, meg nem mutatja ezt, mert adott adatszerkezetnel is kellhet a sok $.

Idézet

ja és most kekecni lehet, de a processzorba csak akkor kerül adat, ha azt egy utasítás behozza

de ez visszafele nem ervenyes? ha adat nem kerul bele, akkor is uncsi lesz a processzornak, nem? tehat meg kene allapitanunk, hogy mennyi az adat/utasitas aranya. erre meg semmi info nincs.

********************************************************************************
a masikat visszafele:

Idézet

mivel csípõs kedvedben vagy hagy csípjek vissza. Az adasávszélességet nem "MHz"-ben mérjük

egyebkent en ezirtam:

Idézet: en

tehat amig nem viszed bele a kepletedbe azt, hogy masodpercenkent hany utasitast hajt vegre az a szerencsetlen processzor, addig a savszelessegrol nem tudsz nyilatkozni. tehat jon a MHz..

azaz nem Hz a savszelesseg, hanem anelkul nem tudsz vele szamolni.

nalam a savszelesseg byte/s merteku (dimenzioju). ebbol az 1/s a Hz. ha csak a byte van meg, az nem savszelesseg!

Idézet

Egyvalamin azért gondolkozz el. Az itanicon az utasításszavak hossza 128bit, és akkoris ennyi hacsak 1 slot-ot populálsz, nem pedig 3-at. Az X86-on a medián 22 bit. Egy 512 bites cacheline esetén az itanic betõlt worst case 4, jó esetben 12 utasítást. Az X86 átlagosan 23 utasítást tõlt be ennyibe. ha azt akarod, hogy az itanic tutira nyerjen, akkor 6x bandwith kell. ha aszondjuk hogy megeléxünk permanensen töltött 2 slottal akkor 3x akkora bandwith kell...

(egyfelol amikor en irtam, hogy lesznek lyukas slot-ok, akkor Te azt elvetetted, raadasul nalad a szorzo eddig azert volt, mert tele volt mind 3 slot, most meg azert mert ures? no mindegy..)

lassuk, hogy igazad van-e! mivel sehol nem adtal meg Hz-et, igy gondolom azt szabadon valaszthatok, mint fuggetlen valtozo. tehat az x86-unk legyen 23Hz-es (es clockonkent 1 utasitast hajtson vegre), az memoriabusza meg 1 bit es 512Hz. (ennek ugye a savszelessege 512b/s) o nem lesz savszelesseglimitalt, hiszen pont annyi utasitast kap, amennyit fel is dolgoz. (ugye adataramlas 0, de ez egy elvadult eset.) az Itaniumunk legyen 4Hz-es (clock-onkent 1 VLIW utasitast hajtson vegre), a busz legyen ugyanugy 1 bites es 512Hz-es. (ennek is 512b/s a savszelessege). es milyen meglepo, o sem savszelesseglimitalt!! sot, akor sem, ha uresek a slot-ok. (igaz akkor unatkozik a processzor, de ennel kevesebb savszelesseg nem lenne eleg!)

hol jon itt ki, hogy 3x-os meg 6x-os savszel kell??

ja, hogy a kulonbozo Hz-ek miatt lett igy?? no igen, en szoltam.

*******************************************************************
es hogy tisztazzuk: en nem azon vitazom veled, hogy savszelesseglimitalt-e az Itanium, mert a cache fuggosege azt mutatja, hogy nagyon sokszor az. en azzal vitatom, hogy a teoretikus felsobecslesed jo-e barmire is. szerintem nem. nem kizart, hogy esetleg jo szamadat jott ki, de annak tippnek nincs koze a szamitashoz.

[SFIJ]

Idézet: bogdan - Dátum: 2005. nov. 25., péntek - 11:03

lassuk lepesrol lepesre:
1) en szolok, hogy nekem gaz, hogy a savszelessegigenyt csak az utasitasok savszelessege alapjan szamolod, es csodalkozom, hogy van-e olyan alkalmazas, ami tenyleg erzekeny erre.
2) Te azt allitod, hogy persze, az Itanium pont ilyen, mint ahogy az SSE is.
3) en kifejtem, hogy tudtommal az SSE nem ilyen, es megmutatom, hogy boven vannak olyan esetek, amikor meg a Celeron 128k cache-be is belefer (nagyon keves lapozassal persze) az utasitasresz.
4) erre Te megkerdezed, hogy mi koze a temahoz?

nos termeszetesen attol, hogy az SSE nem ilyen, attol meg az Itanium lehet ilyen. ezt nem cafoltam, en az analogiadra mutattam ra, hogy az nem all. (minimum, hogy nem altalanossagban!) nincs ezzel gond, nem mukodik, oszt kesz. viszont azt meg meg kene mutatnod, hogy az Itanium tenyleg utasitasokra ehezik nagyon sokszor! az, hogy vannak alkalmazasok, ahol a sok cache segit, meg nem mutatja ezt, mert adott adatszerkezetnel is kellhet a sok $.

de ez visszafele nem ervenyes? ha adat nem kerul bele, akkor is uncsi lesz a processzornak, nem? tehat meg kene allapitanunk, hogy mennyi az adat/utasitas aranya. erre meg semmi info nincs.

********************************************************************************



*******************************************************************

3) hozol nehany peldat anelkul hogy onmagaban forraskododt mutatnal, lattad volna. most mar irod, hogy "lapozassal persze" - tehat kezdesz visszatancolni onnan, hogy egyazegyben belefer a kesbe. ofkorz irhatoak onyan nyulfarknyi kodok, amik belefernek. Az "sse" nem ilyensegere nem lattam bizonyitekot. marcsak azert is nehez lenne latnom, mert komoly linalgebrai es DSP rutinokat irtam SSE-ben nemis keveset es valo igaz ugy kell megirni, hogy VE korlatos legyen amennyire csak lehet, vagyis adott kes eseten novekvo VE sebesseg mellett szepen kovesse le a kod teljesitmenye a novekedest mikozben a nagyobb kest is illik teljesitmenynovekedessel honoralni, merthat ugye azert vett a juzer nagyobb kesu procit.

Amit az idezett oldalrol leszurhetunk az kb az, hogy a DivX 5 optimalizacioja nemigazan sikerult, mig az xvid es a cinemacrafte igen.

4) igen megkerdezem. te hozol konkret "sse" enabled implementaciokat amiknek egy resze jol, mas resze kevesbe jol sikerult, sot vizsgalod ezek teljesitmenyet SSE ill non SSE enabled procikon, netburst architektura es hagyomanyos szuperskalar architektura eseten (nezed a jol/rosszul optimakolt) SSE kodok viselkedeset. ez valahol reframing, mert nemigazan ez volt a felvetesem. a felvetesem az volt, hogy az itanium architekturea egy streaming termeszetu ISA, mindezek mellett meg tobbszalu viselkedest mutat. Az SSE ott jon a kepbe, hogy azis egy straming szemleletu kod ( streaming simd extensions). Namost persze vizsgalni mindezt ha korrekt akartal volna lennei es tartani az analogiat a netburst/ht processzorokra kellett volna, ezek hasonlitanak leginkabb az itaniumra mukodesben. ha pusztan erre korlatozom az oldalon talalt vizsgalatokat csak a celeronokat/pentium4eket nezem az xvid es a cce eseten, nagyonszep korrelacio latszik ateren hogy
a) a core sebesseg novesevel jol lathato aranyos teljesitmenynovekedes latszik
b) a cache novekedesevel is kb aranyban no a teljesitmeny
c) a ht/mt enegdelyezett volta is ilyen hatast mutat

a) arra utal hogy akod VE korlatos, nem memsavszel korlatos. memsavszel korlatos jol lathatoan a divx. (a felsorott processzor tipusok memora savszelessege a tesztben noinalisan azonos)
b) nem allahatna fenn, ha elfogadjuk az altalad hangoztatott "beleferakodakesbe" elekpzelest. gondoljuk vegig: van egzy DDR, dualbank memrendszer, adott savszelesseg potenciallal. ha a kes eredendoen az adatokat puffereli csak ahogy te vallod, akkor a VE sebesseg novekedesevel azonos kes meret eseten (celeron 2 -2.2 -2.4)nem nohetne szepen linearisan a teljesitmeny mer a memsavszel ugye hardlimital

Idézet: bogdan - Dátum: 2005. nov. 25., péntek - 11:03

lassuk, hogy igazad van-e! mivel sehol nem adtal meg Hz-et, igy gondolom azt szabadon valaszthatok, mint fuggetlen valtozo. tehat az x86-unk legyen 23Hz-es (es clockonkent 1 utasitast hajtson vegre), az memoriabusza meg 1 bit es 512Hz. (ennek ugye a savszelessege 512b/s) o nem lesz savszelesseglimitalt, hiszen pont annyi utasitast kap, amennyit fel is dolgoz. (ugye adataramlas 0, de ez egy elvadult eset.) az Itaniumunk legyen 4Hz-es (clock-onkent 1 VLIW utasitast hajtson vegre), a busz legyen ugyanugy 1 bites es 512Hz-es. (ennek is 512b/s a savszelessege). es milyen meglepo, o sem savszelesseglimitalt!! sot, akor sem, ha uresek a slot-ok. (igaz akkor unatkozik a processzor, de ennel kevesebb savszelesseg nem lenne eleg!)

hol jon itt ki, hogy 3x-os meg 6x-os savszel kell??

ja, hogy a kulonbozo Hz-ek miatt lett igy?? no igen, en szoltam.

bogdan itt mar felulrol surolod a demagogiat, ugye erzed?

Idézet: bogdan - Dátum: 2005. nov. 25., péntek - 11:03

es hogy tisztazzuk: en nem azon vitazom veled, hogy savszelesseglimitalt-e az Itanium, mert a cache fuggosege azt mutatja, hogy nagyon sokszor az. en azzal vitatom, hogy a teoretikus felsobecslesed jo-e barmire is. szerintem nem. nem kizart, hogy esetleg jo szamadat jott ki, de annak tippnek nincs koze a szamitashoz.

ez igy majdnem korekt. egyfelol a felso becslesem nem teoretikus, hanem fenomenologikus. az hogy szerinted nem jo a becsles erre aszondom oke, adj egy jobbat. az nem eleg, hogy oreg ez szaaaar, hanem allits fel egy modellt, mutass valami rendszaert te is es avegen ebbol vezess le egy szamot

Idézet: bogdan - Dátum: 2005. nov. 25., péntek - 11:03

a masikat visszafele:
egyebkent en ezirtam:
(egyfelol amikor en irtam, hogy lesznek lyukas slot-ok, akkor Te azt elvetetted, raadasul nalad a szorzo eddig azert volt, mert tele volt mind 3 slot, most meg azert mert ures? no mindegy..)

majdnem jogos a csont, kihagytam a szamitasbol, hogy az itaniumnak 2x 3 slotos futoszalagja van. be kell leatnom hogy abban igazad volt, hogy a nyersen 22 vs 41x3 osszevetes nem all meg. utana neztem, valo igaz az atlagosan 2 populalt slot. es piszok mazlim van hogy ugye 2 toltott slottal kb 3x-os a savszelesseg igeny csakhat kettozott a futoszalag, igy fullosan kihajtva malacom van, nem art az a 6x-os savszelessef :Ð

Szerkesztette: SFIJ 2005. 11. 25. 17:03 -kor

[SFIJ]

bogdan ok. ez a demagogiaval elomaszas kicsit durva volt, bocs. mindazonaltal van egy erdekesseg a szamaidban: az X86 a peldadban 23Hz-en ketyeg, az itanic meg 4Hz-en. mindketto esetben ugy lettek beallitva az ertekek, hogy ne legyen a hipotetikus processzor memsavszel limitalt. namost akkor irjuk le egymas utan a ket szamot. 23 v 4. ha valmennyire hasonlitani akarunk a mahoz, akkor az a 4 inkabb 16. na nem folytatom.

[bogdan]

Idézet: SFIJ - Dátum: 2005. nov. 25., péntek - 23:44

bogdan ok. ez a demagogiaval elomaszas kicsit durva volt, bocs. mindazonaltal van egy erdekesseg a szamaidban: az X86 a peldadban 23Hz-en ketyeg, az itanic meg 4Hz-en. mindketto esetben ugy lettek beallitva az ertekek, hogy ne legyen a hipotetikus processzor memsavszel limitalt. namost akkor irjuk le egymas utan a ket szamot. 23 v 4. ha valmennyire hasonlitani akarunk a mahoz, akkor az a 4 inkabb 16. na nem folytatom.

en kerek bocsanatot, mert valoban demagogia volt! mentsegemre szolgaljon, hogy nem rosszindulatu, hanem inkabb az "ugrassuk ki a nyulat a bokorbol!" tipusu akart lenni, talan el is eri a hatasat. a szamaimban semmi erdekes nincs, hiszen pont azert lettek igy beallitva, hogy ezt az eredmenyt kapjuk. semmi ketseg, hogy a jelenlegi rendszereknel az 1.6 -- ~2.6 arany a helyes. en csak azert adtam ilyen hulye szamokat, hogy megmutassam, hogy a MHz igenis kell. ha ezt elfogadod, akkor latod, hogy mi a hiba a kovetkeztetesedben! (talan sikerul is egy jobbat adni, nem tudom.. en szivesen latnek ilyet!)

viszont sajnos azon tul, hogy ramutassak a kovetkeztetesed belso hibaira, nem tudok tobbet nyujtani. egyfelol ez kisse tul bonyolult feladat a szamomra, masfelol erosen az az erzesem, hogy a "savszelesseglimitalt" hataranak meghatarozasa nem elmeleti, hanem gyakorlati alapu, es az elmelet max hasonlo rendszerek kozotti tippelesre hasznalhato. az Itaniumnal, ha jol ertem, nincs ilyen kiinduloalapunk.

[SFIJ]

Idézet: bogdan - Dátum: 2005. nov. 27., vasárnap - 23:30

viszont sajnos azon tul, hogy ramutassak a kovetkeztetesed belso hibaira, nem tudok tobbet nyujtani. egyfelol ez kisse tul bonyolult feladat a szamomra, masfelol erosen az az erzesem, hogy a "savszelesseglimitalt" hataranak meghatarozasa nem elmeleti, hanem gyakorlati alapu, es az elmelet max hasonlo rendszerek kozotti tippelesre hasznalhato. az Itaniumnal, ha jol ertem, nincs ilyen kiinduloalapunk.

nem úszod meg ilyen könnyen. tessék becslést adni és érvekkel megtámogatni! :Ð

[special]

Megújul a mid-range és a high-end Integrity család -- HP sx2000 platform:

Idézet

    * Triple redundant crossbar mesh
    * Each cell is connected to three crossbars
    * Each bus has two to four times the bandwidth
    * The new chipset has redundant system clocks

The end result of all of this is more resilience and more bandwidth. This means better performance and better availability.

Szerkesztette: special 2005. 11. 28. 01:08 -kor