Odnos 64 bitnih sistema AMD vs Intel

monteboy · 10.03.2005

audiofan citiram gospodina Jim Allchin'a inache kod Microsoft'a odgovornog za operativne sisteme :

“Jim Allchin calls the performance of software on the AMD [processor-based] machines ‘pretty amazing’.”
Microsoft took applications written for today's 32-bit chips and ran
them on an [AMD] Opteron [processor-based] server loaded with the new
Windows® 64-bit operating system. The programs performed considerably
better than the same ones using 32-bit Windows. Microsoft's new operating
system allows any application to reach deeper into memory. “We can give
any 32-bit application an additional gigabyte of memory, and you don't have
to write a single byte of code,” says Allchin. Programs written especially for
64 bits get further ‘dramatic performance advantages,’ he says.”1

audiofreak · 10.03.2005

monteboy je napisao(la):
zato ovo tvoje kompletno izlaganje Datasheet'ova i dokazivanje kako je genialna i efikasna Intel'ova arhitektura ispada kao Spam jer prakticki gledano ne biva primijenjana.

Zasto se ti sad javljas na repliku kada sam ja ovaj drugi PDF namenio mcekovicu licno zbog toga sto smatram da ima neke miskoncepcije u vezi pipeline-a i arhitekture modernih procesora? I jos pokusaj edukacije ljudi nazivas Spam-om? Stvarno mi nisi jasan.

monteboy je napisao(la):
Mislim da su tvoja ocekivanja nerealna ukoliko ocekujes da ce svaka Softwarska kuca optimizovati code na nivou low level programiranja

Nikad ja nisam rekao da imam takva ocekivanja. Ja samo ocekujem da programeri znaju kako radi procesor za koji pisu i da znaju kako radi kompajler kako bi im olaksali posao, a ne da koriste brute-force i traze od ljudi da kupe jak procesor da bi mogli da korsite softver za koji to realno nije neophodno.

monteboy je napisao(la):
Neznam koliko si upoznat sa profesionalnim izradom Software , business aplikacija kao sto ih izradjuje firma gdje radim ali nikad nam panulo nije na pamet optimizovati code samo za jedan procesor

Opet mi imputiras nesto sto nisam rekao, ja ne trazim da kod bude posebno optimizovan za jedan procesor nego samo da bude optimizovan.

monteboy je napisao(la):
Optimizacije koje nude danasnji kompajleri su sasvim dovoljne pogotovo kad su u pitanju C (C++) Kompajleri.

Na zalost nisu dovoljne za sve primene.

monteboy je napisao(la):
nacin programiranja i optimizacije utice sigurno na izvrsavanje code'a ali sigurno ne u tolikim dimenzijama da bi izvrsavanje bilo povecano za preko 50% onda vise ne mozemo govorit o losem stilu programiranja nego namjernom gusenju brzine izvrsavanja aplikacije.

Hoces primer?

Kod:

int CalcIt(double a, int b)
{
	double coef[8] = {1.0, 0.915, 10.0/12.0, 9.0/12.0, 0.715, 8.0/12.0, 5.0/8.0, 1.0/2.0};
	int t;
	t = (int)ceil(a / coef[b]);
	return t;
}

Kompajliraj cime hoces i probaj da pozoves par hiljada puta ovu funkciju. Zatim stavi coef da bude globalna promenljiva (van funkcije) pa probaj ponovo. Ne bi bilo lose ni da pogledas asemblerski listing u oba slucaja da vidis koliku razliku moze da napravi jedna tako banalna stvar uradjena potpuno slucajno. Mozes da probas i da napravis veci niz (npr. stotinak elemenata) ako ne uocis odmah razliku u asemblerskom kodu. Ja nisam merio razliku u brzini, verovatno je manja od 50%, ali malo po malo pa se nakupi pogotovo kad programer nije svestan da to sto je napisao nije optimalno.

monteboy · 10.03.2005

audiofreak je napisao(la):
Zasto se ti sad javljas na repliku kada sam ja ovaj drugi PDF namenio mcekovicu licno zbog toga sto smatram da ima neke miskoncepcije u vezi pipeline-a i arhitekture modernih procesora? I jos pokusaj edukacije ljudi nazivas Spam-om? Stvarno mi nisi jasan.

Nikad ja nisam rekao da imam takva ocekivanja. Ja samo ocekujem da programeri znaju kako radi procesor za koji pisu i da znaju kako radi kompajler kako bi im olaksali posao, a ne da koriste brute-force i traze od ljudi da kupe jak procesor da bi mogli da korsite softver za koji to realno nije neophodno.

Opet mi imputiras nesto sto nisam rekao, ja ne trazim da kod bude posebno optimizovan za jedan procesor nego samo da bude optimizovan.

Na zalost nisu dovoljne za sve primene.

Hoces primer?

Kod:

int CalcIt(double a, int b) { double coef[8] = {1.0, 0.915, 10.0/12.0, 9.0/12.0, 0.715, 8.0/12.0, 5.0/8.0, 1.0/2.0}; int t; t = (int)ceil(a / coef[b]); return t; }

Kompajliraj cime hoces i probaj da pozoves par hiljada puta ovu funkciju. Zatim stavi coef da bude globalna promenljiva (van funkcije) pa probaj ponovo. Ne bi bilo lose ni da pogledas asemblerski listing u oba slucaja da vidis koliku razliku moze da napravi jedna tako banalna stvar uradjena potpuno slucajno. Mozes da probas i da napravis veci niz (npr. stotinak elemenata) ako ne uocis odmah razliku u asemblerskom kodu. Ja nisam merio razliku u brzini, verovatno je manja od 50%, ali malo po malo pa se nakupi pogotovo kad programer nije svestan da to sto je napisao nije optimalno.

Ja pricam o low level optimizaciji na nivou SSE3 ili SSE2 instrukcija a ti o optimizaciji source'a a to su dvije razlicite stvari.Mislim da sam jasno naveo gore optimizaciju za poseban procesor !

Primjer koji si naveo je pocetnicka greska , nikad se konstantni array ne definise u tijelu jedne funkcije on se uvijek definise globalno jer ce u suprotnom svaki put pri ulasku u funkciju biti spremljen na stacku sto automatski znaci i nepotrebno izvrsavanje stack operacija.
I to sam gore u tekstu isto opisao kao namjerno zagusivanje brzine izvrsavanja aplikacije koje nece nijedan solidan programer napraviti.

P.S neoptimiran source ce raditi na bilo kome sistemu i procesoru sporije od optimizovanog.

Optimizacija Source bi bila :

Kod:

double coef[8] = {1.0, 0.915, 10.0/12.0, 9.0/12.0, 0.715, 8.0/12.0,5.0/8.0,1.0/2.0};
 
int CalcIt(double a, int b)
{
   return (int) ceil(a / coef[b]);
}

audiofreak · 10.03.2005

monteboy je napisao(la):
citiram gospodina Jim Allchin'a inache kod Microsoft'a odgovornog za operativne sisteme

Dakle, glavnog i odgovornog za sve probleme koje imamo sa Windows-om? :d

E vidis, ovaj tvoj post bi se mogao okarakterisati kao spam jer gospoda iz Microsoft-a samo kod odredjene grupe ljudi uziva kredibilitet (ja u tu grupu ocigledno ne spadam), a to sto Microsoft zbog AMD-a ne mora da optimizuje operativni sistem pomazuci tako AMD-u (i ostalima) da nam prodaju nov hardver koji nam ne bi ni trebao da je OS iole optimizovan je sramota.

monteboy je napisao(la):
Neznam koliko si upoznat sa profesionalnim izradom Software

Upoznat sam sa nekim od nacina na koji se to radi. Ljudi u firmi u kojoj sam radio su prvo pisali kod, pa unit testove, pa dokumentaciju. U drugoj firmi zadatak mi je bila optimizacija tudjeg koda sto je cesto zahtevalo ponovno pisanje svih kriticnih funkcija, a ponekad zesce prepravke koda koji ih poziva/koristi jer se od g....a ne moze napraviti pita.

Kad vec pominjes milion linija koda nadam se da ne racunas tu i komentare kojih cesto zna da bude i do 70% zato sto se ne postuje jedan od osnovnih principa, a to je "pisi kod koji je lako razumeti umesto kilometarskih komentara koji objasnjavaju kako lose napisan kod radi". Preporuka: ako vec nisi, procitaj kodni standard za Linux kernel.

I na kraju, kompajleri i developer alati jesu napredovali ali je situacija sa njima slicna kao i sa softverom za pravljenje muzike i za crtanje i obradu slike. Naime, svaki ****** moze danas da se "bavi muzikom" i da bude "DJ" ili da bude "fotograf" ili "artist" iako nema blage veze sa osnovama iz doticnih oblasti, a tako je nazalost i sa programiranjem.

monteboy · 10.03.2005

audiofreak je napisao(la):
Dakle, glavnog i odgovornog za sve probleme koje imamo sa Windows-om? :d

E vidis, ovaj tvoj post bi se mogao okarakterisati kao spam jer gospoda iz Microsoft-a samo kod odredjene grupe ljudi uziva kredibilitet (ja u tu grupu ocigledno ne spadam), a to sto Microsoft zbog AMD-a ne mora da optimizuje operativni sistem pomazuci tako AMD-u (i ostalima) da nam prodaju nov hardver koji nam ne bi ni trebao da je OS iole optimizovan je sramota.

Koliko se ja secam upravo Microsoft i Intel su imali dugogodisnju odlicnu monopolsku saradnju to sto je gospoda iz Micosofta konacno shvatila koja je bolja arhitektura to je druga stvar. Takodje nije Microsoft kriv sto je AMD prvi izbacio 64 bitni procesor za Desktop trziste i sto je uspjesan toliko sa njim a kao sto se da vidjeti i bice u buduce.

Upoznat sam sa nekim od nacina na koji se to radi. Ljudi u firmi u kojoj sam radio su prvo pisali kod, pa unit testove, pa dokumentaciju. U drugoj firmi zadatak mi je bila optimizacija tudjeg koda sto je cesto zahtevalo ponovno pisanje svih kriticnih funkcija, a ponekad zesce prepravke koda koji ih poziva/koristi jer se od g....a ne moze napraviti pita.

Kad vec pominjes milion linija koda nadam se da ne racunas tu i komentare kojih cesto zna da bude i do 70% zato sto se ne postuje jedan od osnovnih principa, a to je "pisi kod koji je lako razumeti umesto kilometarskih komentara koji objasnjavaju kako lose napisan kod radi". Preporuka: ako vec nisi, procitaj kodni standard za Linux kernel.

U Programerskom zargonu kilometarski source nazivamo -> "spageti source" , niko ga ne voli niti praktikuje , ja mislim da uopste nemas predstavu sto znaci milion code linija sa i bez komentara i odakle ti ideja da milion redova code'a znace automatski neoptimizovan code. Da li mozes sebe zamisliti da postoje sistemi koji su tako kompleksni i veliki tako da jedan pod sistem od kojih ima najmanje 10 ima obim jedne aplikacije evo recimo Photoshop'a

I na kraju, kompajleri i developer alati jesu napredovali ali je situacija sa njima slicna kao i sa softverom za pravljenje muzike i za crtanje i obradu slike. Naime, svaki ****** moze danas da se "bavi muzikom" i da bude "DJ" ili da bude "fotograf" ili "artist" iako nema blage veze sa osnovama iz doticnih oblasti, a tako je nazalost i sa programiranjem.

Ovo je banalan primjer , programera ima milion -> dobrih manje a veoma dobrih veoma malo a to vazi za sve u zivotu a individuelna sposobnost nema nikakve veze sa ovim o cemu ja sa tobom pricam.

illidan · 10.03.2005

monteboy je napisao(la):
Koliko se ja secam upravo Microsoft i Intel su imali dugogodisnju odlicnu monopolsku saradnju to sto je gospoda iz Micosofta konacno shvatila koja je bolja arhitektura to je druga stvar. Takodje nije Microsoft kriv sto je AMD prvi izbacio 64 bitni procesor za Desktop trziste i sto je uspjesan toliko sa njim a kao sto se da vidjeti i bice u buduce.

A sada i za mobilno trziste 🙂 http://www.tomshardware.com/hardnews/20050310_103652.html

mcekovic · 10.03.2005

Hoces primer?

Iole normalan kompajler bi to optimizovao sam.

mcekovic · 10.03.2005

Evo za mcekovica jedna zanimljiva studija o poboljsanju performansi procesora implementacijom dugackih pipeline-ova.

Dobra teorija, steta sto ne funkcionise u praksi 🙂

audiofreak · 10.03.2005

monteboy je napisao(la):
Ja pricam o low level optimizaciji na nivou SSE3 ili SSE2 instrukcija a ti o optimizaciji source'a a to su dvije razlicite stvari.Mislim da sam jasno naveo gore optimizaciju za poseban procesor !

AMAN, JEL CITAS TI STA JA PISEM UOPSTE?!?

ZASTO PRICAS O TOME?!? JA NISAM ZAHTEVAO LOW LEVEL OPTIMIZACIJU ZA ODREDJENI PROCESOR -- TI SI IZVRNUO MOJE RECI!

monteboy je napisao(la):
Primjer koji si naveo je pocetnicka greska

Tu gresku ce napraviti svako ko ne zna kako kompajler barata sa podacima.

monteboy je napisao(la):
to sto je gospoda iz Micosofta konacno shvatila koja je bolja arhitektura to je druga stvar.

Sa aspekta Microsoft-ovih programera AMD64 je i dalje x86 samo sa nataknutim 64-bitnim ekstenzijama. Intelov EM64T isto.

monteboy je napisao(la):
U Programerskom zargonu kilometarski source nazivamo -> "spageti source" , niko ga ne voli niti praktikuje

Spaghetti Code (1, 2) je termin za kod koji ima kompleksnu kontrolnu strukturu i/ili koristi gomilu goto komandi. Pre nego sto nastavis da me gadjas "strucnim" terminima proveri da li ih sam razumes na pravi nacin.

monteboy je napisao(la):
ja mislim da uopste nemas predstavu sto znaci milion code linija sa i bez komentara i odakle ti ideja da milion redova code'a znace automatski neoptimizovan code.

Odakle tebi ideja da ja imam ideju da milion redova znace automatski neoptimizovan program? Hajde citiraj mi gde sam ja to rekao! Opet izvrces sve sto kazem. Da li to radis namerno u nedostatku boljih argumenata ili sta?

mcekovic je napisao(la):
Iole normalan kompajler bi to optimizovao sam.

mcekovicu razocaravas me, cak i monteboy zna da to kompajler ne moze da optimizuje jer se lokalni niz (i promenljive) svaki put kreiraju (i vrednosti iznova inicijalizuju iako su konstantne) na steku kada se udje u funkciju.

mcekovic · 10.03.2005

mcekovicu razocaravas me, cak i monteboy zna da to kompajler ne moze da optimizuje jer se lokalni niz (i promenljive) svaki put kreiraju (i vrednosti iznova inicijalizuju iako su konstantne) na steku kada se udje u funkciju.

Zasto da ne moze, kompajler moze da ustanovi da je niz konstantan, kao i da su i sami elementi niza takodje konstantni (tj. da se u daljem toku programa ne menjaju) i da 'ladno prebaci ceo niz u konstantu i izbaci ga iz procedure/metoda, na isti nacin na koji to cini i programer. Kompajler moze da uradi sve sto ne menja konacni ishod programa.

monteboy · 10.03.2005

audiofreak je napisao(la):
AMAN, JEL CITAS TI STA JA PISEM UOPSTE?!?

ZASTO PRICAS O TOME?!? JA NISAM ZAHTEVAO LOW LEVEL OPTIMIZACIJU ZA ODREDJENI PROCESOR -- TI SI IZVRNUO MOJE RECI!

Sta da ti kazem stvarno ti se divim ?
Cijelo vrijeme evo od kada je poceo onaj thread uvezi superPI aplikacije pricas o neoptimiranim instrukcijama za Intel , predstavljas SSE2 i 3 set kao jako pojacanje sto u sustini i jeste postavljas nam milion postovo sa datasheet'ovima Intelove arhitekture i optimizacije code'a upravo na tom procesoru a sad od jedan put se pravis lud kao nisam ja zahtevao LOW LEVEL OPTIMIZACIJU.

Sve testove sto sam postavio sto su treci testirali dovodis u pitanje sa opravdanjem da nije code optimiran za Intel i da tu nesto nije u redu.

Shvati covece da sam pokusao na fini nacin da ti objasnim kako je stanje u realnom zivotu da se nema vremena ni para za detaljnu analizu i implementaciju Software resenja samo za pojedine procesore i optimiranje na istim.

Sta mislis da Adobe ili neka slicna kompanija izbaci samo Software za P4 sa SSE3 instrukcijama ?

Sta je sa korisnicima koji nemaju jedan P4 nego koriste Celeron ili P3 na 500 MHz zar ti korisnici nemaju pravo isto se sluziti proizvodima firme Adobe ?

P.S postoje kompajleri koji ce tvoj gore navedeni code itekako optimirati !

Druga stvar spageti code je vise slang nego strucan izraz za nepregledan i necist source dali su goto naredbe u pitanju ili ne nije bitno.
Svaki donekle solidan programer ce izbjegavati goto naredbu mada postoje situacije gdje se sa njom mogu neke stvari elegantno rijeshiti.

monteboy · 10.03.2005

mcekovic je napisao(la):
Zasto da ne moze, kompajler moze da ustanovi da je niz konstantan, kao i da su i sami elementi niza takodje konstantni (tj. da se u daljem toku programa ne menjaju) i da 'ladno prebaci ceo niz u konstantu i izbaci ga iz procedure/metoda, na isti nacin na koji to cini i programer. Kompajler moze da uradi sve sto ne menja konacni ishod programa.

Naravno da moze! , ipak taj nacin programiranje se treba izbjegavati ali
to nas drug audiofan nije svjestan jer on misli da njegova uloga optimizatora na low level nivou postaje svaki dan dragocenija iako svake 18 mjeseci izlazi nova procesorska arhitektura koja je cak i za 50% jaca od predhodne 😉

audiofreak · 11.03.2005

mcekovic je napisao(la):
Zasto da ne moze, kompajler moze da ustanovi da je niz konstantan, kao i da su i sami elementi niza takodje konstantni (tj. da se u daljem toku programa ne menjaju) i da 'ladno prebaci ceo niz u konstantu i izbaci ga iz procedure/metoda, na isti nacin na koji to cini i programer. Kompajler moze da uradi sve sto ne menja konacni ishod programa.

monteboy je napisao(la):

Naravno da moze!

Kliknite za proširenje...

Kompajleri se pisu prema nekom standardu. Taj standard kaze da lokalne promenljive moraju biti na lokalnom stack-u funkcije. Da ste obojca pogledali generisani asemblerski kod videli bi da je kompajler napravio niz konstanti u data sekciji, ali da je inicijalizacija lokalnog niza na stacku ostala jer tako mora da bude za slucaj da funkcija pozove drugu funkciju sa nekim od elemenata niza kao parametrom. Dakle, ne moze, ocigledno nemate pojma obojca, a ja gubim silno vreme pokusavajuci da vam objasnim neke osnove bez kojih se sve to ne moze ni razumeti ispravno.

monteboy je napisao(la):
Sta da ti kazem stvarno ti se divim ?
...
a sad od jedan put se pravis lud kao nisam ja zahtevao LOW LEVEL OPTIMIZACIJU.

Ja u ovom threadu nisam ni spomenuo low-level optimizaciju pa nisi trebao ni ti. Tamo gde sam je spominjao bilo je u potpuno drugom kontekstu koji nema smisla uvoditi ovde jer ja sam ovde o optimizaciji pricao uopsteno.

Cak i u raspravi o SuperPI-ju koju pominjes ja sam tvrdio samo da SuperPI nije uopste optimizovan, a ne da nije optimizovan za Intel.

mcekovic je napisao(la):
Sve testove sto sam postavio sto su treci testirali dovodis u pitanje sa opravdanjem da nije code optimiran za Intel i da tu nesto nije u redu.

Prvo nisam sve testove doveo u pitanje, nego samo one gde je Intel u 64-bitnom modu sporiji nego u 32-bitnom sto nije logicno.

Drugo, naravno da nesto nije u redu sa testom kada u 32-bitnom modu Intel vodi 12% u odnosu na AMD, a u 64-bitnom on ima usporenje, a AMD ubrzanje od 25%.

mcekovic je napisao(la):
Shvati covece da sam pokusao na fini nacin da ti objasnim kako je stanje u realnom zivotu da se nema vremena ni para za detaljnu analizu i implementaciju Software resenja samo za pojedine procesore i optimiranje na istim.

Optimizacija treba da bude deo razvojnog procesa softvera, a ne naknadna faza koja extra kosta, i oduzima nepotrebno vreme. I opet ti ponavljam, ne trazim posebne optimizacije ni za jedan procesor nego maksimalan zajednicki imenitelj za trenutno aktuelne procesore. Ako je to SSE2, onda neka bude SSE2, ako je to SSE onda neka bude SSE, bolje ista nego (kao sto je u vecini slucajeva) nista.

Ti namerno preskaces cinjenicu da npr. Lame encoder ima 3DNow optimizacije za FFT. Intel nema 3DNow!, ali zato AMD ima SSE i SSE2. Zasto se onda ne koristi npr. Gogo no-coda koji je baziran na Lame-u i ima SSE optimizacije, nego Lame za test kojim se redovno na netu i u svim testovima u casopisima dokazuje da je AMD brzi?

monteboy je napisao(la):
Sta mislis da Adobe ili neka slicna kompanija izbaci samo Software za P4 sa SSE3 instrukcijama ?

A bilo bi OK da je Adobe izbacio 64-bitnu verziju a da Intel nema podrsku za to? Bas licemerno. Uzgred, nema tu sta da se misli. Adobe ima optimizovan core za Photoshop i to u tri verzije:

FastCore.8BX
MMXCore.8BX
MultiProcessor Support.8BX

monteboy je napisao(la):
Sta je sa korisnicima koji nemaju jedan P4 nego koriste Celeron ili P3 na 500 MHz zar ti korisnici nemaju pravo isto se sluziti proizvodima firme Adobe ?

O cemu ti pricas covece? O socijalnoj pravdi? Pa Photoshop CS na primer kosta oko 1000 EUR!!! Ko je tolika budala da pljune tolike pare i da ga koristi na masini iz prosloga veka?!? Uostalon, neka oni koriste Photoshop 6, 5 ili 4 koji su nastli otprilike kad i ti procesori, ne zanima me. Necemo valjda svi sad zbog njih koji jadni nemaju para za nove masine (a imaju za Photoshop?) da koristimo spor softver?

monteboy je napisao(la):
P.S postoje kompajleri koji ce tvoj gore navedeni code itekako optimirati !

Ja sam proverio sa MSVC Toolkit 2003, i sa ICC 8.1 i nijedan ga nije optimizovao iz gore navedenih razloga. Slobodno reci koji su to drugi kompajleri koji bi to uradili.

monteboy je napisao(la):
Svaki donekle solidan programer ce izbjegavati goto naredbu mada postoje situacije gdje se sa njom mogu neke stvari elegantno rijeshiti.

Iz linux kernel kodnog stila:

Chapter 6: Centralized exiting of functions

Albeit deprecated by some people, the equivalent of the goto statement is used frequently by compilers in form of the unconditional jump instruction.

The goto statement comes in handy when a function exits from multiple locations and some common work such as cleanup has to be done.

The rationale is:

- unconditional statements are easier to understand and follow
- nesting is reduced
- errors by not updating individual exit points when making
modifications are prevented
- saves the compiler work to optimize redundant code away 😉

monteboy je napisao(la):
to nas drug audiofan nije svjestan jer on misli da njegova uloga optimizatora na low level nivou postaje svaki dan dragocenija iako svake 18 mjeseci izlazi nova procesorska arhitektura koja je cak i za 50% jaca od predhodne

Bas pazljivo citas, vec drugi put mi pogresno pises ime :d

Ja sam odavno prevazisao low-level optimizaciju i radim je samo kada je apsolutno neophodna (npr. kada se trazi skoro real-time obrada). Umesto nje naucio sam da pisem kod koji kompajler lakse optimizuje i koji ne ide procesoru uz dlaku.

To sto pominjes "svakih 18 meseci nova arhitektura" -- nema tu nista novo. Sve je to stari i ne bas tako dobri x86. Mene vise zanima kako iskoristiti snagu grafickih procesora jer se oni ipak mnogo brze razvijaju nego obicni procesori. Primera radi NV40 (6800 Ultra) postize i do 40 GFLOPS-a dok najjaci desktop procesori iz oba tabora jedva dostizu 5-6 GFLOPS-a.

mcekovic · 12.03.2005

Kompajleri se pisu prema nekom standardu. Taj standard kaze da lokalne promenljive moraju biti na lokalnom stack-u funkcije.

Svasta. Ako Intel kopjaler ovo ne moze da optimizuje, ne mora da znaci da ne mogu i drugi.
I jos jedno svasta. Zasto bi se lokalne promenljive nalazile na loklalnom stack-u. Mogu da se nadju i na heap-u, a mogu i da budu u registrima procesora, ko zna gde jos sve, sve je to dozvoljeno, a na kompajleru je da izabere sta smatra da je najbolje.

Da ste obojca pogledali generisani asemblerski kod videli bi da je kompajler napravio niz konstanti u data sekciji, ali da je inicijalizacija lokalnog niza na stacku ostala jer tako mora da bude za slucaj da funkcija pozove drugu funkciju sa nekim od elemenata niza kao parametrom.

U bre, ima raznih kompajlera, ako jedan radi na jedan nacin ne mora da znaci da ce i drugi. Lokalni niz ne mora da se inicijalizuje na stacku, npr. u Javi se svi objekti (pa i nizovi samim tim) inicijalizuju na heap-u.

Dakle, ne moze, ocigledno nemate pojma obojca, a ja gubim silno vreme pokusavajuci da vam objasnim neke osnove bez kojih se sve to ne moze ni razumeti ispravno.

Jos jednom, sve optimizacije su dozvoljene. Ako programer moze da napravi neku optimizaciju a da ne promeni semantiku programa, to moze i kompajler, samo je pitanje da li je dovoljno 'pametan'. Umesto sto mnogo iskusnijima kazes da nemaju pojma, bolje bi bilo da stvari sagledavas malo sire nego sto to cinis sada.

mcekovic · 12.03.2005

Btw, evo bas sam danas kompajlirao tekuci projekat i pratece biblioteke na poslu i kuci. Na poslu imam P4 Northwood [email protected], a kuci A64 S754 3000+ na defaultu. Razlika je drasticna, A64 tuce u Java kompajliranju ovog P4 vise od duplo, ako ne i vise !!!

audiofreak · 12.03.2005

mcekovic je napisao(la):
I jos jedno svasta. Zasto bi se lokalne promenljive nalazile na loklalnom stack-u. Mogu da se nadju i na heap-u, a mogu i da budu u registrima procesora, ko zna gde jos sve, sve je to dozvoljeno, a na kompajleru je da izabere sta smatra da je najbolje.

Application Binary Interface definise nacin prenosa parametara izmedju funkcija. Moguce je preko registara (fastcall) i preko stack-a (sve ostale calling konvencije). Standard je neophodan jer se neke funkcije pisu rucno u asembleru. Ako hoces da napises takvu funkciju (cistu asm __declspec(naked)) onda moras znati gde ti je sta na stacku ili u registrima -- zbog toga postoji ABI. Kod C-a to tako funkcionise. Dakle, nije dozvoljeno da optimizacija generise kod koji nije u skladu sa ABI-jem,

MaxXx · 12.03.2005

mcekovic je napisao(la):
Btw, evo bas sam danas kompajlirao tekuci projekat i pratece biblioteke na poslu i kuci. Na poslu imam P4 Northwood [email protected], a kuci A64 S754 3000+ na defaultu. Razlika je drasticna, A64 tuce u Java kompajliranju ovog P4 vise od duplo, ako ne i vise !!!

E tako neshto dajte, manite te price koliko je kome dugachak .....pipeline 🙂 i slicno. Ovde ste napisali 5 strana, meni je priznajem na prve tri bilo zanimljivo iako nisam neki poznavalac arhitekture procesora i pola nisam ni skapirao, a ovo posle sve smara. Dajte konkretne testove, ono sto prosecnom korisniku treba, znaci igre, neko renderovanje, kompresija video materijala,...

pozdrav

audiofreak · 13.03.2005

MaxXx je napisao(la):
E tako neshto dajte, manite te price koliko je kome dugachak .....pipeline 🙂 i slicno. Ovde ste napisali 5 strana, meni je priznajem na prve tri bilo zanimljivo iako nisam neki poznavalac arhitekture procesora i pola nisam ni skapirao, a ovo posle sve smara. Dajte konkretne testove, ono sto prosecnom korisniku treba, znaci igre, neko renderovanje, kompresija video materijala,...

pozdrav

Bez uvrede, ali testove koje zelis da vidis valjda mozes i sam da nadjes na netu? Mi smo ovde diskutovali o nekim drugim stvarima i malko nas je ponelo ali ako se tebi ne cita, niko te ne tera, a ako te smara to opet nije nas problem nego tvoj -- potrazi za sebe adekvatan sadrzaj umesto sto nam se mesas u diskusiju i teras nas da promenimo temu. Da si se javio na pocetku thread-a pa i da te razumem. Mada i ovo sve nije bas totalno off-topic jer od optimizacije softvera u velikoj meri zavisi dalji razvoj hardvera i obratno.

MaxXx · 13.03.2005

Ja mislim da je tread i poceo nekim testom amd vs intel, a ne arhitektura procesora jednog protiv drugog. Tako da ste vi otisli u off. Na ovo nisam samo ja skrenuo paznju, tako da nema razloga da se na mene brecash. Ne zanimaju me lazirani testovi na internetu, video sam ih nekolicinu, nego lepo uzmite vi koji se prepirete i uporedite to u praksi, kakve veze ima sto jesoftware za jedan proc. optimizovan, a drugi nije. Valjda mozete tu prepreku prevazici tako sto uzmete u obzir veci broj "testova".

Ma ustvari jeste u pravu si, necu da ometam diskusiju, ali skrecem paznju, od trece strane se vrtite non stop u krug.

pozdrav

audiofreak · 14.03.2005

MaxXx je napisao(la):
Ja mislim da je tread i poceo nekim testom amd vs intel, a ne arhitektura procesora jednog protiv drugog. Tako da ste vi otisli u off. Na ovo nisam samo ja skrenuo paznju, tako da nema razloga da se na mene brecash. Ne zanimaju me lazirani testovi na internetu, video sam ih nekolicinu, nego lepo uzmite vi koji se prepirete i uporedite to u praksi, kakve veze ima sto jesoftware za jedan proc. optimizovan, a drugi nije. Valjda mozete tu prepreku prevazici tako sto uzmete u obzir veci broj "testova".

Ma ustvari jeste u pravu si, necu da ometam diskusiju, ali skrecem paznju, od trece strane se vrtite non stop u krug.

pozdrav

Ne brecam se na tebe. Odakle ti to? Samo sam ti skrenuo paznju na to da je diskusija opravdana, ne trazim od tebe da je razumes ili podrzis.

Kao sto rekoh ova diskusija nije off-topic jer od optimizacije softvera (a to je u stvari njegov pravi razvoj ma sta neki mislili) u velikoj meri zavisi dalji razvoj hardvera i obratno.

Veze ima utoliko sto su arhitekture razlicite. Ja se ubih ovde pokusavajuci da dokazem da nijedna nije apriori losa, vec da svaka ima domen primene koji joj bolje lezi, a u svemu drugom sto joj ne lezi potpuno je upotrebljiva.

Malo je nerealno ocekivati da se sad skupimo sa raznih strana i obavimo neke nase nezavisne testove. Da ja vec imam EM64T procesor ja bih ucestvovao u tome drage volje, ali nazalost jos se ne prodaju kod nas, a i ja nisam bas pri parama trenutno.

Sto se tice testova, ako koristis npr. Photoshop 4 za testiranje moci ces da proveris samo kako neki novi procesor izvrsava programe pisane za Pentium 1, a nikako njegove maksimalne performanse jer za to je potreban softver pisan ako ne za njega onda makar imajuci ga u vidu.

monteboy · 14.03.2005

audiofreak je napisao(la):
Application Binary Interface definise nacin prenosa parametara izmedju funkcija. Moguce je preko registara (fastcall) i preko stack-a (sve ostale calling konvencije). Standard je neophodan jer se neke funkcije pisu rucno u asembleru. Ako hoces da napises takvu funkciju (cistu asm __declspec(naked)) onda moras znati gde ti je sta na stacku ili u registrima -- zbog toga postoji ABI. Kod C-a to tako funkcionise. Dakle, nije dozvoljeno da optimizacija generise kod koji nije u skladu sa ABI-jem,

audiofreak ne hvataj se strucnih izraza kad neznas sto znace !
Mozda bi bilo bolje da se drzis toga sto stvarno znas i sto si i sam probao prije nego li pocnes kopirati definicije sa neta.Ovako ispadas samo smijesan !

Mi smo konkretno da li odgovor na primjer dijela code'a koji si postavio u kome nije bilo zvanja bilo koje eksterne funkcije a pogotovo ne neke eksterne funkcije u nekom drugom Modulu ili cak dll'u sto znaci da ako je Compajler inovativan on ce tvoj gore navedeni code optimirati stim sto ce niz rezervisati globalno.

Optimizacija Compajler'a nema nikakve veze sa calling konvencijama i standardima jednog jezika. Sve dok se semantika ne remeti dozvoljena je svaka optimizacija. Normalno za eksportovanje funkcije postoje konvencije na koje se strogo moraju pridrzavati svi kompajleri ali to u ovom gore navedenom primjeru nije slucaj.

Sto se tice moga citanja tvojih postova sledece :Mislim da si me u jednom ranijem postu prozvao amdfan tako da uzimam sebe za pravo tebe da nazovem audiofan! sto bi znacilo da tvoje postove odlicno znam citati mada su vecinom prepuni bukvalnog shvatanja i nelogicnosti.

Tako si i kod izjave da je za Adobe Software potrebna savremena masina isto po milionsti put sve bukvalno shvatio.Ako sam gore pomenuo Adobe kao firmu koja proizvodi Software onda sam mogao pomenuti i bilo koju drugo zato mani se tog bukvalnog shvatanja svega i svacega i prilozi ovom threadu nesto konstruktivno.

gx-x · 14.03.2005

audiofreak je napisao(la):
Ne brecam se na tebe. Odakle ti to? Samo sam ti skrenuo paznju na to da je diskusija opravdana, ne trazim od tebe da je razumes ili podrzis.

Kao sto rekoh ova diskusija nije off-topic jer od optimizacije softvera (a to je u stvari njegov pravi razvoj ma sta neki mislili) u velikoj meri zavisi dalji razvoj hardvera i obratno.

Veze ima utoliko sto su arhitekture razlicite. Ja se ubih ovde pokusavajuci da dokazem da nijedna nije apriori losa, vec da svaka ima domen primene koji joj bolje lezi, a u svemu drugom sto joj ne lezi potpuno je upotrebljiva.

Malo je nerealno ocekivati da se sad skupimo sa raznih strana i obavimo neke nase nezavisne testove. Da ja vec imam EM64T procesor ja bih ucestvovao u tome drage volje, ali nazalost jos se ne prodaju kod nas, a i ja nisam bas pri parama trenutno.

Sto se tice testova, ako koristis npr. Photoshop 4 za testiranje moci ces da proveris samo kako neki novi procesor izvrsava programe pisane za Pentium 1, a nikako njegove maksimalne performanse jer za to je potreban softver pisan ako ne za njega onda makar imajuci ga u vidu.

Bez uvrede ali svi postovi u kojima se vas troje medjusobno "obrazujete" su vezani za 32-bit arhitekturu i stvarno ne vidim kakve to ima veze sa : Odnos 64 bitnih sistema AMD vs Intel . Da ste pricali o programiranju 64bit aplikacija i instrukcija vezanih za njih pa u redu, ali niste, pricate o kompajlerima koji su svi do jednog 32bitni (od onih koje pominjete).

Zakljucak: jeste off-topic 🙂

audiofreak · 14.03.2005

@monteboy:
Ako vec tvrdis da kompajler sme to da optimizuje na taj nacin hoces li molim te vec jednom reci koji je to kompajler umesto sto mlatis praznu slamu sa mnom ovde???

@gx-x:
Kako si ti sada dosao do tog zakljucka? Za 64-bitno ne treba optimizacija sta li? Ili mislis da NetBurst iskljucivo 32-bitna arhitektura? Ili nismo dovoljno pominjali rec AMD64?

monteboy · 15.03.2005

audiofreak , ucini nesto korisno izkompajliraj ovaj source i objavi rezultate interesuje me uporedjenje :

Kod:

#include "stdafx.h"
#include <math.h>
#include <sys/timeb.h>
#include <stdlib.h>
#include <float.h>

const long _max_loop_count=1000000; 
const long _max_data_count=100; 

enum CalcOP
{
	CalcOP_PowLogSinCos = 0
};

double* data1=NULL;
double* data2=NULL;
double* res=NULL;

unsigned int fl_exception_mask;

_timeb t1,t2;
double f1,f2;
double d1,d2;

///////////////////////////////////////////////////////////////////////////////////////////////
/**/
/*********************************************************************************************/      
/*** initializiranje slucajnih double vrijednosti , count oznacava velicinu array'a    
/**/ void InitRandomData(double* fdata,const long count);
/*********************************************************************************************/      
/*** Pokretanje petlje za izracunavanje odgovarajuce operacije 
/**/ void RunLoop(enum CalcOP nOP);
/*********************************************************************************************/      
/**/ void Calc(double* res,double* data1,double* data2,enum CalcOP,const long count);
/*********************************************************************************************/      
/**/ void EnableSSE2(bool bState);
/**/
///////////////////////////////////////////////////////////////////////////////////////////////

int _tmain(int argc, _TCHAR* argv[])
{
	data1   = new double[_max_data_count];
	data2   = new double[_max_data_count];
	res		= new double[_max_data_count];

	fl_exception_mask = _control87(0,0);

	//initializiraj oba Array'a sa slucajnim double vrijednostima
	InitRandomData(data1,_max_data_count);
	InitRandomData(data2,_max_data_count);

	// aktiviraj SSE2 podrsku u Common Runtime Math funkcijama
	EnableSSE2(true);

	printf("\n\nSSE2 podrska aktivirana,stisni taster za pocetak");
	getchar();

	// odradi loop sa _max_data_count operacija sa tekucim zarezom i ukljucenim SSE2
	RunLoop(CalcOP_PowLogSinCos);
	
	d1 = f2-f1;
    
	// deaktiviraj SSE2 podrsku u Common Runtime Math funkcijama
    EnableSSE2(false);

	printf("\n\nSSE2 podrska deaktivirana,stisni taster za pocetak");
	getchar();

	// odradi loop sa _max_data_count operacija sa tekucim zarezom i izgasenim SSE2
	RunLoop(CalcOP_PowLogSinCos);
	
	d2 = f2-f1;

	double rf = (d2 /(d1/(double)100)) - (double)100;
	printf("\n\nrazlika : %.2f %%\n",rf);
	
	getchar();

	// ocisti sve sa heap'a
	delete[] data1;   
	delete[] data2;   
	delete[] res;
    
	return 0;
}

void RunLoop(enum CalcOP nOP)
{	
	_ftime(&t1);
	
	for(long l=0;l<_max_loop_count;l++)
		Calc(res,data1,data2,nOP,_max_data_count);
    
	_ftime(&t2);

	f1 = (double)t1.time+(double)(t1.millitm / (double)1000);
	f2 = (double)t2.time+(double)(t2.millitm / (double)1000);

	printf("izvrsno vrijeme : %.3f s",f2 - f1);
}

// initializiraj podatke sa slucajnim double vrijednostima
void InitRandomData(double* fdata,const long count)
{
	for(long i=0;i<count;i++)
	{
		_timeb t;
		_ftime(&t);
		srand( t.millitm );

        fdata[i] = 1/(1 + rand());
	}
}

// izvrsi odgovarajucu operaciju sa operantima iz data1 i data2 i spremi rezultat u res
void Calc(double* res,double* data1,double* data2,enum CalcOP nOP,const long count)
{
	static long lCounter=0;

	for(long i=0;i<count;i++,lCounter++)
	{
		// ispisi tacku nakon svake 10.000.000'ste operacije
		if(!(lCounter % 10000000))
			printf(".");

		switch(nOP)
		{
			case CalcOP_PowLogSinCos:
				res[i] = pow(log(sin(data1[i])/sin(data2[i])) -  log(cos(data1[i])*cos(data2[i])),2); 
				break;
		}	
	}
}

void EnableSSE2(bool bState)
{
	if(bState)
	{
		_control87(_EM_INVALID | _EM_DENORMAL | _EM_ZERODIVIDE | _EM_OVERFLOW | _EM_UNDERFLOW | _EM_INEXACT ,_MCW_EM);
		_set_SSE2_enable(true);
	}
	else
	{
		_set_SSE2_enable(false);
		_control87(fl_exception_mask,_MCW_EM);
	}
}

// coded by Monteboy 2005

audiofreak · 15.03.2005

monteboy je napisao(la):
audiofreak , ucini nesto korisno izkompajliraj ovaj source i objavi rezultate interesuje me uporedjenje

Vazi. Reci cime hoces da kompajliram, kao i koje switch-eve da koristim za kompajliranje?

Inace, iz MSDN-a:

The following functions have SSE2 implementations that can be enabled with _set_SSE2_enable:

atan
ceil
exp
floor
log
log10
modf
pow

Dakle, sin i cos nisu na spisku, a koristio si ih? Zato je razlika u brzini mala (2.77%) jer sin i cos ogranicavaju throughput.

E sad, lepo probaj ovo sa Intel C/C++ kompajlerom pa mi reci razliku:

Kod:

#include <stdio.h>
#include <math.h>
#include <sys/timeb.h>
#include <stdlib.h>
#include <float.h>

const long _max_loop_count=1000000; 

const long _max_data_count=100; 

enum CalcOP
{
	CalcOP_PowLogSinCos = 0
};

double* data1=NULL;
double* data2=NULL;
double* res=NULL;

unsigned int fl_exception_mask;

_timeb t1,t2;
double f1,f2;
double d1,d2;

bool sse2;

void Calc_FPU(double* res,double* data1,double* data2,enum CalcOP nOP,const long count);
void Calc_SSE2(double* res,double* data1,double* data2,enum CalcOP nOP,const long count);
void InitRandomData(double* fdata,const long count);
void RunLoop(enum CalcOP nOP);

int main(int argc, char* argv[])
{
	data1   = new double[_max_data_count];
	data2   = new double[_max_data_count];
	res	= new double[_max_data_count];

	fl_exception_mask = _control87(0,0);

	//initializiraj oba Array'a sa slucajnim double vrijednostima
	InitRandomData(data1,_max_data_count);
	InitRandomData(data2,_max_data_count);

	// aktiviraj SSE2 podrsku u Common Runtime Math funkcijama
	sse2 = true;

	printf("\n\nSSE2 podrska aktivirana,stisni taster za pocetak");
	getchar();

	// odradi loop sa _max_data_count operacija sa tekucim zarezom i ukljucenim SSE2
	RunLoop(CalcOP_PowLogSinCos);
	
	d1 = f2-f1;
    
	// deaktiviraj SSE2 podrsku u Common Runtime Math funkcijama
	sse2 = false;

	printf("\n\nSSE2 podrska deaktivirana,stisni taster za pocetak");
	getchar();

	// odradi loop sa _max_data_count operacija sa tekucim zarezom i izgasenim SSE2
	RunLoop(CalcOP_PowLogSinCos);
	
	d2 = f2-f1;

	double rf = (d2 /(d1/(double)100)) - (double)100;
	printf("\n\nrazlika : %.2f %%\n",rf);
	
	getchar();

	// ocisti sve sa heap'a
	delete[] data1;   
	delete[] data2;   
	delete[] res;
    
	return 0;
}

void RunLoop(enum CalcOP nOP)
{	
	_ftime(&t1);
	
	if (sse2 == true) {
		for(long l=0;l<_max_loop_count;l++)
			Calc_SSE2(res,data1,data2,nOP,_max_data_count);
	} else {
		for(long l=0;l<_max_loop_count;l++)
			Calc_FPU(res,data1,data2,nOP,_max_data_count);
	}
    
	_ftime(&t2);

	f1 = (double)t1.time+(double)(t1.millitm / (double)1000);
	f2 = (double)t2.time+(double)(t2.millitm / (double)1000);

	printf("izvrsno vrijeme : %.3f s",f2 - f1);
}

// initializiraj podatke sa slucajnim double vrijednostima
void InitRandomData(double* fdata,const long count)
{
	for(long i=0;i<count;i++)
	{
		_timeb t;
		_ftime(&t);
		srand( t.millitm );

        fdata[i] = 1/(1 + rand());
	}
}

// izvrsi odgovarajucu operaciju sa operantima iz data1 i data2 i spremi rezultat u res
#pragma optimize("", off)

// mrzelo me da odvajam u drugi fajl i da podesavam posebne optimizacije
// za njega, rezultat je i sa iskljucenom optimizacijom brzi u odnosu na MSVC

void Calc_FPU(double* res,double* data1,double* data2,enum CalcOP nOP,const long count)
{
	static long lCounter=0;

	for(long i=0;i<count;i++,lCounter++)
	{
		// ispisi tacku nakon svake 10.000.000'ste operacije
		if(!(lCounter % 10000000))
			printf(".");

		switch(nOP)
		{
			case CalcOP_PowLogSinCos:
				res[i] = pow(log(sin(data1[i])/sin(data2[i])) -  log(cos(data1[i])*cos(data2[i])),2); 
				break;
		}	
	}
}
#pragma optimize("", on)

void Calc_SSE2(double* res,double* data1,double* data2,enum CalcOP nOP,const long count)
{
	static long lCounter=0;

	for(long i=0;i<count;i++,lCounter++)
	{
		// ispisi tacku nakon svake 10.000.000'ste operacije
		if(!(lCounter % 10000000))
			printf(".");

		switch(nOP)
		{
			case CalcOP_PowLogSinCos:
				res[i] = pow(log(sin(data1[i])/sin(data2[i])) -  log(cos(data1[i])*cos(data2[i])),2); 
				break;
		}	
	}
}

Kod mene daje sledeci rezultat:

SSE2 podrska aktivirana,stisni taster za pocetak
..........izvrsno vrijeme : 9.391 s

SSE2 podrska deaktivirana,stisni taster za pocetak
..........izvrsno vrijeme : 179.953 s

razlika : 1816.23 %

Ko hoce da proba, u prilogu je .exe preveden sa ICC 8.1 -- moja verzija monteboy source-a. Treba vam SSE2 (prevedeno sa QxN).

monteboy · 16.03.2005

audiofreak je napisao(la):
Vazi. Reci cime hoces da kompajliram, kao i koje switch-eve da koristim za kompajliranje?

Kao prvo nisi trebao code kompilirati samo za Intel arhitekturu jer ti kompilat ne radi na AMD 64 procesorima iako podrzavaju SSE2 kao drugo nisi trebao odvajati kompilat kod SSE2 i bez, jer mene je prvobitno bio cilj da ti na jednom jednostavnom primjeru dokazem koliko uticaja ima SSE2 (patch) na rezultat i opravdam moju ondasnju odluku da patchovane rezultate u SuperPI ne objavljujem.

Kao drugo dovoljno je da VSToolKit'om dodas opvije /Ot /G7 /arch:SSE2

Imaces priblizne vrijednosti kao sa Intel kompilatom samo sa velikom cinjenicom da ce raditi i na AMD 64 sistemima. 😀

Kao trece konstantu za Loop si skratio za jednu 0 (namjerno ili nenamjerno , neznam ?)

Sad sam na poslu! , a veceras cu ti postaviti screenshot sa rezultatima AMD 64'tvorke kao i verziju koja radi i na tvom sistemu bez problema.

Inace, iz MSDN-a:

The following functions have SSE2 implementations that can be enabled with _set_SSE2_enable:

atan
ceil
exp
floor
log
log10
modf
pow

Dakle, sin i cos nisu na spisku, a koristio si ih? Zato je razlika u brzini mala (2.77%) jer sin i cos ogranicavaju throughput.

Tacno , samo gore navedene funkcije imaju SSE2 implementaciju ipak kompleksitet formule odnosno vise poziva gore navedenih funkcija daju vecu razliku u odnosu na FPU implementacije.

audiofreak · 16.03.2005

monteboy je napisao(la):
Kao prvo nisi trebao code kompilirati samo za Intel arhitekturu jer ti kompilat ne radi na AMD 64 procesorima iako podrzavaju SSE2 kao drugo nisi trebao odvajati kompilat kod SSE2 i bez, jer mene je prvobitno bio cilj da ti na jednom jednostavnom primjeru dokazem koliko uticaja ima SSE2 (patch) na rezultat i opravdam moju ondasnju odluku da patchovane rezultate u SuperPI ne objavljujem.

monteboy je napisao(la):
Tacno , samo gore navedene funkcije imaju SSE2 implementaciju ipak kompleksitet formule odnosno vise poziva gore navedenih funkcija daju vecu razliku u odnosu na FPU implementacije.

Vidi, ti imas sledece pozive koji mogu da koriste SSE2:

1x pow
2x log

i ove koji ne mogu:

2x sin (160-200 taktova)
2x cos (180-280 taktova)

Tako da ti primer nije bas dobar pogotovo kada se uzme u obzir par gresaka koje si napravio u testiranju.

monteboy je napisao(la):
Kao drugo dovoljno je da VSToolKit'om dodas opvije /Ot /G7 /arch:SSE2

Ovo su rezultati koje dobijam sa tvojim opcijama i sa MSVC bez izmena u kodu:

SSE2 podrska aktivirana,stisni taster za pocetak
..........izvrsno vrijeme : 148.172 s

SSE2 podrska deaktivirana,stisni taster za pocetak
..........izvrsno vrijeme : 152.750 s

razlika : 3.09 %

Zasto je to tako? Pogledaj kod generisan sa MSVC i tvojim opcijama:

Kod:

loc_4010AE:
		cmp	[ebp+arg_C], 0
		jnz	short loc_401113
		fld	qword ptr [edi+esi]
		movsd	xmm1, ds:dbl_4090E8
		fsin
		mov	eax, 2
		fld	qword ptr [esi]
		fsin
		fdivp	st(1), st
		fldln2
		fxch	st(1)
		fyl2x
		fld	qword ptr [edi+esi]
		fcos
		fld	qword ptr [esi]
		fcos
		fmulp	st(1), st
		fldln2
		fxch	st(1)
		fyl2x
		fsubp	st(1), st
		fstp	[esp+18h+var_8]

To se izvrsava bez obzira da li ti ukljucis ili iskljucis SSE2 podrsku. A evo i zasto:

MSDN je napisao(la):
The floating-point functions listed below do not have true intrinsic forms. If you use the Generate Intrinsic Functions option, the listed functions are replaced with versions that pass arguments directly to the floating-point chip rather than pushing them onto the program stack:

acos
asin
cosh
fmod
pow
sinh
tanh

The floating-point functions listed below have true intrinsic forms when you specify both /Oi and /Og (or any option that includes /Og: /Ox, /O1, and /O2):

atan
atan2
cos
exp
log
log10
sin
sqrt
tan

Ako hoces da probas funkcije sa i bez SSE2 podrske, moras prvo da zabranis kompajleru da generise intrinsic verziju doticnih funkcija. To ces najlakse uraditi ako pre Calc() funkcije ubacis:

Kod:

#pragma function(pow,log,sin,cos)

Sa tako prevedenim kodom preko MSVC ja dobijam sledece rezultate:

SSE2 podrska aktivirana,stisni taster za pocetak
..........izvrsno vrijeme : 132.781 s

SSE2 podrska deaktivirana,stisni taster za pocetak
..........izvrsno vrijeme : 139.891 s

razlika : 5.35 %

Razlika je i dalje mala, ali je program brzi za 9-12% u odnosu na pocetnu verziju. Ako pogledas kod, vidis da izgleda malo drugacije:

Kod:

loc_4010AE:
		cmp	[ebp+arg_C], 0
		jnz	loc_40114A
		fld	qword ptr [edi+esi]
		sub	esp, 8
		fstp	[esp+28h+var_28]
		call	sub_4019D4		; <- sin()
		fstp	[esp+28h+var_10]
		fld	qword ptr [esi]
		fstp	[esp+28h+var_28]
		call	sub_4019D4		; <- sin()
		fdivr	[esp+28h+var_10]
		fstp	[esp+28h+var_28]
		call	sub_401870		; <- log()
		fstp	[esp+28h+var_8]
		fld	qword ptr [esi]
		fstp	[esp+28h+var_28]
		call	sub_4017D4		; <- cos()
		fstp	[esp+28h+var_10]
		fld	qword ptr [edi+esi]
		fstp	[esp+28h+var_28]
		call	sub_4017D4		; <- cos()
		fmul	[esp+28h+var_10]
		fstp	[esp+28h+var_28]
		call	sub_401870		; <- log()
		fsubr	[esp+28h+var_8]
		movsd	xmm1, ds:qword_40C0F0
		add	esp, 8
		mov	eax, 2
		fstp	[esp+20h+var_8]

Dakle samo dva poziva log() funkciji koriste SSE2 kod i zato je razlika i dalje mala jer sin() i cos() (i deljenje sa fdivr) imaju relativno konstantno vreme izvrsavanja koje se mora sacekati pre nego sto se radi log() nad rezultatima.

monteboy je napisao(la):
Imaces priblizne vrijednosti kao sa Intel kompilatom samo sa velikom cinjenicom da ce raditi i na AMD 64 sistemima. 😀

Prvo, vrednosti nisu ni priblizne:

SSE2 podrska aktivirana,stisni taster za pocetak
..........izvrsno vrijeme : 9.312 s

SSE2 podrska deaktivirana,stisni taster za pocetak
..........izvrsno vrijeme : 9.359 s

razlika : 0.50 %

Razlika skoro da ne postoji jer ukljucivanje/iskljucivanje SSE2 ne deluje na kod generisan Intelovim kompajlerom. Ali zato pogledaj vreme izvrsavanja bez ikakvih izmena tvog koda.

Drugo, postoji nacin da program napravljen ICC-om nateras da radi na AMD64. Potrazi malo na internetu.

monteboy je napisao(la):
Kao trece konstantu za Loop si skratio za jednu 0 (namjerno ili nenamjerno , neznam ?)

A da prebrojis nule ponovo? Koliko ja vidim kod oba stoji 6 nula. E sad, mozes ti da editujes svoj post i da kod sebe dodas pa da pokusas da me diskreditujes na taj nacin ako hoces. Ne vidim zasto bih menjao broj iteracija uopste. Ako pogledas malo bolje videces da je cak i space na kraju reda ostao kad sam uradio copy & paste.

Ako hoces da napravis od ovoga benchmark, hajde da to uradimo kako treba. Napravimo dve verzije funkcije Calc i odvojimo ih u posebne .cpp i .obj fajlove i prevedemo sa razlicitim optimizacijama, a podrsku za SSE2 detektujemo sami i zovemo odgovarajucu funkciju iz glavnog koda.

monteboy · 17.03.2005

audiofreak je napisao(la):
Vidi, ti imas sledece pozive koji mogu da koriste SSE2:

1x pow
2x log

i ove koji ne mogu:

2x sin (160-200 taktova)
2x cos (180-280 taktova)

Tako da ti primer nije bas dobar pogotovo kada se uzme u obzir par gresaka koje si napravio u testiranju.

Slazem se sto se tice izbora funkcija malo nesrecan izbor ukoliko se koristi mali loop_counter razlika zaista ne ispada velika u prosjeku 2% e sad kad se malo formula modifikuje i doda jedan arctan i exp onda stvari sasvim drugacije izgledaju.

Kod:
Ovo su rezultati koje dobijam sa tvojim opcijama i sa MSVC bez izmena u kodu:

SSE2 podrska aktivirana,stisni taster za pocetak
..........izvrsno vrijeme : 148.172 s

SSE2 podrska deaktivirana,stisni taster za pocetak
..........izvrsno vrijeme : 152.750 s

razlika : 3.09 %

Zasto je to tako? Pogledaj kod generisan sa MSVC i tvojim opcijama:

Kod:

loc_4010AE: cmp [ebp+arg_C], 0 jnz short loc_401113 fld qword ptr [edi+esi] movsd xmm1, ds:dbl_4090E8 fsin mov eax, 2 fld qword ptr [esi] fsin fdivp st(1), st fldln2 fxch st(1) fyl2x fld qword ptr [edi+esi] fcos fld qword ptr [esi] fcos fmulp st(1), st fldln2 fxch st(1) fyl2x fsubp st(1), st fstp [esp+18h+var_8]

Sto se tice opcija gore koje sam ti naveo debelo se varas da impliciraju intrinsic verziju funkcija jer su u pitanju bile samo /Ot /G7 i /arch:SSE2
e sad to sto si ti u tvom projektu dodatno imao chekiranu opciju /Oi ili si koristio /Ox ili /Og koja inache implizira generisanje sistemskih funkcija je sasvim druga stvar.

Inache intrinsic verzija kao sto si i sam uvidio nema pozeljni efekat dokazivanja koliko utice SSE2 instruktion set na izvrsavanje floatpoint operacija.

Zaista je interesantno da je kod tebe intrinsic verzija sporija na AMD 64 je bas obrnuto ! ,)

SSE2 podrska aktivirana,stisni taster za pocetak
..........izvrsno vrijeme : 9.312 s

SSE2 podrska deaktivirana,stisni taster za pocetak
..........izvrsno vrijeme : 9.359 s

razlika : 0.50 %

Mozda ces sa ovom verzijom osjetiti razliku bolje zamolio bi te da odradis test i postavis screenshot (Inache je MS kompilat sa gore navedenim opcijama , bez intrinsic funkcija !!! SSE2 optimizacija za P4 i AMD)

SSE2bench

Moj odnos je sledeci :

Radi se o kodu koji nije posebno optimizovan samo za Intel P4 ili AMD 64 nego radi na oba CPU'a e sad kao sto vidis odnos je na mom AMD 64 3200+ preko 40% , sad te fino pitam da li bi posteno bilo da sam onda u threadu dozvolio da ljudi koji imaju Intel koriste patch a AMD vlasnici ne ?

Razlika skoro da ne postoji jer ukljucivanje/iskljucivanje SSE2 ne deluje na kod generisan Intelovim kompajlerom. Ali zato pogledaj vreme izvrsavanja bez ikakvih izmena tvog koda.

Pa sobzirom da koristis Intel'ov kompajler a i kompilirao si verzija koja radi samo na njemu nista cudno !

Ako hoces da napravis od ovoga benchmark, hajde da to uradimo kako treba. Napravimo dve verzije funkcije Calc i odvojimo ih u posebne .cpp i .obj fajlove i prevedemo sa razlicitim optimizacijama, a podrsku za SSE2 detektujemo sami i zovemo odgovarajucu funkciju iz glavnog koda.

Mozemo , ja cu uraditi dvije verzije za AMD -> 32bitnu i 64bitnu ispod Win 64 😉
Mozda bi jos bolje bilo da odvojis tvoj part u jedan Dll stim sto bi eksportovao finkciju Calc

Bice interesantno .....

audiofreak · 17.03.2005

monteboy je napisao(la):
Sto se tice opcija gore koje sam ti naveo debelo se varas da impliciraju intrinsic verziju funkcija jer su u pitanju bile samo /Ot /G7 i /arch:SSE2 e sad to sto si ti u tvom projektu dodatno imao chekiranu opciju /Oi ili si koristio /Ox ili /Og koja inache implizira generisanje sistemskih funkcija je sasvim druga stvar.

Nisam koristio ni /Oi ni /Ox ni /Og, opet ne citas pazljivo -- /O1 ili /O2 impliciraju /Og tako da ako njih koristis takodje se dobija takav kod. Kod mene je bilo /O2. Inace, u help-u pise da je /Ot po default-u ukljuceno. Ako ti nije tesko, dodaj /fixed:no parametar sledeci put za linker, zelim da profiliram tvoj .exe sa VTune.

monteboy je napisao(la):
Radi se o kodu koji nije posebno optimizovan samo za Intel P4 ili AMD 64 nego radi na oba CPU'a e sad kao sto vidis odnos je na mom AMD 64 3200+ preko 40% , sad te fino pitam da li bi posteno bilo da sam onda u threadu dozvolio da ljudi koji imaju Intel koriste patch a AMD vlasnici ne ?

Govoris o patch-u koji su mogli da koriste i vlasnici A64 (barem SSE2 verzija), pa ne vidim u cemu je tu problem. Inace tamo je uticaj bio daleko manji.

monteboy je napisao(la):
Mozemo , ja cu uraditi dvije verzije za AMD -> 32bitnu i 64bitnu ispod Win 64 😉
Mozda bi jos bolje bilo da odvojis tvoj part u jedan Dll stim sto bi eksportovao finkciju Calc

Bice interesantno .....

Videcu sta mogu da uradim, ali mislim da cu morati da ti napravim i 64-bitnu verziju dll-a.

I na kraju rezultat kod mene:

Ono sto meni nije jasno je zasto je kod toliko sporiji kod mene nego kod tebe? Imas li mozda neku ideju osim onog "zato sto je AMD bolji od Intel-a"?

EDIT: E da, postuj novu verziju source-a.

monteboy · 17.03.2005

audiofreak je napisao(la):
Nisam koristio ni /Oi ni /Ox ni /Og, opet ne citas pazljivo -- /O1 ili /O2 impliciraju /Og tako da ako njih koristis takodje se dobija takav kod. Kod mene je bilo /O2. Inace, u help-u pise da je /Ot po default-u ukljuceno. Ako ti nije tesko, dodaj /fixed:no parametar sledeci put za linker, zelim da profiliram tvoj .exe sa VTune.

Bilo kako bilo jedna od opcija je implicirala intrinsic, uglavnom nije ni jedna koju sam ti ja bio postovao.

Govoris o patch-u koji su mogli da koriste i vlasnici A64 (barem SSE2 verzija), pa ne vidim u cemu je tu problem. Inace tamo je uticaj bio daleko manji.

Koliko se ja secam patch je bio za P4 Prescott i to SSE3 !, e sad u detalju ga neznam ni ja tako samo mozemo naslutiti sta je optimirano istim u svakom slucaju uporedjenje se ne moze izvrsiti na korektan nacin ako se modifikuje verzija benchmark'a u bilo kom smislu za pojedini procesor.

Videcu sta mogu da uradim, ali mislim da cu morati da ti napravim i 64-bitnu verziju dll-a.

Samo naprijed , muski !

Ono sto meni nije jasno je zasto je kod toliko sporiji kod mene nego kod tebe? Imas li mozda neku ideju osim onog "zato sto je AMD bolji od Intel-a"?
EDIT: E da, postuj novu verziju source-a.

Pa vjerovatno utice i malo cinjenica da je moj sistem clocknut na 2650 Mhz sto bi znacilo 650 MHz vise od default takta. Ipak razlika je i sobzirom te cinjenice prevelika predpostavljam da A64 jednostavno bolje lezi MS kompilat veceras cu ti poslati source , onda mozes odradit optimizaciju za Intel interesantno bi bilo onda uporediti ASM instrukcije da se ustanovi gdje lezi problem.

Odnos 64 bitnih sistema AMD vs Intel

Slavan

Banned

Slavan

Banned

Slavan

- Bike Camper -

Čuven

Čuven

Banned

Čuven

Slavan

Slavan

Banned

Čuven

Čuven

Banned

Čuven

Banned

Čuven

Banned

Slavan

Banned

Banned

Slavan

Banned

Prilozi

Slavan

Banned

Slavan

Banned

Slavan