Ajattele sitä. Mitä tarkalleen kuvittelet "256-bittisen" prosessorin olevan? Mikä tekee prosessorin bittisyydestä ensinnäkin?

Luulen, että jos lisävaatimuksia ei tehdä, prosessorin bittisyys viittaa sen ALU-leveyteen. Tämä on binääriluvun leveys, jonka se voi käsitellä natiivisti yhdellä operaatiolla. "32-bittinen" prosessori voi siis toimia suoraan enintään 32 bitin levyisillä arvoilla yksittäisissä ohjeissa. 256-bittinen prosessorisi siis sisältäisi erittäin suuren ALU: n, joka pystyy lisäämään, vähentämään, ORing, ANDing jne., 256-bittisiä numeroita yksittäisissä operaatioissa. Miksi haluat sen? Minkä ongelman vuoksi suuri ja kallis ALU kannattaa saada ja maksaa, jopa niissä tapauksissa, joissa prosessori laskee vain 100 silmukan iteraatiota ja vastaavia?

Asia on, että sinun on maksettava laaja ALU riippumatta siitä, käytätkö sitä sitten paljon vai vain pieni osa sen ominaisuuksista. 256-bittisen ALU: n perustelemiseksi sinun on löydettävä tarpeeksi tärkeä ongelma, joka voi todella hyötyä 256-bittisten sanojen manipuloinnista yksittäisissä ohjeissa. Vaikka voit todennäköisesti keksiä muutamia esimerkkejä, ei ole tarpeeksi sellaisia ​​ongelmia, jotka saavat valmistajat tuntemaan saavansa koskaan tuottoa tällaisen sirun tuottamiseen tarvittavilta merkittäviltä investoinneilta. Jos siinä on kapeita mutta tärkeitä (hyvin rahoitettuja) ongelmia, jotka voivat todella hyötyä laajasta ALU: sta, näemme sovellukselle erittäin kalliita tarkasti kohdennettuja prosessoreita. Niiden hinta kuitenkin estäisi laajan käytön kapean sovelluksen ulkopuolella, jolle se oli suunniteltu. Esimerkiksi, jos 256 bittiä mahdollistaisi tietyt salaussovellukset armeijalle, syntyisi todennäköisesti erikoistuneita 256-bittisiä prosessoreita, jotka maksavat 100--1000 dollaria. Et kuitenkaan laittaa yhtä näistä leivänpaahtimeen, virtalähteeseen tai edes autoon.

Minun pitäisi myös olla selvä, että laaja ALU ei vain kallista ALU: ta, vaan myös sirun muita osia. 256-bittinen leveä ALU tarkoittaa myös, että datapolkuja on oltava 256-bittisiä. Pelkästään se vie paljon piin aluetta. Tietojen on tultava jostain ja menemään jonnekin, joten laajaa ALU: ta on käytettävä tehokkaasti. Siinä on oltava rekisterit, välimuisti, muu muisti jne.

Toinen asia on, että voit tehdä mitä tahansa leveysaritmeettinen missä tahansa leveysprosessorissa. Voit lisätä 32-bittisen muistisanan toiseen 32-bittiseen muistisanaan PIC 18: ssa 8-ohjeissa, kun taas voit tehdä sen samalla arkkitehtuurilla, joka on skaalattu 32-bittiseksi vain kahdessa ohjeessa. Asia on, että kapea ALU ei estä sinua suorittamasta laajoja laskelmia, vain että leveät laskelmat vievät kauemmin. Kyse on siis nopeudesta, ei kyvystä. Jos tarkastelet sovellusten spektria, joiden on käytettävä tiettyjä leveyslukuja, näet hyvin harvat vaativat 256-bittisiä sanoja. Vain muutaman sovelluksen nopeuttaminen laitteistolla, joka ei auta muita, ei vain ole sen arvoista eikä tee hyvää investointia tuotekehitykseen.

No, en tiedä 256- tai 512-bittisestä, mutta olen kuullut 1024-bittisestä prosessorista (en löydä sitä juuri nyt). Sana on VLIW , joka tarkoittaa erittäin pitkää ohjesanaa . Joten se on komentoväylä, ei tietoväylän leveys. Etuna on, että voit toteuttaa ohjeiden tason rinnakkaisuuden (ILP) laajamittaisesti.

Ensimmäisen tapaamiseni ILP: n kanssa on täytynyt olla 20 vuotta sitten Motorola DSP: n kanssa, jolla oli ohjeita MAC: n suorittamiseen (kerro ja kerää) siirtäessäsi tietoja muistiin ja muistista, jotta voit suorittaa uuden MAC: n seuraavalla käskyllä ​​tuhlaamatta aikaa kahden MAC: n välillä tietojen siirtämiseen.
Nykyään on olemassa myös yleiskäyttöisiä ohjaimet, jotka tarjoavat tämän vaihtoehdon. VLIW soveltaa tätä paljon suuremmassa mittakaavassa.

Koska tietoväylän leveys ei ole yhtä leveä, käskyssä voi olla useita ohjeita ja vakioita. Syy miksi tietoväylä ei noudata trendi on, että se on melko hyödytön; 64-bittinen tietorekisteri voi edustaa 20 desimaalilukua. Milloin tarvitsit viimeksi 20 numeron tarkkuuden? Useimmissa sovelluksissa 10 \ $ ^ {20} \ $ = \ $ \ infty \ $.

Lisätietoja
VLIW-arkkitehtuuri

Mikroprosessorin "todistus" määritellään yleensä yleiskäyttöisten rekisterien koon perusteella. Koko määrittää, kuinka suuria lukuja prosessori pystyy käsittelemään natiivisti ja kuinka paljon muistia se voi käyttää. 64-bittiset numerot riittävät melkein mihin tahansa algoritmiin, ja osoitettavan muistin määrä (16 miljoonaa teratavua) riittää vielä pitkään. Yleiskäyttöisten rekisterien koon kasvattamisella ei yksinkertaisesti ole mitään etua. Kääntöpuolella aritmeettisten logiikkayksiköiden (ALU) alue, jota käytetään toimintojen suorittamiseen rekistereissä, skaalautuu bittien määrän neliöön. 256-bittinen ALU olisi 16x suurempi ja huomattavasti hitaampi.

Toisaalta on syytä laajentaa prosessoria, jotta monet pienemmät toiminnot voidaan suorittaa kerralla. Itse asiassa Intelin Sandy Bridge- ja Ivy Bridge -prosessorit tekevät juuri sen, niillä on 256-bittiset SIMD-rekisterit ja ne voivat tehdä kaksi aritmeettista operaatiota ja yhden muistitoiminnon jaksoa kohti. Joten voisi perustella kutsuvan heitä 256- tai jopa 768-bittisiksi prosessoreiksi, jos joku olisi harha markkinoija, joka haluaa taivuttaa säännöllisesti käytettyjä termejä.

Ensinnäkin prosessorin bittikoko määräytyy yleensä abstraktin arkkitehtuurin mukaan, joka näkyy konekielen ohjelmoijalle, eikä toteutuksen yksityiskohdista, kuten tietoväylän koosta.

Esimerkiksi Motorola 68000 on 32-bittinen prosessori. Siinä on 32-bittiset tietorekisterit ja 32-bittiset osoiterekisterit. Tämän arkkitehtonisen perheen ensimmäinen versio paljastaa vain 24 bittiä osoiteriviä. Lisäksi on olemassa muunnelmia, joissa on vain 8-bittinen tietoväylä (joten prosessori suorittaa 32-bittiset muistitoiminnot useina pääsysykleinä).

Nyt kysymyksestä, miksi ei mennä sivuihin 256 ja 512. "Natiivisti" manipuloida monenlaisia ​​tietotyyppejä, joten on hyödyllistä tarkastella, mitä 256 tai 512 bittiä tarkoittaa kullekin näistä tietotyypeistä erikseen. Meillä on kokonaislukuja, osoittimia ja liukulukutyyppejä.

1. Kokonaisluvut: Ohjelmat saavat paljon mittarilukemia 32- ja 64-bittisistä kokonaislukuista. Jos 64 bittiä on rajoitus, korjaukseen on oltava ohjelmistolla toteutetut bignum-kokonaisluvut. Korkean tason kielet voivat toteuttaa kokonaislukutyyppejä siten, että toiminnot siirtyvät sujuvasti "fixnumien" ja "bignumien" välillä. Tietysti otat suorituskyvyn osuman bignumeilla, mutta sinun on otettava se huomioon suuressa kuvassa: kuinka moni ohjelman toiminnoista on bignum-operaatioita. 256- tai 512-bittiset numerot eivät poista bignumien tarvetta, ne vain lisäävät tilaa, ennen kuin joudumme siirtymään bignumeihin. Jos haluat manipuloida 2048-bittisiä julkisia avaimia, 512-bittiset kokonaisluvut eivät toimi (mutta 512-bittinen bignum voi olla nopea).

2. Osoittimet: Laajemmat osoittimet mahdollistavat kaksi asiaa: laajemmat osoiteavaruudet ja osoittimeen tallennetut lisätiedot. Osoitealueet ovat nykyään virtuaalisia, joten ne voivat kasvaa, vaikka muistot eivät kasva. On ehdotettu, että jos sinulla on 128-bittisiä osoittimia, osoitetila on niin suuri, että voit sijoittaa kaikki käyttöjärjestelmän ja ytimen käyttäjä-avaruusprosessit satunnaisiin paikkoihin yhteen suojaamattomaan tilaan, ja ne ovat epätodennäköisiä törmätä. Sen sijaan, että vain luodaan suurempi osoiteavaruus, paksumpia osoittimia voidaan käyttää bittien, jotka eivät ole osoitebittejä, kuten viittausobjektin (tyyppi, koko ja muu tieto) tai tietoturvaan liittyvien tietojen kuljettamiseen. Tällaisille asioille on todennäköisesti jonkin verran "optimaalista rasvaa", ja jos arvaaisin, korvasin sen edelleen 128 bitillä. Ei vaikuta järkevältä mennä 256-bittisiin osoittimiin, älä välitä 512. Rasvemmilla osoittimilla on haitta: ne paisuttavat kaikkia tietorakenteita, jotka sisältävät osoittimia. Ja yleensä haluat, että osoittimet ovat samankokoisia, muuten tarvitset komplikaatioita komentojoukkoarkkitehtuurissa (kuten muistisegmentit), jolloin sinulla on täydet osoittimet (segmenttikuvaaja ja siirtymä) tai vain paikalliset osoittimet (siirtymä joillakin ymmärretyillä segmenteillä) .

3. Liukulukutyypit: Lisää bittejä liukulukuissa tarkoittaa tarkkuutta. Sanoisin, että liukulukutyypit hyötyvät eniten laajemmasta esityksestä. 256- tai 512-bittinen kelluva tyyppi parantaa numeerisen koodin vakautta ja monia iteraatioita vaativien tieteellisten laskelmien laatua ja kerää virheitä matkan varrella. Liukulukujen tarkkuus ei ole sama kuin kokonaislukujen tarkkuus: emme voi erottaa liukulukutyyppiä alueiksi, kuten kiinteät numerot vs. bignumit. Suurempi tarkkuus kelluvassa pisteessä vaikuttaa kaikkien epätarkkojen numeroiden laatuun, olivatpa ne lähellä nollaa tai suuria. Lisää bittejä liukuluku-eksponenteissa voi myös laajentaa huomattavasti liukulukujen aluetta ja paljon nopeammin kuin bittien lisääminen bignum-kokonaislukuun.

Näistä syistä epäilen, että hallitseva tulevaisuuden trendi on laitteistojen liukulukujen leveyden kasvu, jota ei välttämättä seuraa osoittimien ja kokonaislukujen leveyden kasvu.

Muista, että liukuluvut ovat jo edenneet muita tyypit aiemmin. Esimerkiksi jonkin aikaa meillä oli hallussaan 32-bittisiä prosessoreita, jotka tukivat 64-bittisiä IEEE-kaksoiskellukoita. Tämä johtuu siitä, että vaikka voit tehdä paljon 32-bittisillä osoittimilla ja kokonaisluvuilla, 32-bittiset kellukkeet ovat hyvin rajoitettuja vakavaan numeeriseen työhön.

Yksi erittäin hyödyllinen ominaisuus, jonka olisi mukava nähdä nousevan liukulukuesityksiin, olisi muutama varabitti tyyppi-tagille. Liukulukutyyppien toteuttaminen dynaamisissa, korkean tason kielissä (joissa esineillä on tyyppi, mutta tallennuspaikoilla on minkä tahansa tyyppisiä arvoja) on taistelu, koska kun taas varaosabittejä löytyy osoittimista ja kokonaislukuisista objekteista osien sijoittamiseksi tunnistettaessa tyyppitunnistetta, tätä on vaikea tehdä liukulukujen kanssa. Joten mitä usein tapahtuu, on se, että liukuluvut lasketaan kasaan. Jotkut järjestelmät varastavat bittiä mantissasta, joten tällöin kyseisen kielen kelluvat tyypit menettävät tarkkuuden verrattuna saman koneen muilla kielillä oleviin kellukkeisiin.

Se ei todellakaan auta sinua tekemään mitään hyödyllistä. 64-bittiset numerot antavat sinulle riittävän tarkkuuden melkein mihin tahansa tarkoitukseen (Intel-järjestelmissä on kuitenkin 80-bittinen liukuluku), mutta ylimääräiset linjat lisäävät kustannuksia ja virrankulutusta samalla, kun niillä on pieni negatiivinen vaikutus kellotaajuuteen.

Historiallisesti keskusyksiköt käyttävät bittien vähimmäismäärää, mikä on järkevää käyttötarkoitukseensa. Teknologian kehityksen myötä laajemmat väylät ja ALU: t tulivat mahdolliseksi, joten väyläkoon kasvu lisäsi laajempaa sovellettavuutta:

• 4 bittiä: tarpeeksi numerolle, joten käytännöllinen (BCD-tyylisille) laskimille , kassakoneet jne. (mikä on melko rajoitettu alue)
• 8 bittiä: riittää (ASCII) -merkkiin, käytännöllinen tekstinkäsittelyjärjestelmille (joka on ERITTÄIN laaja alue), myös matalille -laatuääntä
• 16 bittiä: kun 16-bittiä oli suosittu, 2 ^ 16 muistiosoitetta oli kohtuullinen määrä (ainakin paljon kohtuullisempi kuin 2 ^ 8 tai 2 ^ 32). 16 bittiä tuottaa melko hyväksyttävän äänenlaadun, ja useimmat A / D-muuntimet tuottavat alle 16 bittiä tulosta, joten on järkevää laskea tällaisilla arvoilla 16 bitillä
• 32 bittiä: 32 bittiä sopii useimpien tarkkuuteen (mutta ei kaikkia) ihmisen mittaamia määriä, ja ellet ole tekemisissä suurten tietokantojen kanssa, 2 ^ 32 osoitetta olivat riittäviä käytännöllisimpiin tarkoituksiin.
• 64 bittiä:> 2 ^ 32 tavua muistia on nyt käytännöllinen.
• 128 bittiä: tällä hetkellä pieni etu 32: een nähden, paitsi salaus. Milloin kiintolevylle odotetaan yli 2 ^ 64 tavua? ei todennäköisesti pian.

Itse asiassa tällaisia ​​prosessoreita on olemassa ja ne ovat yleisiä, riippuen siitä, kuinka määrität bittisyyden. Käytät melkein varmasti yhtä. Kuten Olin selitti, 256-bittisille numeroille ei ole paljon käyttöä, mutta entä 4 x 32-bittiset numerot? Entä jos ALU voisi lisätä 4 paria 32-bittisiä numeroita samanaikaisesti. Tällaiset ALU: t (joista tiedän) otettiin ensimmäisen kerran käyttöön vektori-supertietokoneissa 1970-luvulla. Ensimmäistä kertaa omistin tällaisen tietokoneen, kun minulla oli yksi Intel Pentium -laitteista MMX: n kanssa.

Muistatko nuo kaverit?

MMX-siruilla oli yksi käsky - usean tiedon käskysarja ( SIMD), jonka avulla voit lisätä 1 × 64-bittisen parin, 2 × 32-bittisen parin, 4 × 16-bittisen parin tai 8 × 8 -bit paria.

Mutta se ei ole mitään. Nykyaikaisella grafiikkakortilla on GPU (joka aikaisemmin tarkoitti grafiikkaprosessoriyksikköä, mutta nyt tarkoittaa yleistä prosessoriyksikköä). Nämä ovat usein laajoja SIMD-toteutuksia, jotka pystyvät haarautumaan, lataamaan ja tallentamaan 128 tai 256 bittiä kerrallaan. Intelin Larrabee-prototyyppimikroarkkitehtuuri sisältää yli kaksi 512-bittistä SIMD-rekisteriä kumpaankin ytimeen.

Huomaa, että SIMD: tä ei pidä sekoittaa moniytimiseen. Jokaisella suorittimen ytimellä on oma laaja ALU, joka pystyy yhdistämään joukon kokonaislukuja.

Koska sitä ei vielä tarvita.

Normaalisti bittiys (jonka määritän rekisterin bittien lukumääräksi) kääntää enemmän tai vähemmän suoraan osoitettavan muistin määräksi. Tätä on tietysti yksinkertaistettu, koska prosessorista riippuen rekistereissä voi olla kaksinkertainen bittipituus, tai on olemassa tekniikoita näiden muistirajoitusten kiertämiseksi (kukaan muu muistaa ohjelmoivan 16-bittisissä ikkunoissa?) / p>

"Miksi he eivät yksinkertaisesti lisää datarivien määrää ja luo 256-bittistä"

Kaikilla LGA-2011 Socketiin sopivilla Intel-prosessoreilla on itse asiassa 256 datanastaa , muodostaen yhteyden emolevyn 256 tietolinjaan, jotka johtavat DRAM-muistiin. Olisin hieman yllättynyt, jos viimeisimmässä käyttämässäsi kannettavassa tietokoneessa tai pöytäkoneessa ei olisi vähintään 256 tietolinjaa. Kysyn, mistä sait tämän virheellisen ajatuksen siitä, että he "eivät ... yksinkertaisesti lisää datarivien määrää"?

LGA-211 Socket -taulukko (oli: LGA-2011 Socket -taulukko), osa 6.1 osoittaa, että näillä suorittimilla on 256 datanasta ja 76 osoitetappia (pankki- ja muistiosoite).

koska ei ole sovellusta, joka tarvitsisi tai jolla olisi mahdollisuus edustaa tietoja yli 128 bitillä kerralla.

Ja tiedät, että multimediaprosessorit ja grafiikkakortit pääsevät tielle ennen emolevyjen suorittimia, vain siksi, että valokuvan / videon kanssa on järkevää käyttää niin suuria datan pituuksia, että ne voidaan käsitellä kerralla.

Tietokonejärjestelmä on merkityksessään tietokonekone, joka vaatii joitain syötteitä ja antaa joitain tuloksia. Meidän on tyydytettävä tietokone näillä linjoilla, joten kehittäjät saivat vertailukohdan omistamalla 3 bussia, nimittäin osoitebussi, tietoväylä ja ohjausväylä. 1) Osoiteväylä hakee / valitsee tietyn osoitteen muistista luku- / kirjoitusoperaatioita varten. 2) Tietoväylä hakee tämän jälkeen tiedot, jotka ovat esillä nämä tiedot prosessorille / prosessorilta ja muistille käsittelyä / tallennusta varten. Luo käyttöliittymän ohjausprotokolla ja pyytää järjestelmää kunnioittamaan sitä.

Näitä tarvitaan jonkin hyödyllisen laskennan tekemiseen käyttäjälle / palvelimelle / asiakkaalle. Yleensä suorituskyky (tehtävän suorittamisen nopeus, vähemmän häiriöitä jne.) Riippuu pullon kaulojen poistamisesta järjestelmässä. ts. jos CPU pystyy prosessoimaan paljon nopeammin kuin siirtonopeus kiintolevyltä, pullonkaula tapahtuu kiintolevyllä. Vastaavasti meillä on oltava oikea käsittelynopeus tietyille tiedonsiirtonopeuksille ja koodileveydelle.

Alusta alkaen useista syistä, kuten valokuvien monimutkaisuus, kustannukset, vaatimus, tehokkaat algoritmit ja tärkein syy markkinoihin Laajuus ovat tärkeimmät esteet suuren tietoväyläleveyden tuotannolle, kuten kysymys isäntä mainitsi, esimerkiksi 256 bittiä tai 512 bittiä. Nämä ovat mahdollisia! Vaatimusta ei kuitenkaan vielä ole, markkinoiden laajuus ei ole vielä näkyvissä nykypäivän tarpeiden ja täydentävän ohjelmistotuen puuttuessa.

256-bittinen prosessori tarkoittaa tietoväylän leveyttä, jonka tietty prosessori voi käsitellä. tai ALU voi käsitellä yhdellä suorituksella. Aloitimme muodosta 4 bittiä, sitten 8,16,32 ja tällä hetkellä 64 ja jopa 128 bittiä, jotka ovat nykyisiä Market Scope -tuotteita.

Joten ennen näiden kysymysten esittämistä sinun on aina tarkasteltava markkinapuolen kysyntää ja sen laajuutta, historiassa se on ainoa suoraviivainen tapa ymmärtää elämäntapoja. Jos sinulla ei ole varaa siihen, miten voit ostaa sen? ja jos et voi ostaa sitä, miten tuottaja voi tuottaa? ja jos hän ei pysty tuottamaan, tuota tuotetta ei ole olemassa !!