65
  • Komolytalan
    #25
    Ja, virtuális szerver, pfff. Erről beszéltem.
  • Komolytalan
    #24
    ""De a CPU ezt nem fogja kiszopni az újából, hogy "a" változó ilyen, "b" meg olyan, és a jelenlegi gépikód nem tartalmaz olyan utasítást, amivel ezt meg lehetne neki súgni."
    Az intelnek hala van. Csak a legtobb programozo nem tud rola, mert az elmult 10 evben kerultek be es ezert nem tanitjak magyar iskolakban. Attol meg letezik es az intelligensebb forditoprogramok berakjak ezeket a buta programozok helyett."
    Megnéztem az intel instruction setjének doksiját, és én csak olyat találtam, amivel azt lehet szabályozni, hogy cachelje-e a memória területet vagy sem. Viszont ez nem elég, mivel a maghoz dedikált cache, meg a közös cache egészen más filozófia, másra jó. A jó az, ha 1x berakjuk a cache - lehetőleg minél gyorsabba - az adatot, ott piszok sok műveletet végzünk rajta, míg elfajul odáig a helyzet, hogy vissza kelljen írni memóriába. A memória kommunikáció, a magok közötti kommunikáció - mind-mind fáj. Jelen architekturában ha sok mag használ egy területet akkor az nem lesz gyors. Márpedig globális változók vannak - egy számítási segédtáblát pl nem szokás lemásolni minden egyes szálhoz. Attól, hogy sok mag használ egy memória területet sokszor sokkal gyorsabb futást eredményezne, ha minden mag tudná cachelni ugyanazt a területet. Pl az előre számolt segédtáblázatok tipikusan ilyenek: a program futásának első időszakában RW, és akkor legfeljebb közös cache-be kerülhet, utána meg RO, és lehet minden magban másolat róla, mivel úgyse fog módosulni. De ahhoz hogy ez működhessen a programnyelvek részéről is kellene változás: nem elég az, hogy egy adatterület változó/konstans, hanem kellene egy olyan is, ami változóként indulhat, és utána konstans lesz (tömbre, bonyolultabb strukturákra, azok elemeire is). A procinak meg meg kellene tudni mondani azt, hogy ez egy olyan adatterület, ami RO, vagyis akár 1000 mag mind becachelheti, ha minden második mov erről szól a kódban. Mert ha nem, akkor várhatja majd a 8-10 ciklusokat, mire hozzá bír férni.

    "Egyebkent 1000-szer annyi mag az akkor jelent 1000x-es teljesitmenynovekedest, ha a memoria ki birja szolgalni es a szalak nem nyulkalnak bele allandoan egymas adatteruleteibe. Ha ez teljesul, akkor mukodik."
    Na igen, csak sok itt a ha. A jelenlegi DDR3 memóriák 9-10ns körül vannak. Az EDO ram meg 10-15 éve 60-70ns volt. Persze tudom, a DDR akkor penge, ha sok adatot kell túrnia, de én nem láttam még olyan asm kódot, ahol minden csupa rep volna. Vagyis persze, gyorsabb a DDR3 mint egy 10ns EDO lenne de messze nem 40x, amit a max sávszélesség mutat. Hanem mondjuk 15-20x, jóindulattal. Vagyis a mai szupergyors DDR3 jobban fog egy 6 magos 2Ghz procit, mint egy EDO fogott 5x86-ot. Persze biztos tudnának gyorsabb memóriát is csinálni, gondolom csak passzióból várakozik 2x annyit ütemciklus százalékában egy proci jelenleg mint 10 éve.
  • zola2000
    #23
    Gondolom 1000 magos lesz a 2020ban bemutatkozó playstation 5, és erőben verni fogja a pcket egészen 2022ig ^^
  • byzhouse
    #22
    minek 1000mag mikor a játékot 1200magra optimizálják? ASD ekkora .... vagy azt hiszik,hogy 1szerre 80játékot fogunk futtatni?
  • endrev
    #21
    A válasz a kérdésre, miszerint lesz-e rá szükség, abban rejlik, hogy mit gondoltunk a 40 MHz-es 386-osok idejében arról hogy lesz-e szükség 1-2-3 GHz-es gépekre. Ezek akkor szuperszámítógép-kategóriába estek, mégis itt vannak és használjuk őket.

    10 év múlva talán holografikus kijelzők lesznek, amelyben 3D-környezet fog megfelelni a munkaasztalnak (akkor már helyesen: munkaszobának). Az ezermagos hordozható Izészámítógépek nyilván akkor is ki fogják majd használni ezt a kapacitást, ahogy ma is kihasználják a 10 évvel ezelőtt még szuperszámítógépnek számító teljesítményeket.
  • vasedeny2
    #20
    1. az intel azért csinál egyre több magot, mert máshogy nem lehet már egy processzor gyorsabb, tehát ha nem lehet hozzá fejleszteni, akkor is ez az út van, amit vágnak, és elméletileg ki lehet használni.
    2. egy jó programozó úgy gondolkodik, ahogy tanult gondolkodni, nem úgy, ahogy ti elképzelitek.
    3. a szoftverek által megoldandó problémákra igaz, hogy elméletben jelentős része nem párhuzamosítható, ám gyakorlatban szinte bármi, amit egy windows-ban láttok párhuzamosítható
  • dyra
    #19
    nem egy embert ismerek aki 9 - 10 éves gépen is viszonylag jól elvan. Nem játszik csak netezget meg elolvas 1 - 2 doksit megnéz egy DVD -t vagy egy AVI filmet.

    Az én gépem most 4 éves, de internetre teljesen jó. Még játszogatni sem olyan rossz pedig csak egy 7900 GTO van. Biztosan vannak olyan területek ahol kelleni fog ez a számítási kapacitás, de én inkább azt szeretném, ha jóval kisebb lenne a villanyszámlám és nem esne vissza teljesítmény.

    Jó lenne ha az otthoni gépek masinák ebbe az irányba fejlődnének.
  • atomkrumpli
    #18
    a kutatóknak és a hadseregnek nagyon jól jön a sok mag, de keress rá pl. az fpga processzor alkalmazására (más proci de a lényeget megtalálod hogy mire jó az a sok mag)
  • JTBM
    #17
    Félelmetes, hogy az amatőrök mekkora baromságokat tudnak leírni.

    Szerinted viccből csinálunk minden kódot alapból párhuzamos futásra???

    100 process 99-szer gyorsabban fut le, mint 1 process. Az overhead kb. 1%.

    Kimaxoljuk a hardware-t kb. 80-90% load-ra, mert akkor fut a leggyorsabban.

    A 100 process egyébként nem 1 gépen fut, hanem egy virtuális szerveren, aminek a HW-ét én nem is ismerem, csak kimérem, hogy mekkora terhelést bír.
  • [HUN]FaTaL
    #16
    Mi a fasznak ennyi mag? Nem lehet mindent párhuzamosítani, főleg ennyi felé...
  • torreadorz
    #15
    "Par korrekcio, mert ezek nem 10 evre vannak, hanem a jelenben/multban:"

    Szerintem ő arra gondolt, hogy azt jósolták ezek mindennapi dolgok lesznek.
  • torreadorz
    #14
    Igazából szerintem a párhuzamosítás sokkal nagyobb meló mint azt gondolnánk. Ahhoz hogy egy program jól párhuzamosítható legyen, úgy kéne azt megirni.

    Csakhogy, egyrészt sok dolog egyszerüen nem párhuzamositható, vagy a párhuzamosítás "költsége" sokkal nagyobb mintha nem csinálnánk ezt.

    Másrészt, ehhez párhuzamos programozói logika kéne, ami nem nagyon müködik az emberekre, mivel ők meg általában lineárisan gondolkodnak.

    De akárhogy is nézzük, azzal tisztában kell lenni, hogy általában egy program csak véges kis számban párhuzamosítható. Ha pl. egy adatbázisba 48 ember akar beszúrni egy adatot, akkor az lehet hogy a 48 szál tudna 48 magon futni. De ha csak egy beszúrást kell elvégezni, akkor lehet akár 10000 mag is a gépben, akkor sem lesz sokkal gyorsabb a dolog.

  • kvp
    #13
    Par korrekcio, mert ezek nem 10 evre vannak, hanem a jelenben/multban:
    -lesz 90%-os hatásfokú napelem : ilyen nem lesz, fizikailag nem megoldhato
    -minden eddiginél nagyobb hatásfokú akkumulátor: ezek evrol evre egyre jobbak, most a vas foszfat a legjobb ar/ertek aranyu
    -szobahőmérsékletű szupravezető: van, csak draga
    -fúzió kémcsőben: nem megoldhato a hidegfuzio nem letezik, forro fuzio viszont van
    -a rakétahajtóművet leváltja a napvitorlás, ionhajtómű és nukleáris hajtómű: ionhajtomuves szondak mar vannak, a plazmat pedig jovore tesztelik az iss-en palyantarto hajtomunek
    -hiperszónikus repülőgép: draga, nem lehet eladni bar van par prototipus
    -sűrített levegővel működő autó: van, kinaban hasznaljak is (pl. taxik)
    -lézerágyú: van, az amerikai hadsereg epitett egyet (de minek?)
    -hűtőgép méretű háztartási üzemanyagcella: van kisebb is, kicsit draga, de van belole ongyujto meretu is (a hutogep meretut varosi buszokban hasznaljak, pl. a kanadai Vancouver-ben)
    -Cső helyett haltestű repülőgép: rossz otlet, utasszallitasra nem igazan jo, ilyen bombazo meg mar van
    -repülőgépnél sokkal gazdaságosabb léghajó: nem gazdasagosabb, mert az ido tobbet er mint az uzemanyag (ha meg nagyon raerunk, akkor olcsobb a hagyomanyos hajo)
    -optikai processzor: van, csak egyelore kisse oriasai (nem ic meretu)
    -világító tapéta: ezt oled-nek hivjak, japanban mar kaphato egy ideje
    -holografikus adattároló: ilyen is van, csak nagyon draga (archivalasra hasznaljak nyugati kormanyzati szervezetek, szerintem a platina lemez a draga benne)

    Szoval attol, hogy valaki meg nem hallott roluk, attol meg leteznek ezek a talalmanyok. Az, hogy meg hany ev amire pesten is felbukkan egy, az meg nem a tudomanytol fugg.

    A memoria szavszelessegre egy jo megoldas van, csak lokalis memoriat kell hasznalni es minden magnak kell sajat teruletet adni, ami szamara teljesen lokalis. A tobbi mag is belelathat a tobbiek memoriajaba, de azt csak ipc buszon keresztul, tehat lassabban. A programokat meg ugy kell megirni, hogy minden folyamat a sajat memoriajat akarja elsosorban hasznalni. (mondjuk ez pont igy van jo 50 eve)

    Ha egy programot bontunk tobb magra akkor mar bonyolultabb a helyzet, mert akkor a programnak tudnia kell, hogy melyik memoriateruletet melyik szal akarja majd hasznalni es a szerint szetosztani az adatokat. Erre is van mar par megoldas, pl. minden adat ott van lokalisan tarolva, ahol eppen utoljara hasznaltak. (ez teljesen automatizalhato)

    "De a CPU ezt nem fogja kiszopni az újából, hogy "a" változó ilyen, "b" meg olyan, és a jelenlegi gépikód nem tartalmaz olyan utasítást, amivel ezt meg lehetne neki súgni."

    Az intelnek hala van. Csak a legtobb programozo nem tud rola, mert az elmult 10 evben kerultek be es ezert nem tanitjak magyar iskolakban. Attol meg letezik es az intelligensebb forditoprogramok berakjak ezeket a buta programozok helyett.

    Egyebkent 1000-szer annyi mag az akkor jelent 1000x-es teljesitmenynovekedest, ha a memoria ki birja szolgalni es a szalak nem nyulkalnak bele allandoan egymas adatteruleteibe. Ha ez teljesul, akkor mukodik.

    ps: A jelenleg letezo legnagyobb mag szamu processzor amivel idaig talalkoztam 65536 magot tartalmazott, persze az meg kiserleti rendszer volt, de mar jo 8 eve, azota akar tovabb is fejlodhetett a technologia. (lokalis memoriat hasznalt, tehat minden mag sajat ram-ot kapott, meg nehany kommunikacios port-ot)
  • Komolytalan
    #12
    Félelmetes hogy programozók mennyire nem ismerik azt, amin a programkódjuk fut. Te leírtad amit látsz mondjuk JAVAból. Csinálsz 1 új threadet, oszt majd lesz valami a háttérben. 1000 mag van akkor 1000x gyorsabb lesz mint 1 mag, mert a JVM majd megoldja. Hát persze, hogyne. Mikor gépi kódban se lehet megoldani x86-on (meg kb semmi máson se, ami halandóknak elérhető).
  • JTBM
    #11
    Már évek óta csak párhuzamosan futtatható programokat fejlesztek.
    Amik pl. 100 párhuzsamos processen vannak végrehajtva, X magon.

    Ha az X az 1000 mag, akkor lehet rajta futtatni 4000 process-t egyszerre (mondjuk 4 P/mag)

    Ez 40+-szoros gyorsulást jelent.

    A számításigényre pedig szükség van, pl. real-time ray-trace megjelenítés vagy a még jobban számításigényes real-time látáshoz.

    A real-time látás az, amikor a számítógép két (v. több) kamerakép alapján folyamatosan felépíti a virtuális világát a képek alapján, pontosan úgy, ahogy az agy teszi.
  • Komolytalan
    #10
    "Valójában a fejlődést egy teljesen új architektúra jelentené.."
    Igen, itt van elásva a kutya. Jelenleg minden programozó Neumanni alapokat tanulja, és az összes programnyelv Neumanni alapú számítógépre lett tervezve. Ami 1 végrehajtó egység, 1 központi memória. Egyszerűen a Neumanni alapú programnyelvek sosem fognak jól párhuzamosan futni, mert ahhoz hogy valami jól fusson párhuzamosan magának a nyelvnek, sőt a gépi kódú fordított programnak kellene segíteni a processzort, hogy melyik memória területet miként kezelje. Egyáltalán nem mind1 az, hogy egy változó "mennyire" változik. Vannak pl táblázatok, amik egyszer kerülnek generálásra, és utána a program teljes futása során változatlanok maradnak. Ezeket nyugodtan be lehetne rakni minden egyes mag saját cacheébe - ha szüksége van rá - mivel biztos lehet benne, hogy másik mag nem fog ebbe a memória területbe beletúrni, így nem kell cache-t borítania (ami a sok idő a többmagos architektúránál). Amik meg gyakran változnak azokat csak a közös cache-ben (mondjuk L2-ben) volna szabad tárolni, mivel ott ha egyik mag ír bele, akkor a másik mag anélkül látja a változást, hogy cache-t borított volna.
    De a CPU ezt nem fogja kiszopni az újából, hogy "a" változó ilyen, "b" meg olyan, és a jelenlegi gépikód nem tartalmaz olyan utasítást, amivel ezt meg lehetne neki súgni.
  • Komolytalan
    #9
    Az a memória probléma azért van annyira apró, hogy kb 1 évtizede nem tudják megoldani. Azóta tény, hogy a procit visszafogja a memória - hol jobban, hol kevésbé. A több memória vezérlő meg azért érdekes, mert 1 memória modult 2 vezérlő nem vezérelhet, vagyis ha 12 maghoz raknak 1 memória vezérlőt akkor 1 gép 12 magból áll, és 48 proci az szimplán 4 gép egy dobozban.

    A renderelésnél igaz amit írsz, de a számítás ott se nő a magok számával egy idő után, mert a renderelési idő el fog törpülni amellett, hogy a közös memóriából feltöltik az egyes magok dedikált memóriájába a rendereléshez szükséges adatokat.
  • sedward
    #8
    Rágogumi hír. Mint a 10 év múlva embert küldhetünk a marsra,
    és 10 év múlva:
    -lesz 90%-os hatásfokú napelem
    -minden eddiginél nagyobb hatásfokú akkumulátor
    -szobahőmérsékletű szupravezető
    -fúzió kémcsőben
    -a rakétahajtóművet leváltja a napvitorlás, ionhajtómű és nukleáris hajtómű
    -hiperszónikus repülőgép
    -sűrített levegővel működő autó
    -lézerágyú
    -hűtőgép méretű háztartási üzemanyagcella
    -Cső helyett haltestű repülőgép
    -repülőgépnél sokkal gazdaságosabb léghajó
    -optikai processzor
    -világító tapéta
    -holografikus adattároló
    Lehet, hogy lesz 1000 magos processzor, de a hír csak egy reklám az Intelnek.
  • barret
    #7
    Piacgazdaság...
    Ne csak a 4 és a 100 magost vedd meg!
    Hanem a közbenső "termékeket" is!
    Mert ezek csak termékek,amit el kell adni.
    mi hasznunk a 16 megapixeles kamerákból?
    A fos képet át kell konvertálni hogy feltölthető legyen!
    Normális optika eszükbe sem jut,mert az drámaian javítja a képminőséget!
  • kvp
    #6
    Minden olyan alkalmazas ki tudja hasznalni, amibol sok fut egyszerre. Peldaul a felho alapu rendszereknel, ahol ugyan 1 szalon fut a szovegszerkeszto, de ha 1000 felhasznalo jut egy szerverre, akkor 1000 mag azt jelenti, hogy minden felhasznalonak jut 1-1 sajat mag. Ugyanez igaz webszerverek eseten is, ahol minden felhasznalo kerese kaphat 1-1 sajat magot.

    Masik felhasznalas a grafikus rendereles, ahol most is tobb szaz mag dolgozik egy kepen, ez egeszen addig bovitheto amig minden pixel kap egy sajat magot. Egy ket megapixeles kijelzovel szamolva ez szoftvermodositas nelkul 2 millio magig skalazhato fel.

    Tehat felhasznalas lenne, csak rendes x86 kompatibilis altalanos magbol kellene tobbet bezsufolni a rendszerbe, ugyanis a grafikus kartyak magjai tul butak a kenyelmes altalanos celu felhasznalasra. Az egyetlen gond a memoria savszelesseg, ami a mostani intel-es elrendezesnel tul keves, viszont tobb sajat memoria beepitesevel vagy tobb memoriacsatolo hasznalataval ez megoldhato.
  • bigjoe
    #5
    EGY GONDOLAT:
    A gyártók már nem tuják tartatni az iramot az órajelben és a memória méretében, illetve e csíkszélességben.. Ezért áttértek a több mag marketingre.
    Jó pár évvel ezelőtt azt sulykolták, hogy a gyorsabb az jobb...
    Nem olyan régen a memória mennyiségének a fontossága volt a téma (L2)..

    Valójában a fejlődést egy teljesen új architektúra jelentené..

    Sztem a gyártók szanaszét szívatnak minket, hogy évente cseréljük a gépeinket...
  • Csirke4
    #4
    Magyarul már rég megvan a technológia rá csak még lehúzzák a rókabőrt a köztes technológiákról is. :D
    Egyébként profi játékoknak 10 év múlva ez is kevés lesz. :C
  • torzsvendeg
    #3
    Ahogy a programfejlesztőket ismerem simán és még ez is kevés lesz.
  • nenad
    #2
    ez már lassan tényleg egyfajta divat kérdés marad csak. Már a játékprogramok közül is jópár több magon is futhat, a profi alkalmazások pedig mind képesek rengeteg magon futni...
  • JL666
    #1
    kérdés az, hogy lesz-e alkalmazás, ami ki tudja majd használni...