Miért nem tudunk 256 / 512 / 1024 / akármennyi bites számítógépeket építeni?

Ha tényleg az a célod, hogy a lehető legnagyobb legyen a CPU, akkor már előkerülnek az olyan kérdések, hogy mi számít egy CPU-nak. A POWER-ek meg z/Architecture chipek simán elérik a 600 mm^2-t, az NVidiának volt pár ennél is nagyobb GPU-ja. De ez egy chip mérete. Ezekből többet is bele lehet rakni egy tokba. Például a Pentium D-k pont így készültek, két processzor egy tokban, amik az FSB-n keresztül kommunikáltak egymással. Itt a korlát a magok közötti kommunikáció lesz. Sávszélesség, késleltetés, ilyesmik.

Vagy lehet a CPU egy egység, amit együtt kezelsz, és számol. Régen igen gyakori volt, hogy ami ma egy chip, azt több chippel oldották meg. Például az Intel iAPX 432-es rendszerében a ,,processzor'' két chipből állt. Az egyik töltötte be, és dekódolta az utasításokat, a másik végrehajtotta őket. Ott mi számít akkor számodra CPU-nak?

Vagy van egy úgynevezett Wafer Scale Engine, amit AI gyorsításra találtak ki. A nevének megfelelően egy egész szilícium ostyányi a chip maga. De ezen külön kisebb egységek vannak (a levilágítás korlátját ők sem tudják megkerülni), csak ezek magán az ostyán vannak összekötve. Akkor ez egy processzor?

De tekinthetünk egy processzornak egy egész rackszekrényt tele chipekkel, ugyanis kívülről édesmindegy, hogy az ott egy chip, vagy sok. (Ez kicsit csúsztatás, ugyanis a magok közötti kommunikáció szempontjából nagyon is számít, de ha azt elfedi előlünk egy absztrakciós réteg, akkor már mindegy lesz.)

De a rövid válasz az, amit már többször is leírtak neked. Gazdaságosság. Minél nagyobb egy chip, annál drágább gyártani, mert a selejtarány a területtel arányosan nő. Ezért lehetnek a POWER-ök, z/Architecture-ök és HPC-ben használt GPU-k olyan nagyok, mert akkora profit van egy chipen is, hogy megéri tíz selejtet gyártani egy eladott chip mellé. (Nyilván túlzás, pontos számokat természetesen nem ismerek.) Ezzel szemben az otthoni felhasználásra gyártott chipeken a haszon sokkal kisebb, ott minden egyes selejtet megéreznek. Úgyhogy kisebb méret sokkal gazdaságosabb. (És a kicsit hibás darabokat el lehet adni gyengébb modellnek.)

Azért ennyi sületlenséget mint itt a több válaszadó összehozott ritkán lehet olvasni. Szerencsére azért vannak nagyon jó bálaszok.

1./ Amiben többekknek igaza van, az, hogy "minek" a jelenlegi technológiai szinten bőségesen elegendő az ami most van.

2./ Nem csak a hűtés a probléma (max. nagyobb méretű lenne a proci, nem egy tokban lenne hanem több tokban. elektroncsővel is épült számítógép, meg diszkrét tranzisztorból is, megoldották). Egy rakás egyéb probléma is fellépne.

Egyik alapvető probléma ott lesz, hogy ha nagyon sok vezetéket kell egyszerre párhuzamosan kapuzni (pl. buszra rátenni egy regiszter értékét) egy idő után olyan számosság kapcsoló elemet kéne rátenni, hogy annyira megnőne a busz vezérlő terhelése, hogy problémákat okozna. Erre megoldás lehet, hogy több csoportba vannak kötve a buszvezérlők és egy-egy vezérlő "csak" néhány tucat busz vezetéket kapuz, ekkor viszont kell valami ami ezeket összefogja, így egy buszműveletnél már 2x lesz a kapuk késleltetése tehát már itt kezdődik, hogy egy adott méret fölött csak azért mert több cosportban kell a buszvezérlőket kialakítani nem biztos, hogy annyit nyerünk sebességben. Pl. 2048 db. MOSFET-et kéne egyszerre feltölteni, kisütni (és akkor még csak 1024 bites a procink) jelentős lesz az eredő G-S kapacítás, csökkenti a sebességet mert fel kell tölteni és ki kell sütni a G-S kapacitást. Szedjük szét kb. 64-es csoportokba (64 még egészen kezelhető) ekkor 16 db. csoport lesz, és kell egy olyan áramkör amelyik a 16 csoportot vezérli (plusz késleltetés).

