Új hozzászólás Aktív témák
-
tlac
nagyúr
-
Fiery
veterán
Amennyiben GPGPU fejlesztest csinalsz, pl. OpenCL vagy CUDA segitsegevel, akkor majdnem mindegy, hogy egy low-end mobil GPU-n fejlesztesz, vagy egy high-end dGPU-n, legalabbis amig egy adott GPU architekturan belul gondolkozunk. Jelen esetben ha mondjuk van egy jo kis CUDA-s fejlesztokornyezeted, akkor ugyanolyan frankon tudsz dolgozni egy K1-en, mint egy GK110B-n. Mas kerdes persze, hogy valoban egyforman jol mukodik-e a fejlesztokornyezet (jelen esetben a CUDA 6.0) egy low-end ARM-os "APU"-n, mint amihez hozzaszokott az ember a PC-n es a dGPU-kon.
-
-
dezz
nagyúr
Izé, kicsit elhamarkodottan fogalmaztam, hiszen az Nvidia SoC-okban természetesen eddig is voltak ARM magok.
Arra gondoltam, vajon lesz-e olyan nagyobb teljesítményű, PC/HPC-s Nvidia GPU, amiben lesz ARM mag? Korábban mintha ezt is pedzegették volna. Vagy esetleg éppen ez a K1 az? (Akkor viszont kár, hogy nincs benne még SVM.) Bár ezt is mobilnak írják. -
Fiery
veterán
Az OpenCL 2.0 mint specifikacio mar veglegesitve lett, ha lehet hinni a Khronos weboldalanak --> [link]
Az megint mas kerdes, hogy melyik gyarto mikor es hogyan implementalja a tamogatast. Amig nincs SVM (megosztott memoria) egy adott termeknel, addig nincs sok jelentosege az OpenCL 2.0 tamogatasanak. Az Intel elso OpenCL 2.0 kepes GPU-ja elvileg a Broadwell lesz. Az nVIDIA dGPU-khoz pedig nem igazan lehet ilyesmit hasznalni, ugyhogy azok velhetoen maradnak OpenCL 1.1 vagy 1.3-on.
-
orbano
félisten
ezt ne kisméretű, jól optimalizálható algoritmusokra értsd, hanem összetettebb alkalmazásokra. pl. van egy szomszédsági bejárásunk, ami dependency injection design patternt használ olyan funkciókra, amik masszívan nagyon sokszor meghívónak, teli van lambda expressionökkel, linq-t használ, stb. itt azért jócskán el tud szivárogni a teljesítmény. de bizonyos egyszerű, ciklusban műveletvégzős esetekre is mértem már ki 5x körüli eltérést, ami meglehetősen kijózanítólag hatott, addig azt hittem a CLR fordítója okos és mindent megold és alig marad el a natív kódtól. Hát a frászt... ráadásul durván lábon tudod lőni magad. Mivel minden oop, egy nagy ismétlésszámú ciklusban pl. ha használsz egy mezőt az objektumból, 10x-es a bünti, ha a ciklusod masszívan igénybeveszi a cachet, és a mezőhozzáférés iszonyat cache misseket produkál. Ezt a C++ lazán kioptimalizálja. De egy sima összezős for ciklus is lassabbra fordul (pontos számokra nem emlékszem, de nem voltam boldog az összehasonlításnál).
-
Fiery
veterán
"lehet-e OpenCL-ben egyik (pl. Maxwell) vagy másik (pl. GCN) architektúra számára kedvezőbb kódot írni?"
Hogyne lehetne. Szerencsere eleg sok mindent ki lehet deriteni a konkret GPU architekturarol, pl. nVIDIA GPU-knal a compute capability konnyen detektalhato, az alapjan meg eleg jol be lehet loni, hogy milyen GPU-n fut az OpenCL kodod. Az mar csak rajtad all, hogy mennyire vagy hajlando az esetleg meglevo kododat tovabb optimalizalni azert, mert mondjuk erkezett egy uj architektura (pl. Maxwell, ez jott legutobb). OpenCL-ben nyilvan nehez lemenni olyan melysegekig, mint x86-on az assembly segitsegevel, de ha tisztaban vagy a GPU architekturaval, akkor berakhatsz kulonfele trukkoket, pl. kulonbozo melysegu unrolling, inline kodreszletek, int24 adattipus, stb. Vagy le is cserelhetsz beepitett fuggvenyeket, ha az adatok fajtajanak ismereteben gyorsabbat tudsz irni, mint amit az OpenCL alapbol kinal. Az OpenCL-lel rengeteget lehet mokolni, es valahol elvezheto is az egesz, amennyiben a compiler nem gancsolja el a kerneledet.
-
A Maxwellen asszem csak az OpenCL 1.1 a tamogatott, szoval celszerubb CUDA-t hasznalni rajta.
Az 5-10x-es szorzot en se ertem egyebkent, altalanos esetben (!) egy Java kod nem sokkal lassabb, mint egy hasonlo minosegu C++ kod (szoval szazalekokban, es nem szorzokkal merik a kulonbseget). Amirol en beszeltem, az a C++ vs egy bizonyos interpretalt nyelv.
-
dezz
nagyúr
Köszi a kimerítő választ! (Persze, jöhet privátban, de elég tőmondatokban.)
A matematikusok nyilván csak akkor lesznek elégedettek, ha elég lesz a képlet.
Amúgy a MathLab nem tud ilyet?(#121) Fiery: Úgy értettem, ha valaki az OpenCL kód elkészítésekor figyelembe veszi a HW felépítését, működését. Emvy válszolt rá. Esetleg még arra lennék kíváncsi, ha már így benne vagyunk, hogy lehet-e OpenCL-ben egyik (pl. Maxwell) vagy másik (pl. GCN) architektúra számára kedvezőbb kódot írni?
(#122) orbano: 5-10x szorzó azért durva.
-
orbano
félisten
nálunk ugyanez a helyzet, jobban megéri egyelőre atom vasak alatt C#-ban fejleszteni, mert túl gyakran kell hozzányúlni az algoritmusokhoz, túl nagy rugalmasságra van szükség, hiába lenne 5-10x gyorsabb C++-ban, amit nyernénk, az elmenne a méregdrága programozó-munkaidőn, ráadásul a versenyképességünk is csökkenne. ha szükség van rá, egy adott verziót még így is egyszerűen át lehet portolni egy alkalmasabb nyelvre, konkrét vasra, ha éppen szükség van rá egy adott ügyfélnél.
-
> Egyébként .NET-ben számít valamit a HW valamelyes ismerete?
Egeszen ritka esetekben igen, nyilvan mondjuk a cache vagy a virtualis memoriakezeles az mindig es mindenhol eleg alapveto ismeret. A regi szep idokben volt egy helyzet, ahol a .Net JITter ASM kimenetet nezegettuk, mert olyan helyzet allt elo, ahol valami miatt erezhetoen szuboptimalis kodot produkalt -- jelezni kellett az MS-nek, es es megcsinaltak a kovetkezo verzioban. Egyebkent .Net kodba is lehet lenyegeben inline assembly kodot rakni, csak nem javasolt
.OpenCL-ben muszaj tudni, hogy korulbelul hogy nez ki egy GPU architektura, hiszen meg mindig blkIdx-ekkel meg tid-ekkel van tele a kod -- ezek meg vegulis hardverspecifikus dolgok, nem a feladatrol szolnak, hanem az implementaciorol. Valojaban mindaz, ami az elmeletet es az implementaciot elvalasztja, az a kornyezetrol szol (hardver ill. szoftverkornyezet). Pelda (wikipediarol, az egyszeruseg kedveert):
# ezt akarom csinalni
# ezt mondom a gepnek
__kernel void fft1D_1024 (__global float2 *in, __global float2 *out,
__local float *sMemx, __local float *sMemy) {
int tid = get_local_id(0);
int blockIdx = get_group_id(0) * 1024 + tid;
float2 data[16];
// starting index of data to/from global memory
in = in + blockIdx; out = out + blockIdx;
globalLoads(data, in, 64); // coalesced global reads
fftRadix16Pass(data); // in-place radix-16 pass
twiddleFactorMul(data, tid, 1024, 0);
// local shuffle using local memory
localShuffle(data, sMemx, sMemy, tid, (((tid & 15) * 65) + (tid >> 4)));
fftRadix16Pass(data); // in-place radix-16 pass
twiddleFactorMul(data, tid, 64, 4); // twiddle factor multiplication
localShuffle(data, sMemx, sMemy, tid, (((tid >> 4) * 64) + (tid & 15)));
// four radix-4 function calls
fftRadix4Pass(data); // radix-4 function number 1
fftRadix4Pass(data + 4); // radix-4 function number 2
fftRadix4Pass(data + 8); // radix-4 function number 3
fftRadix4Pass(data + 12); // radix-4 function number 4
// coalesced global writes
globalStores(data, out, 64);
}A ketto kozotti tavolsagot a hardveres es szoftveres kornyezet adja. Valojaban en nem akarok tobbet, mint amit a fentebbi keplet mond, azert vagyok kenytelen ilyen bobeszeduen irni dolgokat, mert egyelore nem eleg okos az absztrakcios reteg a gep es koztem.
Valojaban mindenkinek jobb lenne, ha eleg lenne a fenti kepletet hasznalni, mert extra idot es mentalis energiat visz el az, hogy a feladat helyett az implementaciora kell koncentralni.
Van egy magyar fejlesztocsapat, akik ugy nyernek tokjo palyazatokat, hogy a kodjuk kb. 5x lassabb, mint a tobbieke (jo okuk van ra, nem az, hogy hulladek kodot irnak, esetleg privatban reszletezem). Viszont 10x gyorsabban megcsinaljak, vesznek 5x annyi hardvert, es igy is sokkal-sokkal gazdasagosabban mukodnek, mint a tobbiek. Ez nekem szimpatikus: a feladatot megoldjak, csak emberi eroforrasok helyett az olcsobb gepi eroforrasokat hasznaljak. Neha ez persze nem opcio.
-
orbano
félisten
persze, vannak ilyenek, nyilván mindenki azt tartja a legf*szábbnak és legszükségesebbnek, amihez ért
Mondjuk én ir régi motoros vagyok és C++ vonalon kezdtem, de mára nem különösebben zavar, hogy nincs a repertoáromban az agyonhekkelt überoptimalizált kód készítésének a képessége. fontosabbnak tartom a jó algoritmusok és az azokhoz illő adatszerkezetek megtervezését (mondjuk itt be tud jönni a hw architektúra a képbe, de csak mértékkel)..NET: igen lehet, de nagyon kell ismerni a CLR fordítóját, sok hekkelés, disassembly, memory dump nézegetés, miegymás. nem éri meg. vagy legalábbis nagyon rika esetben tudom elképzelni. GPU programozás esetében pedig kötelező ismerni a GPU-t bizonyos fokig (a feladatok ütemezése a számolókon, cache/puffer méretek fontosak, ezek nélkül nem lehet értelmesen megszervezni a párhuzamosítást, de ennél lejjebb nem tudom, hogy mikor van értelme, ennyit nem foglalkoztam a témával).
-
dezz
nagyúr
Szerintem sok régi mororos is hasonlóképpen vélekedik, akik megmaradtak a C/C++-nál és esetleg vannak ASM-es tapasztalataik is. Ez olyan macsó dolog.
Egyébként .NET-ben számít valamit a HW valamelyes ismerete? Mármint, tudhat úgy valaki optimálisabb kódot írni benne? Vagy pl. OpenCL-ben (ha valaki ismeri itt behatóbban)?
-
orbano
félisten
azért jellemző, hogy egy bizonyos programozói élettapasztalat és rálátási szint alatt gondolja azt egy programozó, hogy az a tuti, ha valaki mindent saját maga vs. pure metal tud megoldani. rendszerint pont azért, mert valós programozási feladattal nem találkozott, csak beadandókat írt és hobbiprojekteket, ahol lehet tényleg egyszerűbb egy bizonyos szintig megkerülni az APIk megtanulását és mindenből sajátot írni, stb. Ez nem kritika amúgy, csak egy megfigyelés
-
Ok, a szemelyes preferencia tok mas kerdes, mint az, hogy nem vesszuk komolyan azokat, akik mashoz ertenek. Peldaul en nem szeretek GUI-t programozni, de ezzel egyutt latom, hogy a modern GUI fejlesztes valami irtozatosan bonyolult dolog, es verprofinak kell lenni ahhoz, hogy ne omoljon ossze a rendszer a sajat sulya alatt.
> ugyanúgy profinak (és kreatívnak) kell lenni hozzá, mint bármi más nyelvben lekódolni valami összetettebb dolgot.
Na, eljutottunk oda, hogy azt mondod, hogy igazan jo low-level programozonak lenni ugyanugy komoly melo, mint barmely mas nyelvben programozni. En ezzel total egyetertek, merthat ez eleg messze van a kiindulasi ponttol, miszerint csakis a low-level szakertelemmel egyutt lehet valaki komoly
-
dezz
nagyúr
Jó, akkor nem kicsit.
Megjegyzem, attól, hogy így vélekedik, még lehet, hogy tud programozni, akár jól is, csak úgymond régi vágású. Nem kedveli a hw-től nagyon elrugaszkodott dolgokat. (Én se nagyon.)Na igen, ASM-ben is lehet vacak programot írni, az nem nagy kunszt (de legalább felesleges). Azonban komplikáltabb rutinokat/függvényeket úgy megírni, hogy az még igen jól is fut, nem könnyű dolog és ugyanúgy profinak (és kreatívnak) kell lenni hozzá, mint bármi más nyelvben lekódolni valami összetettebb dolgot. Az is igaz, hogy ma már nem érthet mindenki minden területhez.
(A munkámnak csak egy kisebb része a uC, van itt FPGA is, jócskán "kibélelve", meg ami még kell egy komplett feladatorientált panelhez. De kódoltam már különféle OS-ek alatt, többnyire C-ben. Volt >20e soros ASM is [amiből kb. 100 volt adat], mert akkor még sokkal lassabb lett volna C-ben.)
-
Fiery
veterán
"es pont az mondom, hogy ezek ma mar akkora teruletek, hogy legritkabb esetben erthet valaki sokhoz egyszerre, illetve minden teruletnek megvannak a maga autoritasai. A programozas mara nem egy konkret terulet, emiatt tok felesleges azt mondani, hogy mindenkepp erteni kell X reszehez, kulonben nem vagy komoly programozo."
+1
-
> valóban egy kicsit lebecsülte azokat
Az hangzott el, hogy ok nem komoly programozok. Kicsit?> Ha valami, akkor ez egy szép példája a szalmabáb-érvelésnek...
A vege termeszetesen ironikus(nak volt szanva), ne vedd magadra.> hogy te meg éppen őket becsülted le.
Jaj, dehogy.
A mikrokontrollerrel sincs semmi problema, az is egy szakma, en azt nem szeretem, amikor eluralkodik az a nezet, hogy minel alacsonyabb szinten van a kod, annal nehezebb/hardkorabb/profibb. Nem az, es pont az mondom, hogy ezek ma mar akkora teruletek, hogy legritkabb esetben erthet valaki sokhoz egyszerre, illetve minden teruletnek megvannak a maga autoritasai. A programozas mara nem egy konkret terulet, emiatt tok felesleges azt mondani, hogy mindenkepp erteni kell X reszehez, kulonben nem vagy komoly programozo.
-
dezz
nagyúr
Morgyi valóban egy kicsit lebecsülte azokat, akiknek nem a futásidőre való minél alaposabb optimalizálás (és az OS hülyeségeinek kikerülése, stb.) a specialitása. De, nekem erősen úgy tűnt, hogy te meg éppen őket becsülted le.
Szó szerint reagáltam arra, amit írtál. Ezzel nem a másik álláspontot védtem. Nem csak e két álláspont létezhet.
"Meg azert a rend kedveert valaki irja le, hogy a webprogramozas az nem komoly munka (hiszen mikrokontrollert hekkelni komolyabb, mint mondjuk egy Facebook-meretu rendszert egyben tartani), a menedzselt nyelvek hatulgombolosoknak vannak, ja, es persze csak a fizikai munka a valodi munka!"
Ha valami, akkor ez egy szép példája a szalmabáb-érvelésnek... Mert ilyet én nem írtam, éppen ellenkezőleg. És köszi, hogy most már az én munkámat is lebecsülted (mikrokontroller hekkelés), mellesleg az embedded terület szintén nem merül ki ebben.
-
> ugyanakkor azokat sem kell lebecsülni, akiknek ez a specialitása
Most nem ez tortent, hanem a forditottja, azokat becsultuk le, akiknek nem ez a specialitasa.
Akkor a kedvedert kifejtem a maradekot is, bar nem mintha arra valaszoltal volna, amit en irtam, hanem eleg szep szalmabab-erveles zajlott, de azert:
- igen, ASM-ben idonkent celszeru kodolni, bizonyos extrem ritka helyzetekben, ezen extrem ritka helyzetekben. Nyilvan ha valaki drivereket ir, akkor sem Javascriptben kodol.
- "JIT meg nem tudom, hogy jön ide" -- ugy jon ide, hogy a JIT kepes peldaul az aktualis hasznalati mintazatnak megfeleloen optimalizalni a gepi kodot
- a 'valo eletben' a teljesitmenyigenyes alkalmazasok fejlesztesenek legeslegutolso, es meglehetosen ritkan alkalmazott eleme az assembly kod irasa, mert ez eleg ritkan eri meg. (Tovabbra sem a GPU-driverfejlesztes es a videoenkoderek irasa a legjellemzobb nagy teljesitmenyt igenylo feladat, nyilvan a PH-n ez van szem elott, ettol meg nem ez a jellemzo). A 'teljesitmeny' definicioja is nyilvan sokfele. Regebben irtam parallelizalo posztkompilert -- volt benne rendes ASM kodolas? Nem. Novelte a teljesitmenyt? Persze. Ertelmes lett volna ASM-szinten foglalkozni a dologgal? Nem, mert nem 5% hanem 500% teljesitmenynoveles volt a cel.
- "Mellesleg a kettő nem zárja ki egymást, mármint hogy valaki mindkettőben jó legyen." Mint ahogy az sincs kizarva, hogy valaki Nobel-dijas fizikus es iro legyen egyszerre, elvileg. Gyakorlatban persze aki evtizedeket tolt gepi kod-optimalizalassal, az nem meglepo modon menetkozben nem lesz rendkivul tapasztalt mondjuk DSL-ek gyartasaban.
- "Ami továbbra sem merül ki abban, hogy" -- egy szoval sem irtam, hogy kimerul, olvast el megegyszer, hogy mit irtam (vagy ne olvasd el, tokmindegy)Szoval a lentebbi hozzaszolasban mondjuk a 'nem komoly programozo' olyan emberekre is vonatkozik, mint mondjuk Andrejs Hejslberg, Bruce Eckel, Martin Odersky, es meg sokan masok. Hat ha te ezt az allaspontot veded...
Meg azert a rend kedveert valaki irja le, hogy a webprogramozas az nem komoly munka (hiszen mikrokontrollert hekkelni komolyabb, mint mondjuk egy Facebook-meretu rendszert egyben tartani), a menedzselt nyelvek hatulgombolosoknak vannak, ja, es persze csak a fizikai munka a valodi munka! -
dezz
nagyúr
Nekem nem úgy tűnt, mintha azzal azonosítaná, hiszen így folytatódott a mondat: "hogy ismeri az OS minden nyűgjét baját, ha akarja meg is tudja kerülni, és emellett ismeri a vasat is amire fejleszt, és nem retten vissza egy kis ASM-től ha fontos a futásidő." És még ez sem teljesen, mert ugye csak itt kezdődik.
Persze ezzel sem kell feltétlen egyetérteni, mert enélkül is lehet meglehetősen komoly programokat írni (amik viszont nem feltétlen futnak a lehető leggyorsabban), ugyanakkor azokat sem kell lebecsülni, akiknek ez a specialitása. (Ami továbbra sem merül ki abban, hogy "tudja, hogy a az X assembly utasitas utan meg celszeru berakni ket NOP-ot, mert ugy az gyorsabb lesz". Az ASM kódolás nem is igazán vagy nem feltétlen erről szól.)
-
orbano
félisten
szerintem nem is mondtuk, hogy kizárná, inkább csak arra reflektáltunk, hogy " a komoly programozó nálam ott kezdődik, hogy ..."
ettől még egy adott architektúrára való optimalizálás egy fontos szakterület, de ezzel azonosítani a programozást, mint szakmát inkább a lelkes amatőrökre jellemző badarság -
dezz
nagyúr
Nos, én nem vagyok otthon x86/x64 ASM-ben (más platfomokon dolgozom, embedded, stb.), de amíg P.H. előkerül (már ha lesz kedve hozzászólni), aki igen, nos én annyit tennék hozzá, hogy a kézi optimalizálás is sokkal bonyolultabb annál, mint hogy "X assembly utasitas utan meg celszeru berakni ket NOP-ot". Már megbocsáss, de ilyet is az mond, aki meg ehhez nem sokat konyít. És igenis, meg lehet verni a fordítót is. Lehet, hogy nem a fordításban, de ASM-ben olyan dolgokat is meg lehet tenni, amit C/C++-ban nem. Pl. a x264 enkóder egyes részeit is ASM-ben írják. (A JIT meg nem tudom, hogy jön ide, az futásidőben helyettesíti be az X procis kódrészleteket az Y proci előre megírt, megfelelő kódrészleteivel.)
Amúgy nem is tudtam, hogy ilyen rivalizálás van a jó kóderek és a másfajta programozók között.
Mellesleg a kettő nem zárja ki egymást, mármint hogy valaki mindkettőben jó legyen. -
válasz
#32839680
#87
üzenetére
> gyors futásidő kritikus kódhoz ismeri kell nem csak az OS lelkivilágát hanem a vasat is, a komoly programozó nálam ott kezdődik, hogy ismeri az OS minden nyűgjét baját, ha akarja meg is tudja kerülni, és emellett ismeri a vasat is amire fejleszt, és nem retten vissza egy kis ASM-től ha fontos a futásidő.
Ezek olyan dolgok, amiket azok irnak, akik nem ertenek a programozashoz. A forditot nem fogod megverni, a JIT-et se.
Nem attol lesz valaki komoly programozo, hogy tudja, hogy a az X assembly utasitas utan meg celszeru berakni ket NOP-ot, mert ugy az gyorsabb lesz az Y architektura-specifikus dolog miatt. Az tudja ezeket, akik forditoprogramokat irnak, es egesz eletukben ezen torik a fejuket.
Nem attol lesz jo valaki jo novenytermeszto, hogy gyorsabban tud kapalni, mint egy kapalogep.
-
-
pakriksz
őstag
jobb azt úgy hagyni ahogy van: hogy az összes magot használHATja a program (ha tudja), így nem olyan csodás dolog nagyon ritka szükség hogy állítgatni kelljen, csak debugolásnál láttam szükségét főleg HT-nál.
Egyébként igaz hogy ha tudod hány szálon fut a program, és beállítod az affinitást annyi magra, akkor ki lehet iktatni a vindóz "egyenletes magmelegítő" ütemezését
-
pakriksz
őstag
válasz
#32839680
#87
üzenetére
nem mintha VM-es nyelveknél nem számítana az OS lelkivilága. Én Javazom, és azért ott is erősen számít, hogy a kevésbé közvetlen régi IO csomagokat használod, vagy az OS-hez közelebb álló nio-t, ami nem kicsit gyorsabb, na meg ugyanúgy előfordul hogy kicsit átrendezve a kódsorokat "ezt minek minden ciklusban kiszámolni, elég csak előtte egyszer", jelentősen gyorsul a dolog.
De a mai "profi" programozókat nem érdekli az optimalizáció, kedvenc mondatuk a "vegyél jobb gépet".
ASM viszont manapság már csak a megszállottak játéka
Bár úgy megnézés szintjén hogy valami kódsor mekkora ASM kódot generál jó dolog, mert azt látva jöhet ötlet amivel ASM-be írogatás nélkül is lehet optimalizálni a magasabb szintű kódot. -
pakriksz
őstag
válasz
#32839680
#85
üzenetére
Nem tudom ez hogy jön ide, a lényeg az hogy a windows magonkénti cpu használat infoja egy nulla, semmi, egy random grafikonnal egyenértékű.
"de akkor se hagyja az ütemező hogy totál rottyra tedd a gépet." rendes OS-é tényleg nem, windowsé viszont simán, annyira hogy még a grafikus felület is másodpercekig nem reagál, sőt még a task manager billentyűkombinációjára(ctrl.shift-esc) fél perc alatt reagál, mindezt 4 magos procin. Ezért veszélyes nagyobb 3ds max rendert úgy elindítani hogy nincs a max folyamat normál alattira priorizálva
-
pakriksz
őstag
Nem így van ez. A "profi" pc felhasználók nagy része igazi szakbarbár, a munkáján kívül semmihez sem ért, sok olyan profi programozót láttam már, akinek lila gőze nincs a hardverekről, a fotosopperek, és 3d modellezők pedig még rosszabb helyzetben vannak.
Ezt alátámasztja az is, hogy a "profi" felhasználóknál a Pentium 4 is nagyon népszerű volt, holott az egy dologban volt a leggyorsabb, a melegedésben
-
pakriksz
őstag
nincs értelme kitenni. A windows magonkénti cpu használat infoja valami random generált grafikon, köze nincs a valósághoz. (gondolom ezért is került ki ez a dolog a win 8 task manageréből)
Egyedül az összesített cpu használat info ér valamit.
Én összeraktam egy kis programot ami annyit csinál hogy 100%-ra terhel cpu magokat a megadott mennyiségű szálon. És 1 szálon elindítva 4 magos cpu-n rögtön kiírta hogy 25% összterhelés, és a grafikon azt mutatta hogy mindegyik mag 25% körül van terhelve. Ami egy marhaság, mert 1 szálon futott.Bár valaki említette, hogy talán a másodperc tört része alatt végigzongorázza az összes magon a folyamatot(és újra és újra), hogy egyenletesen melegedjen a cpu, de mivel egy időpillanatban 1 magon fut csak így az eredmény ugyan az. Talán ennek az átlagát írja ki a grafikonokban.
-
Cathulhu
addikt
Egyreszt sajnos igaz (mondjuk olyan kb 50-es mintanrol tudok nyilatkozni), masreszt ha megnezed arra reagaltam, hogy a megkerdezett programozo ismerosok 80%-a mit hasznal. Epp ezert lenyegtelen, hogy a cegnel ki vesz helyettuk, mivel otthoni hasznalatrol is beszelunk, es az meg teljesen nyilvanvalo, hogy a cegeknel a beszerzest nem is ok intezik.
-
-
-
MZperX75
addikt
Inkább a P4-el,volt versenytársa.
P3-at azt hiszem utcsót 1333Mhz-ig tólták ,de ettől függetlenül nem volt rossz.
Az első 1.4Ghz-es P4-ennél fényévvel jobbak voltak,inkább a későbbi sima Athlonokkal versenyzett,időben mindenképp.
At első1600+ athlonon P4-2000-el versenyzett teljesítményben 50%-al olcsóbban. -
dezz
nagyúr
Tudom és éppen azt írtam, hogy a Duron nagyon is jó volt. (Később a Sempronnal is hasonló volt a helyzet.) Az lehet, hogy a Coppermine alapú Celeron még jó volt, de a későbbiek (a Core2 alapúakig) sokkal jobban le voltak butítva (nehogy túl olcsón túl jó procihoz juttassa a felhasználót az Intel), egészen kicsi L2 volt, stb., azokat valóban Celeroncsnak hívták.
-
8th
addikt
Máshol már leírtam a véleményem a Kabini platformmal kapcsolatban. Nem írom le újra inkább linkelem. [link] és [link]
A PH-s és IPON-os fogyasztás mérésekből kiindulva azt mondom, hogy ha a fogyasztás a fontosabb szempontok egyike ne Kabini legyen. Annyi pénzből megáll egy hasonló fogyasztású ám sokkal erősebb mini-ITX alapú Haswell konfig is. Ha nem létszükséglet az ITX deszka akkor még sokkal olcsóbban is. Ha pedig tényleg a fogyasztásra hegyezzük ki a dolgot egyértelműen a Bay Trail-D a nyerő. CPU-ban és GPU-ban is gyengébb mint a Kabini de amire szánták arra hibátlan és félelmetesen keveset fogyaszt. És persze a passzív hűtés sem utolsó dolog.
-
Fiery
veterán
"ha fejlesztesre raknek ossze valakinek gepet, akkor annyit kellene csak csinalnom, hogy
a) kivalasztod a leheto leggyorsabb Intel CPU-t
b) beletolsz minel tobb RAM-ot
c) veszel egy SSD-tEs keszen vagy.
"+1. Annyit tennék még hozza, hogy azert sok esetben nem az abszolut ertekben leggyorsabb Intel CPU-t valasztja a programozo, hanem a leggyorsabb 4 magosat, ugyanis fejlesztesre a legritkabb esetben lesz gyorsabb egy HEDT (high-end desktop) kategoriaju, 6+ magos cucc (i7-4960X jelenleg), mint a leggyorsabb mainstream desktop platform (i7-4790 jelenleg). Plusz, az Intel utobbi par evere az volt a jellemzo, hogy a mainstream desktop/mobil platform mindig egy mag generacioval elorebb jart, es ezzel a legujabb x86 utasitaskeszlet kiegesziteseket is megkapta a fejleszto, ha nem a HEDT-t valasztotta. Jelenleg egy i7-4790-cel (Haswell) lehet AVX2-re es FMA-ra is fejleszteni, mig az aktualis HEDT platform (Ivy Bridge-E) erre nem alkalmas jelenleg. Az meg mar csak hab a tortan, hogy a mainstream platformban iGPU is van, ami sok fejlesztonek boven megfelel, nem kell videokartyat is pakolni mellé.
-
Bandi79
aktív tag
Gyors teszt eredmények:
- Sleeping dogs:
a 2-es magot 70 % körül hajtja, a többit 40 körül.- Amnesia Dark Descent:
1-es magot 60 %-on, 2-est 40 %-on, 3-ast 5 %-on, 4-es 25 %-on...- Skyrim
minden magot 50-60 %-on terhel, ez egyenletesnek tűnik.Hogy vmi valóban régebbit is nézzünk:
- Warcraft 3
2-es magot hajtja 30-40 %-on , a többi 0-10 %-on pihen.-Age of Empires Age of Kings:
4-es magot hajtja 70 % felett, 2-es néha besegít 25 %-ig, másik 2 5-10%-on figyel...Röviden: igazad van az asszimetrikus terhelést illetően
, de továbbra is fenntartom, hogy nekem a jelenlegi konfiggal inkább GPU-ra kell költenem és majd csak utána mobo+CPU. -
Fiery
veterán
Fantasztikus hozzaszolasok, rendkivul jol szorakozom
Elmondom, miert vesznek a profi PC felhasznalok (90+ %-ban) Intelt: mert _jelenleg_ az a leggyorsabb es pont. A hardver ára egy bizonyos szint felett nem tetel, ha a PC segitsegevel keresi az ember a kenyerét. Az Intel jobb egy szalon, jobb tobb szalon, az iGPU meg a legtobb profi felhasznalasnal nem szamit. Ha megis kell az eros GPU, akkor berak az ember egy jobbfajta videokartyat, es kesz. HEDT-ben mar nincs is ott az AMD, 1P/2P workstation vonalon szinten sehol nincsenek, sajnos, a szerverekrol nem is beszelve. Ahol eros az AMD (kozepes teljesitmenyu desktop PC, casual gaming APU-val, alacsonyfogyasztasu desktop es mobil), az pont nem a profi felhasznalas. Nem a gyartok tehetnek arrol, hogy mondjuk a Latitude-okbe vagy az EliteBookokba Intel procit raknak: erre van igeny, ezt keresik a vasarlok. Minek kinaljanak lassabb procival lassabb notebookot, ha egyszer ugyis mindenki a legjobbat keresi, nem pedig a legolcsobbat? -
-
-
szacsee
nagyúr
A kolléga nem biztos, hogy hülyeséget beszél. Az erőviszonyok amiket írtál jól írtad kb, viszont a kollégánál lehetett a hiba oka egy Via vagy Sis chipsetes alaplap is ami tudjuk, hogy nem fogyasztott annyit, mint az intel chip, de ellenben nem is ment.Ja hogy koléga gépe volt lassú, akkor a Gef MX440 DX 7.0-s VGA volt a 8500LE pedig DX 8.1 és emiatt lehet pár fícsör amit tudott az ATI bekapcsolva maradt, viszont lelassította játék alatt mert nem volt túl acélos HW.
Bocs, de lejárt a szerk limit.
Off vége.... -
szacsee
nagyúr
Mindkét oldalon voltak és lesznek is bakik az biztos, anno birsalmából x2-t raktam össze ismerősöknek és jöttek egy idő után, hogy újraindul a gép, ami attól volt, hogy auto feszen a terhelés hatására nőtt folyamatosan a Vcore, amint manuálisan beállítottam a VID-nél kisebb feszt jó is lett. Gondolom bios bug... bár egyik Asus másik pedig J&W deszka volt, de mindkettőben X2 4000+ lett bepakolva, azóta ha jól tudom nem fordult elő ilyesmi.
Mantle egy jó irány, viszont még kevés játék támogatja, amikkel én játszom pl egyik sem Mante API-t használ és nem is lesz portolva, viszont multizok ezért nem árt az erős proci sem. A játékokkal amikkel játszom hivatalos fórumon is intelt favorizálják, mert AMD-vel lassabb a játék, ami a fejlesztők hibája is lehet, de ez van ezért inkább Intelt vesznek ha nem akarják, hogy a VGA malmozzon az AMD proci mellett, vagy nem játszanak. Sok a laikus és OC-vel tudná csak utolérni egy 4-6 magos FX az i5-öt ebben a játékban amihez némi tapasztalat kell és egy nagyon jó hűtő, ezért inkább vesznek egy H81/B85-ös deszkát, egy I5-öt mellé (szorzózármentessel is elég szépen fut a játék) és ha hangos a gyári hűtő dobnak rá egy 4-5K-s hűtőt és kész.
Nem kell tuningolni, nem kell szöszölni és a pc-s játékosok többsége nyugaton nem fog babrálni amd-vel ha megveszi az intelt és piszkálás nélkül tudja az OC AMD proci teljesítményét... még ha 2-3 évente cseréli is a pc-t, mert nem ennyiből élnek meg mint mi és nem azon vitáznak, hogy az amd a jobb, vagy az intel, hanem azon, hogy az esti grillpartira mivel pácolják a húst.morgyiEzzel is egyet értek, gondolom PLC-ben nyomod (gyártósorból következtettem), viszont a_n_d_r_e_w amit leírt azzal is egyet kell értsek, mert sokan bemennek a boltba és vesznek egy lapost, aztán mikor valami nem kóser akkor jönnek kérdezni, hogy mi a fene van a géppel...
Sokféle ember van még ez a szerencse így nem mindenki vágja a HW világát, mert elég gyorsan változik.
AMD-től is volt pár gépem és Inteltől is8th: 8-9K egy HDMI-s ITX deszka, ez intelnél még sajnos drága, hacsak nem pl asrock H61MV-ITX-et veszek, de az is 13K, emellé még a proci, de Ivy-re már nem akarok beruházni, LGA1150-ből pedig ITX HDMI-s deszka és G3240 (jóféle pasztás), vagy G3220 is 14-15K.
-
joysefke
veterán
A kolléga hülyeséget beszél, de Te is el vagy tévedve Dezz, az első (Spitfire) Duronok (2000 környéke) a Thunderbird (Socket A Athlon) butításai voltak, ez a butítás akkoriban annyiban merült ki, hogy kevesebb cache volt a prociban, illetve alacsonyabb órajellel jöttek ki a Duronok mint a csúcs Thunderbird-ek. C2C minimális eltérés volt a két processzor között, az is inkább professzionális használat során. Játékban a Thunderbird csupán órajelelőnyére támaszkodhatott, azonban az sem volt jelentős a Duronhoz képest. Nekem akkoriban volt 750-es Duronom illetve később 1200-as (kályha Thunderbird) Athlonom.
A kortárs Coppermine Pentium III- Celeron viszony akkoriban kb ugyanez volt pepitában, talán annyi különbséggel, hogy ott még az FSB is alacsonyabb órajelen futott (PIII ból ugye volt akkoriban E/EB változat, utalva az FSB sebességre) Az akkori Celeronok éppenséggel elég jók volak, nem volt olyan nagy a lemaradás a csúcs PIII-hoz képest. Celeroncsnak hívni egy Coppermine Celeront éppen ezért elég viccesen hangzik.
Az erőviszonyok pedig akkoriban (játék szempontjából) így néztek ki: Celeron < Duron < PIII <= Thundberbird.
A Thunderbird nem volt lassabb a PIII-nál illetve a Duron a Celeronnál gyorsabb volt.
Ezeket az erőviszonyokat a Tualatin magos PIII sem tudta megtörni, kicsit később pedig már jött az Athlon XP (SSE-vel), illetve a P4 Willamette... Utánna a Northwooddal elkezdett elhúzni az Intel, de ez már egy másik sztori
Uff
J. -
Cathulhu
addikt
Latom magadra vetted, de nem tudom miert... Nem az AMD vs Intel vitahoz kivantam hozzaszolni, azert is raktam offba, csak egyszeruen arra probaltam ravilagitani, hogy attol, hogy valaki programozo, meg kozel sem biztos, hogy relevans a velemenye.
Ugyanakkor pl 40e Ft-os CPU kategoriaban en tuti, hogy nem intelt valasztanek, szoval mar nem igaz az elso allitasod, de mindegy, hagyjuk. A vegere meg annyit, hogy ezt pl egy atlag programozo nem tudja, akirol meg en beszelek, ennel sokkal tobbet is, szoval lehet bagatelizalni a dolgokat, csak halal folosleges. -
Az Intel CPU-k kb. azota jobbak fejlesztesre, miota vilag a vilag. Engem speciel nagyon erdekel a HW, de ha fejlesztesre raknek ossze valakinek gepet, akkor annyit kellene csak csinalnom, hogy
a) kivalasztod a leheto leggyorsabb Intel CPU-t
b) beletolsz minel tobb RAM-ot
c) veszel egy SSD-tEs keszen vagy.
Laptopbol meg vagy Macbook Pro-t vesznek, vagy Thinkpadet es kesz.
Ja, es tudni, hogy epp mi a leggyorsabb AMD GPU vagy SSD az csoppet sem hozzaertes, ehhez eleg egy altalanos iskola meg az, hogy sokat olvass netes forumokat. Szoval ehhez nem kell esz.
-
Cathulhu
addikt
Nah a programozokat hagyjuk, joparat ismerek (kollegak
), koztuk hihetetlen tehetsegeseket is, szoval nem az egyetemrol kiszort hulladekrol beszelek, de hardverhez olyan sikhulyek, hogy rossz nezni. Kb 10%-uk, aki meg tudja mondani mi a kulonbseg ket proceszor kozott, egy rendes laptopot nem tudnak kivalasztani szakerto segitseg nelkul (okostelefonrol mar nem is beszelek, az fekete doboz majdnem mindnek), es aki gamer kiskockakent kezdte a 90-es evekben az meg megragadt az intel+nvidia kombonal, es el sem tudja kepzelni, hogy van mas. Szoval annal a programozonal, aki nem hardverkozeli dolgokat csinal, vagy epp nem hobbija a hardver (mint nekem), annal egy muerto kamionos is nagyobb ralatassal bir a dolgokra (olyat is ismerek ) -
pakriksz
őstag
attól hogy 50% alatt van a cpu használat az nem azt jelenti hogy gpu korlátos, hanem gyakran azt hogy a játék erősen asszimmetrikus cpu terhelést generál az 1 szálon futó render threadjával (ami miatt kellenének az új grafikus API-k, és ezt a problémát akarja kilőni a mantle), így egy mag 100% megy (és ez limitel), a többi meg tizen huszon százalékos terhelésen.
Az ősrégi teljesen 1 szálú játékoknál is 25% a cpu terhelés: 1 mag dolgozik, a többi malmozik -
8th
addikt
"Öcsinek egy AM1-es deszkát fogok összerakni, mert a jelenlegi intel procijánál erősebb és kevesebbet fogyaszt (első generációs i3)"
Én az AM1 vásárlást meggondolnám még egyszer. Egy Haswell cerka gyakorlatilag ugyanannyit eszik mint az Athlon 5350. Az AM1 fejleszthetőség szempontjából totál zsákutca és bár a fogyasztása nem rossz de nem is kiemelkedően jó.
-
SylverR
senior tag
Ahhoz képest tényleg jó volt.
Csak azért írtam amit írtam, mert volt egy Duron alapú gép a kezem alatt, amiben aztán procit újítottam, 1700-es Athlon XP-re. Bátyámnak meg közben úgy emlékszem, hogy volt egy 1 ghz-es Celeronja. VGA terén a Cerka alatt egy GF2Mx440 volt, míg enyémben 8500LE. Amit láttam, az az volt, hogy az ő gépén jóformán minden játék folyamatosan futott. Nálam viszont alacsony framerate volt a jellemző.
Aztán pedig tesztekből kiderült, hogy a P4-esek javarésze azért csúnyán alázta a 2400+ alatti Athlon XP-ket. -
-
dezz
nagyúr
Fordításnál számít az egyszálas teljesítmény, amiben mostanában az Intel a jobb (a fogyasztás mellett). Munkaeszköznél (és/vagy mert egy programozónak általában telik rá) nem a legfőbb tényező az ár sem.
De azért van még sokaknál egy jó adag előítélet is ("az AMD megbízhatatlan, fagy, elfüstöl", stb.). Az első x86 procim AMD volt, de utána jó ideig Intel, mert az számított az eredeti jó procinak, az AMD "csak gyenge utánzat", az említett tulajdonságokkal - pedig akkor ezek már rég nem voltak igazak.
Volt egyébként olyan OEM, ami az AMD-s gépein letiltotta a BIOS-ban az UltraDMA-t (talán mert egyszer valamilyen AMD-hez való chipsettel valami problémájuk volt és/vagy valami más megfontolásból, vagy inkább megszámolásból [$]), amitől aztán CPU erő ide vagy oda (K7/K8 korszak) nehézkesebbé vált a gép a hétköznapi használatban.
-
SylverR
senior tag
Mikor régen, két program-kód közt akár 200% különbség is lehetett pozitív irányba, ma viszont inkább csak negatív irányba "javul" a teljesítmény, és alig 40%-okról beszélünk, a programozók véleményére támaszkodni szerintem naivitás.
Ahogy mondod, valószínűleg megszokásból nem váltanak. A nagy cégek gépújításkor fellépő választás oka pedig az Intel által adott nagymértékű kedvezményekben keresendő.
A régi korokban - Duron, első verziójú Athlon, és talán még az Athlon XP-k is - tény és való, hogy nagyon alul maradt az AMD teljesítményben. De ez a Stars processzor család óta megváltozott. A programozók is haladhatnának a korral. Célozva itt most főleg az APU-kra.Nekem egy Trinity-m van perpill, és amióta megvan, még egyszer nem futottam bele olyan esetbe, hogy a proci magoknak akár csak a fele kilett volna 100%-on pörgetve. Természetesen nem professzionális alkalmazásokat futtatok, de egy-két progi amivel szórakoztam igencsak procizabáló. Mégis futnak gond nélkül.
Tehát: -> átlag felhasználás esetén a Steamroller modul bőven jó. Cégekhez, irodai munkára, egy A4-es rendszer bőven megteszi, és még olcsó is. Ha meg kell az erő, akkor A10, vagy kis proci + dvga.
Vagy ha olyan nagy powa kell, akkor ott vannak a Firepro-k, esetleg a szuperszámítógépek. -
szacsee
nagyúr
válasz
atti_2010
#49
üzenetére
Ezzel teljesen egyet értek, mivel a pénz általában az egyik fő szempont vásárláskor és én is ha valaki segítséget kér inkább erősebb VGA és gyengébb procit ajánlok, mivel jobban profitál abból, ha CPU limit miatt néhol leesik az FPS-e mint ha VGA limit miatt erős procival fele annyi sincs, mint előző esetben.
SylverR:
Beszélgettem pár programozóval, kb 80%-uk intelt használ, ez lehet megszokás, vagy "téves" megítélés is nem tudom, a maradék 20%-ról viszont tudom, hogy AMD fanok, mert AMD-s gépet raknak össze ha valaki hozzájuk fordul segítségért.
Rendszergazdáknál szerintem fő szempont az adatokkal való hókuszpók, ami valljuk be AM3 óta csak FM2+ és tsai-n tud felmutatni hasonlót mint az intel, FX pedig egy kazán és a másik nem elhanyagolható ok, hogy sok cég még a mai napig egybe OEM gépeket vesz és ott elég nagy az intel fölény ami a kínálatot illeti. (nem szerverekről beszélek)
Ha pedig egy nagyobb cég pl gépparkot újít, akkor akár több 1000 gép vásárlásával támogathatja akármelyik gyártót, de a kínálatot tekintve általában intelt vesznek.
Otthonra más a helyzet, persze szokásoktól is nagyban függ. -
atti_2010
nagyúr
Azért tesztelnek Intel CPU-val mert az a legerősebb és ezt nem is vitatta senki de nem biztos hogy mindenkinek szüksége is van rá, márpedig egy R9-270 270X -ig nyugodtan elvannak a VGA-k egy FX-Phenom CPU-val is, akinek ez megér egy + költséget az megveszi de nem létszükséglet, hogy itt a forumon sokan megteszik az egy dolog de a tapasztalat azt mutatja hogy sokan mar egy X4 Phenomot is nehezen vesznek meg.
-
szacsee
nagyúr
válasz
atti_2010
#41
üzenetére
Ezt majd kicsit tolmácsolhatnád nyugatra is, hátha ott hallgatnának rád.
Csúcs VGA tesztekben miért mindig Intelt használnak pl? ... gondolom mert a Llano is kihajcsajé
Pár kérdés, ha ennyire frankó az AMD CPU része:
A pc-vel üzletszerűen foglalkozók többsége miért intelt használ? (programozók, rendszergazdák, tervezők)
Játékban VGA limitnél és esetleg magasabb felbontásban CPU erőben nincs nagy eltérés AMD és intel közt dVGA használata mellett (Llano vs i3 pl), de sok helyen láttam, hogy a legkisebb i3 is elgyepálja az AMD-t... nemcsak játékokban. de itt egy példa FHD-nál
Rég leszoktam arról, hogy AMD-s topikban megyek és osztom az észt, mert nincs értelme, kb annyi, hogy a ferrari-val nem lehet szántani, a traktorral meg nem lehet 300km/h-val tekerni.
AMD nagyon jó dolgokat csinál ami az integrált grafikát és a fúziót illeti, demég nincs itt az ideje, illetve én személy szerint a saját felhasználási körömben nem látom értelmét a váltásnak.
Drukkolok, hogy x86 CPU erőben is összeszedje magát, de már nem fogja, mert más a csapásirány.
Jelen állás szerint egy 40K-s APU és egy 15K-s deszka elég sok annak tükrében, hogy 12-13K-ért H81-et, vagy AM1-es deszkát kapni és hozzá 13-15K-ért G-s pentiumot vagy 5350-es Athlont, amihez vesz a manus a maradék pénzen egy 260X-es radeont és pénzben ugyanott van (12k-s deszka 12k-s procit nézve és ~30K-s VGA-t), de nem függ a ram sebességtől, ezért ezen spórolhat, illetve játékokban is jobb az APU+lap-nál és más alkalmazásban sem fog hátrányt szenvedni.
Csúszik a Broadwell.... na és van konkurencia? Nincs, akkor miért kell leállni minden intel topikban?
Ha kihagyna egy 2 éves ciklust a kék óriás akkor sem lenne semmi, mert CPU erőben van hova fejlődni a zöldeknek. A consumer játékosok fele már tableten, vagy konzolon nyomja, a többség pedig nem fog váltani, ha kijön egy APU, max ha lehal a gépe. A HC gammerek pedig intelt vesznek, kivéve az AMD fanok.
Öcsinek egy AM1-es deszkát fogok összerakni, mert a jelenlegi intel procijánál erősebb és kevesebbet fogyaszt (első generációs i3), mellette AMD VGA-m van, és pár ismerősnek is AMD APU-t ajánlok, ahol pl HTPC szerepét tölti be a gép, de tisztában vagyok a határokkal és nem erőltetem, ha nem alkalmas a feladatra. Peace, nem kötekedni szeretnék abszolút, de ha nincs teljesítmény speckó (cikkben szereplő broadwellről), vagy legalább valami adat amiből lehetne következtetni rá, akkor hogy jön ide a Llano és az, hogy milyen frankó az AMD?... nem látom az összefüggést. -
oliba
őstag
válasz
atti_2010
#25
üzenetére
3,6GHz-es Phenom II X4-esem sírt az olyan alapvető játékokban, mint a Hard Reset, ahol a boss harcot élvezhettem 20-25FPS-sel, míg a Witcher 2-nél is sokszor volt durva CPU limit és ekkor volt 25-30FPS-em. Risen 2-t inkább nem is toltam a durva microlag miatt. Kb minden második játék, amit toltam, az CPU limites volt. Nem játszok AAA játékokkal, inkább a kisebb címekkel. Semmit sem ér ott a Llano, az X4-gyel és az egész APU-val együtt. Teszem hozzá, hogy mindez 7770-es kártya mellett...
-
joysefke
veterán
Itt egy mérés a való életből, a játék pedig a listámon van:
http://logout.hu/cikk/the_bureau_xcom_declassified/hardverteszt.html
Mint említettem, az SC2 is meg tudja izzasztani a procimat, a minnél magasabb egyszálas sebességet szereti..
Ha kiadok 200-250E Forintot egy kifejezetten játék PC-re, akkor ne azon a 15E forinton múljon (38E volt a 3550), hogy néha még éppen játszható egy-két helyszínen a játék, vagy már éppen játszhatatlan...
J. -
Bandi79
aktív tag
Nono, "csak" 60 %-kal gyorsabb a 3550 mint a 750
Nem FPS-esekkel játszok (Crysis, BF és társai engem hidegen hagynak)
Sleeping dogs, Saints Row IV, CIV4, Skyrim (nem szétmoddolva, persze) , Amnesia Dark Descent (
![;]](//cdn.rios.hu/dl/s/v1.gif)
)... Ezek szépen elfutnak i5 750-nel is 50% alatti CPU kihasználtsággal. Ezekben mind GPU limitem van, ami persze nem meglepő egy HD 5850-nel...Itt egy jó kis cikk, mennyire nem számít már a CPU erő ha játékokról beszélünk:
http://www.techbuyersguru.com/i5CPUshootout2.php
"for real people spending real hard-earned cash, this is a vivid illustration of why CPU power really takes a back seat to video card prowess when it comes to games."
-
#36
Fiery
veterán
szabi__memo
#34
Fiery
veterán
válasz
szabi__memo
#34
üzenetére
Iden nyarra terveztek, de szerintem legjobb esetben is karacsony kornyekere csuszik.
-
Fiery
veterán
Ugy ertettem a masfel-ket evet, hogy eddig az volt a jellemzo, hogy a teljes mainstream desktop + mainstream mobil vonal egyszerre lett lecserelve, ahogy irod is, kb. 12-14 honapos terkozokkel. Igen, mostanra kellene kijonnie a kereskedelmi forgalomba a Broadwellnek, de ha ez csupan fel evet is kesik, es karacsonyig kijonnek a Broadwell-ULT es Broadwell-ULX (2 magos, 15W alatt TDP-ju, ultrabookokba es tabletekbe szant) variansok, azzal me'g mindig nem lesz lecserelve a mainstream desktop vonal es a mobil vonal jo resze sem, csupan a MacBook Air es tarsai meg a tabletek kapnak friss procit. Jellen allas szerint jovore jon csak a desktopra a Broadwell, valamilyen formaban (pl. Broadwell-K), a mainstream mobil szegmensbe pedig lehet hogy mar nem is jon Broadwell, hanem majd csak a Skylake. Mire minden le lenne cserelve Broadwellre, az eredeti tick-tock szerint minimum 1 eves kesesben lenne az Intel a sajat -- mostanra mar egyertelmuen fenntarthatatlan -- utitervei szerint
-
#34
szabi__memo
nagyúr
Balala2007
#31
szabi__memo
nagyúr
válasz
Balala2007
#31
üzenetére
Ezekből mikkora várható termék, tudja vki?
-
Fiery
veterán
"Ezért - ezt többször említettem korábban - érthetetlen és megalapozatlan a kb. 10 éve indított 2 évenkénti csíkszélességváltási stratégia fenntartása"
Ez abszolut igaz, a PC-piac szukulese nelkul sem lehetne mostanra mar fenntartani ezt a lepest, plane hogy a konkurencia sem indokolja az elore menekulest.
-
-
P.H.
senior tag
Az valahogy mindig kimarad a számításból, hogy egy adott gyártástechnológiába fektetett dollármilliárdok csak annak megfelelő mennyiségű legyártott és értékesített chipből térülnek meg; illetve minél több - és egyre több - pénzbe kerül egy csíkszélességváltás, annál több wafer-t kell legyártani, hogy megtérüljön.
Ezért - ezt többször említettem korábban - érthetetlen és megalapozatlan a kb. 10 éve indított 2 évenkénti csíkszélességváltási stratégia fenntartása, hiszen ez csak egy folyamatosan és előre kiszámíthatóan bővülő piacon lenne fenntartható, ami nem igazán jellemzi több éve már a PC-piacot. A szerver-terület ezt akár felhúzhatta és rentábilissá tehette idáig az x86 térnyerésével, de ha annak növekedési üteme is csökken, akkor nyilvánvalóan a legegyszerűbb ellenlépés az adott (most a 22 nm-es) technológia 2 évnél további fenntartása. Másik lépés lehet(ne) további területekre terjeszkedés (bérgyártás, telefónia/Quark), de ezek inkább csak felfutóban vannak.SZVSZ semmi köze nincs a Kaverinek és az AMD lépéseinek ehhez a "csúszáshoz", még talán a 14 nm problémáinak se, a legésszerűbb érv az lehet, hogy egyszerűen a tick-tock jelenleg nem rentábilis, a 22 nm nem termelte még vissza a befektetett költségek melletti elvárt hasznot.
-
Fiery
veterán
A problemas gyartastechnologia nem indokol cca. masfel-ket ev csuszast
Ebben boven van szandekossag is. Plusz, ha valamennyire mukodik a 14 nano, akkor el lehetne kezdeni kisszeriaban nyomni az egyszerubb Broadwell magokat (ahogy irod is), demonstralando, hogy mukodik a cucc, nem kesik tulajdonkeppen. De latszolag nem sietik el a dolgot. Lehet persze, hogy _annyira_ sz*rul megy a 14 nano, hogy egyaltalan nem tudnak semmi hasznalhatot gyartani -- bar, ennek meg ellentmond, hogy eleg sok Broadwell sample kering mar a vilagban honapok ota."Ettől függetlenül szerintem az nagyobb szükségük lenne van a Cherry Trail Atomokra, mint a Broadwellre"
Ebben abszolut egyetertunk.
-
Fiery
veterán
En arra celoztam, hogy ha a Kaveri erosebb szereplo lenne a mainstream desktop piacon, es a mainstream mobil piacon egyaltalan szereplo lenne (mostanra), akkor az Intel sem erne ra annyira, hogy ide-oda tologassa a Broadwellt es/vagy a Skylake-et. Ha mar a Trinity vagy a Richland is jobbra sikeredett volna, akkor a Haswell Refresh-t sem huzta volna elo a kalapbol az Intel. A tick-tock-ba marhara nem illeszkedik a Haswell Refresh, nyilvanvaloan azert dobta be az Intel, mert nincs ertelme rohanni a folyamatos core valtasokkal; es plane nincs ertelme rohanni a csikszelesseg valtasokkal. Ebbe a vonulatba illeszkedik sajnos a Kaveri is, ami meg a Broadwellt tolta arrebb. Lehet ezt egyfajta Intel presztizs vesztesegkent is elkonyvelni, de a piac nem a presztizsbol taplalkozik, legalabbis a tomegtermekeknel semmikepp (nem a Bentley piaca ez). Plusz, az elso es legnagyobb presztizs veszteseg nem az Intelnel keletkezett, ugyebar, gondoljunk csak a Kaverira meg az FX- es a nagyteljesitmenyu Opteron vonal sullyedo hajojat elhagyo AMD-re
Az OpenCL 2.0-t pedig azert hoztam fel, mert a Kaveri egyetlen eselye az lehetne, az menthetne meg, ha az iGPU szamitasi teljesitmenyet altalanosan sok-sok szoftver is ki tudná hasznalni. Amig ez nem tortenik meg, addig egy eleve (a Haswellhez kepest) eroteljes lemaradasbol indulo CPU-vonal (Trinity/Richland) alacsonyabb orajelu, de kicsit fejlesztett utoda a Kaveri, nem tobb annal. A Kaveriban valoban van potencial, ezt a JPEG Decoder es a LibreOffice Calc is remekul demonstralja, csak epp az a gond, hogy ezt a potencialt ki is kellene szeleskoruen aknazni ahhoz, hogy a Kaveri felnojon a Haswellhez.
Nyilvan ha az OpenCL 2.0 es a HSA vegre tenyleg elkeszul (mert hogy me'g mindig nincs stabil OpenCL 2.0 implementacio, se az AMD-tol, se mastol, a HSA-rol meg ne is beszeljunk), es vegre elkezdenek mozgolodni a fejlesztok is, es csak kapkodjuk a fejunket a szebbnel szebb benchmark eredmenyeken, akkor az Intel is ossze fogja kapni magat. Addig meg az eroforrasaikat inkabb -- okosan -- arra forditjak, hogy optimalizaljak a 14 nanos gyartast, optimalizaljak a Broadwellt magat, meg persze dolgoznak a Skylake-en is kozben. Nincs miert kapkodniuk.
-
joysefke
veterán
válasz
atti_2010
#25
üzenetére
Rég játszottam vele, de mondjuk a SC2-ben /virágbolti/ volt: fullos (200 supply) seregek találkozásakor elfogyott a CPU.
SC2-t leszámítva is gyakran látok nagyon magac CPU utilization értékeket: Crysis 2 single , BF3 multi /mindkettő eredeti, legfrissebb/ amire most így emélkszem.
Ha Neked nem sikerült a Llano-(CPU)-t megfingatni, akkor feltételezem, olyan beállításokkal játszottál, vagy egyszerűen nem veszed észre (ami persze nem probléma), hogy masszív CPU bottleneck van, ami mondjuk mikrolaggban nyilvánulhat meg...
Külön érdekes, mert az AMD közép és felsőkategóriás VGA-i kevésbé tolerálják a gyenge processzort, mint a konkurencia. (SC2-ben, én akkoriban GTX660OC-t hajtottam az i5 mellett).
J.
-
atti_2010
nagyúr
Kíváncsi lennék milyen single player játék akaszt meg egy 4 magos CPU-t, a Crysis3 és a BF4 sem igazán tudta megakasztani a nem túl acélos Llano CPU-t, egyedül a Crysis akadt bele (ami 1 magot használ) olyan módon hogy nem 45 FPS volt hanem csak 40, de itt sem a CPU vetett véget a FPS hajhászásnak hanem a GPU.
Nxn908xxx Le kellene bizony de ezt a gyártók nem fogják egyhamar meglépni, szerintem még megszenvedik a 10nm aluli rétegeket és majd valamikor 2020 környékén kidobják a jelenlegi berendezést, ez csak az én véleményem.
-
Nxn908xxx
őstag
válasz
atti_2010
#19
üzenetére
Vagy le kell váltani a szilíciumot.
Egyébként szerintem nem ekkora tragédia hogy nem jönnek a felsőbb kategóriás modellek.(Nem mintha vettem volna.
) Egy kétmagoson is meg lehet nézni a core2core fejlődést a Haswellhez képest. Ha meg nem olyan nagy az előrelépés akkor a HW tulajok megnyugodhatnak. Másban nem fog változni az IGP-t leszámítva, de gondolom nem sokan használnák. -
-
#18
FIREBLADE78
addikt
FIREBLADE78
addikt
hú de jó,hogy nem vártam a mac vásárlással tovább
-
Oliverda
félisten
Az Intelt korábban sem nagyon érdekelte, hogy mi van a konkurenciával. A Core 2 Quad és a Nehalem sem állt a szekrényben csak azért, mert épp nem volt konkurensük.
Saját bevallásuk szerint is problémás a 14 nm-es gyártástechnológia:
Már 2012 végén lehetett hallani pletykákat arról, hogy komoly gond van, és lehet újra kell tervezni a 1272-es processt. Esélyes, hogy még mindig nem túl jó a kihozatal, így inkább a kisebb, kétmagos lapkákat fogják gyártani, hogy kevesebb legyen a selejt. A TSMC által gyártott GPU-k esetében is ez a bevett gyakorlat, amennyiben problémás az adott gyártástechnológia.
Ettől függetlenül szerintem az nagyobb szükségük lenne van a Cherry Trail Atomokra, mint a Broadwellre.
-
#12
oraihunter
aktív tag
oraihunter
aktív tag
"az Intel kategóriától függően nagyjából 4-10 hónapot csúszik"
Milyen meglepő!
-
Bandi79
aktív tag
mivel főleg játékra használom a gépet,és a CPU erő egyre kevésbbé tűnik fontosnak Mantle / DX 12 miatt, (legalábbis single playerben, 1 VGA-val, full HD-ban), ezért inkább GPU-ra koncentrálom a rendelkezésre álló anyagi javakat
Várom az új generációs AMD / NVidia karikat, HD 5850 már túl lassú ahhoz képest, amennyi hőt + zajt termel
I5 750-et se nagyon izzasztotta meg eddig GTA4-en kívül semmi (emiatt a játék miatt dobtam ki anno a széria coolert és húztam fel 3,6 GHz-re = + 10 min fps
) -
-
Fiery
veterán
Igy van. Hova sietni? Se a Kaveri maga nem sikerult tul jol, se az optimalis mukodesehez szukseges szoftverek nincsenek keszen, raadasul a mobil piacra szant verziok me'g mindig nem kaphatoak. Egy ilyen Kaveri elleneben felesleges a Broadwellt sietosen piacra dobni, nincs ertelme, a Haswell is jol elmuzsikal. Szomoru, de ez van... Engem inkabb az bosszant, hogy ezzel a Skylake-et is arrebb tolta az Intel
A prescott meg... agyhalál, a világ talán leggagyibb processzora.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)... Ezek szépen elfutnak i5 750-nel is 50% alatti CPU kihasználtsággal. Ezekben mind GPU limitem van, ami persze nem meglepő egy HD 5850-nel...
Akkor nem fogok várni rá, az év vége az talán, de inkább lecsapok egy i5-4670K-ra...
Sebaj addig is hajtom az i5 4690-et Új hozzászólás Aktív témák
- Xiaomi Redmi Note 14 5G / 8/256GB / Kártyafüggetlen / 12 Hó Garancia
- Olcsó Notebook! Dell Latitude E6540! I7 4600U / 8GB DDR3 / 128GB SSD! / HD8790M
- GYÖNYÖRŰ iPhone 11 128GB Red -1 ÉV GARANCIA - Kártyafüggetlen, MS3128
- GYÖNYÖRŰ iPhone 13 256GB Pink -1 ÉV GARANCIA - Kártyafüggetlen, MS3209, 94% Akkumulátor
- Samsung Galaxy Z Flip 4 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest