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
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õ.
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.
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.
"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.
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.
É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.
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.
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.
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 :))
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?
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.
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.
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.
(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...
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 :)
É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]).
- 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.
"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.
É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
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.
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????
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.
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.
"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.
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.
Minek már 6 magos, még a 4 magos sincs kihasználva, sõt a 2 magos sem igazán... Mit akarnak ezek?
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...
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.
Informatika és tudomány
KVP: 