57
-
#2
na lassan már 100 magos proci lesz miközben alig pár program hasznosítja a 2 magos tehnológiát nem még ezt. -
bvalek2 #7 A mai chipekben a kompatibilitás, és a komplexitás miatt rengeteg redundancia van. Teljesen új technológiákkal, és sokkal de sokkal több hasznos munkaóra mellett lehetne hatékony chipeket tervezni. Meg persze le kéne seggelni a mérnök uraknak a tervezőasztalhoz, nem library-ból generálni a proci 95%-át, meg automatikus tervezőprogramokkal összerakni őket. Annó milyen jó kis cuccot hoztak össze a DEC-nél, talán az Alpha volt az utolsó komoly teljesen emberek által "kézzel" tervezett processzor.
Szerintem az IBM Power6-osa jobb megközelítés, de nem ismerem a részleteket. A magok egyszerű többszörözése nem tűnik optimális megoldásnak... -
G18XM8 #9 Minek már 6 magos, még a 4 magos sincs kihasználva, sőt a 2 magos sem igazán... Mit akarnak ezek? -
#10
Az hogy nincsenek kihasználva a magok, az nem a tervezők sara hanem a lusta programozóknak.
A korral akkor is haladni kell ha mások nem teszik azt.
Amúgy megjegyzem, hogy a mostani procik melyek több száz millió tranzisztorosak kb, órajelenként 4-6 utasítást hajtanak végre, fejlett több milliós prefetcherrel és több tíz futószalagos pipelines rendszerükkel, meg a több megás cacheval.
Mellette ott van a 486-os proci, a 1.2 millió tranzisztorával, aminek van egy 5 szintű pipelineja és ezzel órajelenként végre tud hajtani EGY utasítást.
Átlagon számolva.
Ennek a felépítése nem olyan komplex mint a mostaniaknak még jobban is növelhető a sebessége.
32 bites memória busza van.
Egy 4 Ghz- s 486-os mag 16 gigabájtot tudna feldolgozni másodpercenként elméletben.
A mai chip gyártási teknológiával ezer db ilyen 1 millió tranzisztoros magot lehetne egy processzorba szervezni.
Eredmény :
1000 db 486 mag = 1000 utasítás / órajel. szemben a mostani 4-6 al.
Persze ehez új memória buszok is kellenének. -
kvp #11 Egy 1 bites, soros cpu kb. 32 orajel alatt kepes feldolgozni egy 32 bites alapmuveletet. Ehhez mindossze csak parszaz tranzisztor kell. Tobbszazmillio tranzisztorral tobbszazmillio utasitast lehet vegrehajtani, osztva 32-vel ami meg mindig tobb tiz millio utasitas orajelenkent, szorozva kb. 10Ghz-el, ami az egyszerubb cpu-k jelenlegi limitje. A vicces az, hogy vannak ilyen aramkorok, de csak kis szeriaban gyartva es csak katonai celokra hasznaljak oket. (kepfeldolgozas, kodtores)
ps: Valoszinuleg a letiltott hozzaszolasok a politikai reklamokrol szoltak, de en meg reklammal ezen az oldalon nem talalkoztam. (alap opera + block all beallitas) -
sgember #12 Az igaz hogy pc-re még mindíg kevés a többszálas porgramok aránya, de itt nem -most muszály lesz elővennem Pistike példáját :)-: Ez nem Pistikének készül, hogy menjen vele a krájzisz (na az se terheli le a quad magjait egyenként még 60 %-ra sem) a PC-n, hanem szerverekben lesz munkára fogva. Ott azért lesz értelme gondolom. -
sgember #13 pistike nem tud írni: programok, az lesz az..., sry -
Kaadi #14 hogy is van ez: 6 mag 16MB cache?
lassuk csak: a 8xxx szerias magoknak 6MB cache-uk van, mig a 9xxx szerias quadoknak 12MB, tehat magonkent 3MB. Ha ezek a magok kerulnek az uj szerver procikba, akkor 6x3=18MB kene legyen a gyorsitotar.
16MB azt jelentene, hogy magonkent 2,66MB van, ami nyilvanvaloan helytelen. kerek pontositast. -
Kaadi #15 Szoval:
A Dunnington 3 par Core 2 magot fog tartalmazni, ezeknek egyenkent 3MB masodszintu (L2) gyorsitotara van, es meg fognak osztozni egy 16MB-os harmadszintu (!!!) gyorsitotaron. Meg kellene tanulni helyesen forditani a forrasokat. -
kacsi01 #16 Milyen ügyes gyerek vagy, hogy rájöttél.. -
A1274815 #17 "Az hogy nincsenek kihasználva a magok, az nem a tervezők sara hanem a lusta programozóknak."
Ezzel csak az a baj, hogy az algoritmusok jó része, nehezen többszálasítható, ha egyáltalán lehetséges. Úgy hogy a videó tömörítés bizonys részeit, AI-t, meg néhány egymással nem feltétlenül kölcsönhatásba vagy együtthatásba kerülő fizikai faktorokat. De a videó tömörítésnél a jövő úgy is a GPU-é, nem kéne proci szinten annyíra törni magunkat. Inkább az órajelen dolgoznának, az utasítás végrefajtásának az idelyén, azok hasznasosabbak, de sajnos komoly kutatásokat vonnak maguk után és az pénzbe kerűl, így ez természetesen jobban megérí, főleg hogy rásegítenek egy kis agymosással. -
#18
Én mint a programozásban picit jártas ember azt veszem észre,hogy azokat a programokat könnyen lehet többszálosítani amik amúgy is nagyon lefoglalják a cpu-t.
Amik meg olyan gyorsan lefutnak hogy észre sem lehet venni, azt meg minek többszálosítani.
Pl: egy tömörítő program, könnyen többszálosítható.
Egy sugárkövetős render program is könnyen multi szálosítható.
Az erős számítás igényes dolgokhoz könnyen ki lehet találni, hogy lehetne megvalósítani a terhelés elosztást.
Mivel ezekben a programokban nagyon nagy a végrehajtás közben a redundancia, azaz sokszor milliószor fut le egymás után ugyan az a kód, csak más más adatokon végez műveleteket.
Az lenne a fasza,hogy már egyből több szálas gondolkodásra tanítanák a programozókat a suliban. Most nemsokára jönnek a 8 magus cpu-k és még csak megemlítik hogy a win támogatja a többszálúságot. Még csak nem is alapkövetelmény a többszálas programkódok írása vizsgákon. -
Dodo55 #20 Na ja, szidja itt mindenki a programozókat, csak azt nem bírják felfogni, hogy a többszálra optimalizálás nem pár sor, hanem sok esetben a program teljes átgondolása és újraírása, már amennyiben egyáltalán optimalizálható, mert az esetek többségében egy egyszerűbb program nem az.
Az utasítások egymás után következnek, hiába szedjük 4 felé őket, attól még nem lesz 4x olyan gyors a program, mert meg kell várnia az előző utasítás befejezését.
Szóval csak akkor lehet többszálú működésre megírni egy programot, ha vannak benne egymástól teljesen függetlenül végrehajtható kódrészletek, de még akkor is figyelni kell az időzítésre. -
A1274815 #21 Tudom, rosszul fogalmaztam meg ugyan, de erre akartam utalni. Többek között lehet redundáns a cucc és mégse tudom többszálasítani, mert az egyik végeredményétől függ a másik. -
#23
Akadnak olyan problémák ahól nem lehet elosztani a számításokat, mert nagyon szorosak a függőségek.
De általában az ilyen programok gyorsan végre hajtódnak, nem kell nekik sok proci idő.
De a gépigényes program 99% épp olyan amit könnyen többszálosíthatnának.
Ott vannak a grafikai, játék motorok. Még mindig egymagosra vannak megírva holott azt mondják már többszálosítottak.
Szerintem nem olyan nehéz az a több szálas programozás, mivel a szálakat az oprendszer kezeli, borland és visual c++ ban egyszerű függvényekkel lehet kezelni az egész szál futását, teljes mértékben támogatva az objektum orientált szemléletet, bármilyen tagot közösen használhatóvá lehet tenni, akár szinkronizálni is lehet a futást úgy hogy ezzel már te nem foglalkozol hanem az op rendszer.
Azt akarom mondani hogy egy 2+2 , összeadó programot nem lehet többszálúsítani de nincs is értelme.
Ellenben ha egy 4 gigás adatbázisban kell egy szót megkeresni, akkor ha ezt 1000 magra elosztod akkor minden magra jut 4 megabájt amit át kell vizsgálni, tehát itt gyakorlatilag ezerszer gyorsabban jön az eredmény.
Én nem nagyon tudok olyan algoritmusról ami olyan nagy vagy olyan nagy adattömbökön dolgozik amik több száz vagy több gigás méretűek és nem lehetne őket több szálakra lebontani.
-
RealPhoenixx #24 Frayer: tobbmindenben igazad van
Kiegeszites: a titkositasok java, ha nem lancolt, es plane ha nem csalo titkositasokrol van szo, mint pl ssl ssh pgp es hasonlok, szval akkor siman parhuzamosithato minden, de mivel gyakori a csalas a titkosito programokban is, meg a konnyu megoldasok valsztasa, ezert nem kell ezeknek a programoknak akkora szamitasi kapac igeny, masfelol pedig a keszitoket kiba modon nem erdekli az hogy csalasmentes legyen a cucc, mert megkapjak erte a kis lovet vagy valami mast (mar aki ert hozza), aki pedig nem, annak nincs is fingja arrol, hogy mekkora szart hasznal vagy fejleszt *mas oldalrol, pl> grafika, etc*.
KVP:
erdekel a cucc, amit a 11-es hozzaszolasodban emlitettel, meg tudsz adni nehany forrast esetleg doksit???? -
#25
Amiről kvp beszél az nem létezik tudtommal.
Én nem hallottam még 1 bites cpu ról, nem is lenne értelme neki.
Egy x.86 os logikai áramkőr is alsó hangon több száz ezer tranzisztor, a nagyon kezdetleges első 32 bites ilyen a 386- os volt, ilyen 350 ezer tranzisztoros, semmi pipeline és egy órajel alatt kb, 0.2 - 0.3 x.86 os utasítást tudott végrehajtani.
Nekem lenne egy jó 5letem egy baromi jó x.86 os arhitektúrára, minden megvan hozzá, csak még a buszrendszerét kellene megírni.
Úgy képzelem el,hogy egy nagy 2d mátrixban 32 x 32 db x.86 os áramkört sorba pakolni és mindegyik rá lenne kötve egy- egy buszra amik sorban és oszlopban kötnék össze a magokat.
Nem olyan bonyolult amúgy.
Minden megvan hozzá már, csak ezt a buszt kellene megírni.
x.86 os áramkörből van egypár az opencore-on.
Bele is kezdenék a dologba ha tudnám hogy a végére is érhetnék, és ha nem lennének millió dolláros költségek a fizikai megvalósításukban. pld. litográfia maszk készítés, tsmc- nél a chipek legyártása stb. Túl drága lenne hobbynak, fpga-hoz meg túl nagyszabású project lenne.
-
floatr #26 Bitszelet processzorok -
bvalek2 #27 Én már terveztem utasításkészletet, meg írtam fordítót, gyártsunk nulláról architektúrát!
- kell írni emulátort, utasításkészlet, prociarchitektúra, kezelje a memóriát, meg mondjuk PCI-t (az emulátoron belül természetesen)
- fordítóprogram az emulált processzorra
- minimális operációs rendszer, némi driver
ki mit vállal a feladatok közül?
-
#28
A 486-os ötlet elsőre jól hangzik, de az a logika ami elosztaná a feladatot 1000 proci között... Ha meg szoftver szinten akarod megvalósítani, akkor meg azért lassul be. Egyébként meg a procik szuperskaláris felépítésüek a Pentium óta, tehát nagyon is létezik már egy magon belülis párhuzamosítás. A töbszálas programozásról meg annyit, hogy ez a szemlélet, hogy ami sokáig fut azt jól lehet párhuzamosítani, nem igazán állja meg a helyét. -
dez #29 "a mostani procik melyek több száz millió tranzisztorosak kb, órajelenként 4-6 utasítást hajtanak végre"
Nem éppen. Ennyit még elméletben sem tudnak, de gyakorlatilag meg 1, azaz egy körül alakul az IPC (instruction per clock), annyira szar a kód, amit végrehajtanak. -
bvalek2 #30 Íme a HCA-2010 (Hungarian Computer Architecture 2010) rövid vázlata:
- regiszterek: 128 darab 128 bites regiszter, egyaránt lehet bennük float és integer tömb, az utasításon múlik hogy mit tesz a tartalmával.
- adattípusok: 1, 2, 4, ... - 128 bites előjeles integer tömbök, és 16, 32, 64, 128 bites float tömbök
- utasítások: 32 bites fix hosszúak, az aritmetikaiak 3 operandusúak, és a regiszterben tömbökön végeznek műveletet, pl. bájot összeadása azt jelenti, hogy a 128 bites regiszterekben minden bájtot regiszterpáronként összead
- párhuzamosítás: egyszerre 4 utasítás hajtódik végre, ha regiszterütközés van, akkor nincs újrarendezés, hanem megy a kivétel a system kódnak, mint Itaniumon
- több mag: fontos a közös cache (systemkód lekezeli) hogy a szálak közötti beszélgetésnél a szemaforok elérése minél gyorsabb legyen
- memóriacímzés: 64 bites, és 16 bites szavakat címez, 8 bites bájtok helyett, szóval ami nálunk 4 gigaword, az pl. Intelnél 8 gigabyte
- lapozás: transaction lookaside buffer van, ha van címtalálat, oké, ha nincs akkor megy a kivétel, mint az Alpha processzornál, legyen minél egyszerűbb
a részleteket nem dolgoztam ki, de el lehet játszani vele, hogy minden regiszter 128 bites, a memóriacímek 64 bitesek, egy regiszterben két cím, miket lehetne művelni... na mi lesz, elkezdjük? :)
dokumentálni kéne, meg C-ben nekiállni valami emulációnak, hogy legyen mire programot írni. -
dez #31 És milyen program is lenne az olyan, aminek több millió utasítását egymástól teljesen függetlenül lehet végrehajtani...????
Egy értelmes kódnak max. egymás utáni pár utasítását lehet párhuzamosan feldolgozni, ha elég jó optimizációval született. Ha nem annyira jó (ez a jellemző), akkor max. 1-2 utasítást.
Persze képfeldolgozáskor minden pixelre külön végre lehet hajtani kódokat (mint a mai GPU-kban a pixel shaderek), de itt is többszázmillió tranyó kell max. néhányszáz pixellel egyszerre dolgozó chipekhez (G80: 128, R600: 64 [de egyszerre akár 5 utasítás, illetve x többelemű SIMD utasítás]). -
bvalek2 #32 Ez így van, az, hogy 3-4 egymástól független utasítással lássák el a processzort, már az Itániumnál is komoly gondokat okozott, a fordítók belegebednek. Viszont ez még megoldható, ha processzort terveznék, ilyenre csinálnám, lásd lent :) -
dez #33 Egyébként a 486-ost mai gyártástechnolgógiával sem lehetne 4 GHz-en járatni, nem olyan a felépítése.
Viszont, pl. az Intel Larrabee-je éppen ilyesmi lesz: egyszerűsített x86 magok, de azokból többtíz egy chipen. A Cell is ilyesmi, csak ott az SPE-k még egyszerűbbek, hogy minnél több lehessen belőlük. -
dez #34 Az első 3 pont a Cell SPE-ire is igaz (csak a 2. pontnál nem 1 bittől kezdődik az integer végrehajtás). Asszem, a 4. pont is áll annyi különbséggel, hogy egyszerre 2 utasítás. Közös cache nincs, sőt nem is cache van az SPE-knél, hanem belső, címezhető, nagyon gyors elérésű memória-blokkok. A külső memóriát nem lehet közvetlenül, utasítás-szinten címezni, csak blokkosan elérni, így rá van kényszerítve a programozó, hogy optimálisan bánjon a belső memóriákkal, és a belső és a külső közötti adatmozgatást is minnél optimálisabban csinálja. Így lehet ugyanannyi tranyóból jóval nagyobb számítási kapacitást kihozni...
A közös cache-en gondolom, nem a L1-re gondolsz. -
dez #35 Egyébként az IBM az utóbbi időben arra törekszik, hogy az amúgy sem igazán kihasznált, sok tranyóba kerülő többszörös superscalar végrehajtás helyett egyszerűsít, ami által jobban növelhető az órajel. A POWER 6 65nm-en is közel 5 GHz-en járatható - mármint nem extrém, 200W-os fogyasztásokat produkáló túlhajtás eredményeképp, hanem normál körülmények között. A számításigényes dolgokat meg csinálják inkább vektorproci-magok (a Cell-ben az SPE-k). A 45nm-es Cell egyébként már 6 GHz-en járatható, 32nm-en ez még tovább gyorsul, és mind a PPE-ből, mind az SPE-kből több lesz, mint most. -
dez #36 (Most 256 KB a belső memória SPE-nként, de az utasításkódok ha jól emlékszem 2MB megcímzését teszik lehetővé, és várhatóan kisebb csíkszélességeknél ezt ki is használják majd.) -
bvalek2 #37 valamilyen másodszintű közös cache kell az egy chipen lévő magoknak, szerintem jót tenne az interprocessz kommunikációnak. a közös memóriakontroller oldhatná meg a szinkronizálást a memóriával, az egyes magok TLB-je alapján. Így, ha egy mag a TLB-ben felvesz egy lapcímet, garantáltan L2 cache-be kerülne a tartalma. Legyen akkora a TLB, hogy az egész L2-őt le tudja képezni, és nem kell áramköri logika a lejárt lapok ürítéséhez. Ami nem kell, az amint felülíródik a TLB-ben, a cache-ben is. L1-ekbe már az egyes magok TLB-je alapján kerül memóriatartalom, L2-ből.
csak eszmefuttatok, szólj ha hibás vagy hiányos az ötlet.
Na meg már a regisztertár is szép nagy, 128 * 128 bit = 2048 byte. Azon goldolkoztam, hogy lehetne 1 magonként több regisztertár, mondjuk 16 darab, a plusz 16 * 2 KB SRAM + a kezelő elektronika talán elég kicsi befektetés ahhoz hogy megérje, ez a hyper-threading csak regiszterszinten.
Ha van magonnént legalább 16 szál, már megéri amikor taszkot vált a processzor, csak egy 16 bites rendszer-regiszterben kell megadni, hogy melyik az aktuális regisztertár. ez egyszerűbb, mint ki-be másolgatni cache-ből (remélem az ilyen infó minden prociban legalább a cache-ben van).
Ha processzoronként 16 mag van, az 256 szál kezelését jelenti, ami minden egyprocesszoros gépnek elég. Ennél többet már többprocesszoros gépek kezelnek. -
#38
Szerinted mi dönti el, hogy mekkora frekvencián járatható max a proci a felépítésében?
Nem a gyártástechnológiára gondlok, hanem azokra amik a tervező asztalnál dőlnek el. Mint forró pontok minimalizálása.
Használ itt valaki valamilyen hardver leíró nyelvet?
Egy 486-os magot át lehetne alakítani úgy hogy nagyon egyszerű legyen és baromi gyors?
Ha lenne egy ezer magos procink, nem lenne gond megírni rá ilyen programokat.
Azokat a programokat amiket meg lehet írni 2 szálra, vagy 4 szálra, ugyan úgy meg lehet írni 1000 szálra is.
-
bvalek2 #39 Lényegében a vezetékek hossza dönti el, mert a jel sebessége még ideális esetben sem lehet nagyobb mint a fénysebesség. Szóval szerintem a tervezőasztalon meg kell oldani, hogy órajelenként végigérjen minden jel az összes vezetéken. Gyakoribb órajel érdekében ezért a teljes úthosszt rövidíteni kell. Erre az x86-os architektúra alapból nem alkalmas, az utasításokban olyan sok a dependencia, és ellenőrizendő kondíció, ami rengeteg extra áramkör munkáját jelenti, és ez nagyon megnöveli a jelek teljes úthosszát.
Ezért lehetett annak idején az Alpha a rekorder, ugyanazon a gyártástechnológián sokkal nagyobb órajelen üzemelt mint a Pentium. Mert az utasítások függéseinek és feltételeinek a csökkentésére törekedtek a tervezőasztalon. Ezért szerintem ha processzort tervezel, úgy utasításkészlet kell. Én is éppen ilyesmin agyalok. -
#40
Na, akkor jobb ha összebratyizunk, mert én is agyalok rajta elméleti szinten.
De nálam az alapfeltétel az x86 os kompatibilitás, legalább 386 szintjéig.
Persze nem 32 bites címbusszal, hanem 64 el, és az adatoknak sem ártana egy 128, vagy 256 bites címbusz, sokkal gyorsabban lapozna be nagyobb adattömböket az áramkör a cache-be, egy magra nem nagyon jutna több cache mint 8kb.
Megnézem ezt az alpha procit, melyik generációrol beszélsz? -
#41
Order-Number Product MHz
21064-AA 21064 150
21064-CA 21064 166
21064-BA 21064 200
21064-BB 21064 233
21064-DB 21064 275
21064-AB 21064A 200
21064-BB 21064A 233
21064-DB 21064A 275
21064-P1 21064A-PC (for NT) 275
21064-EB 21064A 300
Core Frequency: 150 MHz
Data bus (ext.): 64 Bit
Address bus: 64 Bit
Transistors: 1,680,000
Circuit Size: 0.75 µ
Voltage: 3.3 V
Introduced: February 1992
Manufactured: week 13/1993
L1 Cache: 8+8 KB
L2 Cache: ext. 512 KB
Az első alpha proci.
A sorban meg 300 mhz a maximum.
Inkább akkor maradjunk egy kompatibilis x86-os áramkörnél :)
Ha nem így teszünk minden programot át kellene portolni, egy linux kernel átportolása egy hardverre több ezer ember több ezer órájába is bele telne.
Ennyi idő alatt újabb procit is tervezünk akkor már. :)
Legyünk reálisabbak, alakítsunk át egy meglévő magot, és majd egy fpga-n.
FPGA
Tesztlejük, az ide készlethez van hardveres szimulátor, meg elemző rendszer.
Csak annyi a dolgunk hogy vhdl vagy verilog nyelven létrehozzuk a productumot :)) -
bvalek2 #42 Amikor még tanulgattam a programozást, felraktam a dolgaimat a Geocities-re, ezek még erősen kezdő próbálkozások voltak: http://www.geocities.com/bvalek2/
Van köztük egy kisérlet Alpha processzor emulációra, akkor tanultam sokat róla. Már nem sok mindenre emlékszem, hogyan működött, meg ilyenek, szóval erősen unsupported. Abban reménykedem, hogy rendesen dokumentáltam... :)
Ebből láthatod hogy inkább szoftveres ember vagyok, a hardverről annyi fogalmam van, ami a rendszerprogramozáshoz kell, több nem. Szívesen nekiállnék egy újabb processzor emulációnak a mai eszemmel, gondolkoztam rajta, hogy megint nekiállok Alphának, de egyszerűbb a saját architektúra, menet közben lehet rajta változtatni ha valami gáz van vele, na meg egyből fejből tudom a felépítését, nem kell megtanulni :)
Komolyra ferdítve a szót, hacsak nem pénz van a dologban, x86-os architektúra csak szívás. Vagy Alpha, vagy egy kitalált, amit lehetne emulálni, meg IC-kből megvalósítani. Leíró nyelvekben nem hiszek, Istenfélő ember emulátort C-ben ír... :)
Ja és szívesen írnék rá fordítót és oprendszert. Ismételten, ha ez csak hobbiprojekt, akkor saját programnyelvet javaslok C helyett. De persze egy hobbiprojekt is idővel komollyá válhat, és abban az esetben természetesen C-fordítóra is vállalkozok.
Ha mindenképpen létező architektúrát akarsz, legyen Alpha szerintem. Még IC-kből összerakni is könnyebb lenne szerintem. Az első generáció a legtisztább megvalósítása az elvnek. -
bvalek2 #43 Azt hiszem értem hogy mit szeretnél. Akkor a kitalált architektúra kilőve. Az Alpha a legjobban támogatott Linuxos architektúra az x86-os után, szóval portolni nem kell, minden fut rajta. Sőt, még Windows NT 4.0 is volt rá :)
És mivel már ügyködtem vele, ismerem is egy picit, csak fel kell elevenítenem a tudományomat, mert felejtettem rendesen... VHDL-t Verilog-ot sajnos nem ismerem. -
#44
Én sem ismerem nagyon a hardveres leíró nyelveket, de valahól el kell kezdeni, eddig én is csak szoftveres úton haladtam.
Hozzunk létre egy topikot, és aki akar beszálhat.
Egyelőre elmélkedhetnénk azon,hogy mik legyenek a célok, valami olyasmit kellene csinálni amit még nem csinálnak. Ami olyan drasztikus hogy csak a hozzánk hasonló elborult elmékben létezik még.
Én speciel egy 1024 magos chipre gondoltam.
Amit egy vadi új mátrix rendszerbe kötött buszrendszer kötne össze.
Minden chip egy vertikális és egy horizontális busszal lenne összekötve, 64 ilyen busz van, minden buszon 32 mag csücsül és figyel.
A buszok párhuzamos rendszerűek lennének, szemafor sorompóval és jelütközés figyelővel, azért ilyenre gondoltam mert így egy óra jel alatt cserélhetnének jelet a magok egymással és nem kellene kivárni a soronkövetkezést.
Ez egy véletlen elérésű buszrendsze lenne. Amikor az egyik proci ír rá, a többi 31 db a következő szintet vizsgálja és ha szabad a szemafor akkor azon próbál meg üzenetet küldeni, mivel párhuzamos a rendszer, akár 4 ilyen párhuzamos busz is lehet egymás mellett, így csökkentve az ütközéseket és várakozásokat.
4 ilyen busz egymás mellett 128 GigaBájt adatot tudna szállítani /s.
A 64 db ol álló rendszer meg több mint 8 terrabájtot, úgy hogy az egy vezetékre jutó forgalom nem haladná meg az 1 gigabájt / sec-et. Tehát nem kellene új gyártás technológia, mivel úgy tudom,hogy az intel 90 nm nél már 10 GB /s el számolt egy vezetéken átvihető jelek mennyiségénél.
-
bvalek2 #45 Ha sok a mag, és hosszúak a buszok, és egy órajel alatt akarod hogy szinkron beszélgessenek, akkor nem sok órajel lehet másodpercenként.
Különben mire kell az ilyen processzor? 1024 mag egy prociban, mire kell? Nem általános célú magokat szoktak ennyire halmozni, mert azoknak a teljesítménye csak logaritmikusan növekszik tőle. -
#46
Pajti, én x86 os magokra gondoltam.
Azaz általánosított lenne. Szerintem nagyon fontos,hogy megmaradjon az x86 kompatibilitás, úgy talán lenne is neki jövője.
Gondolj bele, milyen lenne egy 1000 magos webszerver, adatbázisszerver, vagy milyen jól jönne a cad-cam szoftvereknek, vagy render parkoknak.
Azért általános x.86 os magok kellenének, mert így elég lenne csupán azt a drivert megírni az bármely op rendszer alá, amely a szálakat kezeli, azaz olyan függvényeket szolgáltat szoftveresen amely lehetővé teszi a magok közti kommunikációt, mely egyszerű megszakítoskkal lennének megvalósítva hardveresen, semmi túl bonyolítás. Minél egyszerűbb annál gyorsabb is lehet.
Nem kellene foglalkozni a programok átportolásával. Még a quake is menne rajta , igaz egy magon.
A buszrendszer nagyon rövid lenne, olyat képzelj el mint a négyzetrácsos füzet, minden csomopontban egy mag.
És akárhova címzed a forgalmat, maximum csak 1 szer kell váltania buszt, így bárhova eljuthat az adat a lehetséges legrövidebb időn belül. Ha 2d-s rendszerben gondolkozol.
A vezetékek hossza meg csupán annyi amennyi kell ahoz hogy 32 db kis magocskát sorban összekössön.
valami ilyesmi lenne a buszrendszer:
+-+-+-+-+
| | | | |
+-+-+-+-+
| | | | |
+-+-+-+-+
A "+" ok a csomopontok és az ott található mag két busszal van összekötve.
32 x 32 rendszerben. -
dez #47 A hardveres multithreadingben mindig meg van legalább duplázva a regiszterkészlet. A 16x-os többszörözés kicsit soknak tűnik, nem nagyon van ilyen, aminek talán nyomós oka van.
"csak egy 16 bites rendszer-regiszterben kell megadni, hogy melyik az aktuális regisztertár."
Elég ide 4 bit is (2^4=16). :)
"Ha processzoronként 16 mag van, az 256 szál kezelését jelenti, ami minden egyprocesszoros gépnek elég. Ennél többet már többprocesszoros gépek kezelnek."
Ez a feladattól függ. Jól párhuzamosítható feladatokra nyugodtan kellhet több is (lásd GPU-k). Kevésbé jól párhuzamosíthatóra meg sok is. -
dez #48 "Persze nem 32 bites címbusszal, hanem 64 el, és az adatoknak sem ártana egy 128, vagy 256 bites címbusz, sokkal gyorsabban lapozna be nagyobb adattömböket az áramkör a cache-be"
Izé, itt egy kicsit keverednek a fogalmak. A címbusz szélessége a fizikailag megcímezhető memória méretét szabja meg, nem az adatmozgatási szélességet. Utóbbit az adatbusz szélessége határozza meg. (Bár ezek egy ideje multiplexáltak.)