Második szintén nem elhanyagolható probléma az ALU esete. Ha az ALU-ban csak az összeadó áramkört nézzük, akkor vagy egy összeadó láncot építenek ami tetszőleges bitig bővíthető. Ennek hibája, hogy az átvitel akkor jön létre amikor egy bitpáron végzett a művelettel (azaz A4 A3 A2 A1 A0 + B4 B3 B2 B1 B0 bitekből álló számot kell összedni akkor A0+B0 fog egy D0 eredményt és egy C0 átvitelt generálni, a második biten A1+B1+C0-t kell számolni és ebből lesz egy D1 eredmény és egy C1 átvitel). Itt minden fokozat késleltetés összadódik a végére már kezelhetetlen lesz a késleltetési idő, és arra fog várni a cucc, hogy végig "fusson" a Carry. Ez a legegyszerűbb összeadó felépítés. Legyen csak 0,1 nanosec egy fokozat késleltetése 16000 bites összeadónál /valamelyik kommentben erre kérdeztél/ 1,6 mikrosec lesz a késleltetés, ennél nagyobb órajellel nem fog menni a proci ez 625 kHz(!)-et fog jelenteni. Vannak olyan megoldások, hogy szintén több lépésben számolják a Carry-t pl. 4-es 8-as csoportoban és egy-egy csoporton belül már "hagyományos" összeadót használnak, de ekkor is lesznek problémák mire "végig fut" az egész láncon. Amennyit nyernénk "sebességben" elveszítjük, hogy vagy elképesztően bonyolult lesz az ALU (plusz szintén bejön a késleltetés mint probléma, mert minnél több "hierarchia szint" kell pl. az összeadásnál a Carry képzéshez annál nagyobb a késleltetés) és ott fogjuk bukni a mutatványt.

Ha meg visszatérünk oda ahonnan elindultunk, hogy soros az ALU és nem párhuzamos (ld. First Draft) akkor megint ott tartunk, hogy iszonyú ideig tart maga a művelet elvégzése. Mert szép sorban kell a biteket betolni. Ekkor nem lenne nagyon bonyolult az ALU cask irtózatosan lassú. Összeadni néhány 100 bitig lehetséges belátható bonyolultságú áramkörrel, egy idő után már a bitek számának növelése túlbonyolítja és lassítja az össszeadás műveletét. Ugyanígy pl. egy balra shift vagy jobbra shift művelet is nagyon időigényes lesz, mert ahhoz is elég sok kapu áramkör fog kelleni. És ez nem integrálás kérdése, meg stb. hanem az, hogy egy idő után nem lehet egyszerűsíteni a logikai függvényeket. Magunkat a műveleteket el kell végezni.

Ahogy növekszik egy busz széléssegé úgy kell csökkentei a buszon a sebességet, mert kezdnek kialakulni különbségek a busz két vége között. Pl. egy kis hőmérséklet különbség és a busz egyik végén és a másik végén nem egyforma sebességgel kapcsolnak a tranzisztorok. Úgy kell belőni majd a busz sebességet, hogy ez a probléma ne okozzon gondot. Ez egyébként a diszkrét elemes gépeknél is okozott problémát, hogy vissza kellett venni a sebességből, hogy szinkronban tudjon maradni a gép.

Miért nincs mondjuk 1000 rekeszes pénztárca? Miért nincs 100 égőfejes gáztűzhely? Mert nincs rá igény.

Az, hogy hány bites architektúráról van szó, annak minimális köze van a gép számítási képességéhez. Vagy legalábbis ma a gyakorlatban így van.

1. A bitek száma határozza meg, hogy mekkora szám ábrázolható egy szón. 16 bites rendszereknél ez azért elég erős korlát volt, lévén 65 535 volt a legnagyobb előjel nélküli egész, ami ábrázolható volt. De még a 32 bites rendszereknél is korlátot jelenthet a 4,2 milliárd, mint legnagyobb egy szón ábrázolható egész. 64 biten ez a korlát 1,8*10^19. Ekkora számokat már a gyakorlatban sem szoktunk pontosan leírni, most sem írtam le ennek a számnak mind a 20 számjegyét. A gyakorlatban ekkora számok esetén bőven elég egy lebegőpontos számábrázolás. A dupla pontosságú lebegőpontos ábrázolásra is viszonylag ritkán van szükség, de az is 64 bit.

2. A bitek száma meghatározó lehet, hogy mennyi memóriát képes kezelni a rendszer. Ha a címet egy 16 bites számmal adod meg, akkor 64 kB memória lesz megcímezhető, ha többet akarsz használni, akkor már tükrözni kell. 32 bites számmal 4 GB memória címezhető meg, ezt is kinőttük, bár jóval a 64 bites processzorok megjelenése után. 64 biten elvileg 16 milliárd terrabájtnyi memória címezhető meg (gyakorlati okok miatt van ennél erősebb limit). Ez is bőven elegendőnek tűnik egyelőre. Tehát ez sem indokolja a több bites rendszereket.

Vannak még más tényezők is, de ezek a legfontosabbak. Még speciális esetekben indokolt lehet a nagyobb bitszám, vannak is videókártyákban 128/256/512 bites memóriabuszok. Illetve ha sok független azonos műveletet kell elvégezni, akkor még kihasználható lenne a sok bit. De a felhasználók 99,x%-a az esetek 99,x%-ban nem tudná kihasználni a nagyobb bitszámú architektúra képességeit. Arra az <1%-ra meg lehet építeni célhardvert, illetve megoldható a probléma más módon illetve kompromisszumokkal.

A kezdő hasonlattal élve az emberek 99+%-a nem tudná kihasználni az 1000 rekeszes pénztárcából azt a 950 extra rekeszt, amit pluszban kap. Nem lenne mivel megtölteni. Az az elenyésző kisebbség, aki meg meg tudná tölteni azt a pénztárcát, annak sem biztos, hogy ez a jó választás, és nem járna jobban 50 darab hagyományos pénztárcával. Adott esetben a sokbites rendszer helyett lehet, hogy jobb a műveleteket párhuzamosítani, több processzormagot használni.

> Csak képzeld el: egy 8 bites számítógép versus 64 bites mennyi idő alatt adná meg pl. a PI értékét mondjuk 100000 számjegyjere?

És milyen gyakran van szükséged – pláne egy titkárnőnek – arra, hogy a PI értékét nagyon gyorsan számold ki 100000 számjegy pontossággal (ahelyett, hogy beolvasnánk egy adattárról)? Nyilván ahogy sok más dolgot sem, a processzorokat sem képzeletbeli extremitásokhoz optimalizáljuk.

> Akkor mi van akkor, amikor élőben kell egy műhold pályályát módosítani?

Milyen pontosság szükséges ehhez? Egy 64 bites egész arra is bőven elég, hogy ezredmilliméterben add meg a Nap-Plútó távolságot. Mit akarsz? Egy a Plútón található darts-táblára dobni azzal a műholddal? Eleve a műhold paramétereit (pozíció, sebesség, perdület) jóval kisebb pontossággal fogod tudni megmérni.Több bit nem fog gyorsabb számítást eredményezni. (Kevesebb bit persze tudna számítási sebességet növelni, de az más tészta.)

> Másképpen: k...-ra nem a tárterület érdekel, amit megcímezhetek, hanem a sebesség.

Na, pont azt nem fogja növelni a több bit. Ahogy az 1000 rekeszes pénztárcától sem lesz több pénzed, és a 100 égőfejes gáztűzhelytől sem fog gyorsabban megfőni a húsleves.

~ ~ ~

Gyakorlati haszna tehát a 64 bites processzorokhoz képest egy 256/512/1024 bites processzornak nem igazán lenne. Gyakorlati hátránya annál több. Több tranzisztor kellene hozzá, ez több hibalehetőséget ad a gyártásnál, több áramot fogyasztana, nagyobb hőt termelne, emiatt nagyobb lenne a processzor ára és a működtetés költsége stb. stb…

~ ~ ~

> Miért ne lehetne egy processzor akár alaplap méretű?

Sok okosságot leírtak az előző válaszolók. Hadd említsem meg még egyet. A fénysebesség 299 792 458 m/s. Egy 5 GH-es órajelű processzornál egy órajelciklus 1/5 000 000 000 másodperc alatt kell, hogy lefusson. Ennyi idő alatt az információ maximum 6 cm távolságot tud megtenni. És tegyük hozzá, hogy az információ a processzoron belül nem egyenes úton halad és nem is folyamatosan vákuumbeli fénysebességgel. Egy alaplap méretű processzor nem tudna 5 GHz-en működni, vagy ha igen, akkor bizonyos műveletkombinációk sokkal több órajelciklust vennének igénybe.

De ha még a fénysebesség jóval nagyobb is lenne, akkor is… Több bit → több tranzisztor → nagyobb méret → hosszabb utat kell megtenni az információnak → lassabb működés

Messzebb lennének a "magok" ezáltal nem lenne gyorsabb.

De erről (is) van egy rakat szájbarágós videó youtube-on.

Remek "informatikus" lehetsz, ha még a keresőt sem tudod használni

"64 bites alaplapom ... messze szarabb, mint a régi Windows XP"

Nem tilos használni a régi socket478-as 32bites P4 gépeket ma is. :)