|
Hinnavaatlus
:: Foorum
:: Uudised
:: Ärifoorumid
:: HV F1 ennustusvõistlus
:: Pangalink
:: Telekavad
:: HV toote otsing
|
|
| autor |
sõnum  |
|
SurfData
HV Guru

liitunud: 19.05.2006
|
08.04.2011 10:53
|
|
|
| Optimist kirjutas: |
Sellest varem ka juttu olnud siin ju:
- FX 8000: 4 modules / 8 cores
- FX 6000: 3 modules / 6 cores
- FX 4000: 2 modules / 4 cores
In total, no fewer than 8 processors are set to be launched, 4 FX 8000s, 2 FX 6000s and 2 FX 4000s. |
huvitabki 8 core umbkaudne hind, et teaks vaikselt oma arvutit planeerima hakata
|
|
| Kommentaarid: 84 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
74 |
|
| tagasi üles |
|
 |
Sven
Kreisi kasutaja

liitunud: 27.04.2007
|
08.04.2011 11:14
|
|
|
| Ma pole ikka päris pihta saanud ja jõudnud kogu teemaga kaasas käia... 8 cores, aga need pole ikkagi "päris tuumad" eks ole? 1 moodul on võrdne ühe tuumaga, lihtsalt kuna sellel on 2 integer tuuma, siis OS näeb seda 2 tuumana?
|
|
| Kommentaarid: 35 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
32 |
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
08.04.2011 11:23
|
|
|
Üks moodul = 2x int tuum, 1x jagatud 256bit FP üksus. Kui kasutada 128bit SIMD instruktsioone siis saavad mõlemad int tuumad seda korraga kasutada, kui üks või teine int tuum kasutab 256bit SIMD'i siis peab teine niikaua ootama kuni esimene valmis saab. OS'i jaoks näeb igat int tuuma eraldi. Ehk siis too 4 moodul-8 int tuumaga vidin on OS'i jaoks 8 tuumaline prose.
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
 |
pohmakas,
käed värisevad

liitunud: 11.06.2009
|
08.04.2011 11:56
|
|
|
MSI to Make AM3+ Processor Upgrade Painless for its Users
techPowerUp!
|
|
| Kommentaarid: 152 loe/lisa |
Kasutajad arvavad: |
   |
:: |
1 :: |
0 :: |
126 |
|
| tagasi üles |
|
 |
1dumbpcuser
HV Guru
liitunud: 05.03.2002
|
08.04.2011 12:47
|
|
|
Jee, minu emmele tuleb ka bjoss update
Nüüd peab siis vaid prosed endid ära ootama
_________________ M: Corsair H80i v2 AIO |
|
| Kommentaarid: 87 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
0 :: |
83 |
|
| tagasi üles |
|
 |
G80
HV Guru

liitunud: 27.03.2006
|
08.04.2011 14:08
|
|
|
| Ho Ho kirjutas: |
| Üks moodul = 2x int tuum, 1x jagatud 256bit FP üksus. Kui kasutada 128bit SIMD instruktsioone siis saavad mõlemad int tuumad seda korraga kasutada, kui üks või teine int tuum kasutab 256bit SIMD'i siis peab teine niikaua ootama kuni esimene valmis saab. OS'i jaoks näeb igat int tuuma eraldi. Ehk siis too 4 moodul-8 int tuumaga vidin on OS'i jaoks 8 tuumaline prose. |
Ehk siis realselt uued AMD prosed siiski 4 tuuma?
_________________ Ära siia kliki |
|
| Kommentaarid: 240 loe/lisa |
Kasutajad arvavad: |
   |
:: |
2 :: |
0 :: |
194 |
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
08.04.2011 14:12
|
|
|
OS'i jaoks on 4 mooduliga proses tuumi 8 ning enamus rakendustes peaks need ka käituma sama moodi kui 8 "päris" tuuma. Ainult siis, kui jagatud üksused muutuvad pudelikaelaks võib jõudlus kannatada.
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
 |
Sven
Kreisi kasutaja

liitunud: 27.04.2007
|
08.04.2011 14:49
|
|
|
| Ho Ho kirjutas: |
| OS'i jaoks on 4 mooduliga proses tuumi 8 ning enamus rakendustes peaks need ka käituma sama moodi kui 8 "päris" tuuma. Ainult siis, kui jagatud üksused muutuvad pudelikaelaks võib jõudlus kannatada. |
Ehk rakendussed kus kasutatakse SIMDi?
| Lauri Kiissel kirjutas: |
MSI to Make AM3+ Processor Upgrade Painless for its Users
techPowerUp! |
Aga HT 3.1 tugi puudub eks?
|
|
| Kommentaarid: 35 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
32 |
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
08.04.2011 15:01
|
|
|
| Svenx kirjutas: |
| Ehk rakendussed kus kasutatakse SIMDi? |
Jagatud on ka x86->prose sisene mikrokood transleeriv üksus ehk siis kui mingi ime läbi on suudetud panna prose eriti palju käske järjest täitma väikse latentsuse juures võib seal samuti pudelikael tekkida. Samas on see üsnagi ebatõenäoline, väga suur rõhuv enamus koodist ei jää selle üksuse taha eales kinni.
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
 |
Optimist
Kreisi kasutaja

liitunud: 18.11.2008
|
08.04.2011 15:58
|
|
|
| Sellel jagamisel on ka omad plussid. Näiteks 3-4 SSE'd kasutavat threadi saavad nii võrdlemisi nobedalt joosta (saavad pmst topelt ressursid kätte), isegi kui rakendus ise pole 6 või 8 CPU jaoks optimeeritud. Samuti saab kirjutada rakenduse, kus 2 threadi jagavad vajadusel kiiret L2 vahemälu ühe mooduli piires, mis võib samuti teatud olukordades kasuks tulla jms
|
|
| Kommentaarid: 10 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
8 |
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
08.04.2011 16:04
|
|
|
| Optimist kirjutas: |
| Näiteks 3-4 SSE'd kasutavat threadi saavad nii võrdlemisi nobedalt joosta (saavad pmst topelt ressursid kätte), isegi kui rakendus ise pole 6 või 8 CPU jaoks optimeeritud |
Ehk räägiksid lähemalt? Minu arusaamist mööda kui kasutatakse 128bit SIMD'i siis too FPU sisuliselt jagatakse kaheks ning kumbki blokis olev int tuum saab pool omale. Kui kasutatakse 256bitist siis peavad nad kaklema kes millal FPUd kasutada saab.
Üks tuum ei saa minu teada endale 2x128bit SIMD üksust eraldada.
Infoks ka niipalju, et Inteli uusimatel prosedel on igal tuumal oma eraldi 256bit SIMD FPU mida nad ei pea kellegagi jagama. Ehk siis kui rakendus kasutab 256bit SIMD'i siis kirvemeetodiga oleks nood prosed 2x kiiremad AMD omadest.
| Optimist kirjutas: |
| Samuti saab kirjutada rakenduse, kus 2 threadi jagavad vajadusel kiiret L2 vahemälu ühe mooduli piires, mis võib samuti teatud olukordades kasuks tulla jms |
Kas on mingit infot kuidas on eri cache tasemete latentsus buldoosris? K10 puhul oli L3 ikka väga "kaugel" prosest. Buldoosril on lisaks ka L1 oluliselt väiksemaks tehtud. Kui L2 on endiselt suht-koht "kaugel" siis võib see jõudlust üsna huvitavalt mõjutada
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
 |
G80
HV Guru

liitunud: 27.03.2006
|
08.04.2011 19:48
|
|
|
Ehk siis 4 füüsilist tuuma ja 8 virtuaalset tuuma?
_________________ Ära siia kliki |
|
| Kommentaarid: 240 loe/lisa |
Kasutajad arvavad: |
   |
:: |
2 :: |
0 :: |
194 |
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
08.04.2011 19:57
|
|
|
Ei ole virtuaalsed, üsnagi reaalsed on. Lihtsalt teatud osad on kahe tuuma peale jagatud.
Samas muidugi ka Inteli virtuaaltuumade puhul on osa tuumast dubleeritud kahe paralleelse threadi jooksutamiseks kuid oluliselt vähem, kui AMDl. Kui mälu ei peta siis oli Intelil eraldi näiteks registrid ja paar teist pisemat juppi, kokku <10% ühe tuuma transsidest ilma cachet arvestamata. AMD'l on eraldi oluliselt rohkem ning tänu sellele ka on üsna tõenäoliselt ühe kaht int tuuma sisaldava mooduli jõudlus suurem, kui Intelil ühe reaalse tuuma oma mis jooksutab kaht threadi. Seda küll ainult int koodi ja 128bit simd'i puhul. Kui asi läheb 256bit simdi peale siis nagu öeldud on kirvega võttes üks AMD moodul võrdeline ühe inteli tuumaga.
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
 |
erick
HV Guru

liitunud: 24.01.2003
|
|
| Kommentaarid: 98 loe/lisa |
Kasutajad arvavad: |
   |
:: |
1 :: |
0 :: |
88 |
|
| tagasi üles |
|
 |
pohmakas,
käed värisevad

liitunud: 11.06.2009
|
09.04.2011 13:22
|
|
|
| tsitaat: |
AMD käib juba koodineegritele midagi välja
|
Õhtu sisustatud
|
|
| Kommentaarid: 152 loe/lisa |
Kasutajad arvavad: |
   |
:: |
1 :: |
0 :: |
126 |
|
| tagasi üles |
|
 |
Optimist
Kreisi kasutaja

liitunud: 18.11.2008
|
10.04.2011 12:18
|
|
|
| Ho Ho kirjutas: |
Ehk räägiksid lähemalt? Minu arusaamist mööda kui kasutatakse 128bit SIMD'i siis too FPU sisuliselt jagatakse kaheks ning kumbki blokis olev int tuum saab pool omale. Kui kasutatakse 256bitist siis peavad nad kaklema kes millal FPUd kasutada saab.
Üks tuum ei saa minu teada endale 2x128bit SIMD üksust eraldada. |
Said valesti aru. 8-tuumasel on 4 jagatud FlexFPU'd ja näiteks 3-4 threadi puhul saab neid vaadusel paremini täita kui traditsioonilises lahenduses, kus FPU on igas tuumas eraldi (threade vähem kui tuumasi).
| Ho Ho kirjutas: |
| Infoks ka niipalju, et Inteli uusimatel prosedel on igal tuumal oma eraldi 256bit SIMD FPU mida nad ei pea kellegagi jagama. Ehk siis kui rakendus kasutab 256bit SIMD'i siis kirvemeetodiga oleks nood prosed 2x kiiremad AMD omadest. |
Sama küsimus esitati ka BD blogis ja JF vastus oli selline, et FlexFPU oskab keerulisemaid operatsioone, mis teevad paljud tehted ära ühe tsükliga kui SB vajab nendest kahte tsüklit. Erinev AVXi optimeerimine kahele prosele on siit teemast varemgi kergelt läbi käinud. Päeva lõpuks oleneb jälle kuidas AVX on optimeeritud. Kui BD teeb takti kohta 2x aeglasemat AVXi on tarkvara valele AVX arhitektuurile optimiseeritud.
|
|
| Kommentaarid: 10 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
8 |
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
10.04.2011 12:34
|
|
|
| Optimist kirjutas: |
| Said valesti aru. 8-tuumasel on 4 jagatud FlexFPU'd ja näiteks 3-4 threadi puhul saab neid vaadusel paremini täita kui traditsioonilises lahenduses, kus FPU on igas tuumas eraldi (threade vähem kui tuumasi). |
Kuidas see täpselt välja näeks? Oletame, et mul on kolm threadi mis kõik hekseldavad 128bit SIMD'i millised FPU osad neid juppe teevad? Sama küsimus kolme threadi ja 256bit SIMD'i kohta. Moodulite arvu võid ise sobivaima valida
Kui pidasid silmas, et sul jookseb proses vähem threade kui on FPUsid siis see on küll paras utoopia. AMD puhul oleks prose endiselt suht piiri peale koormatud kui Intelil on pool idle's. Ehk siis teisisõnu võiks öelda, et kui koormus hoida kusagil poole peal maksimumist siis on prosed enam-vähem võrdelised kuid keda see huvitab kui praktilised proset koormavad rakendused oskavad ära kasutada kogu masinas oleva ressursi. Võta kasvõi video pakkimine. Kui võetakse kasutusse 256bit SIMD siis teoorias peaks Inteli lahendus BD kaugele seljataha jätma.. Arvestades et kõigil noil prosedel on 4+ tuuma siis peab ikka paras idioot olema kui oma programm multithreadida ning kunstlikult piirata paralleelsete threadide arvu.
| Optimist kirjutas: |
| Sama küsimus esitati ka BD blogis ja JF vastus oli selline, et FlexFPU oskab keerulisemaid operatsioone, mis teevad paljud tehted ära ühe tsükliga kui SB vajab nendest kahte tsüklit |
Kui palju sääraseid operatsioone on? Kui mälu ei peta siis enamus erinevusi on suht-koht vähetähtsates käsklsutes. Vast suurim on FMA3 vs FMA4 kuid ma ei näe, et ka too eriliselt problemaatiline oleks jõudluse koha pealt. Samuti on Intelil kahe 256bit SIMD'i jooksutava threadi peale vaja vähem andmete reistrite vahel loksutamist ja context switche kui AMD'l kus kaks proset üht SIMD üksust koormavad. Arvestades, et mõlemad prosed suudavad iga liigutatud väärtuse kohta teha üsna mitu tehet siis on üsnagi olulilne jõudluse kokkuhoid kui pole vaja pidevalt threade vahetades andmeid cachessse ja tagasi kopeerida. Seda enam kus esmainfo järgi BD L1 data cahce on oluliselt väiksem varasematest ning latentsus kasvas jämedalt kolmandiku võrra.
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
 |
Optimist
Kreisi kasutaja

liitunud: 18.11.2008
|
11.04.2011 13:48
|
|
|
Jäta nüüd korraks AVX välja. Siililegi selge, et sellega ei saa mingit boosti jagamisel kätte. Point legacy softis. Mu iva selline, et üks thread saab vs K10 rohkem FPU resursse käsutusse, kui moodul pole mitme threadiga hõivatud ja tehakse 128bit SIMDi. Ma ei tea (ilmselt mitte keegi siit foorumist täna) Flex FPU scheduleri täis võimekust sellises olukorras (võimalik et siin mängitakse lisaks veel taktiga) aga võin kihla vedada, et näiteks StarCraft2 mis sõltub tugevalt ainult 3st CPU threadist saab kamaluga FPSi juurde. Neid programme, mis päeva lõpuks kasu saaks ilma AVXi peale ümberkompileerimist on ilmselt palju.
| Ho Ho kirjutas: |
| Kui palju sääraseid operatsioone on? |
Kahtlen kas JF isegi teaks sellele küsimusele vastust. AVX kood jookseb SB per takt palju paremini, sellele pole keegi vastu vaielnud. BD's on panustanud teistele aspektidele. Isiklikult mulle ei meeldi, et AVXi peab kahel eri viisil optimeerima (loe ainult Inteli arhitektuurile optimeeritud bence on turul niigi palju). Sellegi poolest ootab teste.
Edit: Kui Hans de Vries andmed on õiged, siis arusaadav miks Intel 22nm pushib, AMD 32nm'l 13% väiksem cell size
------------------------- Intel 45nm__ Intel 32nm_____ AMD 45nm____ IBM/AMD/FS 32nm
SRAM cell size_____ 0.346 μm2 ___ 0.171 μm2 __ 0.37 μm2 ____ 0.149 μm2
NMOS drive cur. ___ 1.36 mA/μm __ 1.55 mA/μm __ 1.21 mA/μm __ 1.55 mA/μm
PMOS drive cur. ___ 1.07 mA/μm __ 1.21 mA/μm __ 0.78 mA/μm __ 1.22 mA/μm
Edit2: Huvitav kas MSI on selle ühe pini koha all vasakul oma AM3 versioonis juurde tekitanud et BD sinna sisse surada saab ?
Spoiler 
Vaatasin enda Gigabyte GA-870A-UD3 AM3 emaplaadi rev3.1(=BD supported) versiooni (mul rev2.0) ja nii ongi, 1 pin koht juures
Spoiler 
|
|
| Kommentaarid: 10 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
8 |
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
11.04.2011 17:40
|
|
|
| Optimist kirjutas: |
| Mu iva selline, et üks thread saab vs K10 rohkem FPU resursse käsutusse, kui moodul pole mitme threadiga hõivatud ja tehakse 128bit SIMDi. |
Et siis oletad, et kui ühe bloki peale on üksainus thread mis 128bit SIMD'i kasutab siis laksab too jagatud FPU parallelselt mõlema "poolega" koodi arvutada? Olen üsnagi kindel, et sellist lahendust ei tehtud. See vajaks ikka rämedalt suuri muudatusi tuuma ülesehituses ning L1'st andmete kopeerimine oleks endiselt pudelikaelaks. Rääkimata "pisut" keerukast sünkroniseerimisest. Või siiski AMD arvas et sel jamamisel on mõtet ja tegi ära selle? Kui nii siis loeks huviga. Väga tahaks näha kuidas on lahendatud sisuliselt automaatne paralleliseerimine.
| Optimist kirjutas: |
| Isiklikult mulle ei meeldi, et AVXi peab kahel eri viisil optimeerima |
See ei meeldi tõenäoliselt kellelegi aga mis teha kui ei suudeta omavahel korralikult standardeis kokku leppida.
| Optimist kirjutas: |
| võin kihla vedada, et näiteks StarCraft2 mis sõltub tugevalt ainult 3st CPU threadist saab kamaluga FPSi juurde |
Võiks ju vedada kui teaks millega võrreldakse ja milline on oodatud tulemus. Kamalutäitega on suts keerukas matemaatikat teha
| Optimist kirjutas: |
| Neid programme, mis päeva lõpuks kasu saaks ilma AVXi peale ümberkompileerimist on ilmselt palju |
Ma küll ei tea mida imet võis AMD BD'ga teha kuid oleksin vägagi üllatunud kui mõni praegune rakendus näitaks >30% jõudlust samalt taktil ja int tuumade arvu juures. Siin kohal ei pea silmas rakendusi mis on mälu ribalaiuse taga kinni. Pigem panustaks keskmiseks võrdse takti juures näidatavaks võimekuse muutuseks kusagil +0-15% vs K10 ning kõikumas mõlemas suunas sõltuvalt rakendusest (ei, 0 ei ole trükiviga).
| Optimist kirjutas: |
| ainult Inteli arhitektuurile optimeeritud bence on turul niigi palju |
Valdav enamus noist on p4 aegsed ning suur osa optimeerimistrikkidest aitasid jõudluses kaasa ka k8 peal. Lihtsalt p4'st asjaliku võimkekuse välja väänamiseks pidi noid optimisatsioone tegema, amd sai ebaoptimaalsema koodiga paremini hakkama seega vahe optimeerimata vs optimeeritu vahel oli väiksem. Kui asi intelile optimeeriti siis läks see valdavalt kiiremaks mõlemal, lihtsalt intelil oli asjast rohkem kasu. K8'l lihtsalt polnud erilisi pudelikaelu millest oleks pidanud ümber häkkima ennast.
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
 |
Optimist
Kreisi kasutaja

liitunud: 18.11.2008
|
12.04.2011 15:29
|
|
|
AMDi enda blogi kirjutab mooduli võimekusest nii:
Core1: No FP command
Core2: 2x128b un-recompiled SSE
Teatav võimekus arvutusteks on seega CPU poolel olemas. Kas ja kui hästi keskmine FP'd kasutav rakendus sellest kasu saab on hetkel selgusetu. Vbla FP scheduler analüüsib näiteks SSE koodi ja järjest laskmise asemel üritab migeid käske paralleelselt käivitada. Itaniumis tahab selline käitumine eraldi softis eelnevat modimist saada (thread suudab ennast vajadusel/võimalusel kuni neljaks jagada), näeb mis BD suudab. Isegi kõige mustema stsenaariumi kohaselt, kui ainult pool Flex FPUst on kasutusel, tähendaks see 50% väiksemat FP loadi ja see tähendaks turbo mode võimekust takti oluliselt suuremaks keerata. Lisaks L2 cache piires saab thread üksi laiata, mis IPC'le positiivselt mõjub.
| Ho Ho kirjutas: |
Võiks ju vedada kui teaks millega võrreldakse ja milline on oodatud tulemus. Kamalutäitega on suts keerukas matemaatikat teha |
Techspoti väidab, et kasutades GTX480 videokaarti teeb Phenom II X4 965@3,4Ghz Starcraft II's (1.0.0.16117) 1920*1200 Ultra resolutsioonil keskmiselt 35fpsi. "Täna on ilus ilm", seega oletan et launchil välja tulnud kiireima taktiga BD suudab selle numbri viia vähemalt 60ni (+58%). Place your bets ppl
Ahjaa, SB FP moodulil on mõned miinused BD'ga võrreldes. Int ja FP scheduler on üks ja seesama, mis tähendab, et FP üksuse head täituvust on SB's raske saavutada. Intel ilmselt teab seda. Mälu loade tehakse IMO 3x128bit taktis tuuma kohta, millega ei täideta kuidagi 2x256 AVX käske pikemas perspektiivis ära. BD FMA4 võimekus on juba mainitud (osad tehted saab nii ühe taktiga ära teha kahe asemel), lisaks suudavad kõik BD pipeline'id teha näiteks FADD tehet. SB FP pipeline'd aga on jagatud tarkusega ja kõik kõike ei oska (FADD tugi oli vist ainult ühel pipeline'il kolmest). Teatud rakendustes võib nii tekkida lisaks pudelikaelu. Teoorias on seega võimalik kirjutada AVXi "bench", kus BD on takti kohta kiirem kui SB.
|
|
| Kommentaarid: 10 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
8 |
|
| tagasi üles |
|
 |
erick
HV Guru

liitunud: 24.01.2003
|
12.04.2011 15:35
|
|
|
| Optimist kirjutas: |
Techspoti väidab, et kasutades GTX480 videokaarti teeb Phenom II X4 965@3,4Ghz Starcraft II's (1.0.0.16117) 1920*1200 Ultra resolutsioonil keskmiselt 35fpsi. "Täna on ilus ilm", seega oletan et launchil välja tulnud kiireima taktiga BD suudab selle numbri viia vähemalt 60ni (+58%). Place your bets ppl  |
Sul on tagurpidimatemaatika. Kui 35 fps-ist saab korraga 60, siis edasiminek on 71% (nagu 70 fps oleks 100% ehk 2x kiirem).
_________________ WoT Stats Twitch Stream Ei näe uusi poste WoT teemas? Kliki siia! |
|
| Kommentaarid: 98 loe/lisa |
Kasutajad arvavad: |
   |
:: |
1 :: |
0 :: |
88 |
|
| tagasi üles |
|
 |
Optimist
Kreisi kasutaja

liitunud: 18.11.2008
|
12.04.2011 20:18
|
|
|
My bad jah, +71% siis ikka
|
|
| Kommentaarid: 10 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
8 |
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
13.04.2011 22:32
|
|
|
| Optimist kirjutas: |
AMDi enda blogi kirjutab mooduli võimekusest nii:
Core1: No FP command
Core2: 2x128b un-recompiled SSE
Teatav võimekus arvutusteks on seega CPU poolel olemas. Kas ja kui hästi keskmine FP'd kasutav rakendus sellest kasu saab on hetkel selgusetu. Vbla FP scheduler analüüsib näiteks SSE koodi ja järjest laskmise asemel üritab migeid käske paralleelselt käivitada |
Kui tekstist õigesti aru sain siis on AMD sisuliselt teinud makro-op fusioni SIMD käskude jaoks kus osatakse kokku keevitada FADD ja FMUL operatsioonid üheks FMADD'iks ning noid oskab siis prose jooksutada praktiliselt topeltkiirusel. Samas võibolla sain asjast valesti aru.
| Optimist kirjutas: |
Techspoti väidab, et kasutades GTX480 videokaarti teeb Phenom II X4 965@3,4Ghz Starcraft II's (1.0.0.16117) 1920*1200 Ultra resolutsioonil keskmiselt 35fpsi. "Täna on ilus ilm", seega oletan et launchil välja tulnud kiireima taktiga BD suudab selle numbri viia vähemalt 60ni (+58%). Place your bets ppl  |
Tjah, see jääb väga suuresti sõltuma millise takti peal BD välja tuleb kuid mind isiklikult takt niiväga ei huvitagi vaid tuuma enda efektiivsuse kasv. Ma ise pakuks võrdse takti ja tuumade arvu juures max 30% jõudluskasvu (35->~45-46FPS). Vastavalt siis tuleb skaleerida takti erinevusega
| Optimist kirjutas: |
| Ahjaa, SB FP moodulil on mõned miinused BD'ga võrreldes. Int ja FP scheduler on üks ja seesama, mis tähendab, et FP üksuse head täituvust on SB's raske saavutada. Intel ilmselt teab seda |
Samas pole see eriliseks probleemiks kuna ....
| Optimist kirjutas: |
| Mälu loade tehakse IMO 3x128bit taktis tuuma kohta, millega ei täideta kuidagi 2x256 AVX käske pikemas perspektiivis ära |
Kui mälu ei peta siis Core2 ja K10 saavad SIMD registritesse kopeerida max 128bit andmeid per takt, ehk siis võid küll neid loade-savesid ritta laduda aga lihtsalt kanalid on liiga kitsad. Paraku pole kursis kas ja kudias on kanalite mahutavus muutunud BD/SB puhul kuid olen üsnagi kindel et see on endiselt korralik pudelikael, eriti 256bit puhul.
Kui pidasid aga silmas, et ei suudeta piisavalt käske ette sööta, et FP üksust koormuse all hoida siis selle pärast ma niiväga ei muretseks. On ülivähe koodi, mis suudaks pidurduda schedulerist tekkiva pudelikaela tõttu. Rõhuv enamus SIMD koodist jääb kinni eelkõige koodi sõltuvuse (peab ootama kuni eelmine tehe valmis), mälust laadimise või lihtsalt keerukamate tehete täitmise taga. Scheduleri umbe ajamiseks jääb paraku 16 registrist selgelt väheks. Kui räägiksime Poweri või SPU stiilis 32-128 SIMD registrist siis juba võiks hakata scheduleri läbilaske pärast muretsema
| Optimist kirjutas: |
| Teoorias on seega võimalik kirjutada AVXi "bench", kus BD on takti kohta kiirem kui SB. |
See poleks eriline ime. Annab kirjutada ka säärast SIMD koodi mis on K10 peal per-takt kiirem, kui Core2'l
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
 |
Optimist
Kreisi kasutaja

liitunud: 18.11.2008
|
14.04.2011 13:12
|
|
|
| Ho Ho kirjutas: |
| Kui tekstist õigesti aru sain siis on AMD sisuliselt teinud makro-op fusioni SIMD käskude jaoks kus osatakse kokku keevitada FADD ja FMUL operatsioonid üheks FMADD'iks ning noid oskab siis prose jooksutada praktiliselt topeltkiirusel. Samas võibolla sain asjast valesti aru. |
Nii sain mina ka sellest aru. Vaatamata võimalikele mälukontrolleri piirangutele BD ES testides esineb mõningaid anomaalselt häid FP tulemusi. FMADD võib olla üks panustajatest.
| Ho Ho kirjutas: |
| Kui pidasid aga silmas, et ei suudeta piisavalt käske ette sööta, et FP üksust koormuse all hoida siis selle pärast ma niiväga ei muretseks... |
SB perf analüüs on juba näidanud kerget FP arvutuste pudelikaela mälu läbilaskevõimes. BD Flex FPU on küll lisanud märkimisväärselt latentsust aga läbilaske pudelikaelad on väidetavalt palju väiksemad ja dedicated scheduler parandab kindlasti täituvust. BD jaoks optimeeritud kood võiks siin ideaalis seega väga hästi lipata isegi madalal taktil.
| Ho Ho kirjutas: |
Annab kirjutada ka säärast SIMD koodi mis on K10 peal per-takt kiirem, kui Core2'l  |
Siia sobiks üks teise foorumi kasutaja 2010-11-01 @ 05:12:38 am kommentaar.
| Phenom-X @ citavia.blog.de kirjutas: |
However e.g. if it should be true that mul increases in latency that would be e.g. bad for me, because I liked to use mul to optimize for AMD (which are mul-monsters), but you have to know, that Intel which is not as good in mul heavily tries to avoid muls with icc and translates them whenever possible to lea/add sequences which resulted in icc compiled code to be great on Intel and bad on AMD. However with faster lea and slower mul that just speeds up AMD on icc code. And then with a frequency plus ... |
Huvitav et BD jutt keskendub pea alati Flex FPU võimaluste ümber. Täisarvu üksuse poolel ei rõhutata tihti sedagi, et on teine kompaktne, suurema läbilaskega ja ca 4Ghz juures turbo reziimis korralik loom. Täisarvu üksus skaleerub taktiga võrreldes väga palju paremini, kui suure latentsusega ujuvkoma arvutamine. SB peal tegi takti lisamine täisarvutamist 80% ja ujuvkoma ainult 40% kiiremaks. Eraldi schedulerid BD's seega väga loogiline lahendus nagu ka pisikesed vähe voolu tarbivad ja palju kellatavad täisarvutamise üksused. FPU osa on aga taktkiiruse asemel kostitatud lisatarkuse ja jõuga. Ma ei tea mitmes kord ma seda juba ütlen aga AMD lähenemine BD's mulle jätkuvalt meeldib.
|
|
| Kommentaarid: 10 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
8 |
|
| tagasi üles |
|
 |
Ho Ho
HV Guru

liitunud: 16.02.2002
|
14.04.2011 14:04
|
|
|
| Optimist kirjutas: |
| BD Flex FPU on küll lisanud märkimisväärselt latentsust aga läbilaske pudelikaelad on väidetavalt palju väiksemad ja dedicated scheduler parandab kindlasti täituvust |
on sul ehk ka infot kuidas kõrgem latentsus mõjutab säärast koodi kus järgmise tehte algväärtused tulevad eelmise tehte vastustest?
| Optimist kirjutas: |
| suurema läbilaskega [int tuumad] |
Mingit konkreetset võrdlust k10'ga ka on?
| Optimist kirjutas: |
| 4Ghz juures turbo reziimis |
Kui turbo laeks jääb selle aasta jooksul 4GHz siis olen üpriski pettunud. Pigem ootaks, et see võiks olla non-turbo takt millega välja tullakse.
_________________ Teach a man to reason and he'll think for a lifetime
Common sense - so rare that it's a damn superpower
Vaadates paljude inimeste sõnavõtte siin ja mujal jääb üle ainult klassikuid tsiteerida - "I weep for humanity" |
|
| Kommentaarid: 106 loe/lisa |
Kasutajad arvavad: |
   |
:: |
0 :: |
1 :: |
86 |
|
| tagasi üles |
|
 |
|