 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)
Tudom, hogy van ráció az ilyesmi tömörítésekben, de szerintem nem mai gépeknek való feladat. De ha már elkezdett vele foglalkozni, hát csinálja (ne csak beszéljen róla). Pihenésképp tőlem tervezzen új szuperprocit, de azért talán nézzen utána, miért nem lehet pl. 3 GHz-en hajtani egy 486-ost (mai gyártástechkel sem). :)
|
TAKARITSÁTOK MÁR LE EZEKET A TELEBASZOTT HAZUG POLITIKAI FIBASZOS REKLÁMOKAT INNEN!
|
Dez: ne bantsad, en csipem ot :)
NB: a tomoritot pedig mar parszor atgondoltam, es valszeg igen, lehet faint csinalni, bar sztem kicsit tul buzgon rakapott es elszamolta a becsult dolgokat, szval lehet hogy majd beszallok, ha a sajat dolgaim rendbe lesznek
Asus P5E; Q6600@3,4GHZ; Dragon 800MHZ 8G, Asus 8600GT; Samsung 1,25T; Dragon haz; Cooler Master M620; Logitech G5; Schyte Ninja 1100 RevB; Canon LBP810 & Lide 600F; LG L226WTQ & Belinea 21"; NEC RW
|
Ja, hogy te vagy az, és ez az új mániád... ;) Sok sikert!
|
Lehetne akár a L2 is 16 MB, mert nem a jelenlegi chipekhez hasonló MCM (multi-chip module) lesz, hanem monolítikus. De mindegy, mert tényleg a köv. hsz-edben leírt felépítés valósul meg:
De van itt nagyobb hiba is a cikkben: Ennek a chipnek köze nincs a Quick Path Interconnecthez. Nem is lehetne, mert lábkompatibilis a mai 4-magosokkal, amik a szokásos Inteles FSB-t használják. A QPI a Nehalemekkel jön, új tokozásokban.
|
igen :)
pontosan ezt akarom megcsinálni
Nemsokára lesz egy xilinx edk fejlesztő parkom, ha meg lesz rá a pénzem.
Közben meg majd tanulgatom a HDL leíró nyelveket és nézegetem a procik forrásait.
Nem mondom hogy egy két hónap és lesz eredmény, de kezdetnek nem rossz.
Lehet, hogy egy két éven belül már készen is lesz a busz rendszer.
Egyáltalán nem bonyolult a működési elv, sőt, már meglévő dolgokra épül.
Ha valaki betársul hozzám, és hozzá tud adni valamit az mindig jól jön.
Ebből lehetne akár egy komolyabb project is később.
A legegyszerűbb útja meg az lenne hogy fpga-ra fejleszteni előbb, és ha már minden jól működik kicsiben, fpga-n, akkor lehetne azzal foglalkozni hogy valamelyik chip gyártó támogatás képpen legyártja a prototipusokat.
De most még lázasan dolgozok a tömörítő programon, amit beígértem.
Tudnék mutatni képeket is most de még korai lenne, egyelőre még a grafikonos analizáló rendszeren dolgozok, kb 30 % van készen.
Még kell kb 2-3 hét :( Ha ugyan ilyen lázsan dolgozok majd , de nem valószínű most hogy ilyen jó lett az idő.
I love to walk in the rain, because no one knows im crying
 |
De miért csak fantáziálsz róla? Szerezz egy FPGA IDE-t, és kezdd el megvalósítani. Oda persze nem fog elférni 1024 mag, de kezdetben jó lesz kevesebb is. :)
|
Csak azért használnék ütközésvizsgáló rendszert, mert így bármelyik mag , bármikor igény szerint férhetne hozzá a buszhoz, igaz így lehetnek ütközések, de ezt csökkenthető ha párhuzamossá tesszük a forgalmat, ha meg mégis ütközés van akkor egy két ciklus várakozás.
A többi elvű forgalom vezérlés szerintem lasabb lenne, mivel azok olyan mint egy társas játék, hogy amíg az egyik dob, a többi várakozik.
Egy ilyen ezer magos procinál szerintem nem megengedett a magok üresjárása, nem várakozhatnak folyton.
Az ütközésed rendszerben meg csak akkor várakoznának véletlen ideig amikor ütközés van.
Az meg az adatforgalomtől függően csak nagyon csekély elhanyagolható esetben valósulna meg. Mivel több adatút is lenne, ez egy párhzamos rendszer lenne.
I love to walk in the rain, because no one knows im crying
|
igazad van, címbusz helyett adatbuszt értettem, csak hanyag vagyok , nem lesem vissza mit írok, de azért remélem érthető mit akarok írni.
Azt akartam mondani, hogy mivel tegyük fel hogy 1024 db mag van a rendszerben, ez alá biztos nem lenne elég 4 gigabájt, tehát 64 bites lenne a címbusz.
És hogy minél gyorsabban történken a blokkok belapozása , minél nagyobb, szélesebb legyen az adatbusz.
Ehez persze új memória vezérlőre van szükség.
Én úgy csinálnám, hogy minden magnak lenne egy kis szelete a memóriából, pár megabájt, amihez közvetlen hozzáférne, az egész memória megosztott lenne, és ha egy másik mag is hozzá akar férni a megosztott memóriához, maga a busz intézné a megvalósítását is, a buszra kiküldött kérelem a cím szerint lesz eljutatva ahoz a maghoz amelyik a bekért memória blokkot kezeli közvetlenül, de ott nem megy át a maghoz , hanem közvetlenül a busz kiírja a memória címbuszára a kérelmet, és a proci és memória útvonal szemaforját stop-ra kapcsolja addig amíg nem jön vissza a kiolvasott adat, ha visszajött, küldi vissza a busz a kérő magnak, aztán visszabillenti a szemafort és újra jöhetnek az újabb load, store kérelmek.
Az egész úgy működne mint egy vasúti forgalom irányító rendszer.
Egyszerű, gyors, hibakorrekcióval, ha ütközés van azt érzékeli a rendszer mert a buszra írt adatokat mindig visszahalgatják a magok, ha baj van , várnak egy pár ciklust és újra próbálkoznak.
I love to walk in the rain, because no one knows im crying
|
"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.)
|
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.
|
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.
I love to walk in the rain, because no one knows im crying
|
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.
Fizikakönyvem: http://valek.webs.com/
"Az a baj az Interneten terjedő idézetekkel, hogy nem tudod róluk megállapítani, valódiak-e." /Petőfi Sándor/
|
É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.
I love to walk in the rain, because no one knows im crying
|
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.
Fizikakönyvem: http://valek.webs.com/
"Az a baj az Interneten terjedő idézetekkel, hogy nem tudod róluk megállapítani, valódiak-e." /Petőfi Sándor/
|
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.
Fizikakönyvem: http://valek.webs.com/
"Az a baj az Interneten terjedő idézetekkel, hogy nem tudod róluk megállapítani, valódiak-e." /Petőfi Sándor/
|
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 :))
I love to walk in the rain, because no one knows im crying
|
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?
I love to walk in the rain, because no one knows im crying
|
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.
Fizikakönyvem: http://valek.webs.com/
"Az a baj az Interneten terjedő idézetekkel, hogy nem tudod róluk megállapítani, valódiak-e." /Petőfi Sándor/
|
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.
I love to walk in the rain, because no one knows im crying
|
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.
Fizikakönyvem: http://valek.webs.com/
"Az a baj az Interneten terjedő idézetekkel, hogy nem tudod róluk megállapítani, valódiak-e." /Petőfi Sándor/
|
(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.)
|
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.
|
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.
|
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.
|
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 :)
Fizikakönyvem: http://valek.webs.com/
"Az a baj az Interneten terjedő idézetekkel, hogy nem tudod róluk megállapítani, valódiak-e." /Petőfi Sándor/
|
É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]).
|
Í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.
Fizikakönyvem: http://valek.webs.com/
"Az a baj az Interneten terjedő idézetekkel, hogy nem tudod róluk megállapítani, valódiak-e." /Petőfi Sándor/
|
"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.
|
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.
Gigabyte P35|Intel E5200|Kingmax 4GB DDR2 800|Sapphire HD4670 512MB|Samsung 2243NW
|
É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? 
Fizikakönyvem: http://valek.webs.com/
"Az a baj az Interneten terjedő idézetekkel, hogy nem tudod róluk megállapítani, valódiak-e." /Petőfi Sándor/
|
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.
I love to walk in the rain, because no one knows im crying
|
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????
Asus P5E; Q6600@3,4GHZ; Dragon 800MHZ 8G, Asus 8600GT; Samsung 1,25T; Dragon haz; Cooler Master M620; Logitech G5; Schyte Ninja 1100 RevB; Canon LBP810 & Lide 600F; LG L226WTQ & Belinea 21"; NEC RW
|
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.
I love to walk in the rain, because no one knows im crying
|
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.
|
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.
|
É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.
I love to walk in the rain, because no one knows im crying
|
"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.
|
Milyen ügyes gyerek vagy, hogy rájöttél..
|
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.
|
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.
|
pistike nem tud írni: programok, az lesz az..., sry
|
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.
|
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)
|
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.
I love to walk in the rain, because no one knows im crying
|
Minek már 6 magos, még a 4 magos sincs kihasználva, sőt a 2 magos sem igazán... Mit akarnak ezek?
Asus P8H61-M LX, Intel I3 2100 2x3,1 GHz, 8 Gb Ram 1333 Mhz, Inno3D Nvidia Geforce GTX 550Ti, 500 Gb HDD, Cooler Master Elite 335U.
|
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...
Fizikakönyvem: http://valek.webs.com/
"Az a baj az Interneten terjedő idézetekkel, hogy nem tudod róluk megállapítani, valódiak-e." /Petőfi Sándor/
|
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.
|
|
Nyomtatás
Elküldés e-mailben
Hatmagos chipek az Inteltől
Kiakadt az Intel az európai razzia miatt
nVidia - összeállt a 9. generáció
Intel: jön a Centrino 2
