- Samsung Galaxy S24 - nos, Exynos
- Fotók, videók mobillal
- Android alkalmazások - szoftver kibeszélő topik
- Ár-érték bajnokot avatott a Poco?
- Google Pixel 8a - kis telefon kis késéssel
- Apple iPhone 16 Pro - rutinvizsga
- Google Pixel topik
- Megjelent a Poco F7, eurós ára is van már
- One mobilszolgáltatások
- Samsung Galaxy S22 és S22+ - a kis vagány meg a bátyja
-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
Balala2007
tag
válasz
Balala2007
#14808
üzenetére
Ugyaninnen van az az info is, hogy 1 db Zen mag < 10mm2. Miutan az Excavatort szazadnegyzetmillimeterre megmondta, nincs kizarva, hogy ez is helyes.
-
#14809
FireKeeper
nagyúr
Balala2007
#14808
FireKeeper
nagyúr
válasz
Balala2007
#14808
üzenetére
an old one but a good one
-
#14799
Yutani
nagyúr
Balala2007
#14796
válasz
Balala2007
#14796
üzenetére
Mindegy, csak desktopra hozzák ki mielőbb a szimpla 8 magos verziót, ami itt egy MCM-nek felel meg.
-
#14797
Fiery
veterán
Balala2007
#14796
Fiery
veterán
válasz
Balala2007
#14796
üzenetére
"4x MCM"
Megint a szellel szemben probalni hugyozni az AMD... De lehet, hogy igy sokkal konnyebb legyartaniuk es/vagy levalidalniuk, es ezzel probalnak idot nyerni es/vagy az R&D-n sporolni.
-
#14742
Oliverda
titán
Balala2007
#14741
Oliverda
titán
válasz
Balala2007
#14741
üzenetére
Köszi!
-
#14735
hugo chávez
aktív tag
Balala2007
#14703
hugo chávez
aktív tag
válasz
Balala2007
#14703
üzenetére
Hmmm, fincsi. És végre 1/2 DP. Egy A(ccelerated)PU-nál azért ez is számít valamelyest és remélem, hogy nem csak a szerver-verziókra lesz ez érvényes!
Ha a CPU-magonkénti teljesítményben is felnő az Intelhez, akkor sínen vannak. -
#14706
Z10N
veterán
Balala2007
#14703
Z10N
veterán
válasz
Balala2007
#14703
üzenetére
Ugy nez ki kovetkezo platform valtasnal mar csak alaplapot es apu-t kell venni, mivel meg a cut-down verzio is eleg lesz otthonra (se dgpu, se dram). Ha a HSA bevalik erdekes chip kiszerelesek lesznek. Mar csak a hotermeles es a hutes a kerdes.
-
#14705
Yutani
nagyúr
Balala2007
#14703
válasz
Balala2007
#14703
üzenetére
Hát ha ez megvalósul, és egy szálon is versenyképes sebességet nyújt az Intel processzorokhoz képest, akkor nagy dobás lesz. Csak el ne
k*rjákrontsák! -
#14701
Oliverda
titán
Balala2007
#14695
Oliverda
titán
válasz
Balala2007
#14695
üzenetére
Tehát duplázták az L1D-t.
-
#14699
Valdez
őstag
Balala2007
#14695
Valdez
őstag
válasz
Balala2007
#14695
üzenetére
Mitől van ilyen eltérés a gyengébb javára?
Mindkét gép ugyanaz, egyedül a bios újabb a gyengébbiknél, ez okozhat ekkora eltéréseket?
-
#14696
stratova
veterán
Balala2007
#14695
stratova
veterán
válasz
Balala2007
#14695
üzenetére
Ohhó s végre nem ES.
Hmm, oké hogy 8 aktív CU van benne és a CPU már HDL és nem HPL, de ezek az alapórajelek ijesztően alacsonyak.
Nem úgy volt, hogy Carrizoból 35 W azért lesz?
Csak mert Acer már ráállt a 15 W-os procikra ebben a vékonyságdivatban. íÍy annak még so-so ez az órajel, de FX-8800P-ként 35 W-os modellre gondolna az ember. -
#14605
stratova
veterán
Balala2007
#14603
stratova
veterán
válasz
Balala2007
#14603
üzenetére
Köszi az infót!
Eszerint az alábbiak kerültek ki Zen-ből BDver4-hez (Excavator) képest:
CpuXOP
CpuLWP
CpuTBMAMD explicitly revealed in the description of the patch to the GNU Binutils package that “Zen”, its third-generation x86-64 architecture in its first iteration (znver1 – Zen, version 1), will not support TBM, FMA4, XOP and LWP instructions developed specifically for the “Bulldozer” family of micro-architectures.
...
While FMA4 and XOP could boost performance in gaming, HPC and multimedia applications, a promising thing that will be missed by numerous programmers is LWP, or lightweight profiling.The lightweight profiling was developed to enable code to make dynamic and real-time decisions about how best to improve the performance of simultaneously running tasks, using techniques such as memory organization and code layout, with very little overhead. The LWP is a set of hardware features in AMD “Bulldozer” processors, which should be considered when designing applications.
AMD did not comment on the new-story.
TBM (Trailing Bit Manipulation)
TBM consists of instructions complementary to the instruction set started by BMI1; their complementary nature means they do not necessarily need to be used directly but can be generated by an optimizing compiler when supported.[12] AMD introduced TBM together with BMI1 in its Piledriver[5] line of processors; AMD Jaguar processors do not support TBM.
-
#14604
hugo chávez
aktív tag
Balala2007
#14602
hugo chávez
aktív tag
válasz
Balala2007
#14602
üzenetére
A "BT" milyen architektúra rövidítése?
Szerk: közben rájöttem, Bobcat.
-
Balala2007
tag
válasz
Balala2007
#14602
üzenetére
Nocsak:
+ { "CPU_ZNVER1_FLAGS",
"Cpu186|Cpu286|Cpu386|Cpu486|Cpu586|Cpu686|CpuSYSCALL|CpuRdtscp
|Cpu387|Cpu687|CpuFISTTP|CpuNop|CpuMMX|CpuSSE|CpuSSE2|CpuSSE3
|CpuSSE4a|CpuABM|CpuLM|CpuFMA|CpuFMA4|CpuBMI|CpuF16C|
CpuCX16|CpuClflush|CpuSSSE3|CpuSVME|CpuSSE4_1|CpuSSE4_2
|CpuAES|CpuAVX|CpuPCLMUL|CpuLZCNT|CpuPRFCHW|CpuXsave|
CpuXsaveopt|CpuFSGSBase|CpuAVX2|CpuMovbe|CpuBMI2|CpuRdRnd|
CpuADX|CpuRdSeed|CpuSMAP|CpuSHA|CpuXSAVEC|CpuXSAVES|
CpuClflushOpt|CpuCLZERO" -
#14085
dezz
nagyúr
Balala2007
#14077
dezz
nagyúr
válasz
Balala2007
#14077
üzenetére
"A 3 kozul pontosan az egyik lesz, de meg nem tudom melyik"
Kösz az információt!
"Ennek semmi koze az Intelhez."
Néha van: korábban (talán még ma is) több (amúgy közcélú) distributed computing klienst is szponzoráltak, amik még akkor is csak CPU-n futottak, amikor több hasonló már 1-2 éve GPGPU alapon is működött.
"Vannak olyan problemaosztalyok, amikre a GPU alkalmatlan. Vegul is csak egy koprocesszor, nem varhato, hogy altalaban hatekony legyen mindenre."
Természetesen (bár talán nem az alkalmatlan a legjobb kifejezés, inkább nem optimális).
BTW, utánanézve, mi a helyzet pl. BOINC fronton, a következőket találtam:
"BOINC is designed to be a free structure for anyone wishing to start a volunteer computing project. Most BOINC projects are nonprofit and rely heavily, if not completely, on volunteers.
In essence, BOINC is software that can use the unused CPU and GPU cycles on a computer to do scientific computing—what one individual does not use of his/her computer, BOINC uses. In late 2008, BOINC's official website announced that NVIDIA (a leading GPU manufacturer) had developed a system called CUDA that uses GPUs for scientific computing. With NVIDIA's assistance, some BOINC-based projects (e.g., SETI@home, MilkyWay@home) now have applications that run on NVIDIA GPUs using CUDA. Beginning in October 2009, BOINC added support for the ATI/AMD family of GPUs also. These applications run from 2× to 10× faster than the former CPU-only versions. In 7.x preview versions, GPU support (via OpenCL) was added for computers using Mac OS X with AMD Radeon graphic cards." [link]Ha valakinek van kedve részt venni valamelyik projektben:
List of distributed computing projects -
#14074
dezz
nagyúr
Balala2007
#14066
dezz
nagyúr
válasz
Balala2007
#14066
üzenetére
"<>=?"
Ez mit jelent?
Köszi a listát! Remélhetőleg előbb-utóbb a GPGPU-zásba is belekezdenek a fejlesztőik. Ideje lenne... Hacsak nem az Intel szponzorálja őket a háttérben.
(#14068) Abu85: Úgy értettem, hogy külön HSA a platformra kell őket lekódolni vagy legalábbis optimalizálni? Vagy simán foghatják pl. a korábbi OpenCL kódokat (legfeljebb átírva OpenCL 2.0-ára) és lefordíthatják a HSA keretrendszer (esetleg IDE) fordítójával?
Amúgy van már HSA-s OpenCL 2.0 fordító?
A Java és egyéb hétköznapibb programnyelvek "HSA-sítása" még kicsit azért odébb van tudtommal.
-
#13972
Thrawn
félisten
Balala2007
#13971
Thrawn
félisten
válasz
Balala2007
#13971
üzenetére
Hm.
Software must not attempt to configure “DCT1” or “DCT2” - tehát hardveresen benne van a 4 memvezérlő.GDDR5 memory is not supported - Na majd a következő APU tudni fogja.
De aztán meg ilyet is írnak benne:
Ddr3Mode: The DRAM controller and the phy are configured for DDR3 mode. Note: this mode may not be supported by this processorGddr5Mode: The DRAM controller and the phy are configured for GDDR5 mode. Note: this mode may not be supported by this processor.
-
#13437
Oliverda
titán
Balala2007
#13436
Oliverda
titán
válasz
Balala2007
#13436
üzenetére
Igen, ezzel tisztában vagyok.
-
#13431
Oliverda
titán
Balala2007
#13430
Oliverda
titán
válasz
Balala2007
#13430
üzenetére
Köszi! Az IVB-hez képest írási műveletekben van jelentős lemaradás. A Haswell az L1-nél duplázta az adatút szélességét az IVB-hez képest, ami itt is jól látszik.
-
#8197
Abu85
HÁZIGAZDA
Balala2007
#8196
Abu85
HÁZIGAZDA
válasz
Balala2007
#8196
üzenetére
Biztos is, az exkluzív inkluzív különbségre gondoltam. Na de ha már itt tartunk, akkor mi a különbség a write through és a write back között? Mert nekem ezzel kapcsolatban nem ugrik be semmi. A google-t gyorsan meglesve nem is találtam semmi érdemit.
-
#8183
Abu85
HÁZIGAZDA
Balala2007
#8180
Abu85
HÁZIGAZDA
válasz
Balala2007
#8180
üzenetére
Szuper, akkor erre a rejtélyre is megvan a megoldás. Mondjuk így meg nem értem, hogy mi értelme tesztelni, amikor a szintetikus programok még nem is támogatják a procit.
Azt tudom, hogy a Bulldozer L1D es L2-i write through-ak. Az AMD régóta ezt a megközelítést alkalmazza a procijainál.
(#8178) Hakuoro: Mármint mit? A B0-t még a múlt év közepén hozták ki, így azokat az ES-eket ősszel simán szétküldték a gyártópartnereknek. A nyilván a B1 volt a tervezett modell, amiben már javították a felfedezett hibákat. Ezeket a lapkákat szerintem sokkal jobban őrzik. A B0 innentől már senkinek sem kell, így azért teszik rá a kezüket illetéktelenek.
A domainhaber lehozott egy kiszivárgott listát, hogy a kereskedelmi verzió a B2 és a C0 lesz. Elvileg az előbbi az asztali, míg az utóbbi a szerverbe megy. Később minden C0 lesz, mert már jeleznek egy 8170P-s asztali chipet is, amin 4,2/4,6 GHz a tervezett órajel. Az gondolom ez a B2-nek nem menne.
A legnagyobb kérdés a gyártókapacitás lesz, hiszen ugyanaz a gyártástechnológia, mint a Llanonál. Az egyértelmű, hogy az asztali Bulldozer lesz hátrányos helyzetben, mert a Llano azokat a piacokat fedi le, ahol nagy a kereslet ... noti, allinone, sff. Ezekre a területekre az AMD nem nevezi a Bulldozert, mert nincs benne IGP, és ez mára kizáró tényezővé vált az OEM gyártóknál. -
#8181
siriq
őstag
Balala2007
#8180
siriq
őstag
válasz
Balala2007
#8180
üzenetére
Pontos megerositest en sem kaptam cache ugyben. Mindenestre ha mukodik akkor is komoly bajok vannak. Az itteni kivesezem es irok mindenfele csodas dolgokat nekem nem megfelelo. Ezert is inkabb mashonnan szerzem az infot.
-
#6408
Oliverda
titán
Balala2007
#6405
Oliverda
titán
válasz
Balala2007
#6405
üzenetére
Nem tudom hogy ez mennyire igaz, de:
AMD have released some cache details for Orochi (Bulldozer uarch) via a patch to Open64:
L1D is 16KB, 4-way and uses 64B cache lines, with a 18 clock miss penalty. Barcelona's 64KB, 2-way with a 3 clock access latency and 11 clocks for a miss. Any clues as to whether that's good or bad, or what it could mean for L2 (since L2's shared), since it's quite a big change from K10?
-
#6019
Oliverda
titán
Balala2007
#6018
Oliverda
titán
válasz
Balala2007
#6018
üzenetére
Halmozott szmájlik helyett:
AMD embraces AVX making a new superset with SSE5(256bit support)
-
#5191
dezz
nagyúr
Balala2007
#5190
dezz
nagyúr
válasz
Balala2007
#5190
üzenetére
Lehetséges, hogy az #5188-as hsz-emet olvastad, de az #5189-est már nem...?
-
#5188
dezz
nagyúr
Balala2007
#5186
dezz
nagyúr
válasz
Balala2007
#5186
üzenetére
Hmm, azt kötve hiszem. A BKGD-ben a memóriaidőzítések nem egyeznek meg a Family 0Fh-s BKGD-ben szereplő értékekkel... De most nem tudom, hogy a Family 10h-ra jellemzőeknek felelnek-e meg. (Megjegyzem, a Kuma-t utóbb Athlon néven tervezték piacra dobni.)
-
#5187
Oliverda
titán
Balala2007
#5186
Oliverda
titán
válasz
Balala2007
#5186
üzenetére
Háát... komolyan mondom ez egyszerűen felháborító!
-
#4974
#95904256
törölt tag
Balala2007
#4973
#95904256
törölt tag
válasz
Balala2007
#4973
üzenetére
Szép...
...és logikus.Most hazarobogok és kipróbálom újra.
Rettentő nagy baromságnak tűnik amit leírtam. -
Balala2007
tag
válasz
Balala2007
#4880
üzenetére
Ebben a pdf-ben szemleletesebb leiras talalhato az AVX-rol. Az is kiderul belole, hogy a VEX prefix nem csak a REX-et es SSE-t csereli le, hanem az escape-et is (0Fh), igy igazabol nem novekszik az atlagos utasitashossz, 2 byte-os VEX-nel meg me'g nehany esetben rovidulhet is. Meg egy elony az SSE5-tel szemben...
-
#4895
#95904256
törölt tag
Balala2007
#4892
#95904256
törölt tag
válasz
Balala2007
#4892
üzenetére
Van valahol részletesebb infó a Shanghai-ról, pl. hogy 48 utas lesz az L3?
Amennyiben nő az asszociativítás, biztosra vehető hogy a késleltetés is növekszik. Bár ez a plusz órajel az L3/RAM esetében nem jelentős. Az Intel Penryn procijainál is ez történt, igaz ott az L2-vel...
-
#4893
VaniliásRönk
nagyúr
Balala2007
#4892
VaniliásRönk
nagyúr
válasz
Balala2007
#4892
üzenetére
Ebben a cikkben nem mennek bele részletekbe, finomítások biztosan lesznek, egy sima steppingváltásnál is mindig vannak.
-
Balala2007
tag
válasz
Balala2007
#4880
üzenetére
Nem tudom mennyire uj info, de itt vegre megirtak, hogy a Shanghaiban semmi architekturalis ujitas nem lesz a 6MB L3-on kivul. Semmi SSSE3, semmi SSE5, felesleges remenykedni. Vszeg az L3 latency-nek sem fog jot tenni a nagyobb meret es a nagyobb (32 vs. 48) asszociativitas. A magasabb freq-ban meg lehet remenykedni.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#4888
leviske
veterán
Balala2007
#4880
leviske
veterán
válasz
Balala2007
#4880
üzenetére
Azért még nem kell annyira temetni az AMD-t...
Nem azt ondom, hogy hűűűdeha lefogja előzni az Intelt már a jövő hónapban, de kitudja húzni azért egy darabig. Főleg, ha már sikerül átálnia 45nm-re. (szvsz)
-
#4887
P.H.
senior tag
Balala2007
#4880
P.H.
senior tag
válasz
Balala2007
#4880
üzenetére
Még nem néztem bele az AVX doksiba, de amit leírtál, arról ezek jutottak eszembe (csak a bekezdések elejét idézem, remélem, nem zavaró):
- ("SSE5 nem definiál uj architekturalis allapotot"...) a kérdés, az OS-gyártók (pl. a Microsoft) mennyire fog az AVX mellé állni, gondolok itt arra, mennyire fog visszamenni - Win98? WinME? Win2K? WinXP? Vista? - a patch-csel. Az SSE5 minddel használható lesz.
- ("SSE5 ortogonalis, azaz a regiszterek"...) az x86 egyre inkább arra haladt, hogy ortogonális megoldást adjon szinte minden korábbi register-specifikus megoldásra. Nem tudok indokot találni arra, miért jó visszatérni ehhez a szemlélethez.
- ("Az AVX a boviteseket a 2 vagy 3 byte-os VEX"...) az AMD elég korán elkezdte használni az 0F0Fh prefixet, az Intel a REP/REPNZ és az adatméretváltó byte-okat erőltette eddig. Szerintem ennek inkább decode-egyszerűsítési és valamilyen jövőbeli kiterjeszthetőségi okai vannak. Logikus, bár áldozattal jár.
- ("Az AVX onmagaban csak az alap float és"...) érdekes. Az általános, hétköznapi CPU-orientált média(/image)-alkalmazások inkább felszorzott integer adatokon dolgoznak, ahogy eddig láttam (bár mondjuk én jobban szeretem az fp-megközelítést). Talán az Intel minőségi okok miatt nem erőlteti az integer-t (DCT/IDCT, átméretezés, stb) a nagyobb adatmennyiségen dolgozó algoritmusoknál; kb. ott lehet sebességben így (jobb minőség mellett), mint a kisebb méretű integer-utasításokkal.
- ("Az SSE5 tartalmaz egy olyan FMA supportot, aminek az a hátránya"...) 16-os register-készletre nem hiszem, hogy célszerű alkalmazni valódi négyoperandusos műveleteket (több memóriaoperandus pedig kényszerűen megnöveli pl. az utasítás méretét).
-
#4882
#95904256
törölt tag
Balala2007
#4879
#95904256
törölt tag
válasz
Balala2007
#4879
üzenetére
Tudtommal van 256 bites HADD az AVX-ben.
VHADDPD (VEX.256 encoded version)
DEST[63:0] <- SRC1[127:64] + SRC1[63:0]
DEST[127:64] <- SRC2[127:64] + SRC2[63:0]
DEST[191:128] <- SRC1[255:192] + SRC1[191:128]
DEST[255:192] <- SRC2[255:192] + SRC2[191:128]
VDPPD-bol viszont tenyleg nincs 256 bitesErre mit mondjak? Úgy érzem magam mint akinek tudathasadása van.
Teljesen az rémlik hogy mikor néztem a a VHADDPx-nél DEST[255:128] (unmodified) volt írva, viszont a VDPPD-nél 256 bites volt az osztás! Ez utóbbi épp ez miatt nem is említettem. Ráadásul abban is biztos vagyok hogy nem kevertem össze a két utasítás mnemonikját...
szerk.: Természetesen az előbb letöltöttem az Intel doksit és úgy van benne ahogy írtad.
-
#4881
fLeSs
nagyúr
Balala2007
#4880
fLeSs
nagyúr
válasz
Balala2007
#4880
üzenetére
A Bulldozerben lesz SSE5, addig biztosan élni fog az AMD.
-
#4651
#95904256
törölt tag
Balala2007
#4647
#95904256
törölt tag
válasz
Balala2007
#4647
üzenetére
Azért a Barcelona maghoz képest hasonlítva, erősen eltér a die fotó. Szerintem nem lehetetlen hogy faragtak valamit a cache késleltetéseken, bár ez az elrendezés kicsit érdekes. Lehet hogy jobban fekszik majd a magasabb órajeleknek?
-
#4649
Raymond
titán
Balala2007
#4648
Raymond
titán
válasz
Balala2007
#4648
üzenetére
Epp az elobb neztem
A meresei szerint gyakorlatilag ugyanakkora mindket chip.
-
#4594
#95904256
törölt tag
Balala2007
#4591
#95904256
törölt tag
válasz
Balala2007
#4591
üzenetére
Esetleg itt ugyanazt az áramkört használja mindkét processzor, így ha egyikben ott van a hiba, akkor a másikban is. (?)
-
#4592
Oliverda
titán
Balala2007
#4591
Oliverda
titán
válasz
Balala2007
#4591
üzenetére
Mi a 312? Innen sajnos nem tudok megnyitni PDF fileokat.
-
#4114
fLeSs
nagyúr
Balala2007
#4111
fLeSs
nagyúr
válasz
Balala2007
#4111
üzenetére
de, összekevertem.
szerk: mindig összekeverem.
-
#4113
#95904256
törölt tag
Balala2007
#4112
#95904256
törölt tag
válasz
Balala2007
#4112
üzenetére
Remek!
-
#3348
#95904256
törölt tag
Balala2007
#3347
#95904256
törölt tag
válasz
Balala2007
#3347
üzenetére
Sajna nem vagyok járatos a MASM-ban, elsőre csak az SSE utasításokat sikerült felélesztenem. Illetve makrókkal az SSSE3-ig, de SSE4-re még nem találtam. A Lazy Assembler csak egy részét támogatja az SSE4-nek...
szerk.: Az ML64-et még nem próbáltam...
-
#3338
#95904256
törölt tag
Balala2007
#3331
#95904256
törölt tag
válasz
Balala2007
#3331
üzenetére
Esetleg van tipped, melyik assemblerrel lehet SSE4-es kódot fordítani?
-
#3332
dezz
nagyúr
Balala2007
#3331
dezz
nagyúr
válasz
Balala2007
#3331
üzenetére
Ismerem, de én arra gondolok, hogy ha a 2x annyi mag is alig jön ki (37,6%-os gyorsulás Intelnél clock-for-clock, E6750 vs. Q6600), és a procikihasználtság sem éppen 100% (tehát úgy tűnik, külső akadály van), akkor hogy jöhet ki ilyen szépen az SSE4 hatása?
Bár az is igaz, hogy ugyanekkor AMD-nél 71,2%-os a gyorsulás (szintén clock-for-clock, 6400+ vs. P9900). De ki tudja, hogy pusztán a szélesebb FPU, és/vagy egyéb architektúrális okokból kifolyólag.
-
#3034
zlutor
aktív tag
Balala2007
#3032
zlutor
aktív tag
válasz
Balala2007
#3032
üzenetére
Hat ez az! Mind "engineering sample" amit a tesztelok kaptak (es sikerult oket 3GHz kore tolni).
De mi lesz/van a szeria peldanyokkal?
Azok szorzo lockosak? Gondolom igen... -
#2368
#95904256
törölt tag
Balala2007
#2363
#95904256
törölt tag
válasz
Balala2007
#2363
üzenetére
Lehet hogy nagyon off-topic, de engem érdekelne hogy az ugróutasítások késleltésének mérésében miféle a kivetnivalót látsz. Illetve hogy mi az a módszer amivel a nálam alkalmazott tesztnél nagyobb késleltetési idők is kimutathatóvá válnak, természetesen nem a járulékos idők növelésével...
Az ötletet támogatom hogy nyitni kellene egy ilyen témájú PH!-s topikot. De előbb megnézem hogy létezik-e már valami hasonló...
-
#2258
#95904256
törölt tag
Balala2007
#2257
#95904256
törölt tag
válasz
Balala2007
#2257
üzenetére
Szuper!
Szép kis gyűjtemény!
-
#2113
#95904256
törölt tag
Balala2007
#2111
#95904256
törölt tag
válasz
Balala2007
#2111
üzenetére
Na jó, elhiszem hogy számít ha többen is ezt állítjátok. De mégis miért számít?
Egy új verzóval tesztelve mitől lett volna pontosabb az összehasonlítás a két állapot között? Nevezetesen hogy előszőr 10x200MHz-en járattam a CPU-t, másodszor meg 8x250MHz-en. Ezek szerint a CPU-n belül mégis csak számít valahol a 200/250 MHz-es alapórajel közti különbség? -
#2099
dezz
nagyúr
Balala2007
#2088
dezz
nagyúr
válasz
Balala2007
#2088
üzenetére
No jó. És miért pont azt az értéket írja ki a CPU-Z, és miért pont amazt az EVEREST?
Egyébként itt a Lavalys EVEREST-ről van szó? Mert akkor megragadnám az alkalmat, hogy felhívjam a figyelmeteket, hogy a program CPUID ablakában néhány adatnál hibás a terminológia. ''HTT Clock'' -> External Clock; ''HTT Speed'' -> valójában ez a HT(*) Clock (az adatcsere üteme még ennek a 2x-ese, lévén DDR, de az AMD valami miatt általában nem a duplázott értéket emlegeti, amikor az órajelről van szó); ''CPU Clock'' -> Core Clock (mivel a ''CPU'' általában az egész procira vonatkozó rövidítés).
(*) Felesleges a 2. ''T'', mivel az a Technology rövidítése lehetne itt, de azt nem szokták hozzátenni. Egyszerűen HyperTransport Linkről szoktak beszélni, írni. Sőt, a HTT inkább a Hyper-Threading Technology-ra hajaz - ide vonatkozó szöveg a Wikipedia HyperTransport bejegyzéséből:
''There has been marketing confusion between the use of HT referring to HyperTransport and the use of HT to refer to Intel's Hyper-Threading feature of some Pentium 4 based microprocessors. Hyper-Threading is officially known as Hyper-Threading Technology (HTT) or HT-Technology.
Kösz a figyelmet. -
#2089
#95904256
törölt tag
Balala2007
#2088
#95904256
törölt tag
válasz
Balala2007
#2088
üzenetére
Hali!
Természetesen sokféle programmal sokféle dolgot lehet mérni, ezért célszerű először is meghatározni hogy mit is értünk a memória késleltetése alatt. Persze ezt is sokféle képpen lehet meghatározni. A saját álláspontom az hogy a memória késleltetése az az idő amíg a memóriacellából egy adat a feldolgozó egységbe kerül mindenféle előkészítés és zavaró tényező nélkül.
Ezt megmérni nagyon nehéz. Sőt tökéletesen pontosan lehetetlen, pedig digitális az egész rendszer. Mindig akad pár zavaró tényező. A legjelentősebbek és mindig jelenlévők a prefetch mechanizmusok, a megszakítások által okozott időmérési pontatlanságok és a mérőprogram járulékos hibái ( pl. ciklusszervezés ).
Ezek ismeretében belátható hogy nincs tökéletes benchmark program. Azonban minősíteni mégis lehet őket! Még pedig az alapján hogy mennyire képesek kiszübölni a zavaró tényezőket. Ez pedig a mért értékek jól tükrözik. Értékelni a többszöri futtatás eredményeinek összevetésével lehet.
Mire kell figyelni?
1, A prefetch mechanizmusok kiküszöböléséről az érték nagysága árulkodik. Minél nagyobb, annál jobban sikerült kiküszöbölni.
2, A megszakítások mértékére az érték szórásából következtethetünk. Minél kevésbé változik az érték az újramérések során, annál jobb.
3, A mérőprogram járulékos hibái a legnehezebben észrevehetőek. Ez egy adott rendszeren közel konstans értékű, ráadásul az előbbi kettőnél kisebb hibát jelent. -
#1612
#95904256
törölt tag
Balala2007
#1600
#95904256
törölt tag
válasz
Balala2007
#1600
üzenetére
Bakter... erre meg hogy akadtál? Melyik CPU lesz képes SSE5-re?
Egyébként itt nem csak három, de négy operandusos műveleteket is említenek.
Pl.: FMADDPS dest,src1,src2,src3... naggyon döfi -
#1601
robyeger
addikt
Balala2007
#1598
robyeger
addikt
válasz
Balala2007
#1598
üzenetére
Üdv! Rég beszéltünk már, még 2006-ban
Kösz a tippet fene gondolta,hogy ilyen is van Olvastam, hogy a Vista különbséget tud tenni a magok között az XP még nem, pl: virtuális-e vagy valós fizikális. Akkor ez azt jelenti, hogy XP alatt is lehet manuálisan kiosztani a magok között a feladatot, de Vista már automatikusan is tudja optimalizálni a feladatkiosztást? Visszakanyarodva az elejére, mi van azokkal a programkódokkal, amik megkerülik az op.rendszer kernelét vagy bizonyos SSE utasítások, ahol a processzor szuverén joga felosztani a feladatokat? Lehet hogy ezért nem lehet tiltani BIOS szinten a másik magot? -
#1369
#95904256
törölt tag
Balala2007
#1367
#95904256
törölt tag
válasz
Balala2007
#1367
üzenetére
Szuper vagy! Köszönöm.
Épp pár órája ütöttem le egy Dothan-t meg egy Yonah-ot az ebay-en hogy majd letesztelhessem, de úgy látom felesleges volt.
Hogy konkrétan mi hiányzik? Hm... csak párat mondanék ami hirtelen eszembe jutott, de ha kell később összeírom egy privát üzenetben.
XCHG reg,reg
XCHG reg,mem // ez különösen érdekes eredményt tud adni
PUSH/POP reg/mem
PUSHFD/POPFD
JMP short/near // ez különösen fontos
Jcc shot/near // ez még a JMP-nál is fontosabb
SHRD/SHLD reg,reg/mem,i
BT/BTS/BTR/BTC reg/mem,reg/i // a BTC-t különösen fontosnak tartom
INC/DEC reg/mem // bocsánat most látom K8-nál már van regiszteres!
AAA/AAD/AAM/AAD/DAA/DAS/XLAT
CBW/CWD/CDQ
CLD/STD // meglepő eredményt adhat az STD!
CLC/STC/CMC/SETcc
LOOP short/near // mondjuk ezt ritkán fordítják a fordítók
(REP) LODS/STOS/MOVS/SCAS/CMPS(B/W/D) // ezt viszont sokat
LEAVE/ENTER // a legtöbb fordító a LEAVE-t használja...
FLD/FST(P) reg/mem // mondjuk ezt nem egyszerű tesztelni
FILD/FIST(P)/FRNDINT // FRNDINT különösen fontos, mert ugyan FILD+FISTP pár gyorsabb lenne a fordítók mégis ezt használják
FLDZ/FLPI/FLD1/FLDxx
FNSTSW/FNSTCW/FLDCW // szinte az összes FPU komparálásnál és truncate-nél használják
FIADD/FIMUL
FABS
FPREM/FPREM1 // maradék képzés! milyen jó is forgásszögeknél...
FSIN/FCOS/FSINCOS // ha már a szögeknél tartunk
FPTAN/FPATAN // ezt se egyszerű tesztelni...
FSCALE/F2XM1/FYL2X/FYL2XP1 // mert hatványozni néha kell és csak ez van rá...
Az SSE,MMX,3DNow! -ra nem térnék ki most, de ott is hiányzik pár dolog.
Bár most hogy közben több eredményt is megnéztem úgy tűnik az SIMD bővült.
Pl. bekerült a SHUFPS, amit pár órája még hiányoltam a letöltött EVEREST-ből. -
#1366
#95904256
törölt tag
Balala2007
#1364
#95904256
törölt tag
válasz
Balala2007
#1364
üzenetére
Nem ismerem az Everest-nek ezt a funkcióját, de tényleg jónak tűnik!
Azonban hiányolok belőle jó pár utasítást...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Az ide nem illő hozzászólások topikja:[link]
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva.
- Samsung Galaxy S24 - nos, Exynos
- Epson nyomtatók
- Kerékpárosok, bringások ide!
- Fotók, videók mobillal
- Konkrét moderációval kapcsolatos kérdések
- Óvodások homokozója
- Android alkalmazások - szoftver kibeszélő topik
- Ár-érték bajnokot avatott a Poco?
- Google Pixel 8a - kis telefon kis késéssel
- Milyen NAS-t vegyek?
- További aktív témák...
- Apple iPhone 14 128Gb Kártyafüggetlen, 1Év Garanciával
- LG 32SQ700S-W - 32" VA Smart - 3840x2160 4K UHD - 62Hz 5ms - WebOS - Wifi + BT - USB-C - Hangszórók
- Csere-Beszámítás! Playstation 5 Slim Digital edition! OLVASS!
- Beszámítás! Sony PlayStation 5 825GB SSD lemezeskonzol extra játékokkal garanciával hibátlan működés
- Új! HP 230 Vezetéknélküli USB-s Billentyűzet
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest