Šta je novo?

Odnos 64 bitnih sistema AMD vs Intel

monteboy je napisao(la):
Da li sam ja pristrastan ili ne ovdje nije pitanje!

Jeste, jer tvrdis nesto za sta nemas argumente. Testovi nisu u potpunosti korektni, ne odrazavaju pravu sliku stvari i prerano je diskutovati o tome.

monteboy je napisao(la):
nego sam te pitao zasto Intel gubi 25%

Nemam ja sta da izbegavam, lepo sam ti rekao da je moj odgovor pitanje -- DA LI U SVIM TESTOVIMA GUBI 25%? Ako ne kako je to moguce? Kako kod nVidia testa ima isto ubrzanje kao AMD?
 
@Audiofreak:

Ovo mi bas nije jasno. Sta to bilo koji procesor radi softverski? I gde nije podrzan?

Na onom testu koji si procitao je to objasnjeno. EM64T nije "kompletan" tj neke instrukcije koje zele preko njega da se izvrse nisu prisutne u njemu i tada on te instrukcije emulira softwerski.

E ovde dolazimo do srzi problema -- prvo, nisu jos sve stvari testirane. Drugo, neki od ovih pomenutih testova nisu korektni, a pravih aplikacija jos nema tako da nije realno jos o tome pricati.

🙂 nemoj biti bukvalista, nisam mislio bas sve stvari. Sto se ne testiranih stvari tice ne brini, nece sigurno raditi losije nego sto su na prethodnim modelima radile zar ne ? 😉 To uglavnom nikome nije praksa, ne verujem ni da je intelu i AMD-u, a ni majkrosoftu na kraju krajeva.


E sad, cela ona prica "to jos nije optimizovano kako treba" i "Sta bi bilo kad bi se u izvrsavanje ubacile i SSE3 instrukcije" itd. to mu dodje isto kao kad bi rekli "A sta bi bilo da je sav softwer za win platformu dostupan i za linux i da bolje radi ?" 🙂 Pa koristili bi linux, a ne windows. Tako isto i za ovo. Da na intelu sve to bolje radi ljudi bi sad masovno kupovali intel, a ne a64. Kad to bude sve radilo na intelu kako ti kazes, onda cemo uzeti intela, a ne a64. I nisu sad svi ovde fanovi AMD-a (i vlasnici istog) tek tako, bez razloga. Pa ako imas 100 ljudi koji se razumeju i kupili su AMD naspram 20 ljudi koji se razumeju i kupili su intel, ja licno idem pretpostavkom da je vecina u pravu ! 🙂 Nismo mi fanovi znas, imao sam i ja intela dok je bio bolji, sad jednostavno, imam AMD. Ne mrzim ovo ili ono, uzimam sto mi je bolje i sto mi vise odgovara. Medjutim postoji jedan jako veliki problem ovde: Skoro svi mi stariji korisnici smo ranije imali intele, pa AMD, pa intel pa AMD pa sad bitchujemo po intelu, a korisnici koji su uvek imali intela i sada imaju i dalje intela, a AMD nisu imali vec samo videli (na nekom razje****m sistemu kod komsije ili neku slabiju AMD konfu (via recimo)) bitchuju po AMD-u i pricaju kako smo mi ostali fanovi itd. Razmislite dobro o ovome. Ja sam imao intel i znam sta/kako, radio sam na novim intel konfama itd. pa imzm iz koje perspektive da tvrdim da je nesto bolje/jeftinije/ludje/novije/sarenije/debilnije i tako dalje i tako dalje....Najvise volim kad dodje neki novi clan na forum i kad odvali kao "pa to je AMD, to je djubre, taj barton 2500+ ne moze da se meri sa mojim pentijujm cetr' celleronom na 2.4" ili jos bolje ( 🙂 ) "barton nije bio tako dobar kao Tb-B jezgro" ne znajuci da je razlika samo i iskljucivo u kesu i da je pored toga jezgro identicno i da je barton code name, a tb-b tip jezgra... itd.
 
audiofreak je napisao(la):
To sto si napisao zahteva da procitas ovo i to posebno Appendix C -- IA-32 Instruction Latency and Throughput (strana 425 na dalje). Kada to uradis budi ljubazan pa sam sebe ispravi.
Nema potreba da se ispravljam 🙂. Ovaj link ukazuje na tebele sa podacima o latency-ju za execution fazu pojedinih instrukcija, a sta bi sa fetch/decode/read argumets/write results fazama? Prescott pipeline je 30 stage, i svakoj instrukciji je potrebno bar 30 taktova da se obradi od pocetka do kraja, hteo ti to da priznas ili ne.

audiofreak je napisao(la):
Takodje procitaj Chapter 1 -- IA-32 Intel Architecture Processor Family Overview (strana 26), a narocito poglavlje Intel NetBurst Microarchitecture.
Intel NetBurst Marchitecture 🙂 . NetBurst je cist marketing, kao sto se vidi iz imena.
 
Poslednja izmena:
Nedjo je napisao(la):
E moj djeticu da si procitao ovaj tred http://www.benchmark.co.yu/forum/showthread.php?t=67437
znao bih da je apsolutno besmisleno ulaziti u raspravu sa dvojcem audiofreak&SoSo!

Ne znam za tebe ali imao sam prilike da upoznam dvojac licno tako da mogu da kazem da grdno gresis. Ne smatrajm me nicijim advokatom ali vise cenim prakticno (da ne kazem inzenjersko) nego novinarsko znanje.
 
audiofreak je napisao(la):
Nemam ja sta da izbegavam, lepo sam ti rekao da je moj odgovor pitanje -- DA LI U SVIM TESTOVIMA GUBI 25%? Ako ne kako je to moguce? Kako kod nVidia testa ima isto ubrzanje kao AMD?

Stobom kao sa molom djecom ! 😉

O da ti si toliko u pravu ne da je 25% nego znatno vise evo vidi sam :

AMD INTEL

POV-Ray
116.66 83.95 25%

Pi-Bench
4312 8203 55%


Mini-GZIP
4.34 5.33 22%


Mandelbrot Benchmark

40.53 27.18 29%

znaci kad saberemo sve zajedno 25+55+22+29 / 4 = 32,75 %


Zasto ne postize AMD adekvatne rezultate u NVidia testu ? -> jer nijedan game trenutno ne koristi prednosti 64bitne arhitekture.
 
Poslednja izmena:
Da li bi se moglo konstatovati sledece i izbeci ovo low-level teoretsko prepucavanje?:

Za potreba vecine korisnika ovog foruma (igre, divx, surf, kucanje u wordu, superpiisanje 🙂) trenutno AMD nudi vise muzike za <= para od Intela.
 
Lukija je napisao(la):
Ne znam za tebe ali imao sam prilike da upoznam dvojac licno tako da mogu da kazem da grdno gresis. Ne smatrajm me nicijim advokatom ali vise cenim prakticno (da ne kazem inzenjersko) nego novinarsko znanje.
1. Ja nisam napravio opasku na licnoj osnovi!
2. Ovim postom ti jesi postupio "advokatski"
3. Moje znanje potice iz prakse (ostalom kao i ne znanje, ako se secas treda o polovicnim HT mnoziocima - ako po nekom tehnickom pitanju nisam u pravu nemam sujetu ko kineski zid pa da necu prihvatiti tudju sugestiju i izvinuti se za eventualnu arognaciju)
4. Ja u ovom tredu nisam raspravljao o rezultatima koje su postigli drugi i tvrdim samo ono usta sam se licno uverio. To konkretno znaci da cekam da mi pod ruku dodju novi Intelovi procesori, pa da izadjem ovde sa rezultatima. No, ono sto se u nekoliko do sada objavljenih testova P4 vs. A64 pod Win64 moglo videti, jeste da AMD ima nesumnjivu prednost i u opste mi nije jasno zasto pojedinci ovde tvrde suprotno (svima su nam argumenti tudji rezultati)
 
Ma sve je to lepo, ta Intelova tehnologija, to su super i napredne stvari, imaju potencijal, ali bojim se da ne ispadne kao prica od pre godinu-dve, kada su svi govorili kako ce Intel ici na preko 5GHz, pa bilo je reci i o 10Ghz, cela hajka njihovih predstavnika, svaki skup, svako savetovanje i onda BUM! Objave, onako 'ladno da nece biti verzije ni na 4Ghz. Ko je hteo da shvati ovo, jasno mu je gde ce zavrsiti i ova prica sa 64 bit-a. Trenutno stanje govori da je AMD suvereni vladar na desktop trzistu u svim kategorijama. Za godinu dana videcemo, mozda i ne bude, ali do tada ima svi da promenimo bar po jedan CPU, tako da spustite malo loptu na zemlju sa Intelom i njegovim dual core i 64 bit-a resenjima i pogledajte realno stanje. Svako neka kupuje sta mu se svidja, uostalom svako trosi svoje pare, pa ako je zadovoljan neka tako i ostane.
Pozdrav svima!
 
gx-x je napisao(la):
Na onom testu koji si procitao je to objasnjeno. EM64T nije "kompletan" tj neke instrukcije koje zele preko njega da se izvrse nisu prisutne u njemu i tada on te instrukcije emulira softwerski.

Navedite mi ovde te instrukcije koje se "emuliraju softverski". To je cista glupost.

gx-x je napisao(la):
I nisu sad svi ovde fanovi AMD-a (i vlasnici istog) tek tako, bez razloga.

Nisu, samo 90% njih ne zna razlog.

gx-x je napisao(la):
Pa ako imas 100 ljudi koji se razumeju i kupili su AMD naspram 20 ljudi koji se razumeju i kupili su intel, ja licno idem pretpostavkom da je vecina u pravu ! 🙂

Na ovo moze da se odgovori na vise nacina:

1. Kad je bilo 100 ljudi koji su glasali za Slobu i 20 koji su glasali za promene, da li je i tada vecina bila u pravu?

2. Da li to mozda govori da mali procenat ljudi u ovoj zemlji moze sebi da priusti Intela?

3. Da li to takodje govori da od 100 ljudi koji su kupili AMD njih 10-20 ima high-end konfiguracije sa S939 procesorom?

4. Da li to takodje govori da previse ljudi u ovoj zemlji misli da su pametni?

gx-x je napisao(la):
a korisnici koji su uvek imali intela i sada imaju i dalje intela, a AMD nisu imali vec samo videli (na nekom razje****m sistemu kod komsije ili neku slabiju AMD konfu (via recimo)) bitchuju po AMD-u i pricaju kako smo mi ostali fanovi itd.

Ja sam video i koristio sve od AMD K6 do A64 3200+ S754 u svim mogucim varijantama cipseta tako da to ne stoji sto se mene tice, a nisam ni mladji osim po broju postova mozda.

gx-x je napisao(la):
"barton nije bio tako dobar kao Tb-B jezgro" ne znajuci da je razlika samo i iskljucivo u kesu i da je pored toga jezgro identicno i da je barton code name, a tb-b tip jezgra... itd.

Ako je ovo aluzija na moj post u jednom drugom threadu gde sam pomenuo ova dva procesora mislio sam na termalne karakteristike jer se tb-b manje grejao nego Barton 2500+.

mcekovic je napisao(la):
execution fazu pojedinih instrukcija, a sta bi sa fetch/decode/read argumets/write results fazama?

Procitaj ti to ponovo ali ovaj put sa razumevanjem. Fetch i decode nemaju veze sa pipeline-om jer se nalaze pre njega a izmedju je Instruction Trace cache koji sadrzi dekodirane uop-ove. Read arguments i write results su kodirane u samim uop-ovima. Sto se latencije tice definicija glasi:

The number of clock cycles that are required for the execution core to complete the execution of all the uops that form IA-32 instruction.

Iz toga je jasno da broj taktova koji vidis u tabeli predstavlja broj taktova trajanja instrukcije.

Vrlo je lako to izmeriti. Koristi instrukciju koja ima Latency = Throughput i stavi je u petlju da se ponovi par hiljada puta (1,000 je dovoljno). Ocitaj pre i posle petlje TSC (Time Stamp Counter = broji taktove) pa podeli sa brojem iteracija pa ces videti koliko traje doticna instrukcija u taktovima i moci izracunati i njen vremenski ekvivalent.

mcekovic je napisao(la):
Prescott pipeline je 30 stage, i svakoj instrukciji je potrebno bar 30 taktova da se obradi od pocetka do kraja, hteo ti to da priznas ili ne.

Nema sta tu da se priznaje, ne prolazi svaka instrukcija svih 30 stage-ova, a scheduler moze da primi sledecu instrukciju vec sledeceg takta ili u slucaju ALU jedinice svakih pola takta jer ALU interno radi na duplom taktu.

Ako hoces da diskutujes o NetBurst-u nemoj da mi citiras izvore sa interneta i da ponavljas sta su drugi (koji ne razumeju) rekli o tome nego lepo procitaj ono sto sam ti rekao pa se javi, tu sam da objasnim ako nesto ne razumes.
 
Nedjo je napisao(la):
Ovim postom ti jesi postupio "advokatski"

Pratio sam ceo thread (vec je pomenut) i uvredio si coveka, za ovo ne treba advokatska titula. Ne znam samo na osnovu cega si mogao nekoga da etikatiras tako ako ga ne poznajes a nemas predstavu sta neko zna i sta je do sada uradio.I ne radi se o necijem znanju ili ne znanju, vec i principima. Na ovom forumu bi ljudi trebalo da nesto nauce (sto je moza i moglo da se kaze 2000. kada je sve pocelo) a danas mi vise podseca na spansku seriju.
 
monteboy je napisao(la):
POV-Ray
116.66 83.95 25%
Mandelbrot Benchmark
40.53 27.18 29%

A inace je u 32-bitnom modu intel brzi za 12.45%, zar to nije malo cudno? Pali li ti se lampica negde u glavi da nesto nije u redu sa tim testom? Sta ako se ispravi ta greska pa intel bude imao 131.19, a AMD i dalje 116.66? Isti komentar vazi za Mandelbrot test.

monteboy je napisao(la):
Pi-Bench
4312 8203 55%

Ovde poredis snagu dva procesora, misleci da time porices da i jedan i drugi imaju ubrzanje od 64 bita mada AMD za 15% vece od Intela.

monteboy je napisao(la):
Mini-GZIP
4.34 5.33 22%

Opet oba imaju dobitak od 64 bita iako ti to pokusavas da negiras i opet je intel u 32 bitnom modu brzi od A64.

monteboy je napisao(la):
Zasto ne postize AMD adekvatne rezultate u NVidia testu ? -> jer nijedan game trenutno ne koristi prednosti 64bitne arhitekture.

Kakve to veze s mozgom ima? Ja sam te pitao kako to da imaju isto ubrzanje od 64 bita u tom testu ali ti ocigledno na to ne umes da odgovoris.
 
GoranM je napisao(la):
Ko je hteo da shvati ovo, jasno mu je gde ce zavrsiti i ova prica sa 64 bit-a.
Hoces da kazes da ce ovaj put stati negde na 40-42 bita? 🙂
 
audiofreak je napisao(la):
Jeste, jer tvrdis nesto za sta nemas argumente. Testovi nisu u potpunosti korektni, ne odrazavaju pravu sliku stvari i prerano je diskutovati o tome.
Apsolutno, kao i sto je AMD u SiSoft Sandri sporiji u 64-bitnom modu.
Uostalom, sam autor teksta na X-bitu je rekao da je prerano donositi bilo kakve zakljucke. Ipak, to su dve potpuno razlicite arhotekture, a sad moze da se naglaba do sutra oko toga sta je za sta optimizovano.
 
Procitaj ti to ponovo ali ovaj put sa razumevanjem. Fetch i decode nemaju veze sa pipeline-om jer se nalaze pre njega a izmedju je Instruction Trace cache koji sadrzi dekodirane uop-ove.
Uh, sad si lupio glupost. Fetch i decode su faze kroz koje svaka instrukcija prolazi i itekako su deo pipeline-a. Nisu deo out-of-order ekzekucije, ako si na to mislio.

Read arguments i write results su kodirane u samim uop-ovima. Sto se latencije tice definicija glasi:
The number of clock cycles that are required for the execution core to complete the execution of all the uops that form IA-32 instruction.

Iz toga je jasno da broj taktova koji vidis u tabeli predstavlja broj taktova trajanja instrukcije.
Broj taktova execution faze izvrsavanja instrukcije, zapravo.

Vrlo je lako to izmeriti. Koristi instrukciju koja ima Latency = Throughput i stavi je u petlju da se ponovi par hiljada puta (1,000 je dovoljno). Ocitaj pre i posle petlje TSC (Time Stamp Counter = broji taktove) pa podeli sa brojem iteracija pa ces videti koliko traje doticna instrukcija u taktovima i moci izracunati i njen vremenski ekvivalent.
U, bre, opet si odvalio glupost. Ako napises tu petlju koju si opisao dobices rezultate koje ocekujes (ukoliko nema zavisnosti po podacima i pogresnih predvidjanja grananja). Ovako ces dobiti upravo one rezultate iz table, tj. vremena trajanja execution faze obrade instrukcije. Prescott-ov pipeline ima 30 stage-ova u najboljem slucaju, a pipeline obuhvata fetch, decode, read arguments, execute i write results faze (ovo je gruba pricipijelna podela, razni procesori imaju razne faze).
 
Poslednja izmena:
Nema sta tu da se priznaje, ne prolazi svaka instrukcija svih 30 stage-ova, a scheduler moze da primi sledecu instrukciju vec sledeceg takta ili u slucaju ALU jedinice svakih pola takta jer ALU interno radi na duplom taktu.
Ne znam da li namerno sabotiras ili zaista ne razumes da Prescott ima 30 stage-ova i da svaka instrukcija MORA da prodje kroz svih 30 ili vise stage-ove. To o cemu ti pricas je execution faza inzvrsavanja instrukcije. Pre nego sto instrukcija doje do execution core-a i instruction trace cache mora da bude fetch-ovana i dekodirana. To je takodje deo pipeline-a. Izgleda da brkas out-of-order execution core i pipeline.

Ako hoces da diskutujes o NetBurst-u nemoj da mi citiras izvore sa interneta i da ponavljas sta su drugi (koji ne razumeju) rekli o tome
Naravno da ne citiram nikoga, vec upotrebljavam zdrav mozak i osnove arhitekture mikroprocesora (naucenih na ETF-u, jos uvek se poneceg secam iako je to bilo pre vise od 10 godina 🙂).
 
Teorijski minimalna velicina pipeline je je 4-stage. G4-orke imaju 4-stepeni pajp. Fetch, Decode, Execute i Write su osnovni elementi svakog pipelinea.
 
mcekovic je napisao(la):
Naravno da ne citiram nikoga, vec upotrebljavam zdrav mozak i osnove arhitekture mikroprocesora (naucenih na ETF-u, jos uvek se poneceg secam iako je to bilo pre vise od 10 godina 🙂).

Kolega, bese neki DLX sa 5 stage-ova ?
 
Hajde sad svi sa ETF-a navalite, stvari su malo napredovale od kad ste vi to ucili 🙂

Iako se fetch/decode stepen vodi kao deo pipeline-a ipak on to bas i nije u klasicnom smislu jer instrukcijski cache nije pre njega nego izmedju njega i execution core-a.

Pogledajte dijagram:

netburst.gif


The pipeline of the Intel NetBurst microarchitecture contains:

• an in-order issue front end
• an out-of-order superscalar execution core
• an in-order retirement unit

The front end supplies instructions in program order to the out-of-order core. It fetches and decodes IA-32 instructions. The decoded IA-32 instructions are translated into micro-operations (μops). The front end’s primary job is to feed a continuous stream of μops to the execution core in original program order.

The out-of-order core aggressively reorders μops so that μops whose inputs are ready (and have execution resources available) can execute as soon as possible. The core can issue multiple μops per cycle.

The retirement section ensures that the results of execution are processed according to original program order and that the proper architectural states are updated.

Obratite posebnu paznju na podebljane delove teksta. Dakle, instrukcije se:

1. fetch-uju, dekodiraju i transliraju u uop-ove i salju u Trace cache. Nema nikakvnog zastoja ovde. Procesor ima konstantan priliv uop-ova za izvrsavanje.

2. OOO izvrsno jezgro agresivno rearanzira uop-ove da bi se izvrsili prvo oni koji imaju spremne ulaze i izvrsne resurse.

3. OOO izvrsno jezgro moze da zavrsi vise uop-ova u jednom ciklusu.

mcekovic, necu ti popustiti da si jos toliki i da si bos po glavi 🙂 -- ne traje svaka instrukcija 30 taktova. Pitao sam jednog od inzenjera iz Intela svojevremeno o latency/throughput situaciji i execution portovima kod P4 procesora i evo sta mi je odgovorio:

Yes, there are still execution ports, they're just "different" then what they were on P3. If I recall correctly, on P3 the ports were actual queues. If an instruction was executing on Port 1 for example, then no other instruction could use any of the units behind that Port. On P4, the ports are just groupings. So, even if an instruction is using one of execution units behind the "port", another instruction that needs another execution unit can still issue. There is a queue in front of each of the groupings, so if you have too many instructions that require the same grouping and one of the instructions is long latency (like a divide), then you can stall as a result.

Meditirajte malo nad svim ovim sto sam napisao, a ja odoh da spavam pa se vidimo sutra -- ako treba postovacu vam jos detalja i primera 🙂
 
audiofreak je napisao(la):
Hajde sad svi sa ETF-a navalite, stvari su malo napredovale od kad ste vi to ucili 🙂
Stvari se sustinski nisu promenile, u to vreme je vec postojao PentiumPro koji je prvi Intel-ov procesor sa out-of-order execution core-om. Od tada se poveco broj tranzistora, takt, pipeline, primenjeni usavrseni prediktori grananja, itd., sustinski nista novo.

audiofreak je napisao(la):
Iako se fetch/decode stepen vodi kao deo pipeline-a ipak on to bas i nije u klasicnom smislu jer instrukcijski cache nije pre njega nego izmedju njega i execution core-a.
Ako kazes da nije u klasicnom smislu deo pipeline-a onda je svakako u fizickom, tj. instrukcija mora da prodje kroz fetch/decode i za to je potreban odredjeni broj taktova.

audiofreak je napisao(la):
The pipeline of the Intel NetBurst microarchitecture contains:
• an in-order issue front end
• an out-of-order superscalar execution core
• an in-order retirement unit
Ovde lepo pise (i na slici se vidi) da je fetch/decode deo pipeline-a.

audiofreak je napisao(la):
The front end supplies instructions in program order to the out-of-order core. It fetches and decodes IA-32 instructions. The decoded IA-32 instructions are translated into micro-operations (μops). The front end’s primary job is to feed a continuous stream of μops to the execution core in original program order.

The out-of-order core aggressively reorders μops so that μops whose inputs are ready (and have execution resources available) can execute as soon as possible. The core can issue multiple μops per cycle.

The retirement section ensures that the results of execution are processed according to original program order and that the proper architectural states are updated.

Ovo je opis klasice arhitekture sa out-of-order execution core-om. Tako je radio i Pentium Pro/II/III, obican Athlon i sada Athlon 64, mada svi oni sa manjim brojem stage-ova u fazama pipeline-a.

audiofreak je napisao(la):
Obratite posebnu paznju na podebljane delove teksta. Dakle, instrukcije se:

1. fetch-uju, dekodiraju i transliraju u uop-ove i salju u Trace cache. Nema nikakvnog zastoja ovde. Procesor ima konstantan priliv uop-ova za izvrsavanje.
Sve do trenutka kada nastane greska pri predvidjanju grananja ili dodje do medjuzavisnosti instrukcija po podacima (opet se ponavljam, postaje dosadno), a ovo se moze desiti cesce ili redje, u zavisnosti od tipa algoritma.

audiofreak je napisao(la):
2. OOO izvrsno jezgro agresivno rearanzira uop-ove da bi se izvrsili prvo oni koji imaju spremne ulaze i izvrsne resurse.

3. OOO izvrsno jezgro moze da zavrsi vise uop-ova u jednom ciklusu.
Opet nista sto bi bilo specificno za NetBurst, uz napomenu da je prosecan prakticni ostvariv instrukcijski paralelizam 3-4 instrukcije po taktu i da preko toga dodavanje novih ALU jedinica ne donosi vece ubrzanje.

audiofreak je napisao(la):
mcekovic, necu ti popustiti da si jos toliki i da si bos po glavi 🙂 -- ne traje svaka instrukcija 30 taktova. Pitao sam jednog od inzenjera iz Intela svojevremeno o latency/throughput situaciji i execution portovima kod P4 procesora i evo sta mi je odgovorio...
U tom odgovoru nista ne ukazuje da se neke instrukcije mogu obraditi za manje od 30 taktova, koliko iznosi duzina Prescott pipeline-a, vec samo vise, ako je takav tip instrukcije, kao sto je pomenuto delejenje. Osim ako dodje do retire-ovanja instrukcije koja jos nije obradjena, zbog pogresno predvidjenog ishoda grananja.
 
I jos nesto u vezi pipeline-a. Pipeline postoji da bi se ostvario paralelizam na nivou faza obrade jedne instrukcije (npr. dok se jedna instrukcija fetchuje, druga se dekoduje, trece izvrsava itd...). Povecanjem broja stage-ova u pipeline-u povecava se taj paralelizam, kolicina posla koja se obavi u jednom stage-u se smanjuje i zbog toga je moguce povecati takt procesora.

Negative strane povecenja pipeline su pored hiljadu puta izrecenog pogresnog predvidjanja ishoda grananja i medjuzavisnosti instrukcija po podacima i veci broj tranzistora potreban za realizaciju takvog pipeline-a, sto smanjuje maksimalni ostvarivi takt.

Tako, ako se na primer poveca broj stage-ova u pipeline-u duplo, takt nije moguce povecati duplo, iako je kolicina posla po stage-u smanjena na pola. Prvo, jer je potrebno prebaciti instrukciju iz jednog stage-a u drugi, a za to su potrebni tranzistori, sto povecava disipaciju toplote. Drugo, nije uvek moguce precizno podeliti posao po stage-ovima. Maksimalni takt koji procesor moze da ostvari zavisi od toga koliko traje najduzi stage.

E sad, kao i sve u zivotu i prirodi, i ovde ima neka sredina (velicina pipeline-a) koja daje optimalne rezultate. U pocetku je to bila duzina pipeline-a od 4-5, vremenom se povecavala kako se proces proizvodnje usavrsavao i omogucavao upotrebu veceg broja tranzistora, koji su pak iskoriscavani za unapredjenje arhitekture (npr. sa kalsicnog pipeline-a kod 486-ice, preko dva paralelna pipeline-a kod Petiuma 1 i MMX, do out-of-order execution core-a u Pentium Pro/II/III/IV/M/D i Athlon/XP/64, itd...).

Sadasnji optimum bi bio negde izmedju 10-15 (Pentium III/M, Athlon/XP/64). Pentium 4 inkarnacije odstupaju od toga 'pravila' znacajno, neko bi cak rekao da idu ispred svoga vremena 🙂, ali to nije tako. To bi bilo slicno kada bi resili da pravimo oblakoder od cigle. Ne ide, a niko ko to pokusa ne bi bio proglasen vizionarom.

Da bi se anulirali efekti dugackog pipeline-a potrebno je znatno vise tranzistora nego sto je to danas na raspolaganju (mnogo veci branch history, bolji branch prediction algoritmi, veci out-of-order execution instruction cache-vi, neki novi pomaci u arhitekturi...). Takodje, teorijski limit instrukcijskog paralelizma unosi fizicka ogranicenja po pitanju daljih unapredjanja arhitekture, tako da verovatno postoji i teorijska granica za optimalnu duzinu pipeline-a.

Intel je sa ovako dugackim pipeline-om ciljao 2 cilja:
- ostavriti sto veci takt i iskoristiti to u marketinske svrhe.
- iskoristiti veliki takt i veliku brzinu out-of-order execution core-a uvodjenjem novih instrukcija koje bi sa posebno optimizovanim software-om donelo ubrzanje kod nekih specificnih poslova.

Ispalo je da je doslo do polovicnog ostvarenja tih ciljeva:
- polako se dostizu fizicke barijere povecenja takta procesora, tj. usitnjenje procesa proizvodnje ne dovodi vise do proporcionalno veceg takta.
- broj poslova koji se mogu optimizovati za takvu arhitekturu je relativno mali i zadovoljava relativno mali broj specijalizovanih korisnika.

Intel to sve ipak uspeva da nadoknadi znacajnom prednoscu kada je u pitanju proces proizvodnje, gde je zaista tehnoloski lider.
 
Svaka cast na upornosti, vas su ucili da instrukcija mora da prodje ceo pipeline jer tada verovatno nije ni moglo drugacije sto ne znaci da sada ne moze da bude drugacije.

mcekovic je napisao(la):
Stvari se sustinski nisu promenile, u to vreme je vec postojao PentiumPro koji je prvi Intel-ov procesor sa out-of-order execution core-om. Od tada se poveco broj tranzistora, takt, pipeline, primenjeni usavrseni prediktori grananja, itd., sustinski nista novo.

Prvo pogledaj ovu sliku:

core.gif


A sad mi reci da li si uopste procitao sta mi je odgovorio Dean P. Macri? Da li si primetio da je rekao da execution portovi vise nisu queues (redovi) kao kod ranijih arhitektura nego grupe i da jedan uop moze da ode na slobodan execution unit bez obzira na to sto je na portu drugi uop koji ceka neki drugi execution unit? To sa klasicnim dizajnom nije moguce.

mcekovic je napisao(la):
Ako kazes da nije u klasicnom smislu deo pipeline-a onda je svakako u fizickom, tj. instrukcija mora da prodje kroz fetch/decode i za to je potreban odredjeni broj taktova.
...
Ovde lepo pise (i na slici se vidi) da je fetch/decode deo pipeline-a.

Da ali je i-cache izmedju njega i execution core-a!

i-cache kod netbursta nije isto sto i i-cache kod bilo kog drugog procesora. On sadrzi vec dekodirane instrukcije u vidu uop-ova i to u programskom redosledu, a rezultati skokova se integrisu u istu cache liniju. Ne mozes reci da je to isto kao PPro ili bilo sta drugo.

mcekovic je napisao(la):
U tom odgovoru nista ne ukazuje da se neke instrukcije mogu obraditi za manje od 30 taktova, koliko iznosi duzina Prescott pipeline-a, vec samo vise, ako je takav tip instrukcije, kao sto je pomenuto delejenje. Osim ako dodje do retire-ovanja instrukcije koja jos nije obradjena, zbog pogresno predvidjenog ishoda grananja.

Prvo, zaboravio sam da ti kazem da NetBurst procesori nemaju samo jedan pipeline (sto automatski znaci da nemaju svi pipeline-ovi 30 stage-ova koje pominjes):

"The μops are dispatched to the pipeline that corresponds to the correct type of operation."

Drugo, zasto uporno mislis da ne moze da dodje do retire-ovanja instrukcije koja nema potrebe da prolazi kroz sve stage-ove, odnosno instrukcije koja je zavrsila svoje za manji broj taktova? Da li svaka instrukcija po tebi koristi sve izvrsne jedinice u cipu sa 125 mil. tranzistora ili sta?

Prijateljski te savetujem, pocni da citas onaj pdf od strane 35 i procitaj bar do strane 52 pa se javi da nastavimo.
 
Poslednja izmena:
Lukija je napisao(la):
Pratio sam ceo thread (vec je pomenut) i uvredio si coveka, za ovo ne treba advokatska titula. Ne znam samo na osnovu cega si mogao nekoga da etikatiras tako ako ga ne poznajes a nemas predstavu sta neko zna i sta je do sada uradio.I ne radi se o necijem znanju ili ne znanju, vec i principima. Na ovom forumu bi ljudi trebalo da nesto nauce (sto je moza i moglo da se kaze 2000. kada je sve pocelo) a danas mi vise podseca na spansku seriju.
Ali zasto, zasto se raspravljas samnom bez ikakvog razloga?
Cime sam ja u ovom tredu uvredio tvog prijatelja? Time sto sam rekao da sa njim i sa Soso covek ne moze da se raspravlja?
Pa taj tvoj freak je mnogo tezim recima pocastio mnoge u ovom tredu!
Slazem se da lici na spansku seriju, a debelu odgovornost za to snose tvojoji drugari (vise SoSo koja nije konstruktivnog treda postavila jos od rezultata u Photoshopu)!
Freak, s druge strane, udara u klin, a fedja, Monty, cekovic i donekle ja u plocu! Sumnjam da cemo postici dogovor, zato sam i batalio raspravu!
Sto se Freak-a tice, on nesumnjivo puno zna i gre'ota je da to znanje prodaje za 10€/h, malo je brate, a i nezdravo za pametne mlade ljude poput njega! Ja mu zelim da ode preko grane i minimalno udesetostruci svoju satnicu. Mozda ce mu i postovi tada imati drugaciji tonalitet!
Poz
Nedjo
 
Nedjo je napisao(la):
Pa taj tvoj freak je mnogo tezim recima pocastio mnoge u ovom tredu!
...
Mozda ce mu i postovi tada imati drugaciji tonalitet!

???

Sta je pisac hteo da kaze?

Meni je mcekovic dva puta rekao da sam "odvalio glupost" napola procitavsi sta sam napisao -- da li sam ja to ikome ovde rekao?

Monteboy je rekao SoSo da "polako postaje smjesna", a meni "S tobom kao sa malom decom!" -- da li sam ja to ikome ovde rekao?

S druge strane, ukazati nekome na to da ima predrasude nije uvreda za pametnog coveka, vec prilika da prosiri svoje znanje.

Cak ni reci nekome da je fanboy nije toliko uvredljivo koliko je ruzno otvoreno reci nekome "Glup si!" kao sto si ti meni rekao u drugom threadu, a sada krajnje licemerno hvalis moje znanje.
 
audiofreak je napisao(la):
Svaka cast na upornosti, vas su ucili da instrukcija mora da prodje ceo pipeline jer tada verovatno nije ni moglo drugacije sto ne znaci da sada ne moze da bude drugacije.
Ako mislis na mogucnost da instrukcija ne prodje fetch i decode fazu, vec da se prepozna u obliku UOP-ova i instruction trace cache-u, OK, to mi je jasno. Ali to je samo postapalica da se anuliraju problemi koji nastaju zbog dugackog pipeline-a.

audiofreak je napisao(la):
Prvo, zaboravio sam da ti kazem da NetBurst procesori nemaju samo jedan pipeline (sto automatski znaci da nemaju svi pipeline-ovi 30 stage-ova koje pominjes):

"The μops are dispatched to the pipeline that corresponds to the correct type of operation.
Ovo se odnosi na sub-pipeline-ove u okviru execution core-a.

audiofreak je napisao(la):
Drugo, zasto uporno mislis da ne moze da dodje do retire-ovanja instrukcije koja nema potrebe da prolazi kroz sve stage-ove, odnosno instrukcije koja je zavrsila svoje za manji broj taktova?
Moguce je da postoje neke instrukcije koje npr. ne vracaju rezultat pa ne moraju da prodju kroz write results fazu, ali to je izuzetak.
Vecina instrukcija mora da prodje kroz sve faze 30-stepenog pipeline-a sa svim manama istog.
Da NetBurst valja to bi se pokazalo na benchmarcima, a i drugi proizvodjaci bi odmah maznuli ideju i kopirali je u svojim procesorima.
 
Meni je mcekovic dva puta rekao da sam "odvalio glupost" napola procitavsi sta sam napisao -- da li sam ja to ikome ovde rekao?
Reci da fetch/decode nisu deo pipeline-a nije tacno. Ti posmatras execution core kao jedino sto postoji kod NetBurst-a, a ne vidis da je za optimalno funkcionisanje istog potrebno imati stalan priliv instrukcija iz fetch i decode faze, te podataka za operande iz memorije (ili cache-a sve jedno). Cim dodje do poremecaja u prilivu bilo instrukcija ili operanada gubi se na brzini, sto je duzi pipeline to vise. Sta mislis kako je Athlon 64 brzi od obicnog Athlona 10-20% na istom taktu, a gotovo da imaju isti execution core? Tako sto je priliv instrukcija i podataka poboljsan (integrisani memorisjki kontroler, bolji cache, branch prediction itd.). AMD je uvideo gde je problem, a Intel nije. Tj. verovatno i jeste, ali nije u mogucnosti da ga resi sa trenutnim procesom izrade i respolozivim brojem tranzistora. Zato je i ubacio HyperThreading da poveca iskorsenost resursa u execution core-u jer su nedovoljno iskorisceni.
 
audiofreak je napisao(la):
???
Cak ni reci nekome da je fanboy nije toliko uvredljivo koliko je ruzno otvoreno reci nekome "Glup si!" kao sto si ti meni rekao u drugom threadu, a sada krajnje licemerno hvalis moje znanje.
Zao mi je sto mislis da sam licemeran u hvaljenju tvog znanja! Zaista nisam.
Ono "glup" iz drugog treda sam napisao zato sto si ti rekao da ce te vlasnika AMD-a tako nazvati zbog tvog stava.
Po meni je najgluplje sto si ti u opste napisao da te neko nazove glupim, a moj post je samo bio karikiranje tvog poziva. Ako cemo vec da pravimo paralele izmedju procesora i automobila, onda je AMD Astom Martin, a Intel je Hyundai Coupe 😉
:wave:
 
mcekovic je napisao(la):
Ako mislis na mogucnost da instrukcija ne prodje fetch i decode fazu, vec da se prepozna u obliku UOP-ova i instruction trace cache-u, OK, to mi je jasno. Ali to je samo postapalica da se anuliraju problemi koji nastaju zbog dugackog pipeline-a.

Da, mislim na to da jednom fetch-ovane i dekodirane instrukcije ne prolaze ponovo kroz tu fazu, znaci da je fetch i decode izdvojen ispred pipeline-a, tj. da je to front-end.

mcekovic je napisao(la):
Ovo se odnosi na sub-pipeline-ove u okviru execution core-a.

Da i ono sto je bitno je da ti sub-pipelineovi koji su u stvari pojedinacne izvrsne jedinice koje vidis iza execution portova na poslednjoj slici (ALU, FPU, itd) nisu iste duzine odnosno nemaju svi 30 stageova jer nisu sve instrukcije podjednako kompleksne.

mcekovic je napisao(la):
Vecina instrukcija mora da prodje kroz sve faze 30-stepenog pipeline-a sa svim manama istog.

Ne znam stvarno sta drugo da ti kazem osim da ponovo pazljivo procitas onaj deo u pdf-u dok ne shvatis da to nije tacno. Nema svrhe vise da te ubedjujem. To ti je kao da se C++ programer raspravlja sa matematicarem da li je krug isto sto i elipsa.

mcekovic je napisao(la):
Da NetBurst valja to bi se pokazalo na benchmarcima, a i drugi proizvodjaci bi odmah maznuli ideju i kopirali je u svojim procesorima.

Da ne ulazim u to da li valja ili ne valja, bitno je razumeti kako radi da bi se kritikovalo, a sto se tice maznjavanja ideje to bas nije tako jednostavno maznuti.
 
audiofreak je napisao(la):
Da i ono sto je bitno je da ti sub-pipelineovi koji su u stvari pojedinacne izvrsne jedinice koje vidis iza execution portova na poslednjoj slici (ALU, FPU, itd) nisu iste duzine odnosno nemaju svi 30 stageova jer nisu sve instrukcije podjednako kompleksne.
Kad sam rekao 30 stage-ova mislio sam na pun put instrukcije, od fetch/decode do execute i write results, ne samo na execute.


audiofreak je napisao(la):
Ne znam stvarno sta drugo da ti kazem osim da ponovo pazljivo procitas onaj deo u pdf-u dok ne shvatis da to nije tacno. Nema svrhe vise da te ubedjujem. To ti je kao da se C++ programer raspravlja sa matematicarem da li je krug isto sto i elipsa.
Mozes me uvek ubediti u nesto sto je tacno. Ovde ipak i benchmarci i teorija ukazuju na suprotno.


audiofreak je napisao(la):
a sto se tice maznjavanja ideje to bas nije tako jednostavno maznuti.
Mozda na kraci rok nije (npr. Intel-ova nedorecena implementacija speed step-a u P4 seriji 6, ili pak (nedorecene?) 64-bitne extenzije?).
Ali na srednji i duzi rok to nije problem. Pa Microsoft maznjava ideje, bez pardona implementira u svoje prozvode i od toga lepo zivi. Intel je vec najavio da ce u buducnosti takodje integrisati memorisjki kontroler u procesor, ali niko od vodecih proizvodjaca procesora (pored Intel-a) nije najavio da ce razvijati nesto slicno NetBurst-u.
 
E ljudi mislim stvarno ! Totalno ste off-topik !!! Bez zezanja, audiofreak i mcekovic, vasi programerski postovi i brdo stvari koje jeidno vi razumete nemaju nikakve veze sa amd vs intel 64bit instrukcijama. Niti razumem sta pisete, niti citam, ne verujem da jos neko sem vas dvojice cita vasu pipeline prepirku. Nismo svi sa ETF-a ovde i iako vi pisete stvari vezane za IT one su nevezane za ovaj topik !
 
gx-x je napisao(la):
E ljudi mislim stvarno ! Totalno ste off-topik !!! Bez zezanja, audiofreak i mcekovic, vasi programerski postovi i brdo stvari koje jeidno vi razumete nemaju nikakve veze sa amd vs intel 64bit instrukcijama. Niti razumem sta pisete, niti citam, ne verujem da jos neko sem vas dvojice cita vasu pipeline prepirku. Nismo svi sa ETF-a ovde i iako vi pisete stvari vezane za IT one su nevezane za ovaj topik !

A ko je tebe sta pitao? 😀
Kakvi programerski postovi? O cemu ti pricas? 😀 Kako nema veze sa 64 bitnim instrukcijama? 🙂 Ovo je jedna od zanimljivijih rasprava (svaka cast audiofreak-u na upornosti, ja sam odavno digao ruke 😀) na benchu. Smorile su teme poput onih: "koliko se klokuje vas procesor?"

:wave: za Lukiju, audiofreak-a i SoSo 😀
 
Nazad
Vrh Dno