''Why is Barcelona late?'' & ''New details on Barcelona emerge'':
[link]

Privat velemeny - keretik nem megkovezni...

''He's also the guy that prevented us from running benchmarks, and hid the Cinebench scores from us''

a mocsok

extra - SEXRay

A lényeget ha valaki már kihámozta? Mikorra lesz elérhető árú desktop K10 proci? 2008 előtt?

I am having fun staying poor.

Jó kérdés. Ha tényleg olyan jó lesz, nem lesz olcsó az biztos. Jól bepozicionálják majd az árat.
Szóval szerintem az első jelentősebb árcsökkentés után. Ezt én 2008 elejére olvasom ki a tőlem jobbra eső varázsgömb-ből.

https://hardverapro.hu/aprok/hirdeto/cyberslider/index.html

Hat a bemutatott roadmap-ek szerint 2007 veger majd talan kijon a desktop valtozat, de hogy milyen aron?. Julius-ban jon a Barcelona aztan sokaig semmi.

Szerk.:

Itt van hogy meg varni kell:
[link]

'' You'll see that in the Christmas line-up.''

Szoval raerunk

[Szerkesztve]

Privat velemeny - keretik nem megkovezni...

Hali Raymond!

Remek cikk. Remélem abból a 2010-re datált heterogén CPU/GPU dologból legalább 2015-re lesz valami. Nagyon mókás lenne egy olyat megcsiklandozni.

Az XORPD-t nem értem inkább. Nem 2 vagy 3 SSE ALU van a Core2-ben? 2 esetén már 0.5 órajel/utasításnak kellett volna kijönni.
Nekem van egy tippem, persze lehet hogy tévedek. De...

XORPD xmm,mem -> 1 órajel / utasítás ( 8 bájtos utasítás )
XORPD xmm,xmm -> 0,5 órajel / utasítás ( 4 bájtos utasítás )

Elvileg a Core2 x86 instruction predecodere 128 biten ( 16 bájton ) kapcsolódik az instruction cache-hez. A teszt kód 16 bájra volt illesztve, mégis, nem lehet hogy a decoder nem tudott két'' XORPD xmm,mem''-et 2x8 bájtról leképezni?

Valóban nem figyeltem, hogy OP reg, mem utasításokat használtál, de ekkor nem a Data Cache a szűk keresztmetszet? Hányszor 128 bites az átvitele órajelenként?
A ''4/8 bájtos utasítás'' kifejezéseken mit értesz?

Core/Core2-ról csak nagyon óvatosan merek mondani bármit is, nem ismerem őket eléggé. Tegnap találtam egy nagyon jó dokumentációt róluk, annak áttanulmányozásáig inkább maradok a kérdéseknél velük kapcsolatban. (Most a Raymond által linkelt - köszönet érte - [link] anyagot próbálom összerakni egységes egésszé, picit darabos) . A P2/P3, Netburst és K7 micro-architecture-öket ismerem testközelből alkalmazásprogramozás szinten, mivel (nem klasszikus értelemben, de) irodai programokat készítek, ezekkel találkozom mindenfelé nap, mint nap, és nekem is ezek voltak eddig. A K8-on sem dolgoztam még, de megpróbálok képben lenni vele kapcsolatban. Remélhetőleg a dual K8 konfigom összeáll júniusra, de már ezt direkt úgy terveztem meg, hogy (a lehető legkisebb módosításokkal) K10 fogadására is alkalmas legyen.

[Szerkesztve]

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

Összesen 128 bájtot címezgettem, nem hiszem hogy a Data Cache lett volna a szűk keresztmetszet, de ezt csak egy hét múlva tudom letesztelni.

A ''4/8 bájtos utasítás'' alatt azt értem hogy az utasítás kódja ennyi bájtra fordult le.

szerk.: Majd kipróbálom XORPD XMM0,[DATA0] helyett XORPD XMM0,[ESI+00] formában, így kiderül hogy a data vagy decoder oldalról jött be a csökkenés.

[Szerkesztve]

AMD K10 party mindenki részeg: [link] kb ~30MB wmv

Az embert a gondolkodás tette állattá...

belegondolok 8magnál már nem is elképzelhetetlen....

don't look up, don't look up, don't look up, don't look up, don't look up, don't look up, don't look up...

Egy kicsit elmélyedtem a Core2 micro-architecture-ben, egyáltalán nem érzem rossz döntésnek, hogy az AMD ermékvonalán maradok egyelőre. Ezzel a kóddal elég sok szűk keresztmetszetet megtaláltál, de pont nem azt, amit írsz.

- Igaz, hogy négy decoder van, de csak az első tud több, mint egy micro-opból álló utasításokat fordítani, tehát 4-1-1-1 micro-opre forduló utasításszekcenviák tudják teljesen kihasználni a teljes decode-sávszélességet (...óhh, azok a boldog P2/P3 idők, csak ott még 3-1-1 volt a felállás. Minden OP reg, mem 2 micro-op-ra fordul le (op+load), szóval órajelenként csak egy XORPD reg,mem fordult le egyáltalán. Legalább a trace cache-t megtarthatták volna...

- minden load micro-op a LOAD (port2) exetucion unit-ba kerül, órajelenként egyet tud fogadni. A Data Cache is egy olvasás/órajel szélességű, szóval ha más miatt nem, akkor emiatt is órajelenként egy XORPD reg,mem indulhatna el, egy kapja meg a forrásadatát per cycle. (K8/K10-en 3 AGU van, és a cache 2 load/cycle szélességű). A Data Cache és az core között nincs más ideiglenes tár a Store Buffer-en kívül - az már L0 lenne -, tehát ha még ugyanazt az egyetlen értéket is olvasod be minden utasításnál, akkor is a cache-hez kell fordulni mindig. A Store Buffer meg a store-forwarding-ot tudja segíteni, a kódban viszont nincs store.

A 0.33 utasítás/cycle legfeljebb úgy érhető el, hogy XORPD reg1,reg2 alakokat használsz (úgy, hogy nincsenek függőségek, és reg1 != reg2, mert erre spec. gyorsítás van).

Azt hittem, register-es címzést használsz, XORPD xmm0,xmm1 ugyanakkora méretű, mint az XORPD xmm0,[esi] és a XORPD xmm0,[esi+10h] is csak egy byte-tal nagyobb, +/- 127 byte-os displacement-ig. De pont a 4-1-1-1 felállás miatt itt mindegy, hogy egy 16 byte-os sorba 2, 3 vagy 4 utasítás fér el.

[mod]: Dzsémi, ne rajtam hozzászólás-gyűjtögess!

[Szerkesztve]

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

ezért nincs az AMD-nek pénze, elisszák

extra - SEXRay

Hah, tudtam hogy varnom kell mert te sokkal ertelmesebben le tudod irni mint amit en kiizzadtam volna magambol Nem is beszelve a plusz inforol...

A temahoz kapcsolodik ez:
[link]

Az oldal aljan vannak prezentacios slide-ok. Masodik sor elso kep ami a leirtakat szepen es egyszeruen illusztralja. Azon PR/Marketing slide-ok kevese koze tartozik ahol nem csusztat a gyarto mert nincs miert

Privat velemeny - keretik nem megkovezni...

Én programozói szempontból tudok csak kiindulni, csak azokat tudom, hogy mik segítenék a munkámat.
Ennél a kódnál [link] (SSE IDCT, 2x4 oszlopot konvertál egymás után, majd 8x1 sort SSE2 integer megvalósítással gyorsabb lenne, de mindenképpen a lehető legpontosabb eredmény kellett itt) ha lenne egy megfelelő, shared L1 Data Cache-en alapuló Hyper-Threading, akkor párhuzamosan mehetne a 4 oszlopok dekódolása, nem kellene egymás után írni őket, a függőségek miatt úgyis ''lassú'' a végrehajtás, és kevés egység dolgozik egyszerre, akármennyire is szét vannak dobálva a függő utasítások. Shared L1, mert a cache-vonalak átvitele két cache között nem túl gyors művelet.

Ennél a kódnál [link] pedig annyira véletlenszerű a forrásadat, hogy biztos vagyok benne, hogy nagyon sok a misprediction, ezen segíthetne, ha mindig mindkét ág elindulna. (Ugyancsak a függőségek miatt mindig van szabad ALU).

Mindkét kód saját készítés, kéretik bárkinek felhasználás előtt kikérni az engedélyem
26 megapixeles képen a fenti két kód lefutása 2400 MHz-es K7-en (gettickcount-tal mérve):
- IDCT: több, mint félmillió teljes lefutás kb. 200 millisec alatt
- Huffman-decode: több, mint 17 millió teljes lefutás: 650 millisec alatt
Nagyon kíváncsi leszek, mennyivel gyorsul majd K8-on.

[Szerkesztve]

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

Csúsztatások egy bizonyos szint alatt nem szoktak lenni, csak mese, mese vég nélkül (mint az intelligens mosópor... legiknkább a könnyebb megérthetőség miatt, mondjuk a CPU azért elég intelligens dolog) Sokszor jó, ha az ember megpróbálja lehozni ezeket a meséket is tranzisztor-szintre.

[Szerkesztve]

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

Alaplapok K10 alá:
[link]

Jó olvasást...
AMD - The Road Ahead
[link]


látom már linkelték feljebb átsiklottam felette

[Szerkesztve]

Aki esetleg rosszul beszéli a kinait (olvassa) és azért nem csak a képeket akarja megnézni annak egy erősen rossz, de angolosabb verzio: [link]

Ha Google a barátod és Wiki a barátnőd, akkor a Bábelhal a tolmácsod

[Szerkesztve]

érdekes ez a 266 MHz ext. clock

extra - SEXRay

És érdekes a 266x5=1333-as HT link, az még nem éppen tűnik HT3.0-nak, inkább annak, ami a 939-es és az AM2-es procikhoz jár, és alapból 200x5-ön szokott menni.

Ahogy én látom: az AMD a NetBurst ellenében azért tudott talpon maradni, mert amíg a NB egy erősen specializált architektúra, addig az AMD K7/K8 általános célú: szélesebb körben nyújt kiegyensúlyozott teljesítményt. (Igen, ez most az Intel Core indulásával eléggé megborult.)

Szerintem az AMD-nek továbbra is ehhez az irányvonalhoz kell tartania magát, ha talpon akar maradni.

SZVSZ minden egy mag megosztott erőforrásaira épülő HT erősen korlátozó tényező lenne ebből a szempontból. Hacsak a szűk keresztmetszeteket fel nem oldják valahogyan, pl. extra erőforrások beépítésével.

A másik megoldással kapcsolatban - az elágazások mindkét felének párhuzamos végrehajtása, majd az egyik szál eldobása - elvi számításról tudok, miszerint ebben a formában nagyon kevés gyorsulás várható tőle, aránytalan erőforrásigény mellett. Azt meg ne kérdezd, hogy ezt az elvi számítást hol láttam: már volt néhány éve.

/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

Éljen a tuning!

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

AMD Names the Next PC Computing Thrill Ride: The AMD Phenom™ Processor [link]

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

ja, lehet, hogy csak egy sz*ros tuningot legyintettek meg a godzillások

extra - SEXRay

Hmm...úgy látom hogy ez még nem volt: [link]

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

Jah! és még miányzik az SSE4. Egyedül ami okésos a képen az a B0 Revision, de még a L3-as cache is hiányzik, szóval igencsak sok a baja a képnek. Egyre inkább hajlok a fake felé.

vagy csak a cpuz nem ismerte fel

AMD Phenom and Quad Core Opteron

[link]

Privat velemeny - keretik nem megkovezni...

Sztem valami társprocesszor lesz, amivel a szobád hőmérsékletét tudod majd szabályozni

A pénz nem boldogít, csak amit veszel rajta...

nagyon meg lennék lepve, ha a CPU Z nem ismerné fel a Level 3-as cache-et, amikor már rublika is van neki hozzá.

Kis fuccilla Raymond kedvéért: [link]

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

es az egesz kep... [link] egyebkent egyertelmuen fake.. meg kell nezni nehany hozzaerto forumot..

Play nice!

Amúgy szerintem is eléggé gyanús. Viszont hamarosan kiderül hogy mi az igaz.

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

huh, nagyon durva értékek, de mégis csak fud...
Raymond barátodnak azért igaza van, mert nem kéne 'találgatós topikot' csinálni ebből

extra - SEXRay

Szerintem pedig ez részben egy találgatás, addig a percig amíg a kezünkben nincs a cucc. Vagy legalább a PH! tesztlaborjának a kezében.

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

svédek sara: [link]

extra - SEXRay

Van olyan lap, ami tutkó K10 kompatibilis?

I am having fun staying poor.

Főleg, hogy korábban már felismerte: [link]

(#587) Oliverda: már le is szedték az oldalt. Ez talán jelent valamit. (Találgatás, találgatás... ) szerk: közben látom, inkább csak rájöttek, hogy valószínű kamu.

[Szerkesztve]

pl.:[link]

Play nice!

A kép inkább tűnik egy 4X4-es platformnak, csak nem értem akkor miért nem ismeri fel a procit rendesen, de a fehér processzor váltó is azt mutatja, hogy fizikailag több proci van benne és nem egybe tokolva, hiszem amit te linkeltél azon is szépen felismert mindet.

Szerintem AM2-es lapra gondolt. Amúgy jópofa a Seahorse-on (csikóhal?) az a felfelé álló DVI csati.

CYX: állítólag fake az egész, lásd #593.

[Szerkesztve]

Persze, hogy arra. Elnézést, ha félreérthető voltam.

I am having fun staying poor.