Apple siirtyy Arm-arkkitehtuuriin Mac-tietokoneissa

Hessu

Tukijäsen
Liittynyt
29.10.2016
Viestejä
4 420
OT: Omien kokemusteni mukaan USB-C ei ole sen parempi kuin vanhemmatkaan USB:t. Ihan hyvä liitin siihen asti, kunnes liitin löystyy tai muuten vikaantuu laitteen (puhelimen) päästä, ja näin tapahtuu vähintään yhtä helposti kuin micro-USB:lläkin.
OTOT: On se kyllä sen 5x parempi siinä suhteessa, että ei tarvitse aina kolmea kertaa yrittää, että johto menisi liitimeen vaan menee paikalleen molemmin päin toisinkuin kaikki muut tähän astiset USB -liittimet.
 
Liittynyt
17.10.2016
Viestejä
11 941
Mutta jos ei ole sitä rautaakaan kaupasta tarjolla muuta kuin Air, niin eipä sitä softaakaan silloin tarvitse muualle optimoida? Eiköhän noita tulevaisuuden koneita sitten jaella esiversioina niille joista Apple tykkää (kuten Adobe). Muut vähemmän tärkeät tahot voi sitten jonottaa applestoren ovella muun rahvaan kanssa omaansa ja julkaista softansa armille sit kun kerkiää.
Apple on ilmoittanut tuovansa kaikkiin koneisiinsa Arm prossut parin vuoden aikajaksolla sisällä. Se on myös ilmoittanut, että pro-softaa kuten photoshop, finalcut pro x, MS Office jne. on tulossa.

Miksi Applen pitäisi ehdoin tahdoin vaikeuttaa itselleen tässä muutenkin hankalassa transitiossa tärkeimmän tahon, eli sovelluskehittäjien työtä tuomalla aluksi vain heikkotehoista rautaa ulos, kun tavoitteena on nimenomaan saada ne pro-softatkin käännettyä armille?

En äkkiseltään keksi Applen kannalta mitään hyötyä Macbook Airin arm-version kiirehtimisestä, siinä missä devaajien käyttämä MBP on erittäinkin hyvä saada etulinjassa ulos, jotta softan kehitys uudelle alustalle on maksimaalisen helppoa.

MBP on myös erittäin suosittu kone koodareiden ja etenkin iOS-koodareiden keskuudessa ja he hyötyvät suoraan siitä, että iOS-softaa devatessa simulaattori toimii oikeasti kuten puhelin / iPad / AppleTV itse.

-
Oman näkemyksen mukaan lightning on käytettävyydeltään aivan suvereeni latausliitin mobiililaitteisiin ja selkeästi USB-C:tä helpompi tökätä paikalleen esim. sokkona, pimeässä. Se on myös helppo puhdistaa hammastikulla kaivamalla, siinä missä usb-c:n kolojen putsaaminen on hankalampaa.

Tiedonsiirto- ja latausnopeuden osalta sillä on rajansa, jonka takia USB-C on joissain käyttökohteissa parempi.
 
Liittynyt
20.10.2018
Viestejä
2 504
Tuleekohan Apple ARM:n myötä siirtymään Mac-puolella saman tyyliseen tarjontaan kuin mobiilipuolellakin eli läppäri- ja pöytäkonemallistoon tulisi esimerkiksi kaksi tai kolme erilaista mallia: Macbook (Air)/Macbook Pro tai iMac/iMac Pro ilman sen suurempaa valinnanvaraa koneen konfiguraatiossa. Onkohan tietokoneet menossa tuohon suuntaan tai onko aika vielä valmis siihen. En näe sinänsä edes mahdottomana, jos kuitenkin olisi mahdollista taata vaikka lähemmäs kymmenen vuoden tuki koneelle käyttöjärjestelmän ja sovellusten toimivuuden osalta. Mikäli tällaisen muutaman konfiguraation systeemiin siirryttäisiin, voisi hinnatkin jopa vähän tippua valmistusprosessien yksinkertaistuessa. Näillä keinoilla taas Apple voisi haalia uusia käyttäjiä ja tuollainen luurimaailmasta tuttu vaihtosyklikin rantautuisi tietokonepuolelle eli vaihdetaan laitetta tasaisin väliajoin uuteen. Toki tietokoneitakin vaihdetaan, mutta suurin osa käyttää luultavasti hyvin epäsäännöllisiä ja pitkiäkin syklejä.
 

Juha Uotila

Ylläpidon jäsen
Liittynyt
18.10.2016
Viestejä
4 935
Mutta jos ei ole sitä rautaakaan kaupasta tarjolla muuta kuin Air, niin eipä sitä softaakaan silloin tarvitse muualle optimoida? Eiköhän noita tulevaisuuden koneita sitten jaella esiversioina niille joista Apple tykkää (kuten Adobe). Muut vähemmän tärkeät tahot voi sitten jonottaa applestoren ovella muun rahvaan kanssa omaansa ja julkaista softansa armille sit kun kerkiää.
Applen Pro-tason softat eli Final Cut jne tulevat tarjolle arm-mäkille ekasta päivästä lähtien, tämän sanoivat keynotessa pariin kertaan. Eli ei sieltä nyt ihan mitään lussurautaakaan ole tulossa ensimmäisenä. Myös Adoben CC pyörii jo arm-mäkillä, tämäkin todettiin striimissä. Eli tuskin tulee mitään Airia pelkästään vaan tulee juurikin se huhuilta MBP tason kannettava.

Se millä raudalla MS ja Adobe noita tällä hetkellä kehittää on sitten toinen juttu, siellä voi olla vähän eri rautaa kun nämä DTK-kitit mitä tarjotaan "normikehittäjille". Tai sitten jos ne softat pyörii jo tuolla raudalla sulavasti (eli iPad Pro raudalla) niin ne varmaan pyörii ihan mukavasti myös sillä tehokkaalla raudalla joka syksyllä tulee.
 
Liittynyt
17.10.2016
Viestejä
21 879
Se millä raudalla MS ja Adobe noita tällä hetkellä kehittää on sitten toinen juttu, siellä voi olla vähän eri rautaa kun nämä DTK-kitit mitä tarjotaan "normikehittäjille". Tai sitten jos ne softat pyörii jo tuolla raudalla sulavasti (eli iPad Pro raudalla) niin ne varmaan pyörii ihan mukavasti myös sillä tehokkaalla raudalla joka syksyllä tulee.
Oletko ikinä kuullut cross compilereista?
Lisäksi Applella on kova kokemus LLVM:stä ja se on olennainen osa MacOS:ia.
 

Juha Uotila

Ylläpidon jäsen
Liittynyt
18.10.2016
Viestejä
4 935
Oletko ikinä kuullut cross compilereista?
Lisäksi Applella on kova kokemus LLVM:stä ja se on olennainen osa MacOS:ia.
Niin? En ole koodari eikä sinällään kiinnostakaan olla

Pointti oli siinä, että Apple ei julkaise noita Pro-tason softiaan ARM-mäkille jos ne eivät siinä pyöri sulavasti. Eli ei niillä ole halua julkaista jotain Final Cut:ia jos ei ole sellaista rautaa joka jaksaa vääntää esim 4K materiaalia "on the fly" jne.
 
Liittynyt
17.10.2016
Viestejä
21 879
Niin? En ole koodari eikä sinällään kiinnostakaan olla

Pointti oli siinä, että Apple ei julkaise noita Pro-tason softiaan ARM-mäkille jos ne eivät siinä pyöri sulavasti. Eli ei niillä ole halua julkaista jotain Final Cut:ia jos ei ole sellaista rautaa joka jaksaa vääntää esim 4K materiaalia "on the fly" jne.
Kyllä. Mutta Apple saa nopeasti softat käännettyä mille vaan arkkitehtuurille ja nyt onkin mielenkiintoista nähdä, onko siellä
  1. lisätty ydinmäärää , että saadaan raakaa general purpose laskentatehoa
  2. tehty erityislaskentayksikkö, jossa nuo lasketaan; tai käskykanta, niinkuin MMX ja AVX - eli erityistä käsittelyä special caseille

Mutta siis omana pointtina, että työkalutasolla Applella on kaikki kunnossa ja ARM-siirtymä on helppo. Niinkuin iPhonelle voi tehdä ja kääntää softaa sillä Intel Macbook Pro:lla, niin kehitys ARM-Maceille on vähintään yhtä helppoa. Ellei helpompaa. Best case ne tuottaa suoraan universal binäärit jossain vaiheessa, kun normaalisti käännät softan.

Jos ei tarvitse optimointeja, niin tämä siirtymä voidaan tehdä kehittäjille hyvin helpoksi, eikä ole tarvetta hw dev kiteille.

Valitan lyhenteiden käyttöä ja finglishiä, pitäisi saada grilli lämpeämään ja tulitikkuja ei ole. Tämä on kuitenkin normaalille kehittäjälle mahdollista tehdä helpoksi; läpinäkyväksi. Ei tämä ole Playstation 5, jossa tarvitaan se laite, että voidaan testata pelejä. Fyysisestä laitteesta on hyötyä vaan, kun halutaan puristaa ulos viimeisetkin suorituskyvyn rippeet ja tehdä laadunvarmistusta (tämän sain suomennettua).
 
Liittynyt
20.10.2018
Viestejä
2 504
Mitä tarkoitat? Johan Applella on nyt hyvin pieni määrä konemalleja verrattuna esim. PC-puolelle. Kannettavissa ja pöytäkoneissa.
Pieni määrä malleja, mutta aika laajasti konfiguroitavissa prosessorien, näytönohjainten, keskusmuistien tai tallennustilan suhteen. Tarkoitan, että ei olisi enää tarpeen valita keskusmuistin määrää tai näytönohjaimen tehoa, vaan perus Macbook olisi vain tietyillä osilla ja Macbook Pro olisi sitten tehokkaammilla osilla. Käyttäjän tehtäväksi jäisi vain tallennustilan määrän valinta, kuten mobiilipuolen laitteissa.
 
Liittynyt
09.11.2018
Viestejä
3 147
Itse sinänsä uskon, että Applen armin suorituskyky riittää sinällään ihan kivasti. Varsinkin jos softakehittäjät pakotetaan paljon useamman coren käyttöön sulavuusvaatimuksella. Tämä auttaisi sitten PC puolella myös kun softa osaisi hyödyntää esim. kahdeksaa corea hyvin.

Ongelmallisempaa on sitten saada suorituskyky ylös softista tai projekteista jotka pitää erikseen pienten puljujen vääntää armille tai kehitysympäristöt jotka jo alunperinkin on väsätty harrastemielessä.

Vaikka mäccien kohdalla pelit tunnutaan laskevan monissa piireissä aika pienelle arvolle, niin itse näen nuo isoksi ongelmaksi. Arm arkkitehtuuriin ei konsoli- ja pc julkaisijat noin vain hyppääkään. Linuxilla kun itse pelailen niin tiedän kyllä mitä se tarkoittaa kun lähdetään peliä pelaamaan ei-natiivissa ympäristössä vaikka tuo on valtavasti parantunut.

Yksi iso kysymys on myös GPU ja miten ratkaistaan suorituskyky tuon kohdalta. Niin hyviä kuin Applen piirit ovatkin, niin ne ovat tietyissä tehtävissä auttamattoman mopoja. Sellaista ei sisällöntuottaja vaan pysty käyttämään ilman Applen jotain lisäkiihdytyskortteja tai esim. AMD:n rdna2:n lisensointia jos niiden teho riittää (Samsung on mobiilipuolella lisensoinut jotain, mutta tosiaan noiden suorituskyvystä en tiedä).

Näytönohjainpuoli oikeastaan epäilyttää eniten tässä muutoksessa. Sinänsä ARM rautaa en itse henkilökohtaisesti koske, koska x86 on taaksepäin itselleni niin tärkeä. Raspberryllä on tullut leikittyä ja se riittää. Bootcampin roskiin heitto todennäköisesti hiertää joitakin ihan kiitettävästi.

Itse veikkaan että AIR on eka kone kun tulee armilla. Se nykyinen ei käytä lämpöputkia kuin nimellisesti (ja osittain ei käytä ollenkaan kun sellaista ei ole laitettu) ja käy turkasen kuumana joten läppärin sisältö on jo aika valmis armia varten.
 
Viimeksi muokattu:
Liittynyt
17.10.2016
Viestejä
11 941
Itse sinänsä uskon, että Applen armin suorituskyky riittää sinällään ihan kivasti. Varsinkin jos softakehittäjät pakotetaan paljon useamman coren käyttöön sulavuusvaatimuksella. Tämä auttaisi sitten PC puolella myös kun softa osaisi hyödyntää esim. kahdeksaa corea hyvin.

Ongelmallisempaa on sitten saada suorituskyky ylös softista tai projekteista jotka pitää erikseen pienten puljujen vääntää armille tai kehitysympäristöt jotka jo alunperinkin on väsätty harrastemielessä.

Vaikka mäccien kohdalla pelit tunnutaan laskevan monissa piireissä aika pienelle arvolle, niin itse näen nuo isoksi ongelmaksi. Arm arkkitehtuuriin ei konsoli- ja pc julkaisijat noin vain hyppääkään. Linuxilla kun itse pelailen niin tiedän kyllä mitä se tarkoittaa kun lähdetään peliä pelaamaan ei-natiivissa ympäristössä vaikka tuo on valtavasti parantunut.

Yksi iso kysymys on myös GPU ja miten ratkaistaan suorituskyky tuon kohdalta. Niin hyviä kuin Applen piirit ovatkin, niin ne ovat tietyissä tehtävissä auttamattoman mopoja. Sellaista ei sisällöntuottaja vaan pysty käyttämään ilman Applen jotain lisäkiihdytyskortteja tai esim. AMD:n rdna2:n lisensointia jos niiden teho riittää (Samsung on mobiilipuolella lisensoinut jotain, mutta tosiaan noiden suorituskyvystä en tiedä).
IOS on käsittääkseni joillain mittareilla maailman suurin pelialusta (tyyliin pelien tekemä liikevaihto tjsp.) ja ne pelit pyörivät jatkossa natiivisti mäkillä, joskin kosketysnäyttökontrollit pitää tietty konvertoida tietokoneelle.

”Vakavia” AAA pelejä toki iOS:lle tulee harmittavan vähän, vaikka tehoja ipadeissa riittäisikin.
 
Liittynyt
09.11.2018
Viestejä
3 147
iPadin GPU taso on kylläkin ennemmin 'ihan kiva' tasolla kun ruvetaan vaatimaan suorituskykyä. Mobiililaitteeksi erinomainen, mutta ei juuri muuta. Noi pelidemotkin olivat lähinnä sellaisella tasolla että olisi voinut olla näyttämättä. Vanhahko peli joka pyörii juuri ja juuri siedettävästi suht alhaisella resolla. Ei ihan Intelin CES demon luokkaa mutta ei juuri muutakaan. Ei nyt varsinaisesti hurraa suorityskyvyllään siis. Todella paljon kehitystä vaaditaan että homma toimii siedettävästi. Veikkaan että vaatii vähintään TSMC:n 5nm prosessin käyttöönottoa (johon Apple todennäköisesti aikataulunsa laskee).

Tällä en siis tarkoita etteikö se Applen ekosysteemissä toimi hienosti (tai että iOs pelialustana en sinänsä arvostaisi vaikka itseä ei kiinnostakaan), mutta ei se mikään erillinen näytönohjain oikein ole.
 

Juha Uotila

Ylläpidon jäsen
Liittynyt
18.10.2016
Viestejä
4 935
iPadin GPU taso on kylläkin ennemmin 'ihan kiva' tasolla kun ruvetaan vaatimaan suorituskykyä. Mobiililaitteeksi erinomainen, mutta ei juuri muuta. Noi pelidemotkin olivat lähinnä sellaisella tasolla että olisi voinut olla näyttämättä. Vanhahko peli joka pyörii juuri ja juuri siedettävästi suht alhaisella resolla. Ei ihan Intelin CES demon luokkaa mutta ei juuri muutakaan. Ei nyt varsinaisesti hurraa suorityskyvyllään siis. Todella paljon kehitystä vaaditaan että homma toimii siedettävästi. Veikkaan että vaatii vähintään TSMC:n 5nm prosessin käyttöönottoa (johon Apple todennäköisesti aikataulunsa laskee).
Se pelidemohan oli siis emuloitu eli ajettiin peliä Rosetta 2:n kautta 1080p:nä.

Ei ne pelaajat nyt muutenkaan mäkkiä osta joten pelitehoja nyt varmaan ei ihan heti ei ole tulossa, eikä varmaan tarvettakaan.
 
Liittynyt
09.11.2018
Viestejä
3 147
Se pelidemohan oli siis emuloitu eli ajettiin peliä Rosetta 2:n kautta 1080p:nä.

Ei ne pelaajat nyt muutenkaan mäkkiä osta joten pelitehoja nyt varmaan ei ihan heti ei ole tulossa, eikä varmaan tarvettakaan.
Tämä on kyllä harha. Vähän kuin Thinkpadeissa (tai vastaavassa bisnesläppärissä) jossain vaiheessa kartoitettiin moniko niillä pelaa. Tuo luku oli niin iso, että se käytännössä tappoi idean läppäristä ilman erillistä näytönohjainta vaikka se kohderyhmää seuraten olisi ollut loogisin päätelmä. Todella moni mäkkiä käyttävä myös pelaa sillä, vaikka se ei millään mittarilla olisi tarpeiden yläpäässä.
 

Juha Uotila

Ylläpidon jäsen
Liittynyt
18.10.2016
Viestejä
4 935
Tämä on kyllä harha. Vähän kuin Thinkpadeissa (tai vastaavassa bisnesläppärissä) jossain vaiheessa kartoitettiin moniko niillä pelaa. Tuo luku oli niin iso, että se käytännössä tappoi idean läppäristä ilman erillistä näytönohjainta vaikka se kohderyhmää seuraten olisi ollut loogisin päätelmä. Todella moni mäkkiä käyttävä myös pelaa sillä, vaikka se ei millään mittarilla olisi tarpeiden yläpäässä.
Niin en kiellä etteikö pelaisi mutta samalla tavalla se Intelin integroitu siellä on pullonkaulana eikä taida tarjota sen parempaa suorituskykyä kuin nykyiset A-sarjan huippupiirit. Egpu:t yms sitten erikseen, tosin niidenkin tuki macOS:llä on heikkoa
 

Kaotik

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
21 448
Niin en kiellä etteikö pelaisi mutta samalla tavalla se Intelin integroitu siellä on pullonkaulana eikä taida tarjota sen parempaa suorituskykyä kuin nykyiset A-sarjan huippupiirit. Egpu:t yms sitten erikseen, tosin niidenkin tuki macOS:llä on heikkoa
Mikäs vika niiden eGPU-tuessa on?
 

Kaotik

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
21 448
Hämärä muistikuva että vain tietyt kortit toimii. Ainakin NVIDIAn korttien kanssa ollu ongelmia
Käsittääkseni kyse ei ole muusta kuin NVIDIAn ajurituesta, nopealla vilkaisulla viimeiset ajurit ovat High Sierralle ja niidenkin tuki aika rajallista:
This driver update is for Mac Pro 5,1 (2010) users.

BETA support is for iMac 14,2 / 14,3 (2013), iMac 13,1 / 13,2 (2012) and MacBook Pro 11,3 (2013), MacBook Pro 10,1 (2012), and MacBook Pro 9,1 (2012) users.
 
Liittynyt
17.10.2016
Viestejä
11 941
iPadin GPU taso on kylläkin ennemmin 'ihan kiva' tasolla kun ruvetaan vaatimaan suorituskykyä. Mobiililaitteeksi erinomainen, mutta ei juuri muuta. Noi pelidemotkin olivat lähinnä sellaisella tasolla että olisi voinut olla näyttämättä. Vanhahko peli joka pyörii juuri ja juuri siedettävästi suht alhaisella resolla. Ei ihan Intelin CES demon luokkaa mutta ei juuri muutakaan. Ei nyt varsinaisesti hurraa suorityskyvyllään siis. Todella paljon kehitystä vaaditaan että homma toimii siedettävästi. Veikkaan että vaatii vähintään TSMC:n 5nm prosessin käyttöönottoa (johon Apple todennäköisesti aikataulunsa laskee).

Tällä en siis tarkoita etteikö se Applen ekosysteemissä toimi hienosti (tai että iOs pelialustana en sinänsä arvostaisi vaikka itseä ei kiinnostakaan), mutta ei se mikään erillinen näytönohjain oikein ole.
Jos verrataan esim. Nintendo Switchiä jolle tulee jatkuvasti aika karun näköisiä AAA-portteja, niin uusissa iPadeissa on merkittävästi enemmän sekä CPU-, että GPU-tehoa.

Harmi, että samoja portteja ei saa pädille - nyt kun ipadilla olisi aika hyvä ohjaintukikin.
 
Liittynyt
27.10.2016
Viestejä
315
Hämärä muistikuva että vain tietyt kortit toimii. Ainakin NVIDIAn korttien kanssa ollu ongelmia
Ongelma ei ole Nvidian korttien vaan Nvidian kanssa.

Apple ei ole lähes kymmeneen vuoteen pistänyt tikkua ristiin tukeakseen Nvidian kortteja macOS:ssa, koska firmoilta meni välit erinäisten tapahtumaketjujen johdosta (mm. vialliset 8400/8600 -mobiilipiirit ja niiden jälkilöylyt) ja jossain vaiheessa Cupertinossa tekivät ilmeisesti periaatepäätöksen olla käyttämättä Nvidian tuotteita lainkaan.

Nvidia on moneen kertaan viestittänyt kautta rantain halukkuuttaan tehdä sekä bisnestä että ajureita macOS:lle, mutta ilmeisesti Apple on lopettanut kaiken ajuriyhteistyönkin firman suuntaan. Siksi nykytilanne on mitä on.
 

Juha Uotila

Ylläpidon jäsen
Liittynyt
18.10.2016
Viestejä
4 935
Ongelma ei ole Nvidian korttien vaan Nvidian kanssa.

Apple ei ole lähes kymmeneen vuoteen pistänyt tikkua ristiin tukeakseen Nvidian kortteja macOS:ssa, koska firmoilta meni välit erinäisten tapahtumaketjujen johdosta (mm. vialliset 8400/8600 -mobiilipiirit ja niiden jälkilöylyt) ja jossain vaiheessa Cupertinossa tekivät ilmeisesti periaatepäätöksen olla käyttämättä Nvidian tuotteita lainkaan.

Nvidia on moneen kertaan viestittänyt kautta rantain halukkuuttaan tehdä sekä bisnestä että ajureita macOS:lle, mutta ilmeisesti Apple on lopettanut kaiken ajuriyhteistyönkin firman suuntaan. Siksi nykytilanne on mitä on.
Juu suksethan siellä meni ristiin.
 
Liittynyt
17.10.2016
Viestejä
870
Applen Pro-tason softat eli Final Cut jne tulevat tarjolle arm-mäkille ekasta päivästä lähtien, tämän sanoivat keynotessa pariin kertaan. Eli ei sieltä nyt ihan mitään lussurautaakaan ole tulossa ensimmäisenä. Myös Adoben CC pyörii jo arm-mäkillä, tämäkin todettiin striimissä. Eli tuskin tulee mitään Airia pelkästään vaan tulee juurikin se huhuilta MBP tason kannettava.

Se millä raudalla MS ja Adobe noita tällä hetkellä kehittää on sitten toinen juttu, siellä voi olla vähän eri rautaa kun nämä DTK-kitit mitä tarjotaan "normikehittäjille". Tai sitten jos ne softat pyörii jo tuolla raudalla sulavasti (eli iPad Pro raudalla) niin ne varmaan pyörii ihan mukavasti myös sillä tehokkaalla raudalla joka syksyllä tulee.
Yksi kysymys on onko nuo arm-softat yhteneväisiä nykyisten kanssa. IPad Pron:n Office-paketilla ei ole mitään muuta yhteistä X86-versioiden kanssa kuin etäisesti ulkonäkö, ja iPadin Adobe-softilla edes ulkoasu ei ole vastaava. Molemmat ohjelmistopaketit on minusta iPadilla todella surullisia esityksiä.
 

Juha Uotila

Ylläpidon jäsen
Liittynyt
18.10.2016
Viestejä
4 935
Yksi kysymys on onko nuo arm-softat yhteneväisiä nykyisten kanssa. IPad Pron:n Office-paketilla ei ole mitään muuta yhteistä X86-versioiden kanssa kuin etäisesti ulkonäkö, ja iPadin Adobe-softilla edes ulkoasu ei ole vastaava. Molemmat ohjelmistopaketit on minusta iPadilla todella surullisia esityksiä.
Eiköhän ne tehdä niiden deskariversioiden pohjalta. Photoshopin iPad versio on surullinen mutta office on huomattavasti parempi.

Photoshopille tosin löytyy parempi korvaaja Affinityltä
 

jsa

Tukijäsen
Liittynyt
20.10.2016
Viestejä
611
Nvidia on moneen kertaan viestittänyt kautta rantain halukkuuttaan tehdä sekä bisnestä että ajureita macOS:lle, mutta ilmeisesti Apple on lopettanut kaiken ajuriyhteistyönkin firman suuntaan. Siksi nykytilanne on mitä on.
Aikanaan Imaginationin kanssa homma "kuulemma" meni niin että Apple otti driveri dropin, sanoi kiitos ja palaute oli siinä. Ts takasin päin ei tullut juuri mitään. Tämän toki ymmärtää jos tarkoituksena oli imeä teknologiaa jotta voisi korvata PowerVR piirit omalla tuotannolla (joka nyt jossain määrin otti takapakkia royaltien suhteen). Jos toimintatapa ei ole muuttunut niin ymmärrän täysin miksi Apple ei halua oikein Nvidian kanssa tehdä mitään (etenkin jos Nvidia itse haluaisi pitää ajurien teon itsellään, eikä vain toimittaa referenssiajuria).

Noh sinällään aika sama, kontrollihan on Applella tässä tapauksessa ja firma voi tehdä bisnestä tai olla tekemättä haluamiensa tahojen kanssa.

Mielenkiinnolla odotan millainen hässäkkä transitiosta tulee, olettaisin että suurin osa OSX softasta kääntyy ongelmitta ARM alustalle, ja perffikin on ok. Kaikki välttämättä eivät ole tyytyväisiä ja saattavat pitäytyä pitkäänkin x64 mäkeissä (esimerkiksi musamiehet joille 32bit tuen pudottaminenkin oli aika hässäkkä). Se ei hirveästi lämmitä jos softissa 3rd party plugarit on edelleen vain x64:lle vaikka itse softa olisikin jo saanut ARM tuen.
 

Kaotik

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
21 448
Ei taida ainakaan tämän syksyn iMac olla Armilla vielä
Core i9-109100 (ts kelloiltaan perusmallista erottuva Apple-versio) + Radeon Pro 5300
 

user9999

Platinum-jäsen
Liittynyt
17.10.2016
Viestejä
3 013
Ei taida ainakaan tämän syksyn iMac olla Armilla vielä
Core i9-109100 (ts kelloiltaan perusmallista erottuva Apple-versio) + Radeon Pro 5300
Juu sieltä pitäis tulla vielä Intel iMacit.

Edit:
 
Viimeksi muokattu:
Liittynyt
29.10.2016
Viestejä
2 317
Onko tietäjillä näkemystä siitä, kannattaako päivittää tänä vuonna vai vasta seuraavana tuo late -15 imac. Arm toisaalta kiinnostaa, mutta alkuun siinä voi olla jotain ongelmaa? Toisaalta voiko olla niin, että nämä nyt julkaissut saavat huonommin päivityksiä ja mahdollisesti ~3-5v päästä nuo softat on paremmin optimoitu sille armille?
 
Liittynyt
16.10.2016
Viestejä
12 044
Onko tietäjillä näkemystä siitä, kannattaako päivittää tänä vuonna vai vasta seuraavana tuo late -15 imac. Arm toisaalta kiinnostaa, mutta alkuun siinä voi olla jotain ongelmaa? Toisaalta voiko olla niin, että nämä nyt julkaissut saavat huonommin päivityksiä ja mahdollisesti ~3-5v päästä nuo softat on paremmin optimoitu sille armille?
Tarvitsetko nopeamman / uuden mäkin nyt?
Jos vastaus on kyllä ja lompakko sanoo myös "yes", niin mars ostoksille.
Jos taas et tarvitse tai hillot on finito, niin käytä vanhaa.
Noita on täysin turha pohtia noin yleisesti. Paitsi s.e. tietokone on huono sijoitus, jos sitä ei tarvitse, sillä on lähinnä käyttöarvo.
 
Liittynyt
29.10.2016
Viestejä
2 317
Tarvitsetko nopeamman / uuden mäkin nyt?
Jos vastaus on kyllä ja lompakko sanoo myös "yes", niin mars ostoksille.
Jos taas et tarvitse tai hillot on finito, niin käytä vanhaa.
Noita on täysin turha pohtia noin yleisesti. Paitsi s.e. tietokone on huono sijoitus, jos sitä ei tarvitse, sillä on lähinnä käyttöarvo.
Ei tuosta ehkä niinkään laskentateho ole loppumassa. Voi olla, että tyrkkään vaan keskusmuistia kamman lisää ja vaihdan SSD:n nykyisen fusionin tilalle. Jatkettu takuu päättyy marraskuussa.
 
Liittynyt
17.10.2016
Viestejä
11 941
Ei taida ainakaan tämän syksyn iMac olla Armilla vielä
Core i9-109100 (ts kelloiltaan perusmallista erottuva Apple-versio) + Radeon Pro 5300
On ihan mahdollista, että iso tai pieni iMac tulee ARM:lla ja toinen Intelillä.
 

Foxy

• Artisti •
Liittynyt
11.01.2019
Viestejä
323
Ja minulla on kyllä ollut käsitys, että ARM pohjaiset piirit eivät edelleenkään pärjää nopeimmille X86 pohjaisille
Tuohon voisi sanoa, että riippuu niin paljon mitä teet, softasta. Winkkari puolella esim Premieren export ajat jää välillä Ipad pro/iMovielle.
Onhan ne apit nyt jo tarvinnut "kääntää" Macillekkin erikseen (unix). Veikkaan, että ammatikäyttäjille suunnatut softat esim Finalcut ja muut paljonkäytetyt mac softat tulee hyötymään tuosta hyvinkin paljon kun kaikki tehdään vartavasten samalle ARM pohjalle täysin optimoituina. Aika näyttää ei voi tietää etukäteen :)
 
Viimeksi muokattu:

tle88

BANNATTU
BANNED
Liittynyt
31.10.2016
Viestejä
1 117
Minustakin tällä hetkellä olisi vain viisainta vähän viilailla vanhaa kalustoa paremmaksi, ja odotella ihan rauhassa, mitä sieltä on jouluun mennessä tulossa. Eikä se ensi kevätkään enää niin kauhean kaukana ole. Ei ole mitään niin tympeää asiaa, kuin suljettu rauta jonka tuki on valmistajan puolelta päätetty lopettaa. Jos yksityiseen ja siis nimen omaan ei työkäyttöön konetta tarvitsee, niin minä itse kyllä odottaisin ihan rauhassa noita uusia arm malleja. Siihen suuntaan se nyt kääntyy, ja kaikki kehitys tulee jatkossa menemään uusien arm systeemien suuntaan. Kyllä intel pohjaiset macit ovat tästä päivästä eteenpäin käymässä vanhanaikaisiksi, vaikka niillä tietenkin yhä edelleen on se suuri käyttöarvonsa.

T -.-

Olen siis nähnyt siirtymän sekä Motorolan 68k -> powerPC, että myös siirtymän powerPC -> Intel alustaan. Se tuki vanhoille alustoille päättyi käytännössä aika äkkiä sitten kuitenkin. Eivätkä nykyisetkään 10.14 ja 10.15 käyttöjärjestelmille tehdyt ohjelmat toimi jossain 10.10.5 alustassa. Kyllä se intel systeemikin tuossa mennessä aika paljon kuitenkin on muuttunut. Tulossa oleva seuraava Firefox ei esim. 10.10.5 systeemin kanssa enää toimi, jolloin mitään uutta ja ajan tasalla olevaa selainta ei vanhaan koneeseen enää vain saa, ei mitenkään eikä mistään. Alle 3 vuotta vanhalla Safari selaimellakaan ei pääse enää edes Verkkokauppa.comin sivuille.
 
Liittynyt
16.10.2016
Viestejä
12 044
Jos vielä pysyisin Mac puolella niin en kyllä itse nyt ostaisi omalla rahalla mitään ennenkuin uudet ARM-pohjaiset on kaupoissa. Senkin jälkeen katsoisin jonkin aikaa miltä ne näyttää ja olisiko parempi ostaa vasta toista iteraatiota kun ensimmäisestä opittu on saatu käytäntöön.

Nyt kun ostaisi isolla rahalla Intel pohjaisen niin kyllähän se käytännössä muutamassa vuodessa viimeistään alkaisi jäädä vanhaksi. Näin on itselläkin kokemukset aiemmista Mac siirtymistä. Heti alkuun taas ARM-pohjaisilla menee emulaation virittelyssä ja softien porttailukin kestää ennenkuin alkaa natiivia ARM versiota löytyä kuin noista ihan yleisimmistä kaupallisista softista.

Hyvin optimoituna ja Applen omilla piireillä usko kyllä että tehoa tulee riittämään ARM pohjaisillakin Maceilla. Nyt kun vanhat 32 bittiset pelit jo lakkasi toimimasta ja jatkossa ei Intel yhteensopivuutta ole rautatasolla niin itse kokeilen nyt Linux+Windows läppärillä kehitys ja pelailumahdollisuutta. Saa paljon halvemmalla myös sitä rautaakin sitten.

Riippunee käyttätarkoituksesta, puhtaasit ammattikäyttöön Mac on varmasti jatkossakin oikein hyvä valinta.
Pirun kallis ja täysin apple lukittu. En kyllä nyt noin, niinkuin yleistäen missään nimessä kehuisi mäkkiä hyväksi valinnaksi.
Esim tuossa juuri piti pohtia, mistä saisi yhteen mäkkiin virtalähteen? Vastaus oli, että ei mistään järkevästi. Ei edes vaikka johdot virittäisi siihen poweriin itse. (Joihinkin HP:n palvelinkoneisiin on joutunut pistämään johdotuksen, kun liittimet on epästandardit. muutoin tavan PC poweri käy.)
Applella on myös täysin perseestä tuo varaosapolitiikka muutenkin, ei hyvä. Läppärin näppikseen roiskahtraa vähän kaljaa, niin korjaaminen maksaa yli uuden läppärin hinnan (ko roju toimi muuta kautta korjattuna ilman ongelmia).
 
Liittynyt
29.10.2016
Viestejä
2 317
Pirun kallis ja täysin apple lukittu. En kyllä nyt noin, niinkuin yleistäen missään nimessä kehuisi mäkkiä hyväksi valinnaksi.
Esim tuossa juuri piti pohtia, mistä saisi yhteen mäkkiin virtalähteen? Vastaus oli, että ei mistään järkevästi. Ei edes vaikka johdot virittäisi siihen poweriin itse. (Joihinkin HP:n palvelinkoneisiin on joutunut pistämään johdotuksen, kun liittimet on epästandardit. muutoin tavan PC poweri käy.)
Applella on myös täysin perseestä tuo varaosapolitiikka muutenkin, ei hyvä. Läppärin näppikseen roiskahtraa vähän kaljaa, niin korjaaminen maksaa yli uuden läppärin hinnan (ko roju toimi muuta kautta korjattuna ilman ongelmia).
Köyhille kallis, muille saman hintainen.

Vakavissaan kannattaa pohtia asiaa näin: Osta 5k resoluution näyttö (ei taida edes saada), erillinen keskusyksikkö, langattomat bt-härpäkkeet. Sitten alat lisäämään siihen palikkaa, että saat samantasoisen kuin imac. Ei se ihan halvalla enää onnistu. Nykyään näkyy saavan 4k näyttöjä jo tuohon 500€ luokkaan. Kun ostin iMacini 3v sitten, oli halvimmat liki 1000€.
Toisaalta jos se Apple tuntuu kalliilta, niin kannattaa suosiolla varmaan vain ostaa joku muu?

edit: varaosista olen kyllä samaa mieltä.
 
Liittynyt
05.02.2017
Viestejä
5 124
Liittynyt
17.10.2016
Viestejä
11 941
OpenCL testi ei ole kauhean järkevää ajettavaa, koska Apple on lopettanut OpenCL:n kehittämisen omalla alustallaan.


A12Z:ssa on myös merkittävästi nopeammat LPDDR4X muistit kuin vertailukohteissa.
 
Viimeksi muokattu:

user9999

Platinum-jäsen
Liittynyt
17.10.2016
Viestejä
3 013
Vakavissaan kannattaa pohtia asiaa näin: Osta 5k resoluution näyttö (ei taida edes saada), erillinen keskusyksikkö, langattomat bt-härpäkkeet. Sitten alat lisäämään siihen palikkaa, että saat samantasoisen kuin imac. Ei se ihan halvalla enää onnistu. Nykyään näkyy saavan 4k näyttöjä jo tuohon 500€ luokkaan. Kun ostin iMacini 3v sitten, oli halvimmat liki 1000€.
Offtopic:

LG:ltä löytyy 27" 5K näyttö.
 

user9999

Platinum-jäsen
Liittynyt
17.10.2016
Viestejä
3 013
Etsippä ei-mac jossa tuo toimii täydellä resolla...

Mulla on tuollainen työpaikalla. Tuon monitorin olemassaolo on erinomainen syy käyttää Mac:ia työkoneena.
Erinomainen näyttö. Onkohan 2019 iMacissä sama paneeli? Molemmissa esim. kirkkaus sama 500 nits.
 
Liittynyt
17.10.2016
Viestejä
2 305
Etsippä ei-mac jossa tuo toimii täydellä resolla...

Mulla on tuollainen työpaikalla. Tuon monitorin olemassaolo on erinomainen syy käyttää Mac:ia työkoneena.
OT: Mikä 5k:ssa niin hankalaa on muille kuin Maceille?

e: Vai onko se Thunderbolt 3 joka tuossa tulee ongelmaksi?
 
Liittynyt
03.01.2018
Viestejä
576
Tuoreimmat huhut kertovat että Apple harkitsee prosessoriensa myyntiä muillekin. Saapi nähdä, mutta mikäli pitää paikkaansa niin arm-maihinnousu saattaa vahvistua aika nopeallakin aikataululla.
 
Liittynyt
22.10.2016
Viestejä
11 029
Kyllä. Mutta Apple saa nopeasti softat käännettyä mille vaan arkkitehtuurille ja nyt onkin mielenkiintoista nähdä, onko siellä
  1. lisätty ydinmäärää , että saadaan raakaa general purpose laskentatehoa
  2. tehty erityislaskentayksikkö, jossa nuo lasketaan; tai käskykanta, niinkuin MMX ja AVX - eli erityistä käsittelyä special caseille
ARMissa on jo pitkään ollut NEON-niminen 128-bittinen vektorikäskykanta. Ominaisuuksiltaan ollut jonkin verran SSEtä parempi, mutta vain 128-bittinen kuten SSE.

Pari vuotta sitten julkaistiin SVE ja tänä keväänä SVE2, jotka ovat sitten paljon kehittyneempiä vektorikäskykantoja, SVE(2)ssa vektorin leveys on implementaation päätettävissä, tukee vektoreita jopa 2048 bittiin asti.

Eli itse SVE/SVE2-käskykanta ei lyö lukkoon vektorin pituutta, vaan implementaatio toteuttaa jonkun leveyden sekä mm. käskyt "lisää pointeria vektorin pituuden verran" "lisää laskuria vektorin elementtimäärän verran" "kytke pois päältä vektorilinjat joiden indeksi menee tämän laskuriarvon yli", mikä mahdollistaa sen, että kääntäjä voi autovektoroida melkein minkä tahansa loopin jossa ei datariippuvuuksia, ja se ajautuu oikein (ja optimaalisella nopeudella) riippumatta siitä kuinka leveät vektorit raudala löytyy; Kapeammilla vektooreilla loppia vaan pyöritään useampi kierros.
 
Liittynyt
03.01.2018
Viestejä
576
Jotain lähdettä näille huhuille?
Erittäin epämääräisiä huhuja:



Mutta Microsoft varmasti haluaa nopean arm prossun Windowsille mahdollisimman nopeasti - pari vuotta viivyttelyä ja game over.

-Applella sen sijaan ei ole niin helppo kysymys kannattaako pelkkien prosessorien myynti - nyt voi käydä niin että Mäcistä tulee ARM-serveripuolen kehitysalusta kun muuta varteenotettavaa ei ole tarjolla.
 
Liittynyt
05.02.2017
Viestejä
5 124
Nyt alkoi jo jollain entisellä Apple-pomolla mopo keulia, ja hän oli blogissaan sitä mieltä että Windows-puolellakin pitää vaihtaa ARM-prosessoreihin, etteivät tipu kelkasta:
Mun mielestä kyllä ihan huuhaata. Intelin ongelmana on ollut vanhentunut valmistusprosessi. Se tulee joskus kuntoon, ja vaikka ei tulisi, niin AMD joka tapauksessa valmistaa prosessorit TSMC:n valmistusprosesseilla. Kirjoittaja tuntuu olevan sitä mieltä, että x86 on vain niin huono, että kannattaa vaihtaa. Hän ohittaa kokonaan ne ongelmat, mitkä tulisivat, jos prosessorit vaihtuisivat. Apple on luultavasti tehnyt vuosikausia hommia saadakseen Rosettan toimimaan hyvin.
 

jsa

Tukijäsen
Liittynyt
20.10.2016
Viestejä
611
Kirjoittaja tuntuu olevan sitä mieltä, että x86 on vain niin huono, että kannattaa vaihtaa. Hän ohittaa kokonaan ne ongelmat, mitkä tulisivat, jos prosessorit vaihtuisivat. Apple on luultavasti tehnyt vuosikausia hommia saadakseen Rosettan toimimaan hyvin.
No x86 on HUONO tätä nykyä. Jotain modernisaatiota kaipaa kun nykynen ISA on suunniteltu 16 bittisille laitteille ja on 40 vuotta vanha, johon lätkitty vaan lisää päälle.Ja kuin kirsikaksi kruunuun se 16 bittinen ISA oli suunniteltu lähdekoodi yhteensopivaksi 50 vuotta vanhan 8-bit vermeille tarkoitetun ISAn päälle.

RISCeillä duunailleena tuntuu nykyään aika tympeältä kun x86 käskyt ei olekkaan ihan niin standardi mittasia vaan siellä voi olla se 1 byte (nop) ja sitten aika helvetin pitkiin olikos nyt 15 tavua pitkiin hirvityksiin :) CISCin iloja. Enempi alkaa olemaan rajoitteena jo sekin että siinä missä modernimmissä vermeissä on enempi yleiskäyttösiä rekisterejä niin niiden lukumäärä laahaa x86_64:ssa perässä. Sitä en tiedä miksi aikanaan ei x86_64sen kanssa hypätty suurempaa GPR lukumäärään.

Näitä ongelmia ei valmistusprosessi korjaa :/
 
Liittynyt
22.10.2016
Viestejä
11 029
No x86 on HUONO tätä nykyä.
Ei ole. x86-64 on toiseksi paras yleisesti käytetty CPU-käskykanta, heti ARMv8n jälkeen.

Se on parempi kuin esim. SPARC, MIPS, PPC, Itanium, RISC-V tai Alpha.

Jotain modernisaatiota kaipaa kun nykynen ISA on suunniteltu 16 bittisille laitteille ja on 40 vuotta vanha, johon lätkitty vaan lisää päälle.
Sitä on modernisoitu vaikka kuinka moneen kertaan:

80386 poisti pakon käyttää segmenttejä mihinkään ja toi modernin ja järkevän muistinhallintayksikön.

P6 toi ehdolliset käskyt (vähensi selvästi haarautumisten tarvetta) sekä laajensi fyysiset osoitteet 36-bittisiksi.

P4 toi SSE2n jonka avulla ei ollut mitään tarvetta enää käyttää x87-FPUsta joka oli hirveä sotku.

K8 laajensi kokonaislukudatapolun 64 bittiin, virtuaaluosoitteet 48 bittin (optiolla laajentaa ne täyteen 64 bittiin asti) ja poisti 64-bittisessä tilassa viimeisetkin jäljet segmenteistä. Ja samalla osa alkuperäisistä opkoodeista uudelleen.

Ja kuin kirsikaksi kruunuun se 16 bittinen ISA oli suunniteltu lähdekoodi yhteensopivaksi 50 vuotta vanhan 8-bit vermeille tarkoitetun ISAn päälle.
Tällä ei ole mitään merkitystä. Se, että joillekin rekistereille määritellään samat aliakset assemblyyn ei haittaa yhtään mitään.

RISCeillä duunailleena tuntuu nykyään aika tympeältä kun x86 käskyt ei olekkaan ihan niin standardi mittasia vaan siellä voi olla se 1 byte (nop) ja sitten aika helvetin pitkiin olikos nyt 15 tavua pitkiin hirvityksiin :) CISCin iloja.
"tuntuu tympeältä" arvo teknisenä argumentina on puhdas 0.

Keskimääräinen käskynpituus x86lla on lyhempi kuin suurimmalla osalla RISCejä, ja jos verrataan muihin kuin ARMv8iin, saman asian tekemiseen tarvitaan myös vähemmän käskyjä => koodin koko samalle asialle selvästi pienempi, ja tällä saadaan mm. parempi käskyvälimuistien osumatarkkuus.

Ja niitä 15 tavun käskyjä ei käytännössä koskaan näe missään. Se tarkoittanee sitä, että siellä on kaikki erilaiset prefix-tavut ja sitten jostian pitkästä käskystä versiot joissa on pari 64-bittistä immediate -arvoa. Saman asian tekevät RISC-koodi muuten vaatii PALJON ENEMMÄN tavuja, kun esim useimmissa RISCeissä pelkästään YHDEN 64 bitin immediaten siirtämiseenkin tarvitaan 128 bittiä=16 tavua käskyjä.

Ja x86ssa on vaikka kuinka paljon HYÖDYLLISIÄ JÄRKEVÄÄ TYÖTÄ TEKEVIÄ yhden tavun käskyjä. 4 kertaa lyhyempänä kuin useimmissa RISCeissä. Yhden tavcun ksäkyt ei yleensä ole mitään NOPeja, toki on olemaassa myös yhden tavun NOP.

Se, että käskyt on hankalampi dekoodata tuntuu pikkusen, esim siinä että järeimmät x86-prossut dekoodaa vain 4-5 käskyä kellojaksossa (ja yksi vähemän järeä 2*3), ja käskyn dekoodaukseen tarvii pari liukuhihnavaihetta. Ja siihen, että saadaan prossu etupäässä käsiteltyä enemmän kuin 4-5 käskyä kellojaksossa on silti ratkaisu olemassa, mikro-op-välimuisti, joka tallettaa dekoodattuja käskyjä, löytyy Inteliltä P4sta sekä Core-sarjasta Sandy Bridgestä lähtien, ja AMDltä Zenistä lähtien.

Se mikro-op-välimuisti maksaa inasen pinta-alaa, mutta pii-pinta-ala on nykyään älyttömän halpaa. Ja se 1-2 vaihetta pidempi decode-vaihe tuntuu inasen haarautumisenennustushudissa, mutta se, onko se 16,17 vai 18 kellojaksoa ei ole kovin merkityksellistä, kun haarautumisenennustus on kuitenkin todella hyvä, ja huti on joka tapauksessa paha hidastus.

Enempi alkaa olemaan rajoitteena jo sekin että siinä missä modernimmissä vermeissä on enempi yleiskäyttösiä rekisterejä niin niiden lukumäärä laahaa x86_64:ssa perässä.
Rekisterien uudelleeniomeäminen on keksitty, ja x86-käskyt voivat lukea operandinsa suoraan muistista. Mitään merkittävää pullonkaulaa rekisterimäärän suhteen ei x86-64ssa ole.

Nykyisissä x86-prossuissa on ~180 yleiskäyttöistä rekisteriä.

Sitä en tiedä miksi aikanaan ei x86_64sen kanssa hypätty suurempaa GPR lukumäärään.
Jospa ottaisit selvää, mistä puhut.

x86-64ssa yleiskäyttöisten kokonaislukurekisterien määrä nimenomaan nostettiin kahdeksasta kuuteentoista, koska se 8086n/80386n 8 oli jossain määrin pullonkaula.

Ja syyt miksei sitä lisätty enempä on selvät ja hyvät:

Arkkitehtuurilliset rekisterit näkyy käskyenkoodauksessa. x86-käskyt voivat olla paljon lyhempiä (todella monet yleiset käskyt on 2 tavua, REX-prefixin kanssa 3, tyypillisillä RISCeillä 4 tavua) koska rekistereitä on vähän ja kohderekisterin pitää useimmilla käskyillä olla sama kuin toisen lähderekisterin. Rekisterien tuplaus 8->16 maksoi jo tuon REX-prefix-tavun. Rekisterien määrän laajennus 32 bittiin olisi käytännössä maksanut varmaan toisen tavun, ja poistanut täysin x86n käskyntiheysylivoiman.

Nyt siis x86n koodintiheysetu kapeni selvästi näiden REX-tavujen takia.

Ja hyöty 32 arkkitehtuurillisesta rekisteristä hyvin, hyvin pieni.

Rekistereitä vaatii paljon lähinnä sellaisiin optimointeihin, joita spekulatiivisella out-of-order-prosessorilla ei tarvitse tehdä.

Mutta, tuo tapa miten tuo reksiterien määrän lisäys jouduttiin tekemään tuolla REX-prefixillä on käytännössä melkein AINOA historiapainolasti jota x86-64lla on jäljellä; Jos itse käskykannan olisi pitänyt samana mutta käskyenkoodauksen olisi voinut laittaa täysin uusiksi, samat käskyt olisi menneet keskimäärin hiukan pienempään tilaan, jolloin x86n etumatka käskyenkoodauksen tiheydessä ei olisi kaventunut kuten se nyt kapeni.

Näitä ongelmia ei valmistusprosessi korjaa :/
Nämä eivät ole mitään ongelmia.

Jospa puhuttaisiin niistä muiden arkkitehtuurien oikeista/suuremmista ongelmista:

* MIPSissä ja SPARCissa on branch delay slot.

Hypyn jälkeinen käsky suoritetaan aina, otettiin hyppy tai ei. Tällä saatiin poistettua stalli 5-vaiheiseltaä liukuhihnalta 35 vuotta sitten.. Nykyisssä prossiossa on n. 12-18-vaiheisia liukuhihnoja ja ne fetchaa 4-8 käskyä kellojaksossa. Delay slotteja tarvittaisiin n. 71-95 kpl että niillä voitaisiion ratkaista tämä ongelma mitä delay sloteilla silloin ratkaistiin => nykyään käytetään haarautumisenennustusta haarautumisenkohdepuskurin kanssa. Se, että meillä on se yksi delay slotti siellä tekee vaan kaikesta hankalampaa, ja välillä pakottaa kääntäjän myös tunkemaan sinne ylimääräisen NOPin.

* MIPSissä on erilliset lo- ja hi-rekisterit kerto- ja jakolaskulle.

Näiden takia kerto- ja jakolaskujen kanssa tarvitaan hirveä ylimääärinen härväys datan siirtämiseksi näihiin tai näistä pois. Vähän samaa ongelmaa kuin mitä oli x87.FPUssa (jota ei enää 18 vuoteen ole tarvinnut käyttää)

* SPARCissa ja Itaniumissa on rekisteri-ikkunat.

Nämä tekevät rekisterien uudelleennimeämisestä paljon vaikeampaa, ja tämän takia Sun teki ensimmäisen käskyjä uudelleenjärjestelevän SPARC-suorittimen n. 16 vuotta muita valmistajia myöhemmin. Ja käskyjen uudelleenjärjestely rekisterien uudelleennimeämisellä on käytännössä elinehto hyvälle tai edes välttävälle yhden säikeen suorituskyvylle tällä vuosituhannella.

* MIPSissä, RISC-Vssä ja Alphassa ei ole muuta muistinosoitussmuotoa kuin [reg+imm].

Eli jos halutaan vaikak tehdän normaalia taulukon käyttämistä, tarvitaan siihen KOLME käskyä (indeksin skaalaus datatyypin kokoiseksi, pointterin ja skaalatun indeksin yhteenlasku, ja iutse muistioiperaatio). x86 ja ARM tekee tämän yhdellä käskyillä. Joissain muissa RISCeissä on [reg+reg] eli sujuu kahdella käskyllä, parempi kuin MIPS, RISC-V ja Alpha, mutta silti huonompi kuin ARM ja x86.

* RISC-V:stä puuttuu kokonaan kaikki muut ehdolliset käskyt kuin hypyt.

Koodiin tarvitaan selvästi enemmän haarautumisia, joka pikkuprossulla tarkoittaa enemmän stalleja, tehokkaalla prossulla tarkoittaa sitä, että haarautumisenennustusyksikön kirjanpidosta loppuu tila aiemmin kesken ja sen osumatarkkuus on huonompi. (eli lopulta myös enemmän stalleja). Ja siinä ei ole ollenkaan nopeaa keinoa suorittaa koodia, jossa on haarautumisia, joita on mahdoton ennustaa, esim hakuja binäärihakupuusta; Tällöin se joutuu aina haarautumaan ja failaamaan ennustuksen (josta seuraa pitkä paha stall ja haaskattua virtaa) 50% tapauksista, siinä missä muilla arkkitehtuureilla voidaan ehdollisilla siirroilla odottaa vaan pari kellojaksoa sitä ehdon laskentaa.

* PPCssä on hyvin monimutkaiset käänteiset hajautustauluun perustuvat sivutaulut, joiden käsittely käyttöjärjestelmän toimesta on todella hankalaa ja hidasta, ja niiden lisäksi käyttis joutuu vielä toteuttamaan omaa kirjanpitoaan jota normaalien hierarkisten risvutaulujen tapauksessa ei tarvita (koska suorana prossun käytössä olevat sivutaulut toimii suoraan myös käyttiksen omana kirjanpitona). Tämä tekee esim. uusien prosessien luonnista sekä prosessien vaihtamisesta PPCllä hitaampaa ja on vaikempaa kirjotitaa käyttiskoodi joka tekee nämä bugittomasti.

* PPC on natiivisti big-endian ja sen lisäksi myös kutsuu suurinta bittiä indeksillä 0, pienintä bittiä indeksillä N-1 missä N on prosessorin bittimääärä. Eli alin bitti on jokko bitti 31 tai bitti 63 riippuen prossun toimintatilasta, samoin se bitti mikä 32-bittisenä on ylin bitti on joko bitti 0 tai bitti 32 riippuen prossun toimintatilasta. Melkoista sillisalaattia.

* Itaniumissa kolme käskyä vie yhteensä 16 tavua tilaa, ja sen lisäksi koodiin tarvitana NOPeja => itanium-koodi vie TODELLA PALJON tilaa => Suuri muistintarve käskyille, käskyvälimuistin huono osumatarkkuus.

* RISC-V:stä puuttuu täysin järkevät "keskiraskaat" SIMD-laajennokset.

Sille on määritelty P-laajennos, joka vain mahdollistaa skaalarireksiterien pätkimisen pienemmiksi laskutoimituksisksi, mutta tämä tarkoittaa sitä että vektorin leveys on 32-bittisellä prossulla 32 bittiä ( 8 kertaa kapeampi kuin AVX) ja 64-bittisellä prossulla 64 bittiä (4 kertaa kapeampi kuin AVX). Näillä ei suurta suorituskykyä saada.

Lisäksi sille ollaan määrittelemässä V-laajennusta joka on ominaisuuksiltaan paljon "parempi," mutta se ihan hirveä overnengineerattu häröpallo, joka ei todennäköisesti monimutkaisuutensa takia tule saamaan kunnollista kääntäjätukea n. 10 vuoteen, eikä sitä varmaan implementoidakaan käytännössä mihinkään koska sen implementointikin on niin hankalaa.

* Alphasta ja SPARCista puuttuu myös kaikki "keskiraskaat" ja järeämmät SIMD-laajennokset. Niissä on vain RISC-V:n P-extension tapainen normaaleita (kapeita) skalaarirekisterejä käyttävä, jolla suoerituskykyä ei saa paljoa.

* Kaikilla muilla arkkitehtuureilla paitsi x86lla ja SPARCilla on löysemmät muistin konsistenttiussäännöt. Koodiin tarvii lisätä ylimääräisiä fence-käskyjä, joiden yli muisitoperaatioita ei saa uudelleenjärjestellä, jos halutaan, että muistioperaatiot näkyy toisille säikeille samassa järjestyksessä. X86 voi kuitenkin todellisuudessa uudelleenjärjestellä muistioperaatiota, kunhan vain pitää kirjaa niiden alkuperäisestä järjestyksestä ja sekä huolehtii järjestyksen näennäisestä säilymisestä säikeen sisällä (mm tarvittaessa forwardoiden arvoja store-puskurista loadeille) että välittää muutokset toisille säikeille konsistenttiussääntöjen mukaisessa järjestyksessä.

Mikäli muista, löysemmät konsistenttiussäännöt omaavista arkkitehtuureista tehdään muistioperaatioita yhtä aggressiivisesti uudelleenjärjesteleviä versiota, ne joutuvat kuitenkin pitämään kirjaa operaatioiden alkuperäisestä järjestyksestä sekä tekemään saman store-to-load-forwardingin yhden säikeen sisällä. Tällöin niistä löysemmistä konsistenttiussäännöistä ei enää hyödytäkään mitään, kun ne kuitenkin feikataan, ja jäljelle jää lähinnä overhead niistä fence-ksäkyistä (jotka pakottaa flushailemaan paljon muutakin kuin oikeasti tarvisi)

* ARMv8lla, SPARCilla, PPCllä ja Alphalla kaikki käskyt on 32 bittiä pitkiä. Erityisesti SPARCilla ja PPCllä tämä tarkoittaa huonohkoä käskytiheyttä => tarvitaan paljon käskymuistia, huonompi osumatarkkuus käskyvalimuistille.
ARMv8ssa on sama ominaisuus, mutta siinä on niin paljon ilmaisuvoimaisempia käskyjä, että se tarvii vähemmän käskyjä saman asian tekemiseen, että siinä tämä ei ole merkittävä huonous, sen koodin tiheys ei silti ole huono. PPC on myös jossain määrin ilmaisuvoimaisempi kuin SPARC eli oikeastaan pahana jää jäljelle vain SPARC:
RISC-V:ssä, MIPSissä ja ARMv7ssa sitten myös 16-bittinen käskyenkoodaus eniten käytetyille käskyille, ja ARMv7/Thumb2lla päästää jopa 386sta tiheämpään koodiin ja MIPS16 ja RISCV-C pääsee lähelle 386sta ja välillä jopa voittaa x86-64n.

* Alphassa ei ole hardware-page walkeria. Mikäli osoitteenmuunnosdataa ei löydy TLBstä, seuraa poikkeus joka lentää PAL-koodilla olevaan käsittelijään, joka lataa sivutaulun hitaasti softalla. Tämä on paljon hitaampaa kuin sivutaulujen hakeminen raudalla.

* MIPS, SPARC, Itanium, Alpha eivät tue alifgnoimattomia muistiaccesseja. RISC-V tukee, mutta ainakin toinen kahdesta yleisimmästä kääntäjästä sille kieltäytyy tekemästä niitä, lähinnä koska niiltä vaaditaan tukea vain user-moodissa ja kääntäjän halutaan toimivan myös kernelille.

Näillä arkkitehtuureilla, jos kääntäjä ei pysty todistamaan, että (muuten laillinen) muistiaccess on alignoitu, se luo hirveän häröpallokoodin jossa muuttaa (mahdollisesti) alignoimattoman muistiaccessin moneksi alignoiduksi muistiaccessiksi. Ja tämä häröpallokoodi on HIDAS.
Ja tosiaan, vaikka itse access olisi oikeatit alignoitu, mutta kääntäjä ei vaan tiedä sitä, tämä häröpallokoodi tehdään.

Arkkitehtuureilla, joissa unaligned accessit on aina tuettuja(ja kääntäjä tietää sen), kääntäjä ei tee mitään häröpallokoodia, ja se muistiaccess saattaa olla esim. yhden kellojakson hitaampi JOS se OIKEASTI sattuu olemaan unaligned.


x86-64lla on käytännössä jäljellä kaksi epäoptimaalisuutta:

* Se käskyenkoodaus on turhan monimutkainen eikä optimaalinen. Tästä oli puhetta jo aiemmin.

* Tuettuna ei ole mitään virtuaalimuistisivujen kokoa 4 kiB ja 2 MiB välistä. Nykyaikana joku 16k-64 k olisi usein järkevämpi, 2 megaa on aivan liian suuri käytettäväksi "kaikkialla", 4 kiB yleisesti käytetty virtuaalimuistisivu tarkoittaa sitä, että L1D-kakun maksimi-way-koko on 4 kiB että voidaan tehdä VIPT-tyyppinen L1D-kakku ilman mitään aliasoitumista (joka on hirveä suo). Eli 8 wayllä L1D-kakun maksimikoko on 32 kiB(zen, sandy bridge-skylake), sunny covessa sitten 12-way 48 kiB. Applella on ARMv8ssaan 16 kiB välimuistisivut joilla voidaan VIPT-tyyppisenä tehdä 4 kertaa suurempi L1D-kakku ilman että way-määrä kasvaa suuremmaksi, ja viimeisissä Applen ytimissä L1D-kakku onkin 128 kiB.
 
Viimeksi muokattu:
Liittynyt
17.10.2016
Viestejä
21 879
Erittäin epämääräisiä huhuja:



Mutta Microsoft varmasti haluaa nopean arm prossun Windowsille mahdollisimman nopeasti - pari vuotta viivyttelyä ja game over.

-Applella sen sijaan ei ole niin helppo kysymys kannattaako pelkkien prosessorien myynti - nyt voi käydä niin että Mäcistä tulee ARM-serveripuolen kehitysalusta kun muuta varteenotettavaa ei ole tarjolla.
Häh?

Näitä ARM-läppäreitä on ollut jo tovi:
(myös joku Toshiba Gigantilla oli myynnissä)

Nyt on mennyt vaan Applen propaganda läpi ja "Apple on aina ekana" valheet on uponneet täysin.
 

moukula

Team AMD
Liittynyt
17.10.2016
Viestejä
2 468
Toggle Sidebar

Statistiikka

Viestiketjut
237 336
Viestejä
4 157 587
Jäsenet
70 409
Uusin jäsen
Eycte

Hinta.fi

Ylös Bottom