32- ja 64-bittisyys

[muddus]

tässä mutama vuosi sitten nousi minien bittisyvyys 32:sta 64:seen. Mitä todellista ja käytännön hyötyä tästä on esim. raskaassa kuvankäsittelyssä jos Prosessoreiden tehot ovat aika lailla samansuuruisia. Entä jos voi käyttää 64 bittisyyttä tukevaa kuvankäsittelyohjelmaa
.
http://www.raksi.net

[kallekilponen]

Applen sivuilta löytyy tämmöinen selostus aiheesta: http://www.apple.com/fi/macosx/technology/#sixtyfourbit

[spiidi78]

Kukahan nuo on oikein suomentanut?

Eng: "64-bit computing shatters that barrier by enabling applications to address a theoretical 16 billion gigabytes of memory, or 16 exabytes"

Suom: "64-bittinen laskenta rikkoo tuon rajan sallimalla ohjelmien osoittaa teoriassa 16 miljardia gigatavua tai 16 eksatavua muistia."

Computing = laskenta? No ei todellakaan ole. Ohjelmointi lienee oikea sana. Tuossa puhutaan muistista, EI laskennasta. Kaksi täysin eri asiaa.

Eng: "It can also enable computers to crunch twice the data per clock cycle, which can dramatically speed up numeric calculations and other tasks"

Suom: "Se mahdollistaa kaksinkertaisen käskymäärän käsittelyn kellojaksoa kohden ja nopeuttaa selvästi numeerisia laskutoimituksia ja muita tehtäviä"

twice the data = kaksinkertaisen käskymäärä? No ei tod... Käskymäärä on täysin sama, yhden datablokin (rekisteri) koko on tuplat. Tämä liittyy siihen äsken mainittuun laskentaan.

Hienoa, että Applen suomennokset on täynnä asiavirheitä

[Mailia]

Computing = laskenta? No ei todellakaan ole. Ohjelmointi lienee oikea sana. Tuossa puhutaan muistista, EI laskennasta. Kaksi täysin eri asiaa.

Computing ei kyllä ole ohjelmointi. Programming on.

computing, noun
1° The process or act of calculation.
2° Action of using (a) computer(s).

[spiidi78]

Computing = laskenta? No ei todellakaan ole. Ohjelmointi lienee oikea sana. Tuossa puhutaan muistista, EI laskennasta. Kaksi täysin eri asiaa.

Computing ei kyllä ole ohjelmointi. Programming on.

computing, noun
1° The process or act of calculation.
2° Action of using (a) computer(s).

No, pilkkua jos viilataan, niin niin 64-bit computing on sitä, että prosessori toimii 64-bittisessä tilassa ja siinä ajetaan 64-bit ohjelmaa, ja se vaatii sitä, että ohjelmoidaan 64-bittinen ohjelma. Laskentahan voi olla vaikka 8-bittistä siinä ohjelmassa, eikä sillä ole mitään tekemistä muistin määrän kanssa.

No, miksi tuosta kiehahdin on, kun juttu on täynnä sitä mitä tässäkin foorumissa päivästä toiseen jauhetaan, 64bit muistiosotukset vs 64bit data vs 64bit rekisterit. Menevät helposti sekaisin.

[kamina]

Jos nyt oikeasti meinaat viilata pilkkua niin viilaa sitten tosissaan. Riittänee että käännetään jo ohjelmoidusta sovelluksesta uusi versio sopivalla kääntäjällä, ei tarvitse "ohjelmoida 64bittistä versiota".

Lisäksi jos urputetaan jonkun käännöksistä luulisi että itseltään menisi paremmin, nyt ei tuntunut oikein menevän.

Voidaan varmaa. Olettaa että tuommoiset sivut on kirjoitettu maallikoille, muiden luulisi jo tietävän mitä uutta x86-64 käskykannassa tuli (tai ainakin uskaltavan selvittää).

[spiidi78]

Lisäksi jos urputetaan jonkun käännöksistä luulisi että itseltään menisi paremmin, nyt ei tuntunut oikein menevän.

Hohhoijaa. Asiavirhe on pikkasen eri asia, kuin sen oikean synonyymin kaivaminen. Tuohon keksii miljoona synonyymiä, joissa konteksti pysyy samana, mutta tuo oli suomennettu päin pers*että, koska siinä puhuttiin eri asiasta, mitä alkuperäisessä tekstissä. Tiedoksi vain, että korjasin sen asiavirheen omassa replyssäni.

Riittänee että käännetään jo ohjelmoidusta sovelluksesta uusi versio sopivalla kääntäjällä, ei tarvitse "ohjelmoida 64bittistä versiota".

Eipä kuule riitä, jos halutaan optimoida ohjelma 64-bittiseen ympäristöön.

Voidaan varmaa. Olettaa että tuommoiset sivut on kirjoitettu maallikoille

Jaa minusta tuo pilaa brändiä, jos ei tiedetä asioista, joita itse tehdään.

[kamina]

Lisäksi jos urputetaan jonkun käännöksistä luulisi että itseltään menisi paremmin, nyt ei tuntunut oikein menevän.

Hohhoijaa. Asiavirhe on pikkasen eri asia, kuin sen oikean synonyymin kaivaminen. Tuohon keksii miljoona synonyymiä, joissa konteksti pysyy samana, mutta tuo oli suomennettu päin pers*että, koska siinä puhuttiin eri asiasta, mitä alkuperäisessä tekstissä. Tiedoksi vain, että korjasin sen asiavirheen omassa replyssäni.

Kyllä computing ja laskenta ovat ihan synonyymejä, ohjelmointi ei.

Riittänee että käännetään jo ohjelmoidusta sovelluksesta uusi versio sopivalla kääntäjällä, ei tarvitse "ohjelmoida 64bittistä versiota".

Eipä kuule riitä, jos halutaan optimoida ohjelma 64-bittiseen ympäristöön.

Mutta siitähän tässä ei puhuttu...

Voidaan varmaa. Olettaa että tuommoiset sivut on kirjoitettu maallikoille

Jaa minusta tuo pilaa brändiä, jos ei tiedetä asioista, joita itse tehdään.

Applella on tapana piilottaa kaikkea turhaa taustalla tapahtuvaa käyttäjiltä. Monien mielestä tuo pilaa brändiä, mutta toisaalta ihan hyvin tuo tuntuu kokonaisuutena toimivan.

[spiidi78]

Kyllä computing ja laskenta ovat ihan synonyymejä, ohjelmointi ei.

Laskenta on sitä, että LASKETAAN 64-bit luvuilla, eikä sitä, että käytetään 64-bit muistiosotteita. Täten computing ei ole laskentaa ainakaan TUOSSA ASIAYHTEYDESSÄ. 32-bit ohjelmillakin voidaan laskea vaikka 128-bittisenä, joten mikä ilmotusluontoinen asia se olisi edes 64-bittisyyteen siirryttäessä?

MOT Englanti 4.0 eng-fin
computing (1) [kəm'pju:tɪŋ] s, tietokoneen käyttö, ohjelmointi; computing (2) a, tietokone-, ohjelmisto- ~ literature tietokonekirjallisuus, ~ industry ohjelmistoteollisuus

Myönnettäköön, että tietokoneen käyttö olisi oikea termi, koska computing tulee sanasta computer (eikä compute, niinkuin laskenta olisi) ja tarkoittaa, että käytetään tietokonetta. (http://en.wikipedia.org/wiki/Computing)
Mutta kun se kuulostaa typerältä puukapulakieleltä, niin tuon 64-bit laskennan sijaan pitäisi käyttää yleisesti sanaa 64-bittisyys.

Mut se toinen virhe oli paljon pahempi moka. Jos muka käskyjen määrä per sykli tuplaantuisi, niin koneen nopeuskin tuplaantuisi.

Applella on tapana piilottaa kaikkea turhaa taustalla tapahtuvaa käyttäjiltä. Monien mielestä tuo pilaa brändiä, mutta toisaalta ihan hyvin tuo tuntuu kokonaisuutena toimivan.

Tais mennä pointti ihan kokonaan ohi... Luitko sitä ensimmäistä replyäni ollenkaan? Minähän puhuin pelkästään tuosta suomennoksesta. Kävi ihmetyttämään asiavirheet, ja päätin kurkistaa sitä alkuperäistä englanninkielistä tekstiä ja siellä asiat oli mainittu täysin oikein.

Tuota voisi verrata siihen, että Linus Torvalds sanoisi KDE- tai Gnome-desktoppia Linuxiksi.

Summa summarum: suomentaja ei tiennyt mistä kirjoitti ja valitsi väärät käännökset. Vastaisuudessa nuo kannattaisi oikolukea jollain inssillä, jos kerran puhutaan teknisistä detaileista.

[t0rakka]

Ohjelmoijan perspektiivistä katsottuna 64 bittisyyden suurimmat erot 32 bittisyyteen:

- 32 bittisen sovelluksen tai kirjaston tuominen 64 bittiseksi on yleispätevästi erittäin helppoa jos alkuperäinen lähdekoodi on kirjoitettu ilman oletuksia tyyppien koosta (esim. "int on 32 bittiä", ja koodi ei toimi jos näin ei ole)

- 64 bittinen koodi on hieman suurempaa, mutta keskimäärin 10-15% nopeampaa kuin 32 bittinen koodi (jos käännetään sama lähdekoodi "verbatim"), nopeutus voi olla suurempi jos lähdekoodia muokataan ottamaan huomioon se, että x86_64 tilassa SSE ja ALU rekistereitä on tuplasti enemmän (8 kpl vs 16 kpl). Suurempi määrä rekistereitä vähentää spillausta automaattisesti, mutta jos lähdekoodia muokkaamalla saadaan jokin tiukka prosessing loop pyörimään kokonaan rekistereissä (input/output excluded) voi nopeutus olla huomattavasti enemmän kuin 15% (50% on helposti mahdollinen)

- memory mapped I/O .. 32 bittisessä tilassa ei voida mapata kovin suuria tiedostoja muistiin, koska muistiavaruus on rajallinen resurssi.. jos koneessa on 4 GB muistia, ei periaatteessa muistiavaruutta ole yhtään vapaana. Käytännössä OS jättää muistiin aina sopivan reiän mihin mappaus voidaan suorittaa, mutta let's face it.. suurin mahdollinen (yhtenäinen) muistiavaruus on 32 bittinen eli 4 GB.. ja se on siinä. 64 bittisessä tilassa muistiavaruutta on 4 miljardia kertaa enemmän, siihen mahtuu jo aika paljon tavaraa.

MIKSI memory mapped I/O (MMIO) on hyvä ominaisuus? Siksi, että se säästää muistikaistaa sekä fyysistä muistia. Sovellukset eivät tarvitse yhtä paljon muistia, eikä niiden tarvitse kopioida dataa paikasta toiseen vain lukeakseen sen. Mitä MMIO on? Miten se toimii?

Normaalisti, jos luet tiedostosta dataa käyttäen jotain standardi API:a, vaikka FILE handleä.. se toimii näin:

1. avaan tiedoston lukemista varten (fopen). Saat handlen.
2. luet tiedostosta vaikkapa 20 KB, sitä varten sun pitää varata OMA 20 KB blokki muistia ja fread funktio kirjoittaa sun varaamaas muistilohkoon. Sun täytyy pitää kirjaa muistista, varailla, vapautella sitä.. fread kopioi omasta sisäisestä puskuristaan sun muistilohkoos kamaa kun luet sitä.

MMIO toimii taas näin:

1. avaan tiedoston mmio:ta varten, mappaat koko tiedoston, tai osan siitä muistiin.. saat osoitteen!
2. luet osoitteesta aivan kun se olisi normaalia muistia; se osoite osoittaa suoraan käyttiksen sisäiseen file cacheen eli tiedosto välimuistiin.. huomaat, että yksi turha muistikopiointi jää pois välistä = tehokkaampaa. Huomaat myös, että et tarvitse omaa muistiblokkia lukemiskohteeksi.

Miten tämä on mahdollista!? x86 prosessoreissa on ollut virtuaalimuistille tuki jo ammoisista ajoista lähtien. Kun sä luet muistiosoitteesta X, käyttis katsoo sivutaulukosta (koko koneen muisti on jaettu 4 KB sivuihin, eng. "page") ja kun kirjotus tai lukuoperaatio osuu sivuun, entry siellä taulukossa kertoo mitä siellä muistiosoitteen takana on. Jos sivu ei ole "muistissa", tulee keskeytys.. käyttis käsittelee tämän keskeytyksen ja voi vaikkapa osoittaa sivun filecacheen mikä on muistissa.. jos cachessa ei ole ko. osaa tiedostosta, käyttis voi ladata sen ja vähän extraa ympäriltä ja sovellus ei ole hullua hurskaampi.. se luulee lukevansa ihan normaalia muistia (mitä se tekeekin..)

x86 arkkitehtuurissa fyysiset ja loogiset muistiosoitteet ovat kätevästi virtualisoitu.. hieno systeemi. =)

Eli suurimmat ilon aiheet:

- enemmän rekistereitä
- MMIO avaruus loputon!
- rekisterit on 2x leveämpiä (harvemmin hyödynnetään, mutta sillon kun tarvetta, on hieno että olemassa)


.. computing.. ei tarkoita tässä yhteydessä mitään ohjelmointia. Laskenta on lähempänä, sorry. Itse en edes ajattele asiaa suomeksi.. mutta jos pakko suomentaa, niin computing on sitä mitä tietokone häärää ja puuhaa. ;---o

[spiidi78]

- rekisterit on 2x leveämpiä (harvemmin hyödynnetään, mutta sillon kun tarvetta, on hieno että olemassa)

Tässä on se hyvä puoli, että esim DSP laskennasta saadaan huomattavasti tarkempaa samalla teholla. Ennen sitä ei juurikaan käytetty, koska se söi julmetusti tehoa. Nyt laskeminen 64-bit floateilla ei syö tehoa käytännössä yhtään enempää mitä laskeminen huomattavasti epätarkemmilla 32bit floateilla. Eli saadaan lisätarkkuutta laskutoimituksiin puoli-ilmaiseksi (musiikintekijät huom, parempaa soundia tiedossa .

x86_64 tilassa SSE ja ALU rekistereitä on tuplasti enemmän (8 kpl vs 16 kpl).

Ja tää on aivan loistava homma kanssa, jota en edes muistanut. (muistin tosin, että 32bit tilassa niitä olis ollu 4kpl, muistin väärin). Esim OSX:n vDSP-rajapinta käyttää näitä aivan loistavasti hyödyksi. Tehoero voi olla parhaimmillaan lähes tuplat oikein hyödyntämällä.

.. computing.. ei tarkoita tässä yhteydessä mitään ohjelmointia. Laskenta on lähempänä, sorry. Itse en edes ajattele asiaa suomeksi.. mutta jos pakko suomentaa, niin computing on sitä mitä tietokone häärää ja puuhaa. ;---o

En jaksa enää jauhaa tästä asiasta, kun kukaan ei ymmärrä mun pointtia, joka oli siis se, että 64-bit laskenta on eri asia kuin 64-bit muistiosoitus