Nehalem

[Typhoon.X]

Bloomfield nije chipset vec kodno ime za Nehalem procesore :trust:

Whooops 😀

Lupih pa ostadoh ziv :lupko: ... hteo sam reci da podrshka za SLI ili sa CF nema veze sa procesorom vec sa pratecim chipsetom, to je sve 😀

Evo idem sad u coshak da se stidim malo :d

 

[Northwood]

Whooops 😀

Lupih pa ostadoh ziv :lupko: ... hteo sam reci da podrshka za SLI ili sa CF nema veze sa procesorom vec sa pratecim chipsetom, to je sve 😀

Evo idem sad u coshak da se stidim malo :d

pa nisi ti kriv, kriv je ovaj sto pise te vesti :d
iz njegove recenice se moze lako razumeti da je chipset Bloomfield...

 

[drfedja]

Nehalem nece podrzavati SLI.
Izgleda da Intel i Nvidija vole da ratuju 😀

http://www.itx.ba/index.php?option=com_content&task=view&id=5675&Itemid=1

Ne vole oni da ratuju. Problem nastaje sa svima koji se slizu sa Intelom, a ko gubi taj ima pravo i da se ljuti. :d Jednostavno, Intel je firma koja je sama sebi dovoljna.
nVidia ce verovatno ispushiti za chipsetove od strane Intela, AMD sada ima ATi koji pravi chipsetove za njih, pa se cini da ce uloga nVidije u chipsetovima biti malo marginalizovana.
GPGPU era je nesto sto ce biti neminovnost, a AMD je prvi zauzeo stav da je to tako, kupivsi ATi, Intel je takodje izgleda shvatio o cemu se radi, pa je zapoceo projekte poput Larrabee. I Intel i AMD prave x86 procesore, pa mogu napraviti i x86 kompatibilni GPGPU poput fusion-a, sto ne verujem da ce biti slucaj sa nVidijom. Verovatno je da ce nVidia biti dominantna na polju diskretnih grafickih resenja jos dosta dugo vremena.

 

[kUdtiHaEX]

Ili ce nVidia da popusti za SLI a onda i Intel za chipsetove 🙂

 

[Jerry[NS]]

Nehalem maticne ploce (X58 chipset) ce imati 8-layer PCB zbog problema koje prouzrokuju DDR3 memorije na njima.

http://www.itx.ba/index.php?option=com_content&task=view&id=5952&Itemid=1

Memorijski bandwidth do 32GB/s sa DDR3 memorijom od 1600Mhz

http://www.itx.ba/index.php?option=com_content&task=view&id=5953&Itemid=1

 

[audiofreak]

E pa evo nekih novosti:

Nehalem u Q2 2008 kao sto je i obecano kaze Paul Otellini : Link

Uzgred, 45nm proces rampuje po planu. U Q3 2008 vise od polovine procesora bice pravljeno u 45nm:

On 45 nanometers, Intel is leading the industry by a long stretch," Otellini said. "We are on track to cross over in (the third quarter) of this year, so more than half our processors will be made on 45 nanometers.

Danas sam video i PCN za E8500 i E8400 procesore -- izlazi stepping E0 koji ce imati CPUID 1067A umesto 10676 i dve nove instrukcije XSAVE/XRSTOR. To je koliko znam dodato da bi se OS vendorima omogucilo testiranje i implementacija tih instrukcija u kernel zbog buducih procesora koji ce osim FPU i XMM registara snimati jos ponesto pri promeni konteksta. Prvi E0 semplovi ce ici krajem maja, a bice ih u kanalu krajem Avgusta.

 

[Nedjo]

E pa evo nekih novosti:

Nehalem u Q2 2008 kao sto je i obecano kaze Paul Otellini : Link

ti si kanda u plimi uzbudjenja smetnuo s uma da Q2 nije u "second half" tekuce godine... a bogami ni jedne druge 😉

 

[audiofreak]

ti si kanda u plimi uzbudjenja smetnuo s uma da Q2 nije u "second half" tekuce godine... a bogami ni jedne druge 😉

LOL! Gde me nadje? 😀

Naravno u pitanju je syntax error -- Q2 => H2 :d

 

[audiofreak]

Saznao sam jos nesto zanimljivo, Nehalem ce umesto 1 cycle shuffle engine (Penryn) imati 0.5 cycle shuffle engine -- u prevodu dve 128-bitne shuffle operacije po taktu. To je ocigledno deo pripreme za Sandy Bridge koji ce imati 256-bitne SIMD registre.

 

[drfedja]

Saznao sam jos nesto zanimljivo, Nehalem ce umesto 1 cycle shuffle engine (Penryn) imati 0.5 cycle shuffle engine -- u prevodu dve 128-bitne shuffle operacije po taktu. To je ocigledno deo pripreme za Sandy Bridge koji ce imati 256-bitne SIMD registre.

Meni to izgleda da moze shuffle na 2 SIMD jedince istovremeno. Sandy ce verovatno biti expandovan na 256-bit, bas kao sto je npr. K8 -> K10 sa 64 na 128-bit. Uvodjenjem 256-bitnih AVX javlja se potreba za sirim registrima i vecim troughputom.

 

[audiofreak]

Meni to izgleda da moze shuffle na 2 SIMD jedince istovremeno. Sandy ce verovatno biti expandovan na 256-bit, bas kao sto je npr. K8 -> K10 sa 64 na 128-bit. Uvodjenjem 256-bitnih AVX javlja se potreba za sirim registrima i vecim troughputom.

Cuj verovatno... 😀

Ne verovatno nego sigurno jer je to plan. AVX = prosirenje XMM0-XMM7 na 256 bita, prosireni ce se zvati YMM0-YMM7. Isto vazi i dodatnih 8 u 64-bitnom modu.

Ono sto je interesantno je da vec Nehalem ima performanse (barem za shuffle) koje su dovoljno dobre za 256-bit registre.

 

[delimir]

Kakva izjava lol

Bloomfeld (prvi cipset koji ce izaci za Nehalem-core procesore) nece podrzavati SLI, ali to je i bilo ocekivano s obzirom na dosadashnju istoriju intel chipseta (kao shto je Fudo i rekao)...

S5400 podrzava SLI. Intel Skulltrail platforma je bazirana na Intel cipsetu i podrzava SLI.

 

[audiofreak]

Evo zanimljivog teksta : Link

 

[Typhoon.X]

S5400 podrzava SLI. Intel Skulltrail platforma je bazirana na Intel cipsetu i podrzava SLI.

Ok, ali ni cena ni dostupnost ni primenljivost istih nisu na nivou intel ploca/chipseta koje podrzavaju CF, to je cela poenta... BTW, nije mi bash preterano jasna ova reakcija, ja nisam ni rekao da ne postoji intel reshenje koje podrzava SLI... Mada, kako se razvijaju stvari, ko zna hoce li ih biti josh u buducnosti...

 

[audiofreak]

Da se vratimo na temu.

Evo sazeto sta sve novo donosi 45nm TOCK, odnosno Nehalem.

- veći broj load/store buffera
- SMT
- Bolji branch prediction -- multi-level prediktor, renamed RSB
- Loop streaming -- 28 µop-ova umesto 18 instrukcija, power saving
- Bolji macro-fusion -- sada i u 64-bitnom modu i za više instrukcija
- Unified reservation station i single scheduler za sve izvršne jedinice
- 6 operacija u taktu -- od toga 3 memorijske (1x load, 1x store address, 1x store data) i 3 računske
- dve SSE integer ALU / integer shuffle jedinice
- Out of order window uvećan za 33%
- Nova TLB hijerarhija -- 512 entry 2nd level unified TLB
- Brži 16-bajtni neporavnati pristupi
- Brže sinhronizacione primitive -- poboljšanje latencije LOCK prefiksa i XCHG
- Dodatna cache hijerarhija -- L1 podržava više konkurentnih promašaja nego Core 2, L2 je unified 256KB low latency -- pominje se 12 taktova kao maksimum, L3 shared 8MB za quad-core, inclusive¹
- Brža virtualizacija -- VPID, EPT²
- SSE 4.2 instrukcije³

¹ - Ni u slučaju promašaja ni u slučaju pogotka ne mora da se proverava koherencija sa ostalim jezgrima. Za promašaj garantuje inclusive protokol (što je u L1/L2 mora biti i u L3), a za pogodak "core valid" bitovi koje poseduje svaka L3 cache linija i koji govore da li je potreban snoop ili ne i za koje jezgro.

² - VPID je Virtual Processor ID koji sluzi da smanji frekvenciju invalidacije TLB-a. EPT je Extended Page Table, hardver za translaciju guest<->host fizičkih adresa (ranije zadatak VMM softvera). Nehalem ima 40% bržu virtualizaciju u odnosu na Pernyn -- postignuto smanjenjem broja tranzicija (EPT) i latencije tranzicije (VPID).

³ - application accelerators za stringove (regex, XML parsing), CRC32 (Castagnoli polynomial), population count

Ni sa softverske strane ne izostaju poboljšanja, već postoji beta verzija XML parsera baziranog na novim string instrukcijama (na jesen treba da izađe finalna), a IPP biblioteka će u buduće takođe koristiti nove instrukcije. Tekuće verzije Intel i Microsoft kompajlera već podržavaju SSE 4.2.

 

[drfedja]

Nije neka novost da prozivodjaci procesora prave specificne instrukcije za ubrzanje pojedinih aplikacija. I VIA Issaiah poseduje izvrsnu jedinicu i instrukcije za podrsku enkripcijskom standardu AES. POPCNT vec postoji kod K10.

Latencija L2 mi deluje slicna kao kod Core 2. Ako se ne varam C2D ima 14 ciklusa L2 i 3 ciklusa L1.
EPT moze biti podrzan od strane memorijskog kontrolera, kako je to uradjeno i kod K10. Svakako pohvalno u odnosu na prethodnika.

Loop detektor je izgleda pomeren posle decode faze u pipelineu. Verovatno je to uradjeno da se sacuva front-end bandwidth. Jel ima nesto napisano o tome detaljnije ?
Zanimljivo ce biti videti kako taj SMT radi kod Nehalema. Ja ocekujem dosta bolje skaliranje na vise threadova (vise od 4 npr.), ali mi je nepoznanica koliko jos moze sa SMT da se izvuce na vec ionako dobro iskoriscenoj core2 arhitekturi.

 

[audiofreak]

Nije neka novost da prozivodjaci procesora prave specificne instrukcije za ubrzanje pojedinih aplikacija. I VIA Issaiah poseduje izvrsnu jedinicu i instrukcije za podrsku enkripcijskom standardu AES. POPCNT vec postoji kod K10.

AES ce stici sa AVX ekstenzijama.

Latencija L2 mi deluje slicna kao kod Core 2. Ako se ne varam C2D ima 14 ciklusa L2 i 3 ciklusa L1.

Trebalo bi da bude niza od C2D. Ipak je ugradjen memorijski kontroler.

Loop detektor je izgleda pomeren posle decode faze u pipelineu. Verovatno je to uradjeno da se sacuva front-end bandwidth. Jel ima nesto napisano o tome detaljnije?

Jeste, pomeren je iza dekodera i povecan mu je kapacitet. Sada loop streaming radi bez ponovnog dekodiranja instrukcija. Razlog kako oni kazu nije front-end bandwidth nego veci power saving jer moze da se ugasi i dekoder.

...ali mi je nepoznanica koliko jos moze sa SMT da se izvuce na vec ionako dobro iskoriscenoj core2 arhitekturi.

Hyper-Threading je mogao da izvuce i do 35% u optimizovanim aplikacijama. Verujem da ce i sa Nehalemom biti slicna situacija.

 

[kovacm]

Nije neka novost da prozivodjaci procesora prave specificne instrukcije za ubrzanje pojedinih aplikacija. I VIA Issaiah poseduje izvrsnu jedinicu i instrukcije za podrsku enkripcijskom standardu AES. POPCNT vec postoji kod K10.

lepo je videti da i mainstream x86 svet uvodi neke stvari koje postoje u IBM Power svetu vec neko vreme (AES) - lepo sto stize sa AVX extenzijama... 😉 (nesto kao i AltiVec kod PPC-a :d samo 2-3 godine pre intela...)

 

[audiofreak]

@kovacm:
Dosadan si vec sa tim pojebavanjem. Sta vredi drugima sto su imali AES ili AltiVec ranije kada u poredjenju sa zastupljenoscu x86 od toga niko ziv nije imao vajde?!?

 

[genuine]

Intel mnogo klonira, to je cinjenica

 

[DeanXP]

Nisam video da je postovano dosad, tekst sa RWT, ima dosta detalja, must read:
http://www.realworldtech.com/includes/templates/articles.cfm?ArticleID=RWT040208182719&mode=print

Izgleda da ce SMT biti iskljucen na desktop-u. Mozda ostane samo za Extreme Edition, ali nista definitivno. Za desktop i nije neki gubitak.

Prakticno cela kes hijerarhija je dozivela izmene (nije samo dodat L3). Ocigledno ciljaju multisocket masine i serverske poslove gde ce ovo sjajno raditi. Medjutim, nisam siguran kako ce se to odraziti na desktop.
Pre svega mislim na povecan L1D latency: sa 3 ciklusa na 4. Jedan ciklus mozda ne zvuci kao mnogo, ali u pitanju je 33% povecano kasnjenje u najkriticnijem nivou memorije. Moguci uzrok je novi TLB ili poravnanje sa produzenjem pipeline-a (16 stage pipeline vs. 14 za C2D).
Latency od 12 ciklusa za 256KB L2 nije bas sjajno kad se uzmu u obzir da C2D ima 14 ciklusa na 6MB L2 uz 3 puta vecu asocijativnost (24-way vs. 8-way), a jos je i deljen izmenju dva jezgra. Mada, mozda se ispostave tacne druge glasine o 9 ciklusa sto bi bilo razumnije.
L3 kes je fully inclusive, sto je sjajno jer resava sva pitanja inter-core kes koherencije (audiofreak je objasnio kako to funkcionise). Sto se tice same implementacije, vrlo je slicna AMD Barceloni: zasebno se napaja i radi na manjoj frekvenciji od jezgra. Takodje, ima slican latency od 30-40 ciklusa.
Fully inclusive L3 je sjajan na za multisocket okruzenje, jer snoop iz drugog procesora ne mora da proverava sva jezgra pojedinacno vec samo L3. Na desktopu to ne znaci nista, ali bi velik latency mogao lose da se odrazi obzirom na izuzetno mali L2.

Loop detektor je izgleda pomeren posle decode faze u pipelineu. Verovatno je to uradjeno da se sacuva front-end bandwidth. Jel ima nesto napisano o tome detaljnije ?

Loop Stream Detector: C2D vs. Nehalem
I ima jos malo detaljnije na RWT linku sa pocetka posta.

 

[illidan]

nehalem i x58

 

[Yoti]

Hmm, sram ih bilo, eno su i slotove za RAM prekopirali sa AMD ploha 😡 :-devil-:
:wave:

 

[drfedja]

Nisam video da je postovano dosad, tekst sa RWT, ima dosta detalja, must read:
http://www.realworldtech.com/includes/templates/articles.cfm?ArticleID=RWT040208182719&mode=print

Izgleda da ce SMT biti iskljucen na desktop-u. Mozda ostane samo za Extreme Edition, ali nista definitivno. Za desktop i nije neki gubitak.

Misljenja sam da sa manjim brojem threadova nece biti nekog narocitog dobitka od Nehalemovog SMT-a. Ali u mainframe okruzenju moze da se oseti dobro ubrzanje.

Prakticno cela kes hijerarhija je dozivela izmene (nije samo dodat L3). Ocigledno ciljaju multisocket masine i serverske poslove gde ce ovo sjajno raditi. Medjutim, nisam siguran kako ce se to odraziti na desktop.
Pre svega mislim na povecan L1D latency: sa 3 ciklusa na 4. Jedan ciklus mozda ne zvuci kao mnogo, ali u pitanju je 33% povecano kasnjenje u najkriticnijem nivou memorije. Moguci uzrok je novi TLB ili poravnanje sa produzenjem pipeline-a (16 stage pipeline vs. 14 za C2D).
Latency od 12 ciklusa za 256KB L2 nije bas sjajno kad se uzmu u obzir da C2D ima 14 ciklusa na 6MB L2 uz 3 puta vecu asocijativnost (24-way vs. 8-way), a jos je i deljen izmenju dva jezgra. Mada, mozda se ispostave tacne druge glasine o 9 ciklusa sto bi bilo razumnije.
L3 kes je fully inclusive, sto je sjajno jer resava sva pitanja inter-core kes koherencije (audiofreak je objasnio kako to funkcionise). Sto se tice same implementacije, vrlo je slicna AMD Barceloni: zasebno se napaja i radi na manjoj frekvenciji od jezgra. Takodje, ima slican latency od 30-40 ciklusa.
Fully inclusive L3 je sjajan na za multisocket okruzenje, jer snoop iz drugog procesora ne mora da proverava sva jezgra pojedinacno vec samo L3. Na desktopu to ne znaci nista, ali bi velik latency mogao lose da se odrazi obzirom na izuzetno mali L2.

Znajuci koliko Core 2 arhitektura ima benefit od velikog, brzog i deljenog L2 kesa u single thread operacijama, vrlo je diskutabilno kako ce se ovakva kes hijerarhija odraziti na Nehalema. Ipak, ima tu dosta poboljsanja koja bi mogla da "ispeglaju" stvari.

Trebalo bi da bude niza od C2D. Ipak je ugradjen memorijski kontroler.

Latencija L2 nema veze sa time sto je ugradjen memorijski kontroler.

Jeste, pomeren je iza dekodera i povecan mu je kapacitet.

28 uOps ne mora, ali moze biti vece od 18 instrukcija. 🙂

Hyper-Threading je mogao da izvuce i do 35% u optimizovanim aplikacijama. Verujem da ce i sa Nehalemom biti slicna situacija.

Ne verujem da je ista implementacija. Iskoriscenje pipelinea je daleko bolje nego kod Netbursta.

 

[genuine]

jel moze neko da mi objasni sta se desava sa prioritetima kad imam 2 niti , jednu na realtime drugu na low i smt jezgro ( a samo su njih dve u sistemu). Jel se desava da obe rade i da ova low moze da smeta realtime... ?

 

[drfedja]

Kakve ovo ima veze sa Nehalemom ? :d

 

[genuine]

smt,Nehalemom i eto palo mi je na pamet dal opet da se brinem ko za hyperthreading,

 

[audiofreak]

Latencija L2 nema veze sa time sto je ugradjen memorijski kontroler.

U pravu si. Mislio sam na latenciju promasaja, a ne pogotka. :crash:

@genuine:

Ako imas slobodno jezgro naravno da ce se izvrsavati thread na njemu bez obzira sto je low/idle priority.

 

[genuine]

pa da ali smt jezgro nisu dva jezgra... tako da idle priority nit moze da se izvrsava na istom nivou kao i high priority i time su fakticki istog prioriteta tj.. high ne dobija dovoljno resursa i moze da ceka da idle oslobodi neki resurs....

Koliko bi bilo *****ato da se naprave 4 jezgara koje dele izvrsne jedinice a imaju skroz nezavisne keseve i sve ostalo? Tako da ako je single threaded aplikacija da ona moze da koristi resurse svih ostalih jezgara?

 

[drfedja]

U pravu si. Mislio sam na latenciju promasaja, a ne pogotka. :crash:

Sad si se izvukao ! 😉 ,)