Keresés: - [Re:] Videón az AMD Comal platformja

LOGOUT témák

PROHARDVER! témák

Mobilarena témák

IT café témák

GAMEPOD témák

Keresés

Új hozzászólás Aktív témák

#149 MiklosSaS nagyúr dezz #147

Új Válasz 2012-04-12 01:52:25 #149
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

MiklosSaS

nagyúr

válasz dezz #147 üzenetére

Aha, ha te mondod akkor biztosan ugy van
#125 ddekany nagyúr dezz #116

Új Válasz 2012-04-11 12:46:14 #125
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

ddekany

nagyúr

válasz dezz #116 üzenetére

Egyszálas optimalizáció alatt én nem is alacsony szintű szőrözésre gondoltam, hanem sokkal inkább arra, hogy sokszor a belső "API-k" olyanok, meg néha az alkalmazott adatstruktúrák is, hogy sokkal többet dolgozik a gép, mint kéne.
A másik ami nem tudom mindenkinek világos-e, állatira más az, amikor ugyan azt a feladatot kell elvégezni egymástól függetlenül sok objektumon (tipikus kép/hang kapcsán), meg az, amikor úgy kell vakaródzni rajta, hogy egyáltalán mik azok a részek, amik egymástól függetlenek annyira, hogy egyszerre futtathatók legyenek, és persze akkor is figyelni kell, hogy mi van azokkal az adatokkal amiket közösen használnak és módosítanak (azaz, konkurens programozás). Előbbi biztosan el fog harapódzni, utóbbit meg eddig is csak ott csináltuk ahol muszáj (tipikusan, szerverekben, néhol vezérélésben).
#115 MiklosSaS nagyúr dezz #114

Új Válasz 2012-04-10 19:38:20 #115
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

MiklosSaS

nagyúr

válasz dezz #114 üzenetére

Ezt most nem erdemes targyalni. CAD-CAM es aritmetikai programokkal dolgozok. 6100-om volt 12 giga rammal 4,66 ghz-re tuningolva. Aztan valtottam 2600k-ra, 4,6-ra tuningolva 272 %-kal gyorsabb aritmetikaban. Teszteltem, huztam, gyuztam a bullt meg az i7, en szerintem a bull az fail !
#102 stratova veterán dezz #101

Új Válasz 2012-04-10 07:38:23 #102
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

stratova

veterán

válasz dezz #101 üzenetére

Eddig ismeretlen okból kifolyólag nem reagált a tisztelt fórumtárs e kérdést taglaló válaszomra, pedig én is "CPU számítási teljesítmény / Wattról beszéltem".
Szerintem erre a CPU erő/fogyasztás kérdésre visszatérhetnénk amikor:
1. Megjelent Ivy, Trinity és Vishera, esetleg további tesztek.
2. Intel bármilyen CPU mag "mellé" HD 6550D, HD 7660D ill. 6620G és 7660G kaliberű GPU-t pakol.
3. A konkurens 2 mag/modul, 4 szálas APU-k csak CPU terheléses fogyasztása összevethető.
Nem tudom szemet szúrt-e a teljesítmény/fogyasztást feszegetőknek, hogy jelenleg pl. 35 W-os osztályba mindkét gyártó legfeljebb 2 fizikai maggal/modullal nevez. Ez igaz Ivy bridge-re is, a 22nm és 3D tranzisztor ellenére ez fér a keretbe potensebb (HD 4000) GPU résszel.
#95 ddekany nagyúr dezz #94

Új Válasz 2012-04-09 19:32:01 #95
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

ddekany

nagyúr

válasz dezz #94 üzenetére

"A Trinity elsősorban mobil/mainstream desktop proci. Ehhez megvan a kellő "CPU-erő".
De én a CPU számítási teljesítmény / Wattról beszéltem, nem nyers erőről.
"Sorolnád azt a sok alkalmazást (főleg a hétköznapiakat), ami nem többszálúsítható, de igényli a minél nagyobb teljesítményt?"
A legtöbb kód amit írunk (90%-sok százalék simán) egyszálú volt és reálisan az is marad örökre (hacsak nem tök más nyelvek lesznek mainstream-ek... maaajd, talán), mert egyszerűen nem reális erőfeszítés megkeresni benne a picike párhuzamosítható cafatokat, meg összehangolni őket. Ráadásul ha pici cafatokat tudsz csak párhuzamosítani, akkor sokszor a párhuzamosított megoldás a lassabb. (Illetve a nagyon-nagyon pici párhuzamosítható cafatokat megtalálja egy modern CPU.) Hogy aztán ezek közt ki szerint melyik üti meg a "igényli a minél nagyobb teljesítményt" követelményt... Amikor van kismillió absztrakciós réteged, sőt, meg akár magas szintű nyelved (Python, Ruby, JavaScript, stb), akkor azért van, hogy tetű lesz a program a rakás overheadtól egy modern CPU-n is, szóval a gyorsabb jobb. Amúgy pl. fordítás/értelmezés (parsing) is jellemzően olyan, hogy nem nagyon párhuzamosítható elvileg sem.