''A core es az IMC feszultseg ellatasa eleve szet vont valasztva.''
Hol? AM2-nél nem, Socket F-nél sem. Majd a +-osok egyik újdonsága lesz ez. Még ha a Barcelona tudja is esetleg, jelenleg csak Socket F-ben járatják, mert még nincs is más.

''júni 10-ém launch-olják a K10-t.''
Ez hol van így leírva?

(#843) Gyuri27: LOL, talán nézd meg a szó többi jelentését is.

[link]

Ha az ember féreggé teszi saját magát, ne csodálkozzon, ha rátaposnak.

Lehet hogy ő sem gondolta egészen komolyan.

7600GT: Az a Kanadai Nagydíj dátuma!

[Szerkesztve]

"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)

Lehet de a a vr-zone-on úgy van kinn, hogyhenom launch date: June 10, 2007

Ha az ember féreggé teszi saját magát, ne csodálkozzon, ha rátaposnak.

Nincs ott kint semmi. Egy topicot nyitott valaki a félreértésének. Gondolod ha Te itt nyitsz egy hasonlót, akkor az hivatalos bejelentésnek fog minősülni?

Si vis pacem, para bellum.

Kezdek aggódni az AMD K10-e miatt. A Barcelona hivatalos források szerint egy negyed évet késik, és ez nagyban rontja a cég túlélési esélyeit.

Szerintem túlélik, azért Q4-ig.

Attól függ mennyire vették a kibocsájtott kötvénycsomagot, ha nem haraptak rá akkor lassan kiürül a kassza, jelenleg minden üzletáguk masszívan veszteséges, mivel mindenhol gőzerővel fejlesztenek, az áraikat meg mindenhol önköltség környékére nyomta a konkurencia...

"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)

Ezek rendben is vannak, de azért az ATI és az AMD kötségvetése távol van egymástól. Forrásként ajánlom a Wikipédiát, ott nézzétek meg a két cég bevételét/kiadását. Sajna, mégha az ATInak nagyon jól megy, az sem képes kompenzálni az AMD veszteségeit...

Mik lennének azok a ''hivatalos források''? Eddig csak a Fudzillán olvastam ezt, ebben a formában.

Itt olvastam: [link]

Itt éppen az áll, hogy az AMD tagadta, hogy a Barcelona csúszna, és hogy csak a Budapest fog csúszni (utolsó bekezdés). A többi egyelőre feltételezés, bár van alapja.

Ez tény

Tényleg így van. Akkor viszont nem világos a következő:
Az PFRCP egy belső ROM-táblából veszi a közelítő értéket, latency 3 mellett. (''An (on-chip) ROM-based table lookup can be used to quickly produce a 14-to-15-bit precision approximation of 1/b using just one 3-cycle latency PFRCP instruction''). Az RCPSS lappangása 3, RCPPS-é 4 (a 2 db 2x32 bites adategység miatt), ez alapján ezek is lookup-táblából kell vegyék eredményüket. Ekkor viszont három eset lehetséges:
- van egy ROM-tábla az PFRCP-nek és egy külön ROM-tábla az RCPxS utasításoknak, ezek eredménye különbözik, viszont utóbbi ugyanazt adja, mint Intel esetében?
- az, hogy egy közös ROM-tábla van, és PFRCP és RCPxS utasítások eredménye megegyezik, viszont utóbbi nem ugyanazt adja, mint az Intel-nél, nem jöhet számításba, mivel RCPxS hibahatárának az AMD is az említett relative error-t adja meg,hacsak nem
- a két hibamegjelölés ugyanazt a pontosságot takarja?
Tudnál mondani konkrét példaértéket, ahol kijön a különbség? (Itanium esetében az Intel a RCPxS pontosságát már 2^-17 nagyságrendben jelöli meg, de ez nem hiszem, hogy változhatna x86 esetében a jövőben.)


Ha jól értelmezem, akkor K8 esetében precíz, 24 bites a/b értékek kiszámítása PFRCP-PUNPCKLDQ-PFRCPIT1-PFRCPIT2-PFMUL (latency 4-2-4-4-4) sorozattal jóval gyorsabb, mint DIVPS (latency 33) használatával? És ha jól látom, az előbbi minden utasítása fully pipelined, tehát több sorozat is futhat egymás mellett, sorozatonként 2-2 register használatával? (És akkor ez még K10 esetében is áll, hiába fele a DIVPS lappangása, ha nem pipe-olt). Ezt megjegyzem

[Szerkesztve]

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies

Csak tudnám miről van szó....

''Science has failed our mother Earth.'' - S.O.A.D.

Reciprok letesztelve, tessék megkapaszkodni !!!

Teszthez használt CPU-k:
AMD X2 3600+ Windsor (1800@2400MHz)
Intel E4300 Allendale (1800@3200MHz)

Mérés:
31 bites prímszámok reciprokképzése
AMD 3DNow!, PFRCP 32 bit <-> FIDIV 80 bit
AMD SSE, RCPSS 32 bit <-> FIDIV 80 bit
Intel SSE, RCPSS 32 bit <-> FIDIV 80 bit

Mérés beállítások:
FPU, SSE: Kerekítés a legközelebbi egészhez, egyenlőség esetén pároshoz.
FPU: extended ( 80 bites ) pontosság

Eredmény:
Az esetek túlnyomó többségében mindhárom eredmény eltér egymástól.

Példa:
IEEE734 formátumú reciprok eredmények n=3 -ra.
AMD 3DNow!: 3EAAAA00 ( = 0,33332825 )
AMD SSE: 3EAAA800 ( = 0,3331299 )
Intel SSE: 3EAAA000 ( = 0,33325195 )

Hogy mindhárom eredmény eltért, nos ez erősen meglepett. Ezért a keresést kiterjesztettem az összes 31 bites pozitív egész számra. Ekkor jött a még nagyobb meglepetés, ugyanis a legnagyobb hibát az n=1 eset produkálta!

Maximális eltérések:
AMD 3DNow! : 0,00003051758 ( hiba = 1/32767 -> épp nincs meg a 14 bit )
AMD SSE: 0,000244140625 ( hiba = 2 ^ -12 -> 11 bit mindig jó)
Intel SSE: 0,000244140625 ( hiba = 2 ^ -12 -> 11 bit mindig jó)

Megjegyzés:
Az AMD SSE eredmények mikor eltértek az Intel eredményektől, mindig pontosabbak voltak.

Szerk.: A Newton-Raphson iteráció használható SSE esetén is, csak akkor manuálisan kell leprogramozni. Nem igényel több regisztert, csak eggyel több memória műveletet. Xb=Xa*(2-N*Xa), ahol Xa az N reciprok közelítő értéke. Ez egy körben megduplázza a hasznos bitek számát. Ami azt jelenti hogy az SSE 11 bites pontosságát nem lehet egy körben 24 bites mantissza méretre ( single precision ) interpolálni.

[Szerkesztve]

Köszönöm, nem kevés időt szántál rá.
Nem kapaszkodtam elég erősen.
Először azt hittem, n=1 elírás, de itthon K7-en kipróbáltam, valóban. Sőt, a 3DNow! a kettő hatványaival konzekvensen gondban van, SSE csak 1 esetében. (A példák K7-es eredményei megegyeznek a K8-eredményeiddel. Gondolom, az eltérő első SSE-megvalósítások után fontosabb volt a backward compatibility.)

Igen, meg lehet valósítani, néztem utána a képletet, legfeljebb annyit lehet felhozni ellene, hogy a nagyobb SSE-kód (a 2 menet 2 MOVAPS, 2 MULPS, 1-1 ADDPS és SUBPS, teljes függőségben, ahogy én írtam) csökkenti az ütemezők előrelátási tartományát, illetve az összes 3DNow! DirectPath, a vector SSE-utasítások DirectPath Double-k K8-on. Amúgy nem lehetséges, hogy ezek miatt gyorsabb pár százalékkal a 3DNow!-kód?

alienpapa, VaniliásRönk: én dezz-ék DX10-es beszélgetésére néztem hasonlóan. De gondolom, akosf hsz-e után tisztább a kép.

[Szerkesztve]

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies

Mai: [link]

"Minden negyedik-ötödik magyar fiatal funkcionális analfabéta – derült ki a nemzetközi felmérésekből. Az arány a felnőttek körében sem jobb."

érdekes eredmények jöttek ki.

gondolom a CPU saját kódkészletét használtad.Ami érdekelne,hogyha az Intes kodot futtatod AMD-n milyen eredményt ad bár ha ASM-ben irtad akkor enenk nisc jelentősge

A válaszlehetőség természetesen az övé, de a fent említett 3 dolog egy-egy utasítás kimenete, assembly szinten.
Az AMD esetében x értékre két 1/x gyors közelítő reciprokképzési elemi utasítás adott, a 3DNow!-féle PFRCP és az SSE1-féle RCPSS (vagy RCPPS, előbbi egy értékre számolja, utóbbi négyre, itt mindegy). Az Intel CPU-k csak az SSE1-es utasításokat ismerik, ugyanazokat. A dolog ott vált érdekessé, hogy 3DNow! esetében az AMD bevallottan tényleges számítás helyett egy ROM-táblázatból veszi az eredményeket, 'futásidő' alapján az SSE1 esetében is. Az Intel nem nyilatkozik erről. És mindhárom eredmény különbözhet.

[Szerkesztve]

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies

Valahogy nehezen hiszem, hogy azt reklámoznák az odalukon, hogy a Phenom felirat rákerült egy F1-es sisakra.
Annak az értelmét sem nagyon látnám, ha ilyen negyed évvel korábban reklámoznának valamit, mint hogy egyátalán bemutatásra kerül. Amikor végül sor kerül a bemutatásra, mindenki arra gondolna, ''ez nem is újdonság, már réges rég láttam valahol''.

[Szerkesztve]

Valószínű hogy az Intel is look-up ol, csak spórolósabban. A 14 bites mantisszához elég egy 16kB-os ROM, illetve a kitevőhöz kell még egy 128 bájtos. Az SSE esetén elég 4kB/128. Egy iterátor áramkörnek legalább 1-2 szorzásra lenne szüksége, ami még ha egy ciklusos is ( 12 bites szorzó ) nem lenne gyorsabb a ROM-os megoldásnál, valamint helyet sem spórolna.

Az AMD illetve Intel eredmények közti különbség is a look-up tábla méretéből adódhat. Az RCPxS-nél a mantissza 24 bitjéből az alsó 12-ő törlődik, viszont az AMD-nek megvan a lehetősége hogy az utolsó megmaradó bitet kerekítse.

http://multicore.amd.com/us-en/quadcore/ - [link]

Close the World ..... Open the Next!

Hát nem tudom. Lehet hogy ma bemutatják, holnaptól pedig már indul is a sorozatgyártás.

"Minden negyedik-ötödik magyar fiatal funkcionális analfabéta – derült ki a nemzetközi felmérésekből. Az arány a felnőttek körében sem jobb."

Intel Penryn teszteredmények: [link]

Jó lenne ha kapkodna az AMD, mert 2007-re igéri az Intel a Penryn-t és a fenti eredmények szerint 10-20%-kal veri a Core2-őt ...

[Szerkesztve]

szerint 10-20%-kal veri a Core2-őt ...

14%-al magasabb órajelen

extra

Na meg itt az FSB is magasabb, ami az Intel-nél sokat számít, főleg 4 magnál.

"Minden negyedik-ötödik magyar fiatal funkcionális analfabéta – derült ki a nemzetközi felmérésekből. Az arány a felnőttek körében sem jobb."

Ok. Nem fogalmaztam elég egyértelműen.
Szóval a Penryn 10-20%-kal veri a Core2-őt ugyanarra az órajelre számolva.
( Gondoltam ez egyértelmű, ha nem adom meg külön-külön. )

honnan lehet letölteni a Cinebench R10 Beta-t, sehol nem találom

workworkwork...

ahogy olvastam, majd csak a végleges változatot lehet majd letölteni, de jön nemsokára

workworkwork...

Te skizofrém vagy, hogy magaddal komunikálsz?
Legalább nem unatkozol.
És jó a társaság?

Ha az ember féreggé teszi saját magát, ne csodálkozzon, ha rátaposnak.