- Linux kezdőknek
- Hálózati / IP kamera
- Sweet.tv - internetes TV
- A Microsoft feltalálta az olcsó AI-t
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Musk szerint már jövőre itt vannak a Tesla Optimus humanoid robotok
- Otthoni hálózat és internet megosztás
- Synology NAS
- Windows Insider Program
- Milyen routert?
Új hozzászólás Aktív témák
-
GIJoe
addikt
Opteron 6262 HE (16 mag) 85 TDP kellemes...
-
Devid_81
nagyúr
Kérnék egy 8 magvasat.
- 16 lett, maradhat?Azért a 16 magvasnak egy ideig elégnek kellene lenni egyes szerverekben.
Aranyosak...
-
M@cika
őstag
Nekem a 6212 tetszik, mert csak 300$
Nasit a kis fehér medvének!
-
JoeYi
őstag
16 mag
Intel is jön majd 16 maggal meg 32 threaddel?
-
.mf
veterán
Jelennének meg végre a Dell szerverekben is...
Fotóim és kalandjaim a világ körül: https://www.facebook.com/fmartinphoto/
-
mdraco
őstag
A 8 mag 35 tdp-s a notebookokba is jo lenne, nem?
-
vanhalen
senior tag
(#5) LordX "Ha az AMD-s 'mag' értelmezést átfordítjuk Intelesre, ez egy 8 magos, 16 szálas processzor. Persze nem teljesen, mert míg a HT esetében minden megosztott a két szál között, itt van dedikált végrehajtóegység"
(#7) vanye: "Egy korábbi hírnél én is kamilláztam, hogy bazz, ezeknél az új Opteronoknál nem semmi a mag/fogyasztás-érték... Aztán rájöttem, hogy az AMD-magokat mára már kettővel kell osztani"
Mintha féléven belül Abu-nak lett volna erről egy cikke. Ha emlékezetem nem csal, ezek "rendes" magok és csupán azért oldották meg így (modul) mert így olcsóbb licencelni a szerver-üzemeltetőknek a rákerülő OS miatt és így kelendőbb, mert jobban megéri nekik, mintha duplán fizetnének a mag (processzor) szám után (ami így 8magos esetén 4 "processzor" vagyis "modul" a szerver OS felé. Aztán lehet, hogy rosszul emlékszem, engem nem érint különösebben, de valami ilyesmiről volt szó a cikkben. Akit érdekel, úgyis utána néz
[ Szerkesztve ]
-
vanye
senior tag
"In terms of hardware complexity and functionality, a module is midway between a dual-core processor (in which each core is fully independent) and a single processor core that has two SMT threads (in which each thread shares most of the hardware resources with the other thread)."
Egy ilyen modul tehát technikai értelemben az egy és a kettő mag között van félúton. Ezt a modulos névhasználatot többek között az olyan megoldások indokolják, mint pl. az egy modulban lévő két mag közös másodszintű gyorsítótára. Kb. Hyper Threading AMD-módra. Vagy némileg azért gyorsabb annál. Teszteknél majd kiderül.
[ Szerkesztve ]
Stern des Südens!
-
LordX
veterán
1 modulban 2 darab hardver szál van, pontosan úgy, mint az Inteles HT esetében. Mindegyik szálon tud lebegőpontos számítást csinálni, csak max. az azonos modulon belüli két szál blokkolja egymást, ha mindkettőben épp lebegőpontos utasítás van. Illetve csak blokkolná, mivel out-of-order az egész, így hacsak nem minden egyes utasítás mindkét szálban lebegőpontos (előfordulhat, de szerintem ritka), mindkét szál tovább tud futni.
-
NLZ
tag
Szerencsére kezdenek leszokni a szoftvergyártók a magszám limitálásról, pl vmware is már csak annyit mond, hogy szerverenkénti processzorszám számít.
-
Mozsa
tag
Abu ebben a cikkben miért nem jegyezted meg, hogy remélhetőleg az új sorozat sikeresebb lesz mint az elődjei, amivel az amd leminimalizálta szerver piaci részesedését. Mert olyan szép első bekezdést írtál az inteles hírhez, igazad is van, mert az olvasókat folyamatosan emlékeztetni kell, valamint az esetleges új olvasókra is gondolni kell, akik lehet hogy nem tudnak a sandy bridge-e procik hiányosságairól.
Szóval én csak arra gondolok, hogy nem lenne-e érdemes ezt a cikket is a fentiekkel kezdeni, hátha olyan olvassa, aki nincs tisztába vele, hogy mennyire nem fogytak az opteronok előző sorozatai.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Miért kellene arról találgatni, hogy mi mennyire lesz sikeres? Ilyenbe sose mentünk bele, nem is a profilunk. Vannak erre piackutató cégek, akik évek óta a piac alakulásával foglalkoznak.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Mozsa
tag
Nem kell találgatni, bár én sejtem mennyire lesz sikeres.
Én a múltra gondolok, ahogy írtam is. Én alapvetően arra gondoltam, hogy a sandy bride-e procik problémáiról volt már cikk. Most egy teljesen más, a hűtéssel foglalkozó hírt miért kellett ezzel kezdeni? Értem különben, tájékoztatni kell az olvasókat.
Mivel nem vagyunk ugye részrehajlóak, akkor az amd hírét is lehetne azzal kezdeni, hogy beszámolunk az előző sorozat problémáiról, jelen esetben hogy nem vették őket.[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
És a múlt mennyire befolyásolja a jövőt?
Nem tudom leírni, hogy miket vezet be a Bulldozer a szerverpiacon, mert a technikai részletekre NDA-nk van, de a HPC szerverek piacán nem kicsit lesz gyorsabb az FMA-ra fordított kód. De erről majd beszámolunk.
Ne rajtunk verd le, hogy a Sandy Bridge-E-ben hibák maradtak, nem mi tehetünk róla. Ez a cég tehet róla: [link]
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Mozsa
tag
Ezek szerint nem érted, illetve nem akarod érteni.
Miért kezdted a mai intel hírt azzal, amiről már egy másik hírben / topikban volt szó, és abszolút nem passzol a mai hírhez? Ha ezt megtetted, ami negatívan hat ugye, akkor kérdem én miért nem teszed meg ugyan ezt ebben az amd-s hírben is, mert lehetne arról beszélni, hogy nem voltak sikeresek az előző sorozat procijai, és ugye pontosan akarunk tájékoztatni. Vagy egyszer így, egyszer úgy?
Kérlek ezekre válaszolj
Egyébként másnak [is]
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Válaszoltam már. Nem mi tehetünk arról, hogy a Sandy Bridge-E processzorokban maradtak hibák. Közöm nem volt a tervezéshez, ezt elhiheted.
Mi volt az előző generációs Opteron technikai problémája? Nem tudok róla. A gazdasági résszel kapcsolatban pedig már számtalanszor leírtam, hogy az IT Cafe foglalkozik.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
vanye
senior tag
Az, hogy eddig problémák voltak az egész LGA2011-es platform körül, az simán kapcsolódhat egy másik, szintén ennek a platformnak egy ügyes-bajos dolgáról (CPU-hűtés) szóló íráshoz.
Az viszont eléggé önkényes lenne, ha egy szerverprocesszor előrendelhetőségéről (!) említést tevő hírnél Abu ad hoc az előző széria defektjeiről kezdene el értekezni.
Ha pedig úgy érzed, hogy a nem egyenlő bánásmódra megy ki a játék, akkor panaszod itt jelezd.[ Szerkesztve ]
Stern des Südens!
-
hugo chávez
aktív tag
"a HPC szerverek piacán nem kicsit lesz gyorsabb az FMA-ra fordított kód."
No, arra nagyon kíváncsi leszek, hogy pontosan mennyivel is lesz gyorsabb ugyanazon kód FMA-re is optimalizált változata a 8 magos Bull-okon, mint a 4 magos Sandy-ken az AVX-re optimalizált változat.
[ Szerkesztve ]
"sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari
-
Abu85
HÁZIGAZDA
válasz hugo chávez #26 üzenetére
Nem nehéz kitalálni, hogy sokezer százalékkal, hiszen hardveres FMA nélkül szoftvereset kell emulálni, ami nyilván megöli a teljesítményt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
hugo chávez
aktív tag
Ehh, nem vagyok én abban olyan biztos, anno előástam egy doksit, amiben Itanium-on méregettek FMA-vel és FMA nélkül, íme, 13-14.oldal, de azt se felejtsük el, hogy jelen állás szerint azonos FPU órajel esetén a 4 magos Sandy-k peak 256 bites AVX-ben kétszer erősebbek, mint a 8 magos Bull-ok lesznek.
Ja, miért kéne emulálni? Ha nincs, akkor nincs, attól még csinálhatja az adott cpu az adott feladatot a saját maga által támogatott utasításkészletekkel is, csak így akár jóval több is lehet a végrehajtási idő. Vagy rosszul gondolom?Ezt a szerintem orbitális bullshitet meg inkább hagyjuk.
[ Szerkesztve ]
"sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari
-
LordX
veterán
válasz hugo chávez #28 üzenetére
A cikkben pont az van, hogy némely esetben az FMA-s kód 30%-al gyorsabb, mint az FMA nélküli..
FMA nélkül ugyanazt nem feltétlen egyszerű megcsinálni, mert ha szorzok-összeadok külön, akkor a szorzás részeredménye bekerül valami temporális helyre, ami az ábrázolás miatt növeli a hibát. Ha a hiba elviselhető, akkor "csak" ~2x annyi utasítás, ha viszont nem, akkor tessék felkötni a nadrágot.
-
Abu85
HÁZIGAZDA
válasz hugo chávez #28 üzenetére
Mert, az FMA a MAD-hoz képest csak egyszer kerekít, vagyis ha pontosabb eredményt akarsz, akkor szoftver szinten kell megoldani a MAD kétszeri kerekítésének problémáját, amit az FMA hardver szinten megold. Ezért van azon a képen olyan gyorsulás. Ha pedig nem számít a pontosság, akkor meg FMA-ra nincs szükség.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
hugo chávez
aktív tag
"A cikkben pont az van, hogy némely esetben az FMA-s kód 30%-al gyorsabb, mint az FMA nélküli.."
Bezony, némely esetben kemény 30-40%, hogy is viszonyul ez az itt-ott szárnyrakapott 20-56-szoros gyorsuláshoz?
"Ha a hiba elviselhető, akkor "csak" ~2x annyi utasítás, ha viszont nem, akkor tessék felkötni a nadrágot."
Nyilván lehetnek olyan "helyzetek", amikor problémái lehetnek egy olyan cpu-nak, ami nem támogatja az FMA-t és, mivel nem vagyok programozó, ezért nem is látom át ezt teljes egészében, de, továbbra is fenntartanám a kételyeimet az FMA sebességre gyakorolt jelentős (~2x-esnél nagyobb) pozitív hatásának kapcsán.
(#31) Abu85:
"Ezért van azon a képen olyan gyorsulás."
Hát, azért én megvárnám a megjelenést és a független teszteket, mielőtt elhinném azt a bizonyos képet. Gyanús ez nekem, ráadásul te is írtad, hogy az Intel jelenlegi OpenCL meghajtója finoman szólva sem áll a helyzet magaslatán. Meg, mondjuk, én azért arra is kíváncsi lennék, hogy, amennyiben biztosan lehetne tudni, hogy nem AMD, hanem NV kártya van a tesztgépben, akkor is ilyen eredmény született volna-e?
Még régebben dezz-zel beszéltünk ilyesmikről, akkor találtam ezt a másik doksit is, N-test szimuláció AVX támogatással Sandy-n és láthatóan nagyon jól ki is tudja használni a Sandy FPU-it, na, itt írják azt is, hogy várják az FMA-képes procikat, szóval, ha kijön a Bull és megcsinálják ehhez a progihoz az FMA optimalizációt, akkor majd lehet szépen összemérni őket, hogy valójában mennyit is hoz a Bull FMA-je a konyhára, a Sandy-vel szemben.
[ Szerkesztve ]
"sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari
-
Abu85
HÁZIGAZDA
válasz hugo chávez #32 üzenetére
Mindegy, milyen VGA van procik mellett. A teszt FMA része csak a CPU-ra fut. Láttam a tesztcsomagot, szándékosan így van beállítva (egy batch fájl van, ahol paraméterezve van a program csak a CPU-ra). Természetesen az Intel emulálja az FMA-t, hiszen a hardver nem képes rá. Azért van ekkora különbség köztük.
A test guide-ban az AMD már az 1.5-os Intel OpenCL meghajtóval mért (az már elég korrekt, az 1.0-s meghajtó valóban nem acélos). Ott is hasonlóan nagy a különbség. Majd ha lejár az NDA, akkor odaadom a táblázatot. Igazából az egész előny a hardveres és az emulált FMA közötti különbségből adódik. Márpedig, ha fontos a pontosság, akkor kell az FMA, ha nem kell a pontosság, akkor pedig jó a MAD. Arról is van táblázat persze, majd annak az eredményeit is odaadom.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
hugo chávez
aktív tag
"A teszt FMA része csak a CPU-ra fut. Láttam a tesztcsomagot, szándékosan így van beállítva (egy batch fájl van, ahol paraméterezve van a program csak a CPU-ra)."
Az a baj, hogy a múltkori slide-juk után már nem tudok feltétel nélkül hinni az AMD-nek...
"Majd ha lejár az NDA, akkor odaadom a táblázatot. "
"Arról is van táblázat persze, majd annak az eredményeit is odaadom. "Köszi a megtiszteltetést. Bár, nekem akár az is megfelel, ha majd beleteszed egy Bull hírbe.
Közben látom, hogy az AIDA64 FPU Julia és FPU Mandel bench-e már támogatja az AVX mellett az FMA4-et is [link], szóval, már akár 12-én kiderülhet, hogy sebességben mennyit jelent az FMA.
[ Szerkesztve ]
"sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari
-
Abu85
HÁZIGAZDA
válasz hugo chávez #34 üzenetére
A hírbe nem akarom beletenni az eredményeket, mert az emulált FMA nagyon lassú. Az otthoni felhasználók esetében ez nem fontos fícsőr. Megemlítés szintjén lesz, hiszen a HPC szervereket komolyan érinti. Ott nyilván kiemelten fontos az FMA, de otthon, szerintem nincs jelentősége. Szerintem alig lesz rá program, de ott is úgy lesz, hogy az FMA az Intelen nem lesz emulálva, vagyis a Bulldozer előnye annyi, hogy pontosabban számol. A gyorsulás a MAD-hoz képest nem olyan jelentős. Ami otthonra is számít az az XOP. Főleg a videó transzkódolóknál nagy előny.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
hugo chávez
aktív tag
Ok, értem, akkor jöhet majd privátban, vagy akár mailben.
Nem akarom nagyon szétoffolni a topikot, de, visszatérve még egy kicsit az FMA pontosságára, találtam pár doksit [link] és [link], csak az a baj, hogy én nem biztos, hogy helyesen tudom értelmezni , talán, ha P.H. erre járna, akkor segíthetne ebben.
Persze, ha lenne (van?, lesz?) olyan független bench, ami használja az AVX-et és az FMA4-et is és, amivel nem csak a sebességet, hanem a pontosságot is össze lehet hasonlítani a Bull és a Sandy között, az lenne az igazi.
[ Szerkesztve ]
"sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari
-
P.H.
senior tag
válasz hugo chávez #36 üzenetére
Eléggé szét van matematikázva a két link, megpróbálom egyszerűbben (és egyszerűítésekkel) leírni a lényeget, de így a kályhától kell kezdenem.
Az IEEE 754 szabvány írja le, hogy hogyan kell számítógépen ábrázolni a lebegőpontos számokat: nyilván nem meglepő, hogy kettes számrendszerbeli normálalakban, azaz 1.yyy...y*2^xxx...x formában, ami valójában az y-ok számát (azaz hány bitnyi y-információ van, az előjellel együtt) és az x által ábrázolható kitevők számát (azaz x hány bites) jelenti.
32 biten (Single Precision) 24 y-bit és 8 x-bit van
64 biten (Double Precision) 53 y-bit és 11 x-bit van
80 biten (Extended Precision) 64 y-bit és 15 x-bitAz x (kitevő) bitek száma megadja a legnagyobb és legkisebb nagyságrendet, amit az adott mód ábrázolni tud, azaz 32 bites SP esetén pl. +/- 2^127. Ebből azonnal látható, hogy mivel csak 24 bit áll rendelkezésre mellette - a tizedesjegy mintájára inkább - "kettedesjegynek" hívható valós értékből, így az ábrázolható érték pontossága függ a nagyságrendjétől, konkrétan pl. 2^24 feletti nagyságrendben már nem ábrázolható SP-ben minden egyes egész szám sem külön-külön. Ezért a számítási pontosságot nem abszolútértékben, hanem ulp -ben adják meg.
Lefordítom 10-es számrendszerre, így érthetőbb: ha van egy (feltételezett) adattárolási formánk, ami 3 tizedesjegyig tud ábrázolni, azaz [1-9].yyy*10^x, akkor ha x=5 esetében 100000 feletti számokról beszélünk. Ha ezzel műveleteket végzünk és a CPU 0.5 ulp pontosságot tud, akkor 0.5*10^(5-3)=50 pontossággal tudunk számolni, azaz 100000+1 esetén 100000 lesz a végeredmény, 100000+24 esetén is 100000 lesz, míg 100000+25 esetén, ha kerekítésnek a legközelebbi felé"-t választjuk, akkor 100050 lesz. (SP esetében 100000 nagyságrendű számoknál ez már 0,0001 pontosság lesz, tehát pl. ha olyan bemeneted van, ami 1000000-110000 közötti számokat jelent, akkor a GPS koordinátákra már alkalmatlan a 32 bit SP).
Kerekítés lehet negatív végtelen, pozitív végtelen, 0 vagy legközelebbi felé, ezt a programozó állítja be (vagy egy Control Word-del vagy magában az utasításban kódolva). A CPU belül, legyen a működési módunk 32, 64 vagy 80 bites, pár "kettedesjeggyel" többet ábrázol a számítás folyamán és a végén kerekíti le a megadott módnak megfelelően, ezt a kerekített értéket kapja meg a következő számítás bemenetként.Amennyiben ez a belső eredmény túlmegy a működési mód ábrázolási határain, azaz abszolútértékben nagyobb vagy kisebb, mint az ábrázolható legnagyobb vagy legkisebb abszolútértékú szám, akkor kerekítésnél +/- végtelent vagy denormált értéket kapunk (ami 0.yyy...y*2^x formájú) kapunk, innen lőhetjük a további számításokat. Rosszabb esetben a számítási kapacitást is lőhetjük, mivel végtelennel vagy denormálttal tovább számolni legalább 10x annyi órajelbe telik, mint "rendes" számokkal.
FMA esetében kitolódik ez az ábrázolási maximum/minimum is, mivel a 2 művelet után történik csak kerekítés. Ha pl. adott az ábrázolási módunk határait feszegető "a" szám, akkor az "a*2-a" külön mul+add után végtelen lesz, FMA-val pedig a korrekt "a" értéket kapjuk vissza.Az algoritmus tervezésénél a programozó számol azzal, hogy milyen nagyságrendű bemeneti eredményeket vár a programja és milyen pontosság szükséges, így írja meg a programot vagy így fordíttatja a compilerrel. ( Én pl. mindig 32 bites SSE1 lebegőpontosban számolom a módosított pixelértékeket, ott elég 1-2 tizedesjegy is max. 1000-es átmeneti nagyságrendben, de koordinátageometriai algoritmusokban a koordinátákat mindig 64 biten, SSE2-ben számoltatom; nem azért, mert egy 2D koordináta csak 1-1 x-y értékből áll, hanem mert a bemenete szinte mindig egy valami nagyon kicsi szögre számolt sinus/cosinus érték is, aminek a pontosságát nem hátrány megőrizni.) Ezért az emlegetett »emulálás« CPU-kon igazából a 80 bites x87-et jelenti, ezt meg mindegyik tudja Pentium1 óta beépítve. Amelyik algoritmusokhoz a 80 bit sem elég, azt már eleve úgy írják meg, tehát a 80-64-32 bites műveletvégtzés összehasonlításánál azok irrelevánsak. A grafikonokon mutatott különbségek abból adódnak, hogy az x87 nem SIMD-képes, bármilyen modern x87-felépítésen 2 FLOP/cycle az általános maximális műveletvégzési sebesség (osztás és gyökvonás kivételével; tehát nem lassabb egy 80 bites összeadás vagy szorzás, mint egy 32 vagy 64 bites), míg SSE1-2 vagy AVX esetén ez sokkal magasabb: 32 bites SP-nél az AVX/x87 arány 8:1, 64 bitnél (DP) is 4:1, és az SPP arány már az SSE2 megjelenése óta 2:1.
Ezért "kitolás", amit a GPU-knál csinálnak GPGPU címszó mellett, mert azokon alapból csak a Half Precision (16 bites ábrázolás) és 32 bites SP van engedélyezve, már 8:1-es SP/DP arányú 64 bites számításokért is külön felárat kérnek, 4:1 pedig aranyárban van. És mivel ott nincs nagyobb ábrázolási képesség, mint mentőöv, azért ami nem fér bele 64 bitbe (vagy 32 bitbe 64 bites képesség hiányában), azokat az eseteket valóban emulálni kell (~a CPU számolja).
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
hugo chávez
aktív tag
Köszi a választ!
Bár, jó, ha egy részét értem, de, ha jól szűröm le a lényeget, akkor, addig az FMA-nak nincs különösebb jelentősége, amíg túl nem lépjük a "működési mód ábrázolási határait", de, amennyiben olyan pontosságra törekedünk, hogy közben túllépnénk, már nem lehet kikerülni.
Még két kérdés, ha nem bánod, AVX esetén 4x64, vagy 1x256 bitet lehet-e ábrázolni (egyáltalán, van-e értelme ezt így különbontani?) és AVX esetén is lehet-e FMA?
[ Szerkesztve ]
"sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari
-
P.H.
senior tag
válasz hugo chávez #38 üzenetére
Pedig próbáltam a legegyszerűbben leírni
Amennyiben nem közelítjük meg az ábrázolási mód nagyságrendi határait, ott akár 2x gyorsabb lehet az FMA-kód, mint a sima SIMD megfelelője, mivel (nem törvényszerű, de) Bulldozeren azonos órajelbe telik 1-1 összeadás vagy szorzás, mint egy FMA.
Ha megközelítjük, vagy egyáltalán felmerül az esélye, hogy megközelítheti a bemeneti adat az elvi határt - mint írtam, 32 bit SP esetén 100000 nagyságrend esetén kb. 0.0001 az alsó határ, ameddig pontos; pixel-adatoknál, amik [0..255] tartományban vannak, ott mindegy ez; de máshol általában itt rezeg a léc, mert a 64 bit már fele akkora sebességű CPU esetében, ez nem mindegy-, akkor bizonyos esetekben +1-2 bit( vagy nagyságrendi szempontból ulp) pontosságot elrejt az FMA.A lebegőpontos számok szabványos ábrázolása 32, 64 vagy 80 bites (a 16 bites HP is már csak új jövevény, de nem véletlenül alkalmazzák GPU-kban). A 80 bitnél nagyobb ábrázolás formája nem kötött szabványosan, az AVX is csak több 32 és 64 bites értéket ismer és azokkal tud számolni. 80 bitnél nagyobb ábrázolást már sima integer-kódban szokták megírni (de a DOS-os programok is alapvetően tartalmaztak integer FP-kódot, ha nem lenne a CPU-ban/mellett FPU), ebből a szempontból az FPU még mindig kötött hardware.
Természetesen 256 bites (8*32 vagy 4*64) méretre is is van FMA.[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
hugo chávez
aktív tag
Hát, végül is, talán tényleg nem olyan bonyolult, azt hiszem, hogy nagyjából már értem, de, biztos, ami biztos, azért még átolvasom néhányszor.
Köszi a többit is!
[ Szerkesztve ]
"sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari
-
nyunyu
félisten
pl vmware is már csak annyit mond, hogy szerverenkénti processzorszám számít.
VMWare hany magot tud kezelni?
Tegnap panaszkodtak az egyik bank IT uzemeltetoi, hogy az aktualis HyperV csak 64 magot kezel, igy foloslegesen tettek 4 db Xeon E7-et a szerverbe.
Mi is azert tettunk a legcombosabb adatbazis szerverunkbe E7-et 8 magos Opteronok helyett, mert az SQL Server Enterprise licensze is fizikai procinkent ertendo.
1 SQL licensz az Xeon E7 aranak az otszorosebe faj, igy mindjart megeri 1000$-os procit venni 2 feleannyiba se kerulo helyett.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
Új hozzászólás Aktív témák
- Beszámítás! Intel Core i5 6500 4 mag 4 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i5 4690K 4 mag 4 szál processzor garanciával hibátlan működéssel
- Intel I7 13700K 16mag/24szál - Új, Tesztelt - Eladó! 128.000.-
- ! Intel 13700KF + ASUS TUF Gaming Z790 Plus D4 + Kingston FURY DDR4 3600MHz CL18 !
- Újszerű - INTEL Core i5-14600KF 14mag 20 szál 5.3GHz CPU - bolti garanciával