A felhasználók is négymagos chipekre vágynak
2007. szeptember 16. 12:20, vasárnap
Egy augusztusi felmérés szerint a téma iránt érdeklődő felhasználók több mint fele már most beruházna egy asztali négymagos processzorba, az AMD és az Intel tehát kellően előkészített talajra lép majd fejlesztéseivel.

Hirdetés

Az X-bit Labs több mint 3700 olvasója részvételével bonyolította le az online szavazást július 23. és augusztus 24. között és az eredmények némileg meglepték a lap szerkesztőit. Eszerint ugyanis a válaszadók 58 százaléka már most egy négymagos asztali processzort választana a gyors ikermagosokkal szemben, feltéve persze ha az árak nagyjából közel esnének egymáshoz. A lap értékelése szerint mindez azt jelenti, hogy a felhasználók végre kellő mértékben elfogadják a többmagos jövevényeket, és abban reménykednek, hogy a bonyolultabb asztali processzorok egyben a teljesítményben is előrelépést jelentenek majd a mindennapi használat során. A válaszadók 41 százaléka ugyan inkább egy magasabb órajelű ikermagos chipet részesítene előnyben, a többség azonban már a négymagosok mellett teszi le a voksát - a feltétel azonban az árak közelisége, amire még nyilván várni kell majd a megjelenést követően.

Szakértők azt jósolják, hogy a két processzorgyártó minden ezzel ellentétes értelmű nyilatkozata ellenére jövőre mégis beindul majd a "magháború", ahogy nem is olyan rég még a "frekvenciaháborúban" igyekeztek egymás fölé ígérni - bár az AMD az Athlon 64 esetében már a felépítésre helyezte a hangsúlyt a marketingben az alacsonyabb órajel miatt. Az első körben tehát biztosítottnak látszik a négymagosok kedvező fogadtatása, ezután azonban viszonylag gyorsan érkezhetnek az újabb generációk, ahogy a két rivális megpróbálja majd a maga oldalára csábítani a vásárlókat.

2008 eleje tehát minden tekintetben érdekesnek ígérkezik. Néhány csúcskategóriás példány kivételével mindkét gyártó asztali négymagos családja jövőre rajtol el, az Intel 45 nanométeren, az AMD pedig 65 nanométeren küzd majd az első helyért.
Kapcsolódó linkek
Laptopok

Már 49 900 Ft-tól!

E-book olvasók

Már 17 043 Ft-tól!

Tablet PC-k

Már 23 140 Ft-tól!

LCD monitorok

Már 19 800 Ft-tól!

részletek » részletek » részletek » részletek »
Megosztás
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
 

IT/Tech, Hardver
Tudomány, Mobil, Film, Játék
Hirdetés



Hozzászólások
A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
dez  
2007. szept. 18. 13:40 | válasz | #44
Ja, és szóval vannak többszálú AVC/WMV/VC-1 codecek.
dez  
2007. szept. 18. 13:38 | válasz | #43
Azon azért csodálkozom, hogy a VirtualDub, illetle legalább a codecjei nem támogatják a multicore-t, de ma már nem csak XviD-ezni szokás, hanem HD-s anyagokat x.264-be tömcsizni (mpeg2-es adásokat, vagy nagy bitrátás h.264-es anyagokat kisebbre).

Optimálisabb 2 vinyó között ki-/betömöríteni, lehetőleg más vezérlőn. Így sem lesz 100%, de legalább gyorsabb. :) Meg közben mást is csinálhatsz. Mert azért eléggé fogja a gépet egy tömörítés is. (Persze a háttérbe lehet tenni, azaz alacsony prioritásra, de akkor meg jó lassú lesz.) Mondjuk itt vannak olyan bénaságok is, hogy a vinyókezelés is egy szálon fut.
2007. szept. 18. 12:32 | válasz | #42
Én sem az "AVI-TO-DVD" nevű programot használtam, csak olyan programot, ami azt csinálja. Mittom én már mit szedtem le, de elég drága lett volna, ha megveszem. Amúgy szerintem a VirtualDub+XVID codec nem annyira "gagyi" kombináció, mégsem futott két szálon nálam (egyik CPU 50%, másik 1-2%).

Amúgy akármit is csinálok otthon, jelenleg nem a CPU, hanem a HDD a kicsinyke sávszélesség. Mint mondtad pl a ZIP, RAR, 15%-on használja az egy magot, mikor a winyó mér nem bírja tovább.
dez  
2007. szept. 18. 09:29 | válasz | #41
Sokan renderelgetnek hobbiból. Hang-, video-, képfeldolgozással (rippelés, konvertálás) is sokan "szórakoznak" (a "warez" nem a szervereken terem :) ). Persze ők nem ilyen gagyi AVI-to-DVD-ket használnak. :) Aztán azt mind zippelni, rarolni... Másik oldalon meg kifelé... Miközben mondjuk valami mást is akarsz csinálni.
2007. szept. 18. 08:57 | válasz | #40
Temészetesen magamról beszéltem (otthoni gép) amikor azt mondtam, felesleges. Egy SQL-, Print-, Web-szerver vagy egy professionális felhasználás esetén (értem ezalatt renderelés, 3D tervezés, stb..) nagyon is jól a jön több mag. De itt akikről beszélnek a cikkben azok otthoni júzerek. Nekik minek 4 mag?
dez  
2007. szept. 17. 22:08 | válasz | #39
Ja, egyébként azért vacakolt annyit az az AVI-to-DVD, mert egyszerűen szar (esetleg hiperjó minőségben dolgozik, de nem hiszem). Ha azt a WinAVI-t írnák át többszálúra, mondjuk 7 perc alatt végezne. Szóval ennyit a programozókról.
dez  
2007. szept. 17. 22:05 | válasz | #38
Az utolsó mondatodból hiányzik a "nekem" szó a felesleges után... :P
2007. szept. 17. 20:15 | válasz | #37
Nekem 2 magos procim van (C2D@3.2 GHZ). Leszedtem egy AVI to DVD convertáló programot, ami elvileg 2 magon dolgozik. Ment is minden szépen, mind a két mag izzott ezerrel, igaz 2 óra volt a konvertálási idő. Felraktam a jól bevált WINAVI nevezetű konvertáló programot, ami igaz egy szálas, de 13 perc alatt átnyomta DVD-be. Ennyit a két magra optimalizációról...

Amúgy kipróbáltam fordítva is, konvertáltam DIVX-be, XVID-be, próbáltam mindennel, de az istenért sem akarták a másik magot használni. Én vagyok a hülye? Vagy mit kell átállítani?

Amúgy szerintem teljesen felesleges a 4 mag, a 2magot sem használom ki...
dez  
2007. szept. 17. 19:05 | válasz | #36
A Java programok ebből a szempontból nem különböznek a többitől.
2007. szept. 17. 12:13 | galéria | válasz | #35
na és a Java VM? az hol maradt?
Yv@n  
2007. szept. 17. 12:01 | válasz | #34
Az optimális gyors futásért általában előbb felelős a fordító program.

Ezen felül azt képzeld el, hogy van egy vödör feladatod, ami közül sok egymásra épül. Például hogyan párhuzamosítanál két összeadást, ami egymástól függ? Egyszerűen sok esetben nem lehet.

Te látod át a kódod logikáját, az algoritmust, hogy szálakra tudd szedni azt. A fordítók nem képesek erre. Olyan ez, mint a végtelen ciklus detektálása.
hiftu  
2007. szept. 17. 10:53 | galéria | válasz | #33
Ha az operációs rendszernek adsz egy problémát (program) akkor azt egyben fogja kezelni, mert honnan is tudná, hogy valójában mit futtat.
NEKED kell tudnod, hogy hol tudod a problémát különálló, egymástól a lehető legkevésbé függő részekre osztani. Ezeket lehet bedobálni az egyes procikba...
2007. szept. 17. 10:31 | galéria | válasz | #32
Gyerekek, én valamit nem értek.

Ha én írok egy játékprogramot, vagy szövegszerkesztőt, tök mindegy, minek nekem azzal foglalkozni, hogy hány magos procija van a felhasználónak? Művész-programozóként ugyanis én az örökkévalóságnak írom a progit, amelyet majd ezer év múlva is leeht futtatni, adott esetben.

Most, az, hogy a futás optimális, gyors legyen, és más programok is megfelelően kapjanak erőforrást, az kurvára nem kellene, hogy érdekeljen engem, ezt intézze el az operációs rendszer ("kernel").

Ezt mondatja velem a Józan Paraszti Ész.
assdf  
2007. szept. 17. 08:49 | válasz | #31
Érdekes ez a vita. Nekem egy mezei core-duos gépem van, és tapasztalatból mondom a legtöbb program képtelen kihasználni a két mag előnyét.
Nem egyszer látom hogy csinálok valamit és pörög a proci 50%on mert ugye az egyik mag fullra le van terhelve a másik meg áll üresben. Ennek meg van az az előnye hogy mellette mást is tudok csinálni a gépen, meg megvan az a hátránya hogy ugyannyi ideig tart a munka mint az egymagosakon.
RealPhoenixx   3 db büntetőpont 3 db büntetőpont 3 db büntetőpont 
2007. szept. 17. 08:19 | válasz | #30
2000-ben jopar jatekot megneztem, akkoriban a kozel 37 jatekbol, amiket megneztem, csak es kizarolag a microfostos jatekok voltak amik kepesek voltak kihasznalni a tobbmagos gepet /vagyis akkor 2 microfostos jatekom volt (3d-s), az egyik repcsis, a masik valami maszkalos/.

Ma mar valamelyest javult a dolog, de inkabb az alkalmazasok kepesek kihasznalni a kapacitast, mintsem a jatekok.

NB: gondolom a jatekok eseteben a gyors olcso jatekkeszites a lenyeg, es a sok primitiv jatekkeszito ceg a motorjaiban anno arra alapozott, hogy mivel grafikus fg-ket hivogatnak es valojaban nem programoznak, csak meglevo dxfg-ket hasznalnak, szval majd akik keszitik az alltaluk hasznalt fg-ket, majd azok lerendezik a kapacitas kihasznalast.

Magyarazat: mert minden balfasz arra var, hogy helyette vegzik el a munkat *esetleg segitsegkeres cimen kikuncsorogja ezen kegyet*
dara  
2007. szept. 17. 08:15 | válasz | #29
A Supreme Commander erről a címről bőségesen lemaradt, lévén a Q3 motor a kezdetektől fogva támogatja a több magon futást. Mikor is jelent meg? 1999-ben.
dez  
2007. szept. 17. 02:48 | válasz | #28
Nem csak drágább és bonyolultabb lett volna, a céljukat sem érték volna el. Ugyanis a sima proci elég rossz volt lebegőpontos számításokban (FPU -> Floating Point Unit), mivel az egészet szoftveresen kellett utánoznia, integer alapú kóddal...
2007. szept. 17. 01:15 | galéria | válasz | #27
ja, ezt poszgraduális képzés volt.
2007. szept. 17. 01:12 | galéria | válasz | #26
1993-ban kérdeztem a számtech tanáromtól: Mi értelme van az XT-be tenni egy procit (4,6 Mhz) és mellé egy matematikai ko-processzort (ki emlékszik már erre az édes megnevezésre?), inkább tennének helyette két rendes 4,6 Mhz-es procit. Már nem emlékszem mi volt a válasz, talán az, hogy úgy drágább lenne.
kvp  
2007. szept. 17. 00:10 | válasz | #25
Eloszor is hatalmas nagy marhasag hogy a windows nt kernelek nincsennek felkeszitve a tobb cpu magra. Mar az elso nt, a 3.51-es is eleve tobb cpu-ra keszult, ezt a teljes rendszer azota is tamogatja. Minden egyes i/o kerelem mehet kulon cpu-n, csak a kritikus reszek (amik a hardvert kezelik) futnak keszulekenkent egy-egy szalon. Az egyetlen alrendszer ami meg nem volt tobbszalu, az a gdi volt ami a grafikaert felel mivel ennek mukodese nem valtozott a windows 2.0 ota. Ezt a vista-ban korrigaltak.

A linux eredetileg egy szalon tudott csak dolgozni, de a fo kernel lock mar kezd eltunni, egyre tobb modul kepes kernelszintu tobbszalu mukodesre, bar eleg kaotikus a megoszlas. Van olyan resz ami tranzakcio szintu, mint windows nt sorozat, van ami modul szintu mint a macos, van ami meg mindig globalis lock-al megy, mint a regi linux-okban.

A solaris mindig is tobbszalu volt, csakugy mint a vms vagy winnt sorozat, tehat itt sem volt gond, sot meg jobban is skalazodik mint a tobbseg.

A macos-x jelenleg nem igazan tobbszalu, alrendszerenkent van egy-egy lock, tehat mondjuk a lemez es a halozati muveletek fuggetlenek, de ket halokartya meghajtoprogramja mar nem tud parhuzamosan dolgozni.

"Nem értem miért, vagy úgy oda microkernelekért. Részek közötti kommunikáción többet bukhatnál sebbeségben."

A mikrokernel csak azert jo, mert bar lassabb de stabilabb es egy bena driver programozo nehezebben szurja el az egesz rendszert. Mindezek melett sokkal konyebb es kenyelmesebb ugy driver-t fejleszteni, ha programozoi kornyezetben nincs kulonbseg a felhasznaloi programok es a driver-ek kozott. Egyebkent a sajat fejlesztesu mikrokernelem pl. egymagos egyszalu lett, mert ezt volt a legkonnyebb leprogramozni. A tobbszalusag nem a mikro/monolitikus architektura kerdese, hanem az, hogy milyen finom a kernel objektumok hozzaferesvedelme (lock-olasa). A lehetseges modok: minden szal egy ponton szinkronizal (kernel lock), minden szal a modulhatarokon szinkronizal (module or coarse grained lock), vagy minden szal az objektumhatarokon szinkronizal. (fine grained lock) Mindel fejlettebb egy rendszer annal bonyolultabb megirni. A legegyszerubb egy cpu-s, egy szalas megoldas osszesen ket assembly utasitas (cli/sti), a legbonyolultabb megoldas pedig komoly egyseges architekturat es kulon szinkronizacios modult igenyel. (winnt i/o request packets)
Sanyix   "Rest in Peace Sanyix" 
2007. szept. 17. 00:05 | galéria | válasz | #24
Dehogy használják ki. Mindenre ezt mondják, de mind kamu, ez csak reklám, de persze semmi sem igaz belőle.
dez  
2007. szept. 17. 00:04 | válasz | #23
Veszel egy több proci-foglalatos (szerver/munkaállomás-)alaplapot, és máris megteheted. Néhányszáz dolcsiból meg is van. Mármint az alaplap. Proci bele még párszáz. Per proci. :)
2007. szept. 16. 22:37 | galéria | válasz | #22
Mondja meg nekem egy guru, hogy miért nem lehet azt csinálni, hogy a prockókat is hálózatba szervezzék. Modularitásra gondolok. Tehát, ha csak 1 procira van szükségem, akkor annyi lesz, és ha nőnek az igényeim, akkor bedugdosok az alaplapba még egy-két-há.. procit, a RAM-hoz hasonlóan. Bővíthetőség.
2007. szept. 16. 22:19 | válasz | #21
Core Servernél is lesz minimális GUI (egy ablakban fog futni a parancssor), illetve nem a Powershell lesz a parancssor (ahhoz .NET kell, ami nincs benne a Core változatban).
bvalek2   "Rest in Peace bvalek2" 
2007. szept. 16. 19:45 | válasz | #20
Egy kis flém, és az ember miket meg nem tud a mindennap használt oprendszeréről, köszi.

Tudom, Google a barátom, legközelebb okosabb leszek...
barret  
2007. szept. 16. 19:17 | galéria | válasz | #19
Akkor mar nem sokat kell varnunk a 8 magos procikra :D
Ez jo uzlet lesz a gyartoknak :)
Evente duplazni a magok szamat ketszer XD
A sok birka meg rohan feljeszteni...
2007. szept. 16. 18:57 | válasz | #18
Nem értem miért, vagy úgy oda microkernelekért. Részek közötti kommunikáción többet bukhatnál sebbeségben. De ott Minix 3, ha minden áron micro kernel kell.

Linux-ot moduláris monolitikus kernelnek mondjuk.
Másrészt az, hogy monolitikus nem jelenti azt, hogy egyszálas vagy, hogy egy magot használ. (Több kernel thread is van)
Linux esetén egy rendszerhívást vagy megszakítást bármelyik mag kiszolgálhatja.
2007. szept. 16. 17:51 | válasz | #17
a 7-zip 2 magon biztosan szépen fut és ott már a winyó a szűk keresztmetszet. kíváncsi leszek, mit kezd majd 4 maggal.
bvalek2   "Rest in Peace bvalek2" 
2007. szept. 16. 15:33 | válasz | #16
A Linux is csinálhatná azt, amit a VMS, pl ha lehetne a kernellel párhuzamos szálba modulokat betölteni, akkor csak minden drivert modulba kéne forgatni, és az egyszeri kocka kapna egy mikrokerneles Linuxot :)
bvalek2   "Rest in Peace bvalek2" 
2007. szept. 16. 15:30 | válasz | #15
Ezeknek a játékoknak azért olyan nagy a memóriaigényük, hogy induláskor minél többmindent betöltsenek, mert ha menet közben is betöltenének ezt-azt, a Vista nem bírná szusszal, hiában van több mag a processzorban, csak egyet használ a kernel (a Linux is). Szerintem a Vista memóriaigénye is ezért ilyen hatalmas, a bloated monolitikus kernel miatt mindenféléket kénytelenek kitalálni, hogy megkerüljék ezt a szűk keresztmetszetet.
2007. szept. 16. 15:29 | válasz | #14
Sun jósolja :) , milyen meglepő.
Én inkább azt jósolom, hogy nem fog elsüllyedni, mint lassacskán a többi Unix a Linux árnyékában.

Linux köszöni szépen (cc)NUMA és SMP rendszereket is tud jól kezelni.

p7zip mintha több szálat is használna.
bvalek2   "Rest in Peace bvalek2" 
2007. szept. 16. 15:25 | válasz | #13
A Vistában még egyben van a grafika és a kernel, bár azt igérték, hogy külön jön. Most ott tartanak, hogy 2008 Server lesz ilyen, GUI nélkül használható, Powershell parancssoros Windows.

Solaris és a BSD is monolitikus, ezzel együtt az OS-X is.

Amiről tudok, a VMS a 8-as verziótól már tud többszálas kernelt, ami gyakorlatilag megvalósítja azt, amit a mikrokerneltől várnak, pl a fájl I/O kezelését több szálban képes elvégezni, de az csak Alpha és Itanium processzorokon fut. QNX-nek mikrokernele van (Neutrino), fut PC-n, de őket meg a valósidejű, beágyazott alkalmazások érdeklik, talán nem látnak pénzt az egyszerű userben. Gondolom Mikroszofttal nem akarnak bírkózni, a Linux és a BSD pedig elszívja előlük a levegőt.

Ja, van Unicos is, azt a Cray (the Supercomputer Company) fejleszti, na azt sem fogják hamar laptopra portolni, pedig AMD procikon futó változata is van. IBM-nek van néhány oprendszere, majd ha egy manager azt álmodja, hogy lehetne kaszálni vele, talán :)
2007. szept. 16. 15:15 | válasz | #12
Hát igen. Ps9-ben is van már multiprocesszor támogatás, egyéb 3Ds progikban is.
Asszem az első játék a aaa nem jut eszembe a nevee naaa, megvaan a supreme commander volt. Aztán Bishock , Crysis is mind már kihasználják a multiprocit. Lehet kicsit megkésve de azért meglesz a szoftveres támogatása ezeknek.
dez  
2007. szept. 16. 15:10 | válasz | #11
Ezért variálták át a dolgokat grafika ügyben a Vistán, bár nem tudom, hogy sikerült.
A Solaris milyen? Tudom, az is monolitikus, de amúgy? Csak mert az OpenSolaris felemelkedését jósolják egyesek.
Hát a BSD, és változata? És ezzel együtt az OS-X?
dez  
2007. szept. 16. 15:01 | válasz | #10
Na igen. De nem hiszem, hogy ma ez lenne a fő gond, később már igen, de addigra csak lesz valami. (Vagy nem. :P) Mondjuk ma is tud akadni szépen, de más hülyeségek miatt, főleg a Windows. A mai vinyókkal amúgy sem lehet kiszolgálni akár csak néhány file-műveletet végző taszkot sem. Bár jönnek az SSD-k. Jópár dolog nem a kernelben van, hanem külön driverekben, stb. Pl. az Nvidia gfx driverek támogatják már a több magot, talán az ATI/AMD-sek is.

Pl. ilyenek vannak ma, hogy többprocis Opteron/2 procis FX rendszereknél, az IMC miatt sokkal gyorsabb a saját ram elérése, mint a szomszédoké, de pl. az XP erre egyátalán nincs tekintettel. Meg amúgy is körülményes elérni, hogy valami fixen az egyik, másvalami fixen a másik magon fusson.
bvalek2   "Rest in Peace bvalek2" 
2007. szept. 16. 14:47 | válasz | #9
Grafikus megjelenítésbe a GUI logikát is beleértem, pl ha felhasználó türelmetlenül kattintgat XY belassult alkalmazás oké gombjára, akkor Linuxon a külön szálon futó ablakkezelőt terheli, míg Windowson a kernelbe van építve az is. Szóval ezért hal le az ilyenkor. A Linux előnye az, hogy a kernele vékonyabb, de sajnos több kritikus dolog egyben van benne. Szegény Tannenbaum nem véletlenül mérgelődött annak idején, hogy mikrokerneles OS kellene.
bvalek2   "Rest in Peace bvalek2" 
2007. szept. 16. 14:41 | válasz | #8
A butácska enyhe kifejezés, ha belegondolunk, hogy minden fontos PC-s oprendszer monolitikus kernelű. A Linuxon legalább a grafikus megjelenítést felhasználói program felügyeli, ott van rá esély, hogy tehermentesítésként egy másik processzor foglalkozzon vele. De ha pl. több alkalmazás szeretne valamit a kerneltől, pl. fájlokat írni/olvasni, eszközt inicializálni, vagy egyszerűen sok a taszk és le van terhelve a kernel shedulere, akkor hiába van 50 magos processzorom, az az egy mag fog izzadni, amin a kernelszál fut, a többi ül és nézi, és az egész rendszer akadni fog. Windowson előbb, Linuxon később, de ebből a szempontból a kettő egykutya.
poizon  
2007. szept. 16. 14:26 | válasz | #7
nekem konkrétan tömöritéshez hiányzik a teljes proci: az unrar csak 1 magot használ, de most hogy szóbajött a dolog, kiprobálom a bz2-t 2 magon :)
dez  
2007. szept. 16. 14:24 | válasz | #6
Amúgy, khmm, már egy éve kapható 4-magos Inteléktől. Igaz, nem olcsón, és kicsit szűkös neki az FSB.
dez  
2007. szept. 16. 14:20 | válasz | #5
De igen, csak adott esetben kicsit butácskán.
dez  
2007. szept. 16. 14:19 | válasz | #4
A fontosabb teljesítményigényes programok (3D renderelők, médiafeldolgozók, tömörítők küzül is több, stb.) többsége ki tudja már használni a több magot. Kivétel a játékok, mert ott nagy átalakításokra van szükség ehhez. De egyes játékok tudják.
bvalek2   "Rest in Peace bvalek2" 
2007. szept. 16. 13:43 | válasz | #3
Az operációs rendszereket pl. nem
poizon  
2007. szept. 16. 13:34 | válasz | #2
ha már a tanitásnál vagyunk... a prociigényes szoftvereket megtanitották a 2-4 mag kihasználására? :P
bvalek2   "Rest in Peace bvalek2" 
2007. szept. 16. 13:23 | válasz | #1
A felhasználók arra vágynak amire megtanították őket...