[ace22]

A tegnapi termes:

PEter

Csatolt képek:

• 

[Picur]

A szemem már nem a régi. A jobb oldalt milyen proci van? 

[_Geri_]

ace22: IBM 6x68MX nekem is van, és azt vettem észre, hogy bizonyos feladatokra meglepõen gyors. Jó kis procik voltak ezek, a hõskorban...

[ace22]

Idézet: _Geri_ - Dátum: 2009. febr. 2., hétfõ - 11:29

ace22: IBM 6x68MX nekem is van, és azt vettem észre, hogy bizonyos feladatokra meglepõen gyors. Jó kis procik voltak ezek, a hõskorban...

Az am, amig nem kellett a koprocit hasznalni, es az aruk is nagyon baratsagos volt az Intelehez kepest... A jobb oldali proci amugy az utolso PPGA-s celeron: 533MHz-et tud.

PEter

[_Geri_]

A beépített matematikai társprocesszorra gondolsz? Amúgy egy átlagos szoftvernek a logikai egység jobban kell, mint a matematikai, kivéve persze ha nekiállsz vele pl renderelni (vertexeket súlyozni, stb), de az IBM, ahogy láttam, ezt is kielégítõ sebességgel vitte. Igazából a 3d-s enginemet eresztettem rá a pr166-ra, egy scenet, ami kb fél millió polygont tartalmazott, és gyakorlatilag a vga rosszul megírt drivere csuklott meg 1-2 helyen, de összevetve az ibm gyakorlatilag simán képes volt leszámolni az egész scenet, holott nem csak egy modell viewer funkcionalitáson volt a cucc. Persze ezt simán be lehet tudni annak is, hogy csak én tudok túlságosan jól optimizálni, de ezt nem tudom megállapítani most még, majd kb 2 hét múlva, amikor más kóddal is betesztelem a cuccot. Amúgy az egész cucc sajna egy kurva régi szarfos alaplapban van, ami csak 92 mega ramot hajlandó max felismerni összesen, bármennyit is rakok bele, és AGP sincs rajta.

[akosf]

Idézet: ace22 - Dátum: 2009. febr. 2., hétfõ - 12:52

A jobb oldali proci amugy az utolso PPGA-s celeron: 533MHz-et tud.

Kíváncsiságból utánanéztem a dolognak. Úgy néz ki hogy az 533MHz-es Celeron megjelenése után kb. egy évvel még megjelent egy 500MHz-es típus (SL3FY) 180nm-es technológiával.

[Picur]

Abból az 500-as cerkából valamelyik fiókban pihen egy.

[Telcontar]

Idézet: akosf - Dátum: 2009. febr. 2., hétfõ - 13:57

Kíváncsiságból utánanéztem a dolognak. Úgy néz ki hogy az 533MHz-es Celeron megjelenése után kb. egy évvel még megjelent egy 500MHz-es típus (SL3FY) 180nm-es technológiával.

A CPU World szerint az SL3FY is 0,25 mikronos volt. Te hol láttad ezt a 0,180 mikronos infót?

[Telcontar]

Idézet: _Geri_ - Dátum: 2009. febr. 2., hétfõ - 13:22

A beépített matematikai társprocesszorra gondolsz? Amúgy egy átlagos szoftvernek a logikai egység jobban kell, mint a matematikai...

Állításod ezen része még igaz volt 1996-97-ben, de 1998-ban már nem. Ez tett be a Cyrix-nak, a Winchipnek és részben a K6-nak is, amelyek az egészpontos aritmetikára gyúrtak. De közben, amíg ezeket fejlesztették, a világ megváltozott. Egyre több programot optimalizáltak az FPU használatára. Ez a folyamat még a 80486DX-nél kezdõdött el, amitõl kezdve ugye mindig rendelkezésre állt egy beépített FPU. A folyamat eredményét jól jellemzi, hogy pl. a PowerDVD megnemmondom hányas változatának hivatalos hardverigénye min. 400 MHz-es Celeron, vagy bármilyen K7 alapú processzor. És tényleg: egy 400-as Celkával meg lehet nézni egy DVD filmet hardveres dekóder nélkül is (csak ne fusson semmi felesleges szolgáltatás a háttérben), de ugyanaz a film nem képes röccenés nélkül futni a K6-oson (én egy K6/2+-550-esen próbáltam), semmilyen szoftveres beállítással, trükkel sem.

[Valdy]

Idézet: Telcontar - Dátum: 2009. febr. 2., hétfõ - 21:39

A CPU World szerint az SL3FY is 0,25 mikronos volt. Te hol láttad ezt a 0,180 mikronos infót?

http://processorfind...spx?sSpec=SL3FY

[_Geri_]

Telcontar: ez egy nagyon rossz példa volt a véleményem szerint, ugyanis a codekek oroszlánrésze köszönõviszonyban sincs a floatokkal, hisz egy RGB egész hármason alapuló technológiának ilyesmi természetesen abszolút nem kell, persze akadhatnak kivételek, de ettõl még a videólejátszás idevonatkoztatása eléggé rossz dolog. A videó (de)kódolás egy tipikusan olyan folyamat, ahol számhármasokkal, számnégyesekkel kell dolgozni, ahhoz pedig MMX és egész számok kellenek de marhamód, nem pedig lebegõpontos számok. Épp emiatt a Cyrix processzorok gyengeségét nem lehet kizárólag az FPU gyengeségére fogni, sõt, egyáltalán nem, hisz az FPU sebessége egy bizonyos szint felett egy vegyes, átlagos bonyolultságú alkalmazást gyakorlatilag csak nagyon lagymatag mértékben gyorsít. A Cyrixnek egymillió más problémája is volt, amik azt a lassú videólejátszást eredményezték.
Hogy példának okáért modjak párat, ami a videódekódoláshoz kell: jó hatásfokú utasításbecslés, nagy memóriasávszélesség, MMX, marha mód gyors stack mûveletek, marha gyors jump és return, JÓL MEGÍRT CODEC...

És mégegyszer, ami nem kell hozzá: spéci FPU.

[akosf]

Idézet: Telcontar - Dátum: 2009. febr. 2., hétfõ - 22:56

A folyamat eredményét jól jellemzi, hogy pl. a PowerDVD megnemmondom hányas változatának hivatalos hardverigénye min. 400 MHz-es Celeron, vagy bármilyen K7 alapú processzor. És tényleg: egy 400-as Celkával meg lehet nézni egy DVD filmet hardveres dekóder nélkül is (csak ne fusson semmi felesleges szolgáltatás a háttérben), de ugyanaz a film nem képes röccenés nélkül futni a K6-oson (én egy K6/2+-550-esen próbáltam), semmilyen szoftveres beállítással, trükkel sem.

Valószínûleg a PowerDVD 5-ös lesz az. CyberLink PowerDVD 5 System Requirements

Ha lesz idõm, utánanézek ennek is. Úgy gondolom hogy a 400-as Celeron és az 550-es K6-2+ közel azonos teljesítményû processzorok, így érdekel a dolog hogy mégis min hasal el a K6-os.

[Telcontar]

Idézet: _Geri_ - Dátum: 2009. febr. 3., kedd - 1:31

Telcontar: ez egy nagyon rossz példa volt a véleményem szerint, ugyanis a codekek oroszlánrésze köszönõviszonyban sincs a floatokkal, hisz egy RGB egész hármason alapuló technológiának ilyesmi természetesen abszolút nem kell, persze akadhatnak kivételek, de ettõl még a videólejátszás idevonatkoztatása eléggé rossz dolog. A videó (de)kódolás egy tipikusan olyan folyamat, ahol számhármasokkal, számnégyesekkel kell dolgozni, ahhoz pedig MMX és egész számok kellenek de marhamód, nem pedig lebegõpontos számok. Épp emiatt a Cyrix processzorok gyengeségét nem lehet kizárólag az FPU gyengeségére fogni, sõt, egyáltalán nem, hisz az FPU sebessége egy bizonyos szint felett egy vegyes, átlagos bonyolultságú alkalmazást gyakorlatilag csak nagyon lagymatag mértékben gyorsít. A Cyrixnek egymillió más problémája is volt, amik azt a lassú videólejátszást eredményezték.
Hogy példának okáért modjak párat, ami a videódekódoláshoz kell: jó hatásfokú utasításbecslés, nagy memóriasávszélesség, MMX, marha mód gyors stack mûveletek, marha gyors jump és return, JÓL MEGÍRT CODEC...

És mégegyszer, ami nem kell hozzá: spéci FPU.

Jó.

Akkor csak azt nem értem, hogy egy 66 MHz-es FSB-vel szaladgáló 400 MHz-es Celeron miként tudja megverni dekódolásban a 100 MHz-es FSB-vel hasító K6/2+-550-est. Ennyivel gyengébb lenne a K6-os elágazásbecslése? Vagy hiába a magasabb FSB, a memóriasávszélesség mégis kevesebb? A gyengébb MMX utasításvégrehajtás talán nem jön szóba, hiszen a K6/2-eseknek két MMX-végrehajtó egységük van.

[_Geri_]

Én sem tudom, a legjobb lenne lemérni. Ami miatt biztos hogy nem, az az fpu.
Ha gondolod, írhatok pár, bizonyos specifikus részegységekre rátehénkedõ sebességmérõ tesztet, amit aztán ráereszthetünk több processzorra, és megvizsgálhatjuk, melyik feladatot melyik processzor milyen sebességgel teljesíti. Már csak ki kellene találni, hogy mik legyenek ezek a feladatok, és találni kellene valakit, aki végigfuttatja vagy 10-20 processzoron õket, majd az eredményeket idemásolja.

[Valdy]

Idézet

Hardware Information:
  Processor: AMD Athlon™ 64 X2 Dual Core Processor 4000+ running at 1189 MHz
  3DNow! technology:  In Use
  Enhanced 3DNow! technology:  In Use
  3DNow! professional technology:  In Use
  IA MMX technology:  In Use
  IA sStreaming SIMD extensions:  In Use
  IA SSE 2:  In Use
  Video accelerator:  DirectX VA (not in use)
  Multispeaker audio device:  Creative SB Audigy (not in use)
  S/PDIF output device:  SB Audigy Audio [AC00] (not in use)

Ki kéne próbálni, hogy újabb powerdvd-vel (ami támogatja ezeket az utasításkészleteket) hogy viselkedik k6 alatt, hardveres mpeg2 gyorsítás nélkül.
Bár k6-nál nyilván csak a 3dnow, enhanced 3dnow (k6+ esetén) és az mmx jöhet szóba.

Szerkesztette: Valdy 2009. 02. 03. 18:40 -kor

[akosf]

Idézet: Telcontar - Dátum: 2009. febr. 3., kedd - 19:00

Vagy hiába a magasabb FSB, a memóriasávszélesség mégis kevesebb?

Gyorsan belenéztem az Everest beépített eredményeibe.
Memória olvasás:
Celeron 266MHz: 360MB/mp PC66 SDRAM 3-2-2-5
K6-2 333MHz: 150MB/mp PC66 SDRAM 3-3-3-6

Valamint még megjegyezném hogy az Intel processzorok rendszeresen jobbak az elágazásbecslésben és általában az MMX utasítások végrehajtásában is.

Szerkesztette: akosf 2009. 02. 03. 18:45 -kor

[_Geri_]

No igen, ez a másik tévhit, hogy az emberek azt hiszik hogy a memóriaolvasás sebessége az minden processzor számára megegyezik az fsb bizonyos konstans szorosával, holott ez nagyon nem így van. Az olvasás sokkal erõsebben függ attól, hogy a processzor egy memóriaszelet olvasásakor hány várakozó órajelet kénytelen eltölteni, mire a kívánt adatok megérkeznek. És ez nem 1-2 órajel, hanem platformtól, processzortól függõen lehet akár 400-1500 is.

Szerkesztette: _Geri_ 2009. 02. 03. 18:47 -kor

[akosf]

Idézet: _Geri_ - Dátum: 2009. febr. 3., kedd - 19:47

No igen, ez a másik tévhit, hogy az emberek azt hiszik hogy a memóriaolvasás sebessége az minden processzor számára megegyezik az fsb bizonyos konstans szorosával, holott ez nagyon nem így van. Az olvasás sokkal erõsebben függ attól, hogy a processzor egy memóriaszelet olvasásakor hány várakozó órajelet kénytelen eltölteni, mire a kívánt adatok megérkeznek. És ez nem 1-2 órajel, hanem platformtól, processzortól függõen lehet akár 400-1500 is.

Már csak az a kérdés hogy videodekódolásnál miért van szükség nagy memóriasávszélességre. Mondjuk egy képkocka 2MB-nyi adat írását igényli, akkor 25fps mellett ez 50MB/s. Ez azt jelenti hogy csak a kész képkockák videomemóriába juttatása 20-25%-ban is felemésztheti egy K6-2-550 erõforrásait. Ez jó hipotézisnek tûnik, nem?

[_Geri_]

Nem, ez nem így mûködik. Az, hogy egy 2 megabájtos kockát te 25 fps-en ki tudd tolni, nem 50 megabájt sávszélesség szûkséges, hanem legalább 500. Nem szorozni kell, a programok nem így mûködnek
Egy videó dekódoláshoz elõször a nyers adatokat át kell másolni a DMA-n keresztül egy központi tárolóba, dekódolni kell ezeket az adatokat gyakran úgy, hogy az elõzõ frame vagy kulcsframe alapján kell bizonyos számításokat elvégezni, ezek röviden azt jelentik, hogy azon az ominózus 2 megabájtos kockán legalább 8x átméssz teljesen, mire odajutsz, hogy a driver DMA-n keresztül ismét csak mirrorozzon és strameljen rajta egy szépet.

[akosf]

Idézet: _Geri_ - Dátum: 2009. febr. 3., kedd - 20:00

Nem, ez nem így mûködik. Az, hogy egy 2 megabájtos kockát te 25 fps-en ki tudd tolni, nem 50 megabájt sávszélesség szûkséges, hanem legalább 500. Nem szorozni kell, a programok nem így mûködnek
Egy videó dekódoláshoz elõször a nyers adatokat át kell másolni a DMA-n keresztül egy központi tárolóba, dekódolni kell ezeket az adatokat gyakran úgy, hogy az elõzõ frame vagy kulcsframe alapján kell bizonyos számításokat elvégezni, ezek röviden azt jelentik, hogy azon az ominózus 2 megabájtos kockán legalább 8x átméssz teljesen, mire odajutsz, hogy a driver DMA-n keresztül ismét csak mirrorozzon és strameljen rajta egy szépet.

Úgy látszik csak elolvastad amit írtam, de dekódolnod nem sikerült. 

Nem arról beszéltem hogy mekkora sávszélesség igénye van egy dekódernek, hanem csak arról hogy a kész adatok videomemóriába írása mennyi idõbe telik.