Kako radi AMD Phenom

[drfedja]

U photoshopu ti je komp brz onoliko koliko ti je brza najsporija komponenta i to stoji. Ako imas 4GB RAM-a sasvim sigurno je da ce ti Photoshop bolje raditi nego sa 512 MB.

 

[audiofreak]

U photoshopu ti je komp brz onoliko koliko ti je brza najsporija komponenta i to stoji. Ako imas 4GB RAM-a sasvim sigurno je da ce ti Photoshop bolje raditi nego sa 512 MB.

To je tacno ali covek upravo kaze da kad popunis ram (a to se desi brzo ako zaista radis nesto) vrlo brzo to usko grlo postaje disk. Znaci Photoshop scratch na RAID0, a Windows swap na neki drugi disk. I naravno, sto vise RAM-a, x64 i Bigger Tiles.

 

[Nedjo]

mene mrzi, a iskren da budem ne znam ni kako, da isprobam da li CS3 moze da radi sa fajlovima iznad 2 GB pod x64-vorkom. Ako neko moze, bilo bi lepo da javi utiske.

Audio jel mozes da pitas te svoje kontakte da li je realno ocekivati da CS4 bud 4bit app, obzirom da je cena memare toliko zveknula i obzirom da Photoshopu toliko puno znaci kolicina RAM-a?

P.S
jedna pomalo bizarna trivija: pre dve godine sam od prodaje 2 GB memare mogao da platim mesecnu stanarinu, danas mi za to treba 4x vise memorije 🙁 (doduse, za ovaj stan sada mi treba 16 GB 🙁 🙁 )

 

[monteboy]

Eh, znaci opet se bitka bije oko takta, ja sam mislio da je ta faza prosla. Zar nije ono AMD bese govorio da frekvencija nije bitna nego efikasnost?

Pa kad ti je arhitektura toliko nadmocnija kao sto je bio slucaj kod K8 u odnosu na Netburst onda da .....

Opet se vracas na stare grehove ..... a ja mislio da si konacno skrenuo sa fanboy putanje 🙂

 

[ima-li-koga-tu]

photoshop je dosta zavistan od diskova, tako da on za testiranje rada procesora i nije najpouzdaniji.
ja sam primetio tek razliku kada sam stavio sata2 diskove, a radio sam sa ovom x2 konfom i sa ata diskom, maxtor od 40gb. pa to je bilo stvarno sporo. tu se najvishe videlo kada napusti memoriju i krene na disk. kao da je odapeo.
sata2 je za svaku pohvalu, sto se PSa tice. na poslu imam neke C2d procesore na 2.6 ghz, bas cu da probam obradu raw fajla u capture NX programu, znam da je trebalo na sljaci oko 4 sekunde da ga otvori. cim skinem capture kuci probacu. nisam bas stopericom merio ali oko4s.

 

[drfedja]

SATA2 ti ne donosi bas neko narocito ubrzanje, vise ces osetiti ako diskove uparis u raid0. Brzina transfera izmedju interfejsa i SATA kontrolera nije limitirajuci faktor u brzini rada diska. Cak stavise, sa brzim diskovima u RAID-u ce ti brze raditi sa ATA 100 interfejsom nego sa SATA2 sa jednim diskom.

 

[audiofreak]

mene mrzi, a iskren da budem ne znam ni kako, da isprobam da li CS3 moze da radi sa fajlovima iznad 2 GB pod x64-vorkom. Ako neko moze, bilo bi lepo da javi utiske.

Ja sam probao CS3 pod x64 i video je vise od 3GB fizickog RAM-a u opcijama. Moglo je da mu se dodeli skoro 3.5 GB. Znam sigurno da koriscenje pod x64 ima prednosti.

Audio jel mozes da pitas te svoje kontakte da li je realno ocekivati da CS4 bud 4bit app, obzirom da je cena memare toliko zveknula i obzirom da Photoshopu toliko puno znaci kolicina RAM-a?

Mogu da pitam ali licno mislim da su sanse male. Glavni problem je u 3rd party pluginovima koji su svi 32-bitni. Novi Photoshop ne bi mogao da ih koristi posto 64-bitna aplikacija ne moze da koristi 32-bitne DLL-ove. Takodje sam Photoshop nema nikakve prednosti od 64-bitne arhitekture osim adresiranja vece kolicine memorije sto su oni vec resili svojim custom VMM-om. Ne znam da li si uopznat ali Photoshop ne koristi Windows VMM uopste vec sam alocira memoriju i radi management jer bi inace posle par alokacija memorija bila toliko fragmentirana da nista vise ne bi mogao da ucitas. Taj custom VMM je inace drugi glavni razlog neprelazenja na 64-bitnu platformu.

 

[drfedja]

Ne znam da li si uopznat ali Photoshop ne koristi Windows VMM uopste vec sam alocira memoriju i radi management jer bi inace posle par alokacija memorija bila toliko fragmentirana da nista vise ne bi mogao da ucitas. Taj custom VMM je inace drugi glavni razlog neprelazenja na 64-bitnu platformu.

A zasto mislis da bi memorija bila fragmentisana? Photoshop ne alocira memoriju "na sitno". Verovatno postoji razlog sto PS koristi svoj memory manager. Koliko sam primetio, on u startu alocira recimo, 50% raspolozivog sistemskog RAM-a, a nakon toga dodatno ako zatreba.

 

[audiofreak]

A zasto mislis da bi memorija bila fragmentisana? Photoshop ne alocira memoriju "na sitno". Verovatno postoji razlog sto PS koristi svoj memory manager. Koliko sam primetio, on u startu alocira recimo, 50% raspolozivog sistemskog RAM-a, a nakon toga dodatno ako zatreba.

Ne mislim, znam da bi bila fragmentirana kada bi Photoshop koristio Windows VMM.

Upravo zato sam i naglasio da Photoshop koristi svoj custom VMM jer Windows VMM jednostavno nije dorastao takvom zadatku. To sam napomenuo i kao jedan od razloga zasto ne prelaze na 64-bitnu arhitekturu. Citaj malo pazljivije 😉

Sto se tice velicine alokacije, on alocira onoliko procenata koliko mu zadas u opcijama. Ja sam cuo da je 65-70% optimalno.

 

[drfedja]

Ajd da preciziram pitanje. Zasto mislis da bi windows VMM zasrao stvar? :d 😉

PS bi morao da koristi Windows VMM za prvobitnu alokaciju memorije, sumnjam da su potpuno zaobisli OS. Alokacija se vrsi pri ucitavanju i resizeovanju dokumenta. Alociran prostor je veci nego sto je velicina dokumenta. Ono sto sam primetio je da Photoshop ne vraca alociranu memoriju nakon zatvaranja dokumenta. Alocirano je onoliko prostora na heap-u koliko je prethodni najveci dokument alocirao. Memoriju koju je vec dobio od OS-a verovatno PS VMM sam "handluje", sto naravno predupredjuje fragmentaciju. Verovatno da bi koristeci Windows VMM posle otvaranja i zatvaranja vise dokumenata doslo do fragmentisanja. Postavlja se pitanje kako je zaista uradjen Photoshopov memory manager, a odgovor na to pitanje tesko da cu da dobijem. 😉

 

[alfaunits]

Windoze-ov VMM (za user mode) je radjen genericki za obicne aplikacije, ne za workstation/server (pricam za obican XP/Vistu, ne Srv0x). Da ce zashrati je sigurno 😉
Kernel mode je druga stvar potpuno.

 

[audiofreak]

Ajd da preciziram pitanje. Zasto mislis da bi windows VMM zasrao stvar? :d 😉

Zato sto ima krajnje primitivan algoritam. Ako na primer imas 500 MB slobodne memorije u komadima od 300, 150 i 50 MB i ako mu aplikacija zatrazi 100 MB on ce uraditi sledece:

1. Naci prvi najveci slobodan blok (300 MB)
2. Odvojiti 100 MB i dati aplikaciji koja je trazila
3. Vratiti 200 MB na gomilu slobodnog RAM-a

Znaci posle alokacije od 100 MB imaces 200, 150 i 50 MB slobodno. Kao sto vidis, najveci kontinualan blok memorije se upravo smanjio. Ko bude trazio 300 MB, dobice NULL pointer od VirtualAlloc() odnosno alokacija nece uspeti.

PS bi morao da koristi Windows VMM za prvobitnu alokaciju memorije, sumnjam da su potpuno zaobisli OS.

Koliko ja znam bio bi ogranicen na 3 GB cak i pod x64 operativnim sistemom da je to slucaj. Posto u x64 vidi vise od 3 GB RAM-a onda je to dobar znak da koriste direktnu alokaciju fizicke memorije i da sami rade heap management.

Alokacija se vrsi pri ucitavanju i resizeovanju dokumenta. Alociran prostor je veci nego sto je velicina dokumenta.

To je samo commit u tom trenutku, memorija je rezervisana jos ranije.

Ono sto sam primetio je da Photoshop ne vraca alociranu memoriju nakon zatvaranja dokumenta.

Uradi purge history i empty clipboard, trebalo bi da vrati.

Postavlja se pitanje kako je zaista uradjen Photoshopov memory manager, a odgovor na to pitanje tesko da cu da dobijem. 😉

Danas imas srece 😀

Photoshop rezervise fizicku memoriju u onom procentu koji mu odredis u opcijama. Upotrebom se ta rezervacija pretvara u alokaciju. Windows to vidi kao smanjenje dostupne fizicke memorije za sebe i ostale aplikacije. Photoshop sam radi sopstveni heap management, i pride vodi racuna da vrati Windows-u fizicku memoriju ako isti krene da swap-uje.

Evo sta je Scott rekao o VM-u:

No, the operating system VMs aren't good enough to get peak performance while maintaining interactivity. The page sizes are very small, and don't have the 2D locality needed for responsive image editing. The memory hinting interfaces have too much overhead to replace what we're doing now. I'd love to not have to maintain our own VM system, but I doubt our customers would want to put up with the loss of performance - and we check the performance loss with every new OS, hoping.

A evo i o bandwidthu:

As for the bandwidth issue, the problem is very, very real. We do cache management, prefetching, use SIMD, and all the other tricks we can to maximize the use of that bandwidth, but most operations are now bandwidth bound. The simple truth is that there isn't enough bandwidth for the number of cores in current machines for all but the most compute bound operations.

A evo njegovim recima zato 64-bitna aplikacija nema smisla trenutno:

First, Photoshop is already able to deal with data sets much larger than 4GB by having it's own VM system, so the 4GB address space limitation isn't nearly as much of a barrier for us.

Evo sta kaze za quad-core i threading:

Photoshop will take advantage of as many cores are in a machine. However... not all operations are threadable, and even for those that are, there are diminishing returns - most of which depend on operating system overhead for threading APIs and memory bandwidth available in the system - that means the performance improvement going from 2 cores to 4 isn't 2x expect for increasingly rare cases (e.g., Radial Blur is a perennial favorite way of pegging all the cores in a machine at once). As always, we are looking at ways of more fully utilizing all that power.

I za kraj, evo necega sto sam ja davno govorio kad su neki ovde propagirali AMD64 kao Sveti Gral performansi:

And, we have done a bit of performance testing on our low-level processing routines which have been tweaked and tuned over many years. Untweaked code tends to be where the biggest gains are, and starts to approach the performance of our tweaked code. Our tweaked code is already fast and didn't see much, if any, gain.

Ko je pratio moje postove sigurno se seca da sam tada kada su se mnogi kleli u AMD64 govorio da najvise dobiti od prelaska na 64-bitnu verziju imaju neoptimizovane aplikacije i da je jedina prava dobit veci adresni prostor.

 

[Bogda]

B3 revizija kod Ananda: http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3272
Nije loše, ovo je Phenom trebao da bude u Novembru 2007. Konačno se primakao C2Q6600. Međutim onaj C2Q9300 se odmakao tačno onoliko koliko je C2Q600 bio brži od B2 Phenoma.

 

[Nedjo]

Audio svaka cast za informacije od Skota Bajera!!! taj post je vredan posebnog clanka za koji verujem da bi privukao desetine hiljada citalaca sa neta!!

 

[audiofreak]

Audio svaka cast za informacije od Skota Bajera!!! taj post je vredan posebnog clanka za koji verujem da bi privukao desetine hiljada citalaca sa neta!!

Treba zahvaliti njemu. Sto se mene tice, ja sam cini mi se jos davno linkovao taj njegov blog post negde na benchu, ali niko se nije "odvazio" da procita sve komentare, a covek je na jako veliki broj komentara odgovorio dajuci veliku kolicinu korisnih informacija.

Ako hoces, odvoj ove postove o Photoshopu u poseban thread da ne razvodnjavamo ovaj o Phenomu, a ovde ostavi samo link.

 

[monteboy]

I za kraj, evo necega sto sam ja davno govorio kad su neki ovde propagirali AMD64 kao Sveti Gral performansi:

Ko je pratio moje postove sigurno se seca da sam tada kada su se mnogi kleli u AMD64 govorio da najvise dobiti od prelaska na 64-bitnu verziju imaju neoptimizovane aplikacije i da je jedina prava dobit veci adresni prostor.

nije isklljucivo adresni prostor to i sam znas neznam cemu pokusavas da se vracas na stare nebuloze 🙂
16 SSE registara u 64bit modu nemogu biti sporiji od 8 SSE u 32bitnom to i moja bama razume koja veze nema sa informatikom.

U zavisnosti od zadatka ako se aplikacija pise i optimizuje za 64bitni mode moze se lako izvuci performansna dobit sto naravno ne vazi za svaki deo
koda koji je napisan u zadnjih 20 godina

 

[milanbb]

B3 revizija kod Ananda: http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3272
Nije loše, ovo je Phenom trebao da bude u Novembru 2007. Konačno se primakao C2Q6600. Međutim onaj C2Q9300 se odmakao tačno onoliko koliko je C2Q600 bio brži od B2 Phenoma.

Anand bi mogao sve testove AMD procesora da pocinje sa "I hate AMD and want them to die" :smoke:

 

[audiofreak]

nije isklljucivo adresni prostor to i sam znas neznam cemu pokusavas da se vracas na stare nebuloze 🙂

Hajde da to preformulisemo -- jeste iskljucivo adresni prostor osim za aplikacije koje imaju prednosti od 64-bitne aritmetike.

16 SSE registara u 64bit modu nemogu biti sporiji od 8 SSE u 32bitnom to i moja bama razume koja veze nema sa informatikom.

Za razliku od tebe i tvoje bame(?) ja sam probao :d

Prema mom iskustvu u 99% slucajeva jesu sporiji. Sa tekucom arhtekturom i ne mogu biti brzi jer je problem u tome sto dekodiranje 64-bitnih instrukcija nije jednako brzo kao dekodiranje 32-bitnih zbog dodatnih prefiksa. Pride, kompajleri su se vec dovoljno dobro snalazili i sa 8 registara, a hardware register renaming i da ne pominjem.

Moje licno misljenje je da su dodatni registri potpuno nepotrebno utrosen silicijum. Da je makar AMD omogucio da se koriste i van 64-bitnog moda (sto je moglo uz odgovarajuci kernel patch za Windows, Linux, etc) pa hajde, ali ovako... pa vise se performansi dobija budzenjem L2 nego od tih registara.

E sad, ako ti imas neke druge podatke -- na primer ako si video asemblerski kod neke 64-bitne aplikacije koja koristi ekstra registre i profitira od toga znacajno (vise od 5%), a da u isto vreme ne profitira od drugih optimizacija (SSE2 umesto FPU, SIMD, optimalniji algoritam, itd) bilo bi lepo da to podelis sa nama.

Drugim recima, dok ne vidim primer 32-bitnog i istog takvog (osim sto koristi vise registara) ali brzeg 64-bitnog koda ne zelim dalje da raspravljam na tu temu.

 

[monteboy]

Hajde da to preformulisemo -- jeste iskljucivo adresni prostor osim za aplikacije koje imaju prednosti od 64-bitne aritmetike.



Za razliku od tebe i tvoje bame(?) ja sam probao :d

Prema mom iskustvu u 99% slucajeva jesu sporiji. Sa tekucom arhtekturom i ne mogu biti brzi jer je problem u tome sto dekodiranje 64-bitnih instrukcija nije jednako brzo kao dekodiranje 32-bitnih zbog dodatnih prefiksa. Pride, kompajleri su se vec dovoljno dobro snalazili i sa 8 registara, a hardware register renaming i da ne pominjem.

Moje licno misljenje je da su dodatni registri potpuno nepotrebno utrosen silicijum. Da je makar AMD omogucio da se koriste i van 64-bitnog moda (sto je moglo uz odgovarajuci kernel patch za Windows, Linux, etc) pa hajde, ali ovako... pa vise se performansi dobija budzenjem L2 nego od tih registara.

E sad, ako ti imas neke druge podatke -- na primer ako si video asemblerski kod neke 64-bitne aplikacije koja koristi ekstra registre i profitira od toga znacajno (vise od 5%), a da u isto vreme ne profitira od drugih optimizacija (SSE2 umesto FPU, SIMD, optimalniji algoritam, itd) bilo bi lepo da to podelis sa nama.

Drugim recima, dok ne vidim primer 32-bitnog i istog takvog (osim sto koristi vise registara) ali brzeg 64-bitnog koda ne zelim dalje da raspravljam na tu temu.

Al si ti smesan pa rekao si da nema nikakve prednosti u performansama osim adresorskog prostora a sad pricas o procentima +5% ili nista.

Kakvi su to argumenti ajde se molim te odluci imali ili nema prednosti ......

Sasvim jasno pitanje bez ikakvih pokusaja koprcanja odgovori sa Da ili Ne

 

[audiofreak]

Al si ti smesan pa rekao si da nema nikakve prednosti u performansama osim adresorskog prostora a sad pricas o procentima +5% ili nista.

Kakvi su to argumenti ajde se molim te odluci imali ili nema prednosti ......

Sasvim jasno pitanje bez ikakvih pokusaja koprcanja odgovori sa Da ili Ne

Rasprava je pocela tako sto si ti rekao da vise registara ne moze biti sporije i kako je vise registara znacajna prednost pored adresnog prostora -- ja tvrdim da moze biti sporije i da nije prednost kao sto se misli.

Takodje sam rekao da je osim adresnog prostora 64-bitna aritmetika prednost, ali to je za jako mali broj aplikacija -- vecina njih nema potrebe da radi sa tako velikim celim brojevima zato to iz prve nisam ni spomenuo.

Ne vidim u cemu je sad tu problem?

 

[drfedja]

Mislim da glavna prednost 64-bitnog moda nije 64-bitna aritmetika i rad sa ogromnim celim brojevima nego veci broj registara i drugacije prosledjivanje parametara funkcija pri koriscenju SIMD-a.

 

[audiofreak]

Mislim da glavna prednost 64-bitnog moda nije 64-bitna aritmetika i rad sa ogromnim celim brojevima nego veci broj registara i drugacije prosledjivanje parametara funkcija pri koriscenju SIMD-a.

Ajoj bre, otkacite se vise od tih registara, prednost od toga je minimalna! Uostalom ako mi ne verujete probajte sami.

 

[drfedja]

Ovde http://www.benchmark.co.yu/forum/showpost.php?p=1388696&postcount=22 si tvrdio da u 32-bitnom modu postoje ogranicenja u vidu implicitnog prenosa parametara funkcija. Kako onda nema koristi od 64-bitnog rezima, kada ima.

 

[audiofreak]

Ovde http://www.benchmark.co.yu/forum/showpost.php?p=1388696&postcount=22 si tvrdio da u 32-bitnom modu postoje ogranicenja u vidu implicitnog prenosa parametara funkcija. Kako onda nema koristi od 64-bitnog rezima, kada ima.

Aman, to sto sam tamo rekao nema veze sa brojem registara. Naravno da postoji odredjena prednost (u vidu manje latencije) u tome sto se float parametri u 64-bitnom modu prenose preko XMM registara, ali za to ih je bilo dovoljno i 8 komada.

Takodje, ako su ih vec dodali trebalo je da budu svugde dostupni (i to GPR u punoj sirini) a ne samo u 64-bitnom modu.

Tu se u stvari vidi koliko je x86 koncept general purpose registara bezveze -- da su imali odvojene data i adresne registre kao Motorola 680x0 (D0-D7/A0-A7) mogli su cak da dozvole koriscenje 64-bitnih data registara u 32-bitnom modu bez posledica po stare aplikacije.

Kazem opet najveca prednost AMD64 je od veceg adresnog prostora jer se izbegava potreba za swapovanjem i koriscenjem AWE i time drasticno ubrzava pristup podacima, a samim tim i njihova obrada.

Ne sporim uopste da postoje i druge prednosti ali su sve minorne (da ne kazem da nisu vredne pomena) u odnosu na adresni prostor.

 

[drfedja]

Aman, to sto sam tamo rekao nema veze sa brojem registara.

Ja nisam ni rekao da je jedina prednost postojanje veceg broja registara. :d

 

[Ji 4Tze]

Purge opcija u Photoshop-u ne radi kako treba, ne prazni visak, cak i kad je dokument ugasen. Ili je kriv Adobe ili PS ili operativni sistem. Je l' tako?
E sad, u AfterEffects-u Purge radi odlicno, i sa aktivnim dokumentom. Dakle, nije OS, nije Adobe, kriv je PS. Je l' tako? 😀

 

[drfedja]

Ocigledno da nije oslobodio alociranu memoriju. Photoshop vraca memoriju OS-u tek kada izadjes iz programa. Malo bi neozbiljno bilo da su ostavili "curenje memorije".

 

[Igoritza]

izvinte ljudi, ja u kuci imam dve konfiguracije, bavim se web design-om, samim time i grafichkim dizajnom, ponekad i posebno, i nikakav problem mi nije da PS CS3 startujem na kelerabi na 3Ghz sa 2x512 ram ddr2. sa kolkim vi rezolucijama radite pa vam je bitno kako uchitava, i kolko mu treba za odredjenu operaciju, pogotovo shto fotoshop zahteva odredjeno razmishljanje, pa sve moze da se sacheka ? ... evo, na mojoj konfiguraciji (Phenom 9600, 2x1GB, K9A2 Platinum, 3870@256mb) radi ko zmija, ne chekam nikad ni za shta, sve izlece u mikrosekundama

 

[ima-li-koga-tu]

sa minimum 3mb po slici, a rezolucija uglavnom oko 3000x2000. milisekunde nikad nisam osetio, samo sekunde.
nisam se josh poigrao sa nekim C2D, nadam se i da necu. ne verujem da je mnogo brzi od moje konfe.
voleo bih da mi je bitno brza mashina. ti mozda jesi zadovoljan
sa jednom slikom uglavnom nije problem raditi, i to je OK. 5 layera na 5 fotografija, i psovke vec pocinju

 

[Ji 4Tze]

4x3k, 5-50 lejera (lupam cifru, ali ni ne pratim je tacno jer pravim foldere i subfoldere), 200-500MB su psd fajlovi.
Uglavnom kad upalim PS i krenem da radim, znaci ucitam baznu sliku (render), par prolaza, maski i sl. to je to, nema sta vise od programa da palim. Mogu, ali da swapuje, zato i palim samo PS.

ima-li-koga-tu, brzi je nego sto mislis 😉

Ocigledno da nije oslobodio alociranu memoriju. Photoshop vraca memoriju OS-u tek kada izadjes iz programa. Malo bi neozbiljno bilo da su ostavili "curenje memorije".

Alocira je na sta, na nista? 🙂
Bas zato sam i naveo AE, koji to radi kako treba. Purge je purge.