57
-
dez #57 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). :) -
bandee1 #56 TAKARITSÁTOK MÁR LE EZEKET A TELEBASZOTT HAZUG POLITIKAI FIBASZOS REKLÁMOKAT INNEN! -
RealPhoenixx #55 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 -
dez #54 Ja, hogy te vagy az, és ez az új mániád... ;) Sok sikert! -
dez #53 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. -
#52
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ő. -
dez #51 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. :) -
#50
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. -
#49
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. -
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.) -
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. -
#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. -
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. -
#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 #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. -
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. -
#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 :)) -
#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? -
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. -
#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 #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. -
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.) -
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 #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 #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. -
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 #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 #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 #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. -
#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. -
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?
-
floatr #26 Bitszelet processzorok -
#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.
-
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???? -
#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.
-
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. -
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. -
#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. -
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. -
kacsi01 #16 Milyen ügyes gyerek vagy, hogy rájöttél..
