Új hozzászólás Aktív témák

• #433 P.H. senior tag Abu85 #429

  Új Válasz 2013-06-02 23:07:23 #433

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  P.H.

  senior tag

  válasz Abu85 #429 üzenetére

  Csak 1 generációra gondoltam a kérdéssel. 2 generáció alatt úgyis el kell költeniük 1 milliárd tranzisztort, hova lenne különben Moore törvénye
  Addigra a ZiiLabs-féle megoldás is beérhet náluk.

  Ez az L4-használat új megvilágításba helyez(het)i a majdani Xeonokat, ha nem is elsősorban a Haswell-alapúakat, de legalábbis a következő tick-et. Pl. külső chip-en mellékelt cache, mikor is láttunk ilyet x86-ban legutóbb?

• #427 P.H. senior tag Abu85 #424

  Új Válasz 2013-06-02 22:33:02 #427

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  P.H.

  senior tag

  válasz Abu85 #424 üzenetére

  Mint gondolsz, a helyzetet az Intel tényleg új architektúrával fogja megoldani, vagy inkább 'izomból'? A 14 nm 2014-es bevezetése általánosan elterjedté teheti az eDRAM-ot náluk. Átmeneti megoldásként nem elképzelhető, hogy ebbe fektetik azokat bizonyos a tranzisztorokat, ha már 22 nm-en is 'helyreteszi' a dolgokat?

  BTW, a 128 MB L4-et a CPU-k is használhatják most, vagy ez kizárólag az IGP privilégiuma?

• #386 P.H. senior tag Zeratul #380

  Új Válasz 2013-06-02 19:49:07 #386

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  P.H.

  senior tag

  válasz Zeratul #380 üzenetére

  A SIMD integer (egész számos) feldolgozást tradicionálisan FPU-műveletnek szokás nevezni, mivel az egész az x87 80 bites regisztereinek 64 bites részén működve indult (az MMX, 3DNow! utasítások MM0-MM7 regisztereken dolgoztak, amik a 8 db FPU-regiszter alsó 64 bitje), mégha időközben már rendelkezésre áll is külön 128, majd 256 bites regiszterkészlet számukra (SSEx esetén XMM0-XMM7 - 64 bit esetén XMM0-XMM15 - és AVX-nek YMM0-YMM15, utóbbiak alsó 128 bitje a számozásnak megfelelő XMM regiszter). Ezért kellett most egy Windows 7 OS-patch, hogy task-váltáskor a teljes 256 bites AVX-regiszterek tartalma mentődjön, anno is kellett a Win98-cal ilyen patch az SSE-regiszterekhez; tehát ez eddig kétszer történt meg ~30 év alatt, ezért nem közismert.

  Az AMD ezt a részt - megintcsak tradicionálisan - el is különíti a felépítésben FPU néven, náluk még mindig körül is rajzolható az a CPU-terület, amely a lebegőpontos és az összes SIMD-integer feldolgozást végrehajtja, az Intel viszont ugyanazon végrehajtó egységeken hajtja végre a SISD és SIMD egész számos műveleteket (mostmár a Haswell-lel 256 bites az integer ALU, a képeken 'SSE integer ALU').

  Az AVX2 azért fontos, mert a legtöbb esetben a video-, kép- és hangfeldolgozó programok egész adatokon dolgoznak, és a pontosság megtartása végett sokszor egy trükköt alkalmaznak: a feldolgozás elején eggyel nagyobb méretre konvertálják (8 bit byte -> 16 bit word vagy 16 bit word -> 32 bit doubleword) a bemeneti adatokat, majd megszorozzák 8-cal vagy 16-tal: így lebegőpontos helyett fixpontos módon, de 0.125 vagy 0.075 pontossággal számolnak. Ennek jelentősége, hogy Intel-nél egy vektoros integer összeadás/kivonás időigénye SIMD esetben is 1 órajel, addig egy lebegőpontosé 3; vagy egy vektoros lebegőpontos szorzásé 5, míg egy egész számosé 3; a 8/16-tal szorzása és 'visszaosztása' pedig az egész algoritmus elején és a végén 1-1 órajel SSE4.1 utasításokat alkalmazva.

  Az már az Intel üzletpolitikáján múlik, hogy az AVX2-vel is megcsinálják-e azt, amit az AVX-szel, hogy kimarad a kisebb (Pnetium/Celeron) CPU-kból. A korábbi integer SSE2 és 4.1 ereje abból adódik, hogy a leglassabb Celeron is ismerte a Pentium 4-es időkben, kár lenne ezt az AVX2-vel kihagyni (főleg annak tekintetében, hogy a Jaguar tud AVX-et, a low-end laptopokban megszokott SB/IB Pentium pedig nem).

Új hozzászólás Aktív témák