Hirdetés
-
Az Apple megszerezné a klubvilágbajnokság közvetítési jogait
ph A vállalat ezért irgalmatlan pénzt fizetne a FIFA-nak, és ezzel rajzolná át az online streaming platformok háborújában a frontvonalakat.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
Hamarosan indul a SERUM korai hozzáférése PC-n
gp A belső nézetes túlélőjáték premierje május végétől lesz elérhető.
-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
#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... -
#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. -
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?
Keresem a 9th Company: Roots Of Terror játék magyar feliratos változatát,mindenféle megoldás érdekel; Intel Pentium-D940/''C1''stepping/ (1.3V-200x16) @ (1.43V-333x12) 4Ghz
-
#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 -
#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. -
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. -
#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? -
#95904256
törölt tag
válasz Balala2007 #2257 üzenetére
Szuper!
Szép kis gyűjtemény!
-
#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ó...
[ Szerkesztve ]
-
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...
Amit írok az nem az igazság, hanem a véleményem... ;-)
-
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.
-
#95904256
törölt tag
válasz Balala2007 #3331 üzenetére
Esetleg van tipped, melyik assemblerrel lehet SSE4-es kódot fordítani?
-
#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...
[ Szerkesztve ]
-
#95904256
törölt tag
válasz Balala2007 #4112 üzenetére
Remek!
-
fLeSs
nagyúr
válasz Balala2007 #4111 üzenetére
de, összekevertem.
szerk: mindig összekeverem.
[ Szerkesztve ]
"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."
-
Oliverda
félisten
válasz Balala2007 #4591 üzenetére
Mi a 312? Innen sajnos nem tudok megnyitni PDF fileokat.
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
#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. (?)
-
Raymond
félisten
válasz Balala2007 #4648 üzenetére
Epp az elobb neztem
A meresei szerint gyakorlatilag ugyanakkora mindket chip.
Privat velemeny - keretik nem megkovezni...
-
#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?
-
fLeSs
nagyúr
válasz Balala2007 #4880 üzenetére
A Bulldozerben lesz SSE5, addig biztosan élni fog az AMD.
"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."
-
#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.
[ Szerkesztve ]
-
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).
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
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)
-
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.
AIDA64.com
-
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.
"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)
-
#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...
-
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...
AIDA64.com
-
#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. -
Oliverda
félisten
válasz Balala2007 #5186 üzenetére
Háát... komolyan mondom ez egyszerűen felháborító!
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
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.)
[ Szerkesztve ]
-
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...?
-
Oliverda
félisten
válasz Balala2007 #6018 üzenetére
Halmozott szmájlik helyett:
AMD embraces AVX making a new superset with SSE5(256bit support)
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
Oliverda
félisten
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?
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
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.
Meg mindig nincs 1000 oras BF3 nev, kozben mar masok is erdeklodnek utana... Mar bevallottan nincs 1000 ora neki... Varjunk Dec 31-ig a Mantle-a.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Oliverda
félisten
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.
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
Oliverda
félisten
válasz Balala2007 #13436 üzenetére
Igen, ezzel tisztában vagyok.
[ Szerkesztve ]
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
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.
Different songs for different moods. łłł DIII Thrawn#2856 łłł Look! More hidden footprints! łłł D4BAD łłł WoT: s_thrawn łłł
-
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.
-
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 -
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"[ Szerkesztve ]
AIDA64.com
-
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.
[ Szerkesztve ]
"sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari
-
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.
[ Szerkesztve ]
-
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.[ Szerkesztve ]
-
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?
-
Oliverda
félisten
válasz Balala2007 #14695 üzenetére
Tehát duplázták az L1D-t.
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
Yutani
nagyúr
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!#tarcsad
-
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.
# sshnuke 10.2.2.2 -rootpw="Z10N0101"
-
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."sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari
Új hozzászólás Aktív témák
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.
- Crypto Trade
- gban: Ingyen kellene, de tegnapra
- Építő/felújító topik
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- A fociról könnyedén, egy baráti társaságban
- LEGO klub
- Dell notebook topic
- eBay-es kütyük kis pénzért
- Vicces képek
- Samsung Galaxy S23 Ultra - non plus ultra
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen