Šta je novo?

DualCore i za igrache

  • Začetnik teme Začetnik teme Nedjo
  • Datum pokretanja Datum pokretanja

Nedjo

Čuven
VIP član
Učlanjen(a)
12.07.2000
Poruke
6,934
Poena
800
Evo jednog veeoma intrigantnog grafikona:

http://www.firingsquad.com/hardware/quake_4_cpu_performance/images/amdlow.gif

Jasno je sta je intrigantno! A64 3200 (2GHz/512kb L2) baca 96 fps, a X2 3800 (2GHz/512kb L2) 113, sto ga cini brzim cak i od FX-a 55, odn. A64 4000?!
Ovo je prvi put, koliko je meni poznato, da DC CPU ima ikakvu, a kamoli merljivu prednost u igrama u odnosu na isto klokovani SingleCore.
Ne verujem da je nesto D3 masina unapredjena u SMT smeru, i sve "smrdi" na ForceWare optimizaciju, mada mi je i to na granici sa neverovatnim. Mislim, da programeri drajvera toliko mogu da uticu na performanse da je to vidljivo... zaista sjajno! Definitivno programeri igara moraju debelo da zagreju stolice i savladaju kako treba SMT programiranje!

Inace grafikon je iz clanka u kome je Athlon ponovo razbio Pentiuma:

http://www.firingsquad.com/print_article.asp?current_section=Hardware&fs_article_id=1746
 
Meni su ti resultati sumljivi, moguce je da je doslo do neke greske pri testu, neko setovanje nije bilo isto u oba slucaja ili slicno.
 
Sumnjam da su netacni, pogotovo zato sto sam dobijao slicne rezultate, kada sam za casopis PC (#115) testirao, doduse, PentiumD procesor. F.E.A.R u odredjenoj meri koristi i resurse drugog jezgra, a mislim da drugi procesor odradjuje "fiziku" ili tako nesto.
 
Poslednja izmena:
Nedjo koliko god neverovao drajveri za graficku su napravili toliku razliku. D3 Engine je nazalost veoma single threded.
 
Poslednja izmena:
Ma da, onda bi bilo logicno da povuku Single Core armadu sa trzishta🙂))))
 
Paradigma je napisao(la):
Nedjo koliko god neverovao drajveri za graficku su napravili toliku razliku.

Cekaj malo, sta bre rade onda ti drajveri kada je ubrzanje toliko, tj. oko 15% dodavanjem drugog core-a?

Ako pretpostavimo da je u datom test usko grlo procesor (sto verovatno i jeste jer FPS lepo linearno skalira sa ubrzanjem procesora), znaci da bar 15% vremena procesor provodi u driverima za graficku. Strasno. A ja mislio da su driver-i za graficku samo thin layer oko hardware-a.
 
mcekovic je napisao(la):
Cekaj malo, sta bre rade onda ti drajveri kada je ubrzanje toliko, tj. oko 15% dodavanjem drugog core-a?

Ako pretpostavimo da je u datom test usko grlo procesor (sto verovatno i jeste jer FPS lepo linearno skalira sa ubrzanjem procesora), znaci da bar 15% vremena procesor provodi u driverima za graficku. Strasno. A ja mislio da su driver-i za graficku samo thin layer oko hardware-a.

Lepo si rezonovao i dosao do odgovora. Filozofija grafickog hardvera je odavno u paralelizmu i drajveri to prate vec dugo vremena pa im je ovakva podrska u hardveru "legla ko budali samar".
 
genijalcin@23 je napisao(la):
Sumnjam da su netacni, pogotovo zato sto sam dobijao slicne rezultate, kada sam za casopis PC (#115) testirao, doduse, PentiumD procesor. F.E.A.R u odredjenoj meri koristi i resurse drugog jezgra, a mislim da drugi procesor odradjuje "fiziku" ili tako nesto.

Au, ja sam izgleda pogresio forum. :d Mislio sam da pricate o F.E.A.R-u i DC. Pa nista, odoh ja 😀😀😀
 
http://techreport.com/reviews/2005q2/opteron-x75/index.x?pg=14

ne moze dual CPU masina da crta sa vise procesora bilo kakav 3D bre, to je valjda (cenim, nemam pojma realno) ogranicenje u samom APIju, tako da od smp-a nema leba u skorije vreme, ko i 64bita, mazanje ochiju radi vece prodaje 😉
aj da se ne lazemo, ko je mislio drugachije, grdno se ponadao i prevario 😛
 
Poslednja izmena:
Ne znam zasto ne bi moglo.
Tj. mozda trenutno ne zna, ali moze sigurno.
 
Чекајте...
Колико се мени чини, архитекте графичких процесора на сва звона кукају да сцена треба да се исцртава у што мањем броју batch позива, јер у противном апликација постаје cpu-limited. То се уосталом јако лепо види у 3Dmark05, у оном тесту FPS vs. Batch Size, не сећам се тачно како се зове.
Да ли постоји могућност да драјвер распореди позиве на оба језгра?
 
Poslednja izmena:
Serious Sam 2 koristi multi threading!I...AMD "ubija" Intela!

Ozbiljni Sima2,kao i Q4 definitivno nesto koristi od multi thread.Rezultati su nedvosmisleni.
Pogledajte samo razliku u frejmovima izmedju AMD i intela u Battlef2...Auu,razlika je ubitacna(posebno u non-GPU bound igrama)

http://www.xbitlabs.com/articles/cpu/display/28cpu-games_5.html
 
ivanbo2003 je napisao(la):
Ozbiljni Sima2,kao i Q4 definitivno nesto koristi od multi thread.Rezultati su nedvosmisleni.
Pogledajte samo razliku u frejmovima izmedju AMD i intela u Battlef2...Auu,razlika je ubitacna(posebno u non-GPU bound igrama)

http://www.xbitlabs.com/articles/cpu/display/28cpu-games_5.html

Toliko je ubitacna razlika da bi ja voleo da disasembliram kod i da vidim zasto ga AMD izvrsava toliko brze, prosto mi je sumnjivo kako u drugim igrama to nije tako drasticno.

EDIT:

Pogledao, delimicno double precision FPU, Visual Studio 2003 C++ kompajler, katastrofalno neoptimizovan kod. Uopste nije cudno sto je sporo na NetBurst-u. Kao da je neko namerno to uradio. Pa mogli su makar da stave /G7 /arch:SSE ako nista drugo majku im.
 
Poslednja izmena:
audiofreak je napisao(la):
Toliko je ubitacna da bi ja voleo da disasembliram kod i da vidim zasto ga AMD izvrsava toliko brze, prosto mi je sumnjivo kako u drugim igrama to nije tako drasticno.

Neverujem da je optimizovano za amd-a,mislim toliko muke da bi optimizovali za cpu koji nema ni 1/4 cpu trzista.It is ilogical.Implikacija==>tek cemo videti prednosti k8 derivata sa novijom generacijom igara(posebno multithreadovanim)
 
ivanbo2003 je napisao(la):
Neverujem da je optimizovano za amd-a,mislim toliko muke da bi optimizovali za cpu koji nema ni 1/4 cpu trzista.It is ilogical.Implikacija==>tek cemo videti prednosti k8 derivata sa novijom generacijom igara(posebno multithreadovanim)

Nisi me razumeo, ne da nije optimizovan za AMD nego NIJE OPTIMIZOVAN NI ZA STA OSIM ZA Pentium 1.

Takodje, ovakve "prednosti" K8 mogu optimizacijom koda samo da se smanje, nikako povecaju i to ne zato sto ce optimizacija usporiti kod za K8 nego ce dovesti NetBurst na normalan nivo koji ima u drugim igrama.
 
Poslednja izmena:
audiofreak je napisao(la):
Nisi me razumeo, ne da nije optimizovan za AMD nego NIJE OPTIMIZOVAN NI ZA STA OSIM ZA Pentium 1.

Takodje, ovakve "prednosti" K8 mogu optimizacijom koda samo da se smanje, nikako povecaju i to ne zato sto ce optimizacija usporiti kod za K8 nego ce dovesti NetBurst na normalan nivo koji ima u drugim igrama.

U svakom slucaju cemo videti vremenom sta je u pitanju.Neko ce vec uzeti Sema i iseckati ga 😀 :type: .Inace k8 je i ranije u skoro svim igrama dominirao(negde vise negde manje),tako da su nove vesti u stvari "stare".Lepo je videti da Q4 "priznaje" drugi core i upotrebljava ga za nesto koristno(kroz forceware driver?).Hm pitam se kada ce ATI da izbaci nove multi thread. kataliste...
 
audiofreak je napisao(la):
Nisi me razumeo, ne da nije optimizovan za AMD nego NIJE OPTIMIZOVAN NI ZA STA OSIM ZA Pentium 1.
Cek malo, pa zar nije konstatovanoo da je optimizovano za DuaCore?
Ako sam dobro razumeo drugi deo posta, ti 'oces da kazes da u SS2 u opste nije implementirana SS(kakve li ironije)E optimizacija?
 
Sad sam pogledao test.. Ako su već merili performanse u igrama, mogli su i Intel da stave na nforce ploču. Asus P5N32-SLI na primer, koja u igrama daje i 10% bolje rezultate u odnosu na 955X.
 
Poslednja izmena:
Snejk je napisao(la):
Sad sam pogledao test.. Ako su već merili performanse u igrama, mogli su i Intel da stave na nforce ploču. Asus P5N32-SLI na primer, koja u igrama daje i 10% bolje rezultate u odnosu na 955X.
Heh ne bi to spasilo intel kad je razlika skoro dupla u nekim sllucajevima(10% mnogo ne pomaze...)
 
Nedjo je napisao(la):
Cek malo, pa zar nije konstatovanoo da je optimizovano za DuaCore?
Ako sam dobro razumeo drugi deo posta, ti 'oces da kazes da u SS2 u opste nije implementirana SS(kakve li ironije)E optimizacija?

Nisi razumeo ja pricam za Battlefield II koji je uzasno sporiji, njega sam disasemblirao. Nema uopste nikakve optimizacije, floor() se zove sa 15-tak mesta, 64-bitni shift preko 2 32 bitna registra (shld edx, eax, cl) umesto preko MMX ili SSE sa 50-tak mesta, itd. FPU kod dominira.

Jos jedan primer, moderne CD zastite (npr. Starforce) nabacuju veliki penal za P4 jer delove koda desifruju pred izvrsavanje pa ga posle ponovo sifruju sto se svodi na samomodifikujuci kod (inace veliko NO-NO u programiranju). To za P4 znaci flush ne samo pipeline-a nego i celog Trace cache-a. Koliko je to uzasan penal ne moram uopste da objasnjavam.
 
Poslednja izmena:
znas koliko bilo kog prosecnog korisnika kompa zanima to sto ti pricas, tj. kakav je BF2 sto se toga sto ti pises tice? Isto onoliko koliko i prosecnog kupca dual core procesora da li je 'lelegantno' kao kod intela ili 'elegantno' kao kod amd-a 😉
znachi rezultati su jedno, a ShBBKBB je sasvim drugo 🙂
 
audiofreak je napisao(la):
Nisi razumeo ja pricam za Battlefield II koji je uzasno sporiji, njega sam disasemblirao. Nema uopste nikakve optimizacije, floor() se zove sa 15-tak mesta, 64-bitni shift preko 2 32 bitna registra (shld edx, eax, cl) umesto preko MMX ili SSE sa 50-tak mesta, itd. FPU kod dominira.

Jos jedan primer, moderne CD zastite (npr. Starforce) nabacuju veliki penal za P4 jer delove koda desifruju pred izvrsavanje pa ga posle ponovo sifruju sto se svodi na samomodifikujuci kod (inace veliko NO-NO u programiranju). To za P4 znaci flush ne samo pipeline-a nego i celog Trace cache-a. Koliko je to uzasan penal ne moram uopste da objasnjavam.
Proslo je vec pet godina od predstavljanja NET Burst arhitekture, a softverasi jos nisu napravili kod koji radi kako treba. To izgleda znaci da je vreme da se Net Burst salje u penziju jer je P4 jednostavno osakacen za neke stvari. :crash:
Ne znam sta da ti kazem, ali pisi im, posalji im tvoju optimizaciju za Battlefield 2, ko zna mozda ti ponude dobar posao 😀
 
@Ji4tze:

Slazem se da to mnoge ne zanima, ali hteo sam da kazem da ljudi em placaju za neoptimizovano djubre od softvera, em jos i za jak hardver da bi mogli iole pristojnom brzinom da ga izvrsavaju.

drfedja je napisao(la):
Proslo je vec pet godina od predstavljanja NET Burst arhitekture, a softverasi jos nisu napravili kod koji radi kako treba. To izgleda znaci da je vreme da se Net Burst salje u penziju jer je P4 jednostavno osakacen za neke stvari. :crash:
Ne znam sta da ti kazem, ali pisi im, posalji im tvoju optimizaciju za Battlefield 2, ko zna mozda ti ponude dobar posao 😀

Nije mi smesno, bilo bi dovoljno da su stavili /O2 /G7 /arch:SSE kad su prevodili program (to cak i MonteBoy zna 😀), nisu cak morali ni da trose pare na neki razvoj i sta ti ja znam nego samo da iskoriste mogucnosti kompajlera do kraja, a oni ni to nisu uradili. Sramota. Kao da zaista ocekuju da ce neko jos takvu igru moci da igra na bilo cemu slabijem od Pentiuma 3 ili Athlona XP kad se dobro zna da u takve masine ne mogu da udju graficke koje su potrebne za neki minimum igrivosti.
 
Slazem se da je ukoliko postoji tako lak nacin za neku, pa maka ona bila i minimalna, optimizaciju glupo je ne iskoristiti! Sta mislis da li mozda postoji neki scenaio, sem besmislenog jurenja kompatibilnosti za nonSSE procesorima, zbog kog bi bilo problema sa eventualnim SSE kompajliranjem? Da li bi ukljucivanje SSE flaga za kompajler generisalo kod koji bi bio sporiji na AXP-ima, ili bi oni i dalje mogli da se oslanjaju na svoju jaku trostruku FPU jedinicu, bez obzira na SSE kompajl?
Cinjneica je da SIMD optimizacija moze dosta da ubrza kod i ukoliko su aktuelni alati do te mere pojednostavljeni, onda mi stvarno nije jasno zasto ni u danasnje vreme jako jako malo sw-a ne koristi SIMD?
 
pogledajte osvrt na optimizaciju kompajlera i na sve drugo sto vas zanima u vezi arhitekture procesora/kompajlera/net bursta na www.emulators.com pa odeljak "secrets".
tu mozete naci detaljnu analizu Pentiuma 4, mozda najbolje objasnjenu do sada - razumljivo je 🙂 pored toga ima i prica o kompajlerima... bas ono sto je audio freak rekao - kompajleri su uglavnom losi i ne stizu da isprate procesore.
 
Nedjo je napisao(la):
Cinjneica je da SIMD optimizacija moze dosta da ubrza kod i ukoliko su aktuelni alati do te mere pojednostavljeni, onda mi stvarno nije jasno zasto ni u danasnje vreme jako jako malo sw-a ne koristi SIMD?

Па не знам баш... Моје искуство говори да SIMD оптимизације у компајлеру и не доносе значајан добитак ако сам код није написан како треба. То су векторске операције (сабирање/множење 4 и 4 32-битна float-a) па сами операнди треба да буду доступни у исто време и међусобно независни како би компајлер знао да искористи SSE сет.
Навешћу пример брзе Фуријеове трансформације коју сам из хобија (желећи да научим SSE) програмирао прошле зиме- Коришћењем пажљиво испрограмираног SSE intrinsics кода (_mm_add_ps, _mm_mul_ps, довлачење у кеш података који ће ти ускоро требати...) добијају се и до 3 пута бољи резултати него чистим C-ом, уз све укључене оптимизације. Наравно, ово је један драстичан пример, FFT је као створен за векторске операције, али поента је да никакав компајлер не може да направи тако добар код какав могу ручне оптимизације.
 
audiofreak je napisao(la):
Nije mi smesno, bilo bi dovoljno da su stavili /O2 /G7 /arch:SSE kad su prevodili program (to cak i MonteBoy zna 😀), nisu cak morali ni da trose pare na neki razvoj i sta ti ja znam nego samo da iskoriste mogucnosti kompajlera do kraja, a oni ni to nisu uradili. Sramota. Kao da zaista ocekuju da ce neko jos takvu igru moci da igra na bilo cemu slabijem od Pentiuma 3 ili Athlona XP kad se dobro zna da u takve masine ne mogu da udju graficke koje su potrebne za neki minimum igrivosti.

A da nisi mozda dosao na ideju da su kompilirali Source koji bi radio i na masinama koje ne podrzavaju SSE2 cisto radi kompatibilnosti na dolje ?

Recimo Athlon XP savrseno podrzava graficke koje su u mogucnostima da odrade sasvim solidno posao. Zasto bi zbog bulja FPU'a jednog P4 zabranio korisnicima jednog Athlon XP'a ovu igru ?
 
monteboy je napisao(la):
A da nisi mozda dosao na ideju da su kompilirali Source koji bi radio i na masinama koje ne podrzavaju SSE2 cisto radi kompatibilnosti na dolje ?

Audiofreak prica o SSE i masinama slabijim od P!!! i Athlona XP, a ti o SSE2 i masinama slabijim od P4.

Razlika izmedju SSE i SSE2 je u tome sto ovaj prvi radi sa 32-bitnim FP brojevima (float), dok je potonji malte-ne isto to, samo sto operise sa 64-bitnim brojevima (double). SSE instrukcijski set je savrseno dovoljan za primenu u igrama i low end multimediji, dok se SSE2 koristi pretezno u kompresiji videa i CAD aplikacijama.

Poenta - SSE2 uopste nisu morali da koriste, samo bi bilo sporije. SSE su mogli itekako.
 
3MaJ je napisao(la):
Razlika izmedju SSE i SSE2 je u tome sto ovaj prvi radi sa 32-bitnim FP brojevima (float), dok je potonji malte-ne isto to, samo sto operise sa 64-bitnim brojevima (double). SSE instrukcijski set je savrseno dovoljan za primenu u igrama i low end multimediji, dok se SSE2 koristi pretezno u kompresiji videa i CAD aplikacijama.

Poenta - SSE2 uopste nisu morali da koriste, samo bi bilo sporije. SSE su mogli itekako.

SSE su mogli slazem se ali zbog cega onda to znaci da se isto nebi izvrsavalo i na AMD masinama brze ?

konkretna razlika izemedju P4 i AMD sistema bi bila od prilike ista. Jedino ako koristis specialno Intelov kompajler sa G7 opcijom koju je audio gore pomenuo imas poseban benefit na P4 platformi jer optimizuje code posebno za NetBurst

Ipak nebih stavio tezinu toliko na SSE , to inache voli audio da koristi kao argumenat da bi odbranio Intel platormu. Usko grlo je uvijek bila memorija i pristup istoj gdje ja vidim najvecu prednost AMD arhitekture.

Jednostavno mozes testirati uticaj -> izradi aplikaciju koja odradjuje recimo miliardu SSE operacija dok recimo svaka 100 operacija pristupi memoriji

i onda izradi drugu aplikaciju koja 100 puta pristupi memoriji a onda tek odradi jedan SSE proracun naravno sve ukupno miliardu puta videces enormnu prednost AMD arhitekture kad je cest pristup memoriji u pitanju.
 
Poslednja izmena:
monteboy je napisao(la):
SSE su mogli slazem se ali zbog cega onda to znaci da se isto nebi izvrsavalo i na AMD masinama brze ?
Ако се програмер ослони само на компајлер, може да се деси да коришћењем SSE "оптимизација" добије спорији код. Али, ако тачно за шта пише, дакле, критичне делове кода као
Kod:
asm{
.
<SSE инструкције овде>
.
}
Или користи SSE intrinsics (што је по мом скромном мишљењу решење боље од претходног ), добици на брзини су више него приметни!
 
Poslednja izmena:
Nazad
Vrh Dno