Apple siirtyy Arm-arkkitehtuuriin Mac-tietokoneissa

[Marti77]

Yllättävän tiukan aikatalun asettivat siirtymälle vaikka se on jo ollut tiedossa viime vuodesta lähtien.
Voi olla ihan hyvä ratkaisu kunhan saavat tarpeeksi suorituskykyiset ytimet.

 

[hkultala]

Jos uudet sovellukset käännetäänkin ARM:ille ja niitä emuloidaan x86-arkkitehtuurilla? Näin saadaan se suorituskykyero heti kättelyssä ARM:in hyväksi.. Apple on niin iso firma, että se voi vain sanella tämmöiset ehdot.

Uudet softat käännetään molemmille, fat binaries.

Ei varmasti tule mitään RM-emulaatiota x86lle.

Lisäksi. kun Apple osti PA Semin - saadakseen omat ARM-prosessorit taloon, niin ketä olikaan se kaveri , joka sieltä tuli samalla tuomaan prosessoriosaamista taloon? Tämä kaveri on taas vapautumassa nykyisestä positiostaan "henkilökohtaisista syistä" ja eiköhän tässä olisi rahakas keikka vetää tätä siirtymää. Kenestä olikaan kysymys?

Jim Keller.

Ja ei, tässä muutoksessa on pääosin kyse softasta (Sen binäärikääntäjän väsääminen yms.), Keller on raudansuunnittelija.

Ja se rauta on jo niin pitkällä että nyt olisi en suhteen jo liian myöhäistä,

 

[hkultala]

Jännä miten x86 alkaa jäämään niin altavastaajaksi ARM prossuja vastaan, vaikka senhän pitäisi olla paperilla nimenomaan moderni ja suorituskykyinen toisin kuin alkukantaisen yksinkertainen RISC.

ARM ei ole alkukantainen ja yksinkertainen.

ARMv8 on modernein(*) kaikista yleisistä käskykannoista ja se on kaikkea muuta kuin normaali RISC; Se tekee paljon asioita melko epä-RISCillä tavalla.

Esimerkkejä mm.
* Load pair ja store pair
* Osoitusmuodot taulukkojen accessointiin
* Ehdolliset vertailukäskyt (yhdistelmäehtojen if (a>b && c < d) kätevään generointiin ilman haarautumisia)
* Tuki analignoiduille muistioperaatioille
* Tulossa on SVE(2)-vektorikäskykanta joka on vektorin pituus-agnostinen; SVE/SVE2lle käännetty koodi toimii täydllä nopeulla minkätahansaleveyksisellä vektoridatapolull, vektoridatapolun leventäminen moninkertaistaa nopeuden vanhallekin koodille


(*) Eri asia kuin uusin; RISC-V on uudempi kuin ARMv8 mutta RISC-V on lähinnä vain 1980-luvun MIPS josta kaikkein typerimmät jutut korjattu, siihen ei ole otettu mitään mitä viimeisen 20 vuoden aikana käskykannoista on opittu.

 

[hkultala]

Apple ei voi sanella tuollaisia ehtoja, koska sillä ei ole mitään voimaa tai valtaa MacOS-softan devaajien suhteen. Kuka vaan voi kirjoittaa koodia ja kääntää sen opensource x86-kääntäjällä binääriksi ja ajaa sen missä tahansa x86-mac:ssä.

EI voi, koska jo nyt uusi Macos X oletusasetuksilla kieltäytyy ajamasta binääriä, jota ei ole allekirjoitettu sopivalla Applen hyväksymällä allekirjoituksella

Pitää ruksata aika monta "olen varma että haluan tehdä tämän hyvin vaarallisen asian"-dialogia että sen saa ajautumaan.

Eli kun sen softan yrittää toimittaa niille asiakkaille niin niiltä tulee aika paljon valitusta että "se ei toimi".

Tuollaiset ehdot voisi sanella vain, mikäli MacOS suljetaan AppStoren taaksi kuten iOS ja siitä taas ei ole mitään viitteitä.

Ei; Ratkaisevaa ei ole Appstore vaan binäärien allekirjoitus.

 

[hkultala]

Softaemulaatio on aina hitaampi kuin aito tuki ja useimmissa tapauksissa se ei ole edes 100% yhteensopiva.

Hitaampi, joo.

Yhteensopivuus saadaan kyllä kuntoon kun vaan korjataan emulaattorisoftasta/binäärikääntäjästä kaikki bugit.

ARMilla ja x86lla on täysin samat säännöt datan sijoittelun suhteen, mikä helpottaa yhteensopivuutta selvästi; Ainoastaan koodia pitää muuttaa, datan sijoittelua ei.

Tällä on hyvin oleellinen vaikutus siihen, kuinka helppoa kaikki on saada toimimaan.

PPCssä taas data oli sijoiteltu muistiin aivan eri tavalla kuin x86ssa ja ARMissa (PPC oli big endian, ARM ja x86 little endian)

Jos minä oikeasti tekisin töitä Macillä, niin minua kyllä arveluttaisi ajaa sitä työhön tarvittavaa softaa jollain emulaattorilla. Jos ei emulaation toimivuuden kannalta, niin vauhdin ainakin.

Mikähän se softa mahtaisi olla?

EIköhän ne kaikki oleelliset uudet hyötysoftat käännetä ARMille. Vanhojen softien yhteensopivuudesta Apple taas ei ole muutenkaan koskaan piitannut.

Ongelmaksi muodostuu lähinnä pelit.

Ja minulla on kyllä ollut käsitys, että ARM pohjaiset piirit eivät edelleenkään pärjää nopeimmille X86 pohjaisille

TÄLLÄ HETKELLÄ.

Apple on julistanut kahden vuoden siirtymäajan.

Ja ne pärjäävät jo nyt IPCssä esim. skylakelle ja zen2lle, mutteivät vaan saavuta yhtä suuria kelloja.

Applella on aika varmasti kehitteillä pidemmällä liukuhihnalla varustettu "PC-teholuokan" ARM-ydin.

ARM-käskykannassa itsessään ei ole mitään minkä takia sille ei voisi tehdä yhtä tehokkaita ytimiä kuin x86lle; Päin vastoin:

1) Isompi virtuaalimuistisivu mahdollistaa myös isomman nopean L1-kakun (koska ei tarvita ziljoona-way-assosiatiivisuutta että VIPT toimii ilman alisoitumista vaikka kakun kokoa kasvatetaan)
2) ARM on helpompi dekoodata, voidaan helpolla tehdä prossu joka dekoodaa 6-8 käskyä kellojaksossa, nopeimmat x86t dekoodaa maksimissaan 4-5 käskyä kellojaksossa (haaskaten siihen paljon virtaa ja vaatien siihen monta liukuhihnavaihetta)
3) ARMissa on kivat ehdolliset vertailukäskyt joilla voi kivasti laskea yhdistelmäehtoja (if a>b && c < d)
4) ARMissa on lataus- ja tallennuskäskyt joilla voidaan ladata/tallentaa 2 rekisteriä kerrallaan
5) SVE(2) tarjoaa vektoripituusagnostisen vektorikäskykannan

Ja niin, ARMv8issa ei ole oikeastaan mitään niitä idioottimaisuuksia mitä monissa muissa RISCeissä on minkä takia ne häviää x86lle.

 

[love_doctor]

EIköhän ne kaikki oleelliset uudet hyötysoftat käännetä ARMille. Vanhojen softien yhteensopivuudesta Apple taas ei ole muutenkaan koskaan piitannut.

Vanhassa softassa muutenkin emulaatio voi riittää ilman uudelleenkäännöstä. Kun koneet nopeutuvat, se emuloitukin toimii sitten jo yhtä nopeasti kuin alkup. laitteella natiivisti. Ja jos käyttää työssä niin legacyä, mutta haluaa myöhemmin lisää tehoja, tähän on helppo ratkaisu päivittää ne binäärit, jolloin pääsee vapaaksi koko emulointiloukusta ennen pitkää.

 

[hkultala]

Ja niin muuttuvat tarpeetkin. Todella monen softan muuttaessa (tai ainakin osittain) pilveen, raakan laskentatehon tarve vähenee. Eiköhän kehityssuunta ole se että päätelaitteet ovat lähinnä ruutuja ja yhteydenottoclientteja eri paikkoihin jossa varsinainen ohjelmisto pyörii. Maailma ei vielä ole valmis, mutta suunta on oikea.

Ei se tehontarve vähene yhtään mihinkään vaan siirtyy vaan toiseen paikkaan.

Kokonaislaskennan tarve vaan kasvaa, kun tietoliikenne lisääntyy ja tietoliikenteen vaatima laskentatarve kasvaa.

Ja kun taskuun mahtuva laskentateho kasvaa jatkuvasti, datam käsittely "pilvessä" yhä turhempaa suorituskyvyn kannalta.

Ja datansiirrossa on myös viiveet.

Eli kehitys menee nimenomaan aivan väärään suuntaan.

 

[zepi]

EI voi, koska jo nyt uusi Macos X oletusasetuksilla kieltäytyy ajamasta binääriä, jota ei ole allekirjoitettu sopivalla Applen hyväksymällä allekirjoituksella

Pitää ruksata aika monta "olen varma että halauan tehdä tämän hyvin vaarallisen asian"-dialogia että sen saa ajautumaan.



EI; Ratkaisevaa ei ole Appstore vaan binäärien allekirjoitus.

Toistaiseksi Apple ei vaadi MacOS:ssä binäärien allekirjoitusta Applen maksullisella omalla avaimella, vaan softaa voi sideloadata asetuksista yhden ruksin paikkaa siirtämällä..

Sitten jos homma muuttuu tuon haastavammaksi, niin tilanne on ehkä eri.

Siitä ei ole vielä ainakaan tietääkseni ollut myöskään puhetta.

Apple voi halutessaan sulkea MacOS:n, mutta ainakaan vielä se ei ole sitä tehnyt. Minkään idiottimaisen x86-koneella arm-binäärin pakotuksen takia sitä tusikin tullaan tekemään. Muista syistä ehkä, joskin toivon, että ei.

Minusta tietokone ei ole oikein tietokone jos en voi ladata tai kirjoittaa itse sorsakoodia ja kääntää sitä konekieliseksi.

 

[hkultala]

Toistaiseksi Apple ei vaadi MacOS:ssä binäärien allekirjoitusta Applen maksullisella omalla avaimella, vaan softaa voi sideloadata asetuksista yhden ruksin paikkaa siirtämällä..

Ei voi.

Asetusruudussa ei oletuksena ole nykyään ollenkaan vaihtoehtoa disabloida gatekeeper ja sallia ohjelmien ajaminen mistä lähteestä tahansa.

Asetusruutu "Allow apps downloaded from" sallii kaksi vaihtoehtoa, "App store" ja "App store and identified developers"

Eli ei onnistu millään graafisella kilkkeellä millään määrällä "olen varma että haluan tehdä tämän vaarallisen asian" -dialogeja eli olin itse asiassa väärässä kun sanoin että vaatii "monta ruksia".

Gatekeeper pitää disabloita komentoriviltä spctrl-komennolla.

How To Disable Gatekeeper on macOS Mojave and Catalina (video) — cronotek.net - Gaming, Technology, and Enterprise IT

Having difficulty installing apps remotely due to macOS Catalina security features? Sick of having to go into Security & Privacy to click "Allow" anytime you download an app?! Watch this video to see how to disable Gatekeeper (the program that blocks these settings by default) so y

cronotek.net

 

[escalibur]

Ei se tehontarve vähene yhtään mihinkään vaan siirtyy vaan toiseen paikkaan.

Kokonaislaskennan tarve vaan kasvaa, kun tietoliikenne lisääntyy ja tietoliikenteen vaatima laskentatarve kasvaa.

Ja kun taskuun mahtuva laskentateho kasvaa jatkuvasti, datam käsittely "pilvessä" yhä turhempaa suorituskyvyn kannalta.

Ja datansiirrossa on myös viiveet.

Eli kehitys menee nimenomaan aivan väärään suuntaan.

Tarkoitin kyllä että laskentatehon tarve vähenee itse päätelaitteissa, softien siirtyessä pilveen. Toki sitä paikallista laskentaa voidaan käyttää, tai tuhlata vaikka mihin. Siirtymä ei ole ongelmaton ja tietyissä tapauksissa viiveet ovat yhä haasteena.

 

[Lämpöpumppu]

Muokkasin viestiäni kun jäi ajatuksissani laittamatta, että tarkoitin puhua pöytäkoneista enkä niinkään kannettavista. Ja mitä nyt on seurannut esim. Louis Rossmannia Tuubissa niin uudemmissa Applen vehkeissä on kaikki juotettu emolevylle sekä käyttäjät ovat kusessa massamuistien suhteen, kun tuo aiemmin mainittu rautaan sitominen kusee heidän muroihin ja Apple ei näissä tapauksissa ilmeisesti liiemmin apua anna, vaan se on voi voi ja olisi pitänyt käyttää esim. Applen pilveä varmuuskopiointiin. Tosin onneksi on näitä 3. osapuolen oikeita fiksaajia jotka pystyvät joissain tapauksissa käyttäjiä auttamaan.

Vaikka se olisi pientä, niin en näe positiivisena asiana sen mahdollista menettämistä. Minä taas näen että sillä päivitettävyydellä on merkitystä ja se lisää mahdollista käyttöikää pidemmälle. Eikä pidä unohtaa myöskään sitä ettei joka puolella esim. eurooppaa kaikilla ole samallalailla euroa per henkilö, kuin vaikkapa meillä Suomessa.

Toki alkuperäisosillakin pärjää jos sietää kompromisseja, mutta tuossa olen katsonut esim. 2010-luvun core i5/i7-läppäreitä, niin esim. töihin tuli Applea ja muita merkkejä eka 128 gigan SSD:llä ja nyt vielä 256 GB. Samoin muistia oli 2-4 gigaa, Macbook Aireissa näki 2 gigaakin. Kun joku taitonetti tai muu pistää koneita käytettyjen markkinoille toiselle tai kolmannelle kierrokselle, levyn tuplaus esim. 256-512 gigaan olisi jo perusteltu. Samoin muisti 4-8 gigaan. Tämä tilanne elää koko ajan ja softan koko kasvaa eli nyt 10 vuoden päästä varmaan 4 gigaa muistiakin ja 256 GB ssd:tä kuulostaa jo melko pieneltä. Ainakin käyttökokemusta heikentää seuraavalla käyttäjällä jos ei muuta. Tässäkin huomautan, että käytettyjen markkinoista saa vain osittaisen kuvan, jos keskittyy noihin parempiin malleihin. Esim. virastoihin ja vastaaviin tulee nytkin noita täysin alispeksattuja koneita, joita voisi hyvin käyttää lukiolaiskannettavina yms. tulevaisuudessa. Kaikki on kiinni siitä, saako muistipaloja ja ssd:tä vaihdettua ekan 3-5 käyttövuoden jälkeen.

Jos on harrastuneisuutta räplätä tietokoneiden kanssa, niin eipä tuollaiseen iMaciin ole mitenkään ylitsepääsemätöntä vaihtaa SSD:tä tai lisätä RAM:ia. Tuossa 2015 tienoilla Apple kolvasi pikku-iMacin RAM:it kiinni, mutta vanhemmissa ja uudemmissa malleissa on taas ollut ihan normaalit SO-DIMM palikat. SSD ollut kai aina vaihdettavissa perinteisen kovalevyn tilalle. Itse vaihtanut SSD:n ja lisännyt RAM:ia 21,5" iMacciin ja voisi sanoa sen olevan ihan yhtä helppoa kuin perinteisen koneen kasaaminenkin. Tai jokainen osaa varmuudella tehdä vaihdon, jos osaa perinteiseen laatikkokoneeseenkin vaihtaa kovalevyn ja lisätä RAM:ia. Silti edelleen epäilen tämän olevan vain hyvin marginaalipuuhastelua kokonaiskuvassa, oli sitten yritysten vanhoja koneita tai ei. Tuskin Apple itseään jalkaan ampuu tämänkään suhteen.

 

[love_doctor]

Jos on harrastuneisuutta räplätä tietokoneiden kanssa, niin eipä tuollaiseen iMaciin ole mitenkään ylitsepääsemätöntä vaihtaa SSD:tä tai lisätä RAM:ia. Tuossa 2015 tienoilla Apple kolvasi pikku-iMacin RAM:it kiinni, mutta vanhemmissa ja uudemmissa malleissa on taas ollut ihan normaalit SO-DIMM palikat. SSD ollut kai aina vaihdettavissa perinteisen kovalevyn tilalle. Itse vaihtanut SSD:n ja lisännyt RAM:ia 21,5" iMacciin ja voisi sanoa sen olevan ihan yhtä helppoa kuin perinteisen koneen kasaaminenkin. Tai jokainen osaa varmuudella tehdä vaihdon, jos osaa perinteiseen laatikkokoneeseenkin vaihtaa kovalevyn ja lisätä RAM:ia. Silti edelleen epäilen tämän olevan vain hyvin marginaalipuuhastelua kokonaiskuvassa, oli sitten yritysten vanhoja koneita tai ei. Tuskin Apple itseään jalkaan ampuu tämänkään suhteen.

Otin vaan kantaa tuohon, mikä tilanne on, jos vaihto tehty vaikeaksi ja vaatii kolvaamista. Rossman ja vastaavat ovat ammattilaisia, mutta monessa paikassa osien vaihto ei yksinkertaisesti onnistu, jos vaatii ruuvimeisseliä kummempaa työkalua. Jos siis halutaan tarjota takuu ja kustannustehokas jälkimarkkina, kuten noissa suomalaisissa firmoissa, jotka myyvät ihan ansiotarkoituksessa vanhoja koneita, ei harrastuksena. Samoin tuo mitä sanoin "halpojen" koneiden osista pätee. Esimerkiksi juuri nyt yhdenkin yleisesti käytetyn tilauskanavan kautta saa yhä max 256GB SSD ja 8GB RAM jos koneesta ei maksa lähemmäs 2000 eur ja erikseen perustele isompia osia. Pitäisin jo nyt ihan toimistotyössä peruskäyttöönkin miniminä 512 GB SSD ja 16 GB RAM, jos ostaa kahden tonnin koneen ja haluaa käyttöikää edes sen 3 vuotta. MacBook Pro with Touch Bar - 16" on saman tilauskanavan kautta noin kolmen tonnin paketti (hinnat alkaen) ja siinä on 512 GB SSD juotettu ja myös 16GB DDR4 2666. Riittää ehkä 3 vuotta, mutta aika nihkeä tilanne 5-10 vuoden päästä, jos joku taitonetti alkaa sitten myymään. Mieluummin jo harkitsee siinä jotain Huawei Matebookia kuin käytettyä omenakonetta, jos speksit merkkaa jotain.

 

[user9999]

Kyllä tuo ainakin minulla tapaa tarjota mahdollisuuden mennä tuonne System Preferences -> Security and Privacy. Kun yrittää käynnistää jotain random softaa jonka on ladannut netistä, se kertoo että ei onnistu kun tuntematon. Jos silloin menee tuonne Securityyn niin sinne on (yleensä) ilmestynyt valinta "XXXX is not trusted -> run anyway". Eihän sitä silleen pysyvästi saa pois päältä ettei tarvisi mennä tuonne aina erikseen joka kerta, mutta eipä tuota kovin usein tule uutta softaa latailtuakaan..

Noiden unidentified ohjelmien asentamiseen/avaamiseen riittää, että painaa control näppäimen pohjaa ja klikkaa ohjelmapakettia ja open valikosta.

Open a Mac app from an unidentified developer

If you try to open an app by an unidentified developer and you see a warning dialogue, you can override your security settings to open it.

support.apple.com

 

[zepi]

Otin vaan kantaa tuohon, mikä tilanne on, jos vaihto tehty vaikeaksi ja vaatii kolvaamista. Rossman ja vastaavat ovat ammattilaisia, mutta monessa paikassa osien vaihto ei yksinkertaisesti onnistu, jos vaatii ruuvimeisseliä kummempaa työkalua. Jos siis halutaan tarjota takuu ja kustannustehokas jälkimarkkina, kuten noissa suomalaisissa firmoissa, jotka myyvät ihan ansiotarkoituksessa vanhoja koneita, ei harrastuksena. Samoin tuo mitä sanoin "halpojen" koneiden osista pätee. Esimerkiksi juuri nyt yhdenkin yleisesti käytetyn tilauskanavan kautta saa yhä max 256GB SSD ja 8GB RAM jos koneesta ei maksa lähemmäs 2000 eur ja erikseen perustele isompia osia. Pitäisin jo nyt ihan toimistotyössä peruskäyttöönkin miniminä 512 GB SSD ja 16 GB RAM, jos ostaa kahden tonnin koneen ja haluaa käyttöikää edes sen 3 vuotta. MacBook Pro with Touch Bar - 16" on saman tilauskanavan kautta noin kolmen tonnin paketti (hinnat alkaen) ja siinä on 512 GB SSD juotettu ja myös 16GB DDR4 2666. Riittää ehkä 3 vuotta, mutta aika nihkeä tilanne 5-10 vuoden päästä, jos joku taitonetti alkaa sitten myymään. Mieluummin jo harkitsee siinä jotain Huawei Matebookia kuin käytettyä omenakonetta, jos speksit merkkaa jotain.

Applen tehtävä ei ole suojella ihmistä riittämättömän muistimäärän ostamiselta.

Itse tykkään, että tarjolla on myös vähän edullisempi perusmalli käyttäjille jotka eivät tarvitse 32 gigaa muistia tai teraa ssd:tä.

Osa ihmisistä haluaa vaan peruskoneen jossa on hyvä näyttö, akkukesto ja MacOS, eikä tarvitse terakaupalla levyä tai loputtomasti muistia.

 

[tle88]

Mielestäni noin muuten pitkäikäisen koneen teilaaminen liian pienellä muistilla tai levyllä on vähän ikävää voiton maksimointia. Applen muistimäärän lisäys tehtaan tekemänä on aivan kohtuuttoman hintainen. Firmoilla on myös maine, ja sitä mainetta ei kannattaisi ryvettää. En ole itse enää pitkiin aikoihin tykännyt Applen tavasta tehdä koneita. Vika on tietenkin minussa, mutta se myös estää sitten sen asiakkuuden.

T -.-

 

[antero]

Venturebeatin mukaan Apple oli sanonut, että emuloinnin pitäisi onnistua Rosetta 2:lla huomattavasti sulavammin kuin aikanaan PowerPC -> Intel siirtymässä.

• Apple confirms Mac transition to ARM CPUs, Rosetta 2 Intel emulation

Mielenkiintoista seurata, mitä kaikkea ARM-alustaan siirtyminen tuo tullessaan esimerkiksi puhelinpuolelle. Jatkossa sinulla on lähes yhtä tehokas laite taskussa kuin työpöydällä odottamassa? Tai ainakin työpöydältä tuttujen ohjelmistojen ajaminen onnistunee kivuitta myös puhelimella?

Ainakin näyttää tulevan ajureiden päivitys rumba.

ARM's next Mali GPUs will support updateable drivers via the Google Play Store

AMR Holding's upcoming Mali GPUs on MediaTek, Samsung Exynos, and Huawei HiSilicon chips will support GPU drivers updateable via Google Play Store.

www.xda-developers.com

 

[pomk]

Hitaampi, joo.

Onko jotain erityistä syytä sille miksi lopputulos olisi hitaampi? Applella on kuitenkin kaikki resurssit tehdä uudelleentulkkaus erittäin tehokkaasti ja lisäksi voivat samalla optimoida tarkasti omille suorittimilleen. Toki ohjelmakoodin takaisinmallintaminen x86 binäärin pohjalta ja sen uudelleenkääntäminen on aika hidasta tehdä hyvin ja jotain kompromisseja tehtäneen jotta softan asentamisessa ei kestä ikuisuuksia.

Miten muuten edes mittaisit hidastumista, ehkä vertaamalla ARM alustalle natiivikäännettyä softaa saman softan x86->ARM tulkattuun versioon? Jos kuitenkin molemmat näistä on energiatehokkaampia ja ehkä jopa nopeampia kuin natiivi x86 intelin prossulla niin eikö silloin voitaisi ajatella että lopputulos on tulkkauksesta riippumatta 'parempi'? Isot pitkälle optimoidut x86 softat tuskin kovin kivuttomasti tulkkaantuvat, mutta joku perussofta voi toimia melko ripeästikkin.

 

[hkultala]

Onko jotain erityistä syytä sille miksi lopputulos olisi hitaampi?

On

Fundamentaalisia juttuja on esim.

1) Kysymys, koska ylipäätään koodi käännetään, ja miten funktiopointterit hanskataan?

Ohjelmakoodia ei ole vain binääreissä vaan myös
* Dynaamisesti ladatuissa kirjastoissa
* Sitä generoidaan dynaamisesti ajonaikana. Erityisesti tämän tunnistaminen ja hanskaaminen oikein on vaikeaa.

Eli koska tahansa saatetaan kutsua funktiota jota ei ollut siinä binäärissä mikä ladattiin(ja käännettiin ohjelmaa ladatessa muistiin). Eli kaikista funktiopointereista pitää tarkastaa, onko sen kohde jo käännetty vai ei, ja mahdollisesti funktiokutsun tullen joko 1) triggeroida hyvin pitkään kestävä kääntöprosessi tai 2) suorittaa se funktio hitaalla tulkkausloopilla.

Ja kumpaan niiden funktiopointterien ylipäätään pitäisi osoittaa, alkuperäiseen x86-funktioon vai sen ARMille käännettyyn kopioon?

Ja pitää mm. tunnistaa, että jos ylikirjoitetaankin koodia, joka on jo käännetty, ja tässä tilanteessa invalidoida se käännetty koodi. Miten tämä tunnistetaan?

2) Vaikka asia, mitä x86-käsky korkealla tasolla tekee kääntyisi yhdeksi ARM-käskyksi, sen x86n-käskyn tarkka semantiikka ei usein käännykään yhdeksi ARM-käskyksi.

Tällainen juttu on esim. x86n flags-rekisteri. Melkein kaikki käskyt päivittävät sitä. Ja kun sen tilan pitää olla konsistentti myös esim. virtuaalimuistin läsnäolopoikkeuksien yms. yli, sitä ei usein voi vaan ignorata, vaan sen käytös pitää oikeasti emuloida kunnolla.

3) ARMilla on löysempi muistimalli kuin x86lla. Monisäikeistetty koodi voi luottaa x86n tiukempaan muistijärjestykseen, mutta jos se vaan binäärikäännetän suoraan käyttämän ARMin lataus- ja tallennuskäskyjä, se voi bugata. Jotta monisäikeistetty x86-koodi toimii ARMille binäärikännettynä kaikissa tilanteissa varmasti oikein, joudutaan siihen lisäämään ylimääräisiä synkronointikäskyjä, joita alkuperäisessä x86-koodissa ei ollenkaan tarvita.

4) Apple hallunnee käyttää 16 kiB virtuaalimuistisivua (mm. koska se mahdollistaa isomman L1D-kakun tekemisen nopeaksi, tehty jo Applen nykysissä ytimissä). x86-softat olettavat 4 kiB virtuaalimuistisivun. Jos softa kikkailee jotain jollain mmap()llä, erikokoinen virtuaalimuistisivu saattaa rikkoa ne.

Voi olla että Apple joutuu tarjoamaan x86-softille 4 kiB virtuaalimuistisivut ja laittamaan L1D-kakun toimimaan eri moodissa (joka on joko hitaampi tai disabloi 75% sen kapasiteetista) kun käytetään 4 kiB virtuaalimuistisivuja. Tosin en ole aivan varma, voiko ARMv8lla kerralla edes olla yhtä aikaa käytössä sekä 4 kiB että 16 kiB sivukokoja, jos ei, sitten tämä on vielä yhteensopivuusongelma eikä vain nopeusongelma x86-emulaatiolle.


80% ohjelmista saadaan toimimaan 99% tilanteista melko nopeasti binäärikääntäjällä, joka bugaa lopuilla 20% ohjelmilla todella pahasti ja näillä 80%llakin 1% tapauksista.

Ongelma vaan on se, että tällainen toimivuus ei ole hyväksyttävää. Ne harvinaisten erikoistapausten hitaat tunnistukset on pakko olla siellä että saadaan ne harvinaiset erikoistapaukset toimimaan oikein, ja niiden tunnistusten olemassaolo hidastaa kaikkia ohjelmia merkittävästi.



Tästä on aika paljon juttua realworldtechin forumilla, kannattaa lukea Linusin kommentteja sieltä:

RWT Forums - Real World Tech

content overridden

www.realworldtech.com

 

[Kaotik]

Ainakin näyttää tulevan ajureiden päivitys rumba.

ARM's next Mali GPUs will support updateable drivers via the Google Play Store

AMR Holding's upcoming Mali GPUs on MediaTek, Samsung Exynos, and Huawei HiSilicon chips will support GPU drivers updateable via Google Play Store.

www.xda-developers.com

Apple ei käytä Armin Maleja vaan imaginationin PowerVR:ää. Toki ajuripäivityksiä niillekin varmasti tulee mutta eiköhän ne toimiteta Applen toimesta suoraan

 

[jive]

Isoin etu x86 legacyssa on että voit ottaa sen Windows asennusmedian ja lykätä kenen tahansa valmistamaan PC koneeseen ja olettaa että homma toimii. ARM laitteiden kanssa oletus on että homma ei toimi. Applen kohdalla tämä on varmaan vain toivottu ominaisuus jolla voidaan sementoida valmistajariippuvuus.

 

[Lämpöpumppu]

Mielestäni noin muuten pitkäikäisen koneen teilaaminen liian pienellä muistilla tai levyllä on vähän ikävää voiton maksimointia. Applen muistimäärän lisäys tehtaan tekemänä on aivan kohtuuttoman hintainen. Firmoilla on myös maine, ja sitä mainetta ei kannattaisi ryvettää. En ole itse enää pitkiin aikoihin tykännyt Applen tavasta tehdä koneita. Vika on tietenkin minussa, mutta se myös estää sitten sen asiakkuuden.

T -.-

Ainahan Apple on muistien ja tallenustilojen määrässä osannut hinnoitella "hyvin". Mutta en silti koe tätä ongelmana, itsellä oli vajaa 8 vuotta kakkoskoneena Macbook Air parin gigan rammilla ja hyvin pärjäsin. Se kone toimi juurikin siinä peruskäytössä niin nopeasti ja sulavasti kuin vain pystyi toivoa; kannen avaamisesta parissa sekunnissa näpyttelin salasanaa ja siitä pari sekuntia eteenpäin niin olin internetissä ja musiikki soi taustalla, myös kevyt kuvankäsittely onnistui tarvittaessa. Juuri muuhun sitä en käyttänyt. iPad alkoi hoitaa kuitenkin kakkoskoneen virkaa ja yhdellä tori-ilmoituksella pääsin parissa päivässä tuosta Macbookista eroon ja sain vielä pari sataa euroa taskurahaakin. Kyllä noille entryhintaisillekin käytettyjen koneiden ostajille vielä löytyy kysyntää ja miksi ei löytyisi, se toimi loppuun asti nopeasti ja sulavasti tuollaisessa peruskäytössä. Ei kukaan tuollaista 8 vuotta vanhaa käytettyä konetta mopomuistilla osta mihinkään raskaaseen käyttöön. Nuo uusimmatkin entryhinnoitellut mäkit ovat varmasti kolmen vuoden päästä ihan validia käyttökamaa ja tämän jälkeen sillä ei ole enää väliäkään, kun uusien käyttöjärjestelmien tuki alkaa olla ainoastaan siellä ARM:n puolella.

 

[Bladekill]

Gatekeeper pitää disabloita komentoriviltä spctrl-komennolla.

How To Disable Gatekeeper on macOS Mojave and Catalina (video) — cronotek.net - Gaming, Technology, and Enterprise IT

Having difficulty installing apps remotely due to macOS Catalina security features? Sick of having to go into Security & Privacy to click "Allow" anytime you download an app?! Watch this video to see how to disable Gatekeeper (the program that blocks these settings by default) so y

cronotek.net

Kyllä tuo ainakin minulla tapaa tarjota mahdollisuuden mennä tuonne System Preferences -> Security and Privacy. Kun yrittää käynnistää jotain random softaa jonka on ladannut netistä, se kertoo että ei onnistu kun tuntematon. Jos silloin menee tuonne Securityyn niin sinne on (yleensä) ilmestynyt valinta "XXXX is not trusted -> run anyway". Eihän sitä silleen pysyvästi saa pois päältä ettei tarvisi mennä tuonne aina erikseen joka kerta, mutta eipä tuota kovin usein tule uutta softaa latailtuakaan..

Näiden lisäksi gatekeeperiä ei edes tarvitse disabloida vaan macOS:ssä voi itse codesignata minkä tahansa sovelluksen codesign -työkalulla. Voit vaikka ladata app storesta virallisen sovelluksen, modifoida binääriä disassemblerilla + codesign ja ajaa sen.

 

[escalibur]

Yksi lisäys siihen miksi Apple hylkäsi Intelin:

"The quality assurance of Skylake was more than a problem," says Piednoël during a casual Xplane chat and stream session. "It was abnormally bad. We were getting way too much citing for little things inside Skylake. Basically our buddies at Apple became the number one filer of problems in the architecture. And that went really, really bad.

"When your customer starts finding almost as much bugs as you found yourself, you're not leading into the right place."

"For me this is the inflection point," says Piednoël. "This is where the Apple guys who were always contemplating to switch, they went and looked at it and said: 'Well, we've probably got to do it.' Basically the bad quality assurance of Skylake is responsible for them to actually go away from the platform."

Intel insider claims it finally lost Apple because Skylake QA 'was abnormally bad'

Ex-Intel principal engineer, François Piednoël, believes he witnessed the inflection point three years ago with Skylake.

www.pcgamer.com

 

[vemkki]

Mietin tässä, että mitähän Macceja mahtaa tulla ensimmäisenä ARM-pohjaisina. Luulisi, että suurimmat hyödyt tulisivat nimenomaan kevyimmissä kannettavissa. Samoin voisin kuvitella, että esim. Macbook Pro 16":n ostajat ovat keskimäärin sen sortin tehokäyttäjiä, että he halunnevat ensin nähdä, että miten luotettavasti uusi prosessorityyppi pelittää ennen kuin itse lähtevät päivittämään. Täten ennustan, että ensin tulee ARM-pohjainen Macbook Air.

 

[Tup3x]

Apple ei käytä Armin Maleja vaan imaginationin PowerVR:ää. Toki ajuripäivityksiä niillekin varmasti tulee mutta eiköhän ne toimiteta Applen toimesta suoraan

Siis käytti PowerVRää. Ei enää A11 jälkeen. Koneissa pyörisi Applen oma tai sitten jonkun ison valmistajan erillinen.

 

[user9999]

Mietin tässä, että mitähän Macceja mahtaa tulla ensimmäisenä ARM-pohjaisina. Luulisi, että suurimmat hyödyt tulisivat nimenomaan kevyimmissä kannettavissa. Samoin voisin kuvitella, että esim. Macbook Pro 16":n ostajat ovat keskimäärin sen sortin tehokäyttäjiä, että he halunnevat ensin nähdä, että miten luotettavasti uusi prosessorityyppi pelittää ennen kuin itse lähtevät päivittämään. Täten ennustan, että ensin tulee ARM-pohjainen Macbook Air.

Jotain huhua tuohon

First Arm-Based Macs to Be 13-Inch MacBook Pro and Redesigned iMac, Launches Coming in Late 2020 or Early 2021

Apple plans to introduce its Arm-based custom designed chips for Macs at WWDC, Apple analyst Ming-Chi Kuo said in a note to investors today, agreeing with an earlier report from Bloomberg. Kuo says that the first Mac models to adopt Arm-based chips will be the 13.3-inch MacBook Pro and an iMac...

www.macrumors.com

 

[Kaotik]

Siis käytti PowerVRää. Ei enää A11 jälkeen. Koneissa pyörisi Applen oma tai sitten jonkun ison valmistajan erillinen.

On ne edelleen PowerVR:ää vaikka nimellisesti "erosivat", Applella tuli vissiin hiki kun tajusivat ettei lisenssit ole ikuisia ja alkuvuodesta sopivat uuden lisensointisopimuksen.

London, UK; 2nd January 2020 – Imagination Technologies (“Imagination”) announces that it has replaced the multi-year, multi-use license agreement with Apple, first announced on February 6, 2014, with a new multi-year license agreement under which Apple has access to a wider range of Imagination’s intellectual property in exchange for license fees.

 

[hkultala]

On ne edelleen PowerVR:ää vaikka nimellisesti "erosivat", Applella tuli vissiin hiki kun tajusivat ettei lisenssit ole ikuisia ja alkuvuodesta sopivat uuden lisensointisopimuksen.

Nyt menee minulla mutuilun puolelle, mutta luulisin että menee jotenkin siihen tyyliin, että:

1) Apple käytti PowerVRn näyttiksiä
2) Apple alkoi muokata/jatkokehittää käyttämiään PowerVRn näyttiksiä
3) Jossain vaiheessa suurin osa alkuperäisestä PowerVR:n IPstä oli jo korvattu Applen omalla, ja Apple ajatteli, että parin vuoden päästä lopustakin PowerVRn IPstä päästään eroon, ja sitten ei tarvi maksella enää lisenssimaksuja PowerVRlle. Apple alkoi kutsua näitä näyttiksiään "omiksi näyttiksikseen" eikä enää PowerVR-näyttiksiksi.

Sitten tapahtui jompi kumpi seuraavista:

A) Joko Apple tajusi, että jäljellä on sellaista PoweVRn IPtä, josta ei parissa vuodessa päästäkään eroon, ja meni nöyränä takaisin PowerVRn puheille, että "tarvittaisiin sittenkin lisenssi näihin"
B) PowerVRn lakimiehet lähettivät Applelle listan patenteista, joita heidän näyttiksensä hyvin todennäköisesti rikkovat, ja ehdottivat, että jos nyt vaan maksatte sen normaalin PowerVR-lisenssin niin ei tarvi lähteä riitelemään näistä, ja Apple suostui.

 

[pomk]

On

Fundamentaalisia juttuja on esim.

1) Kysymys, koska ylipäätään koodi käännetään, ja miten funktiopointterit hanskataan?

Ohjelmakoodia ei ole vain binääreissä vaan myös
* Dynaamisesti ladatuissa kirjastoissa
* Sitä generoidaan dynaamisesti ajonaikana. Erityisesti tämän tunnistaminen ja hanskaaminen oikein on vaikeaa.

Eli koska tahansa saatetaan kutsua funktiota jota ei ollut siinä binäärissä mikä ladattiin(ja käännettiin ohjelmaa ladatessa muistiin). Eli kaikista funktiopointereista pitää tarkastaa, onko sen kohde jo käännetty vai ei, ja mahdollisesti funktiokutsun tullen joko 1) triggeroida hyvin pitkään kestävä kääntöprosessi tai 2) suorittaa se funktio hitaalla tulkkausloopilla.

Ja kumpaan niiden funktiopointterien ylipäätään pitäisi osoittaa, alkuperäiseen x86-funktioon vai sen ARMille käännettyyn kopioon?

Ja pitää mm. tunnistaa, että jos ylikirjoitetaankin koodia, joka on jo käännetty, ja tässä tilanteessa invalidoida se käännetty koodi. Miten tämä tunnistetaan?

2) Vaikka asia, mitä x86-käsky korkealla tasolla tekee kääntyisi yhdeksi ARM-käskyksi, sen x86n-käskyn tarkka semantiikka ei usein käännykään yhdeksi ARM-käskyksi.

Tällainen juttu on esim. x86n flags-rekisteri. Melkein kaikki käskyt päivittävät sitä. Ja kun sen tilan pitää olla konsistentti myös esim. virtuaalimuistin läsnäolopoikkeuksien yms. yli, sitä ei usein voi vaan ignorata, vaan sen käytös pitää oikeasti emuloida kunnolla.

3) ARMilla on löysempi muistimalli kuin x86lla. Monisäikeistetty koodi voi luottaa x86n tiukempaan muistijärjestykseen, mutta jos se vaan binäärikäännetän suoraan käyttämän ARMin lataus- ja tallennuskäskyjä, se voi bugata. Jotta monisäikeistetty x86-koodi toimii ARMille binäärikännettynä kaikissa tilanteissa varmasti oikein, joudutaan siihen lisäämään ylimääräisiä synkronointikäskyjä, joita alkuperäisessä x86-koodissa ei ollenkaan tarvita.

4) Apple hallunnee käyttää 16 kiB virtuaalimuistisivua (mm. koska se mahdollistaa isomman L1D-kakun tekemisen nopeaksi, tehty jo Applen nykysissä ytimissä). x86-softat olettavat 4 kiB virtuaalimuistisivun. Jos softa kikkailee jotain jollain mmap()llä, erikokoinen virtuaalimuistisivu saattaa rikkoa ne.

Voi olla että Apple joutuu tarjoamaan x86-softille 4 kiB virtuaalimuistisivut ja laittamaan L1D-kakun toimimaan eri moodissa (joka on joko hitaampi tai disabloi 75% sen kapasiteetista) kun käytetään 4 kiB virtuaalimuistisivuja. Tosin en ole aivan varma, voiko ARMv8lla kerralla edes olla yhtä aikaa käytössä sekä 4 kiB että 16 kiB sivukokoja, jos ei, sitten tämä on vielä yhteensopivuusongelma eikä vain nopeusongelma x86-emulaatiolle.


80% ohjelmista saadaan toimimaan 99% tilanteista melko nopeasti binäärikääntäjällä, joka bugaa lopuilla 20% ohjelmilla todella pahasti ja näillä 80%llakin 1% tapauksista.

Ongelma vaan on se, että tällainen toimivuus ei ole hyväksyttävää. Ne harvinaisten erikoistapausten hitaat tunnistukset on pakko olla siellä että saadaan ne harvinaiset erikoistapaukset toimimaan oikein, ja niiden tunnistusten olemassaolo hidastaa kaikkia ohjelmia merkittävästi.



Tästä on aika paljon juttua realworldtechin forumilla, kannattaa lukea Linusin kommentteja sieltä:

RWT Forums - Real World Tech

content overridden

www.realworldtech.com

Ajon aikana tulkattavien ja generoitavien ohjelmien ajonopeus laskee merkittävästi, siitä olen täysin samaa mieltä ja niiden emuloiminen voi olla verrattaen haastavaa. Tulkit kuitenkin varmaan melko nopeasti saavat natiiviversiot ja jäljelle jää vain tuo erikoistapaus jossa x86 softa generoi itsenäisesti lisää x86 softaa, joka lienee (en oikeasti tiedä, ei vaan ole tullut vastaan) harvinainen poikkeustapaus.

Dynaamisesti ladattavat kirjastot voidaan myös uudelleentulkata ARM koodiksi siinä missä muutkin binäärit. Ehkä alkuvaiheessa näitä joudutaan ajonaikaisesti tulkkaamaan, mutta näin tehtäessä kyseinen kirjasto voidaan merkitä myöhemmin uudelleentulkattavaksi ja seuraavalla ajokerralla se voisi olla jo prosessoitu valmiiksi. Ohjelmien asentamisen yhteydessä voidaan myös analysoida että mitä kaikkia kirjastoja kyseinen softa voi ladata ja pitää huoli jo siinä vaiheessa että niistä on olemassa tulkattu versio.

Loput pointtisi liittyvät jotenkin x86 ja ARM arkkitehtuurien käytännön eroihin ja miten emuloinnissa kyseiset erot pitää ottaa huomioon. Arvioisin että usein hyviä tuloksia voitaisiin saada takaisinmallintamalla (osittain x86 kääntäjän valitettavasti jo optimoima) ohjelmakoodi ja sitten kääntämällä se ARM alustalle. Modernit takaisinmallintamistyökalut on jo aika tehokkaita. Tällöin noita x86 spesifejä detaljeja ei tarvitse (juurikaan) huomioida. Luonnollisesti tämä ei voi tapahtua ajonaikaisesti sillä se on liian hidasta moiseen, Apple on kuitenkin maininnut että ohjelmat ensisijaisesti muunnetaan yhteensopiviksi jo ohjelman asentamisen yhteydessä.

Jos oletetaan että uudet Applen prossut on merkittävästi energiatehokkaampia kuin nykyiset intelit, niin ei sen tulkatun softan tarvitse olla kuin lähes yhtä optimoitu jotta lopputulos on energiatehokkuudeltaan yli 100% alkuperäisestä x86+intel kokonaisuudesta.

 

[zepi]

Macbook Pro:n julkaisu yhtenä ensimmäisenä laitteena on melkein pakollista, jos Apple haluaa että devaajat saavat devattua uudelle platalle.

Yksi iso harmi tästä tulee ainakin minulle olemaan: on paljon vaikeampi ennustaa, että millaisia upgradeja missäkin MBP-sukupolvessa tulee tarjolle.

Aikaisemmin oli helppo katsoa intelin roadmapista, että millaisia CPU:ita on tulossa. Nyt julkista tietoa Applen SOC:eista ei tule tarjolle samalla tavalla ja on vaikeampi ennustaa, että miten eri sukupolvien mäkit tulevat kestämään aikaa.

 

[SheikYerbouti]

Jotain huhua tuohon

First Arm-Based Macs to Be 13-Inch MacBook Pro and Redesigned iMac, Launches Coming in Late 2020 or Early 2021

Apple plans to introduce its Arm-based custom designed chips for Macs at WWDC, Apple analyst Ming-Chi Kuo said in a note to investors today, agreeing with an earlier report from Bloomberg. Kuo says that the first Mac models to adopt Arm-based chips will be the 13.3-inch MacBook Pro and an iMac...

www.macrumors.com

Varmasti suurelti riippuvaista siitä, millaista jäähdytystehoa ensimmäisenä tietokoneisiin laitettava prosessori vaatii. Airissa ei tunnetusti ole tuuletin edes yhteydessä prossujäähdyttimeen, joten siihen ei ilman laajempaa uudelleensuunnittelua voi onnistuneesti laittaa kuin vähätehoisia prosessoreja. Eikä Apple varmastikkaan halua ensimmäisenä laittaa prossua koneeseen, jossa siitä ei voi ottaa kaikkea irti jäädytyksen vuoksi. Joten kannettavista Pro ja pöytäkoneista erityisesti iMac on silloin tosiaan ne loogisimmat vaihtoehdot.

 

[zepi]

Varmasti suurelti riippuvaista siitä, millaista jäähdytystehoa ensimmäisenä tietokoneisiin laitettava prosessori vaatii. Airissa ei tunnetusti ole tuuletin edes yhteydessä prossujäähdyttimeen, joten siihen ei ilman laajempaa uudelleensuunnittelua voi onnistuneesti laittaa kuin vähätehoisia prosessoreja. Eikä Apple varmastikkaan halua ensimmäisenä laittaa prossua koneeseen, jossa siitä ei voi ottaa kaikkea irti jäädytyksen vuoksi. Joten kannettavista Pro ja pöytäkoneista erityisesti iMac on silloin tosiaan ne loogisimmat vaihtoehdot.

Uusi soc tarkoittaa anyway kokonaan uuden piirilevyn suunnittelua ja käytännössä johtaa myös jäähdytyksen uudelleensuunnitteluun, joten nykyisestä airista on ainakin minusta aika turha vetää päätelmiä arm-airin suunnittelusta.

Jos itse pitäisi veikata, niin Apple siirtyy arm-airissa täyspassiiviin rakenteeseen ja korkeintaan levittää lämpöä pohjalevyyn/saranaosaan lämpöputkilla.

Air on vain huono ensimmäinen julkaistava kone, koska devaajat eivät anyway halua airia vaan tehokkaamman ja isommalla muistilla varustetun koneen.

-
Omakohtaisesti mietittäväksi jää se, että pitäisikö päivittää paremman puoliskon 2014 MBP x86-malliin vai odotella Arm-vehkeitä. Vanhan akku alkaa olla vähän kehno ja vanhan Intelin integroidun 4K-outputin ja USB-C:n puute estää fiksun ulkoisen näytön käytön. 13” näytön sijaan 14” olisi paljon kivempi...

 

[hsalonen]

Jotain huhua tuohon

First Arm-Based Macs to Be 13-Inch MacBook Pro and Redesigned iMac, Launches Coming in Late 2020 or Early 2021

Apple plans to introduce its Arm-based custom designed chips for Macs at WWDC, Apple analyst Ming-Chi Kuo said in a note to investors today, agreeing with an earlier report from Bloomberg. Kuo says that the first Mac models to adopt Arm-based chips will be the 13.3-inch MacBook Pro and an iMac...

www.macrumors.com

Miksiköhän olisivat lähtemässä Macbook Prolla liikenteeseen? Eikö tässä olisi ollut saumaa tehdä kaikista pienin Macbook Air?

Ihan itse spekuloiden noilla vielä oma design maksaa vähemmän kuin Inteliltä ostettu, niin ei olisi edes hinnasta kiinni.

 

[hkultala]

Ajon aikana tulkattavien ja generoitavien ohjelmien ajonopeus laskee merkittävästi, siitä olen täysin samaa mieltä ja niiden emuloiminen voi olla verrattaen haastavaa. Tulkit kuitenkin varmaan melko nopeasti saavat natiiviversiot ja jäljelle jää vain tuo erikoistapaus jossa x86 softa generoi itsenäisesti lisää x86 softaa, joka lienee (en oikeasti tiedä, ei vaan ole tullut vastaan) harvinainen poikkeustapaus.

Sitä tekee mm. kaikki yhtään kehittyneemmät scriptikielien tulkit, jotka kääntävät palasia suorittamastaan koodista natiivikoodiksi.

Eli esim. selain ajaessaan javascriptiä. Ja nykyään vaikka missä softassa on sisäänrakennettu selain, joka saattaa tukea javascriptiä ja sisältää tällaista tekevän tulkin.

Samoin esim. peleissä saattaa pelilogiikka olla koodattu jollain korkeamman tason scriptikielellä, joka saatetaan ajon aikana kääntää natiivikoodiksi.

Se on poikkeustapaus, mutta oikeasti paljon yleisempi poikkeustapaus kuin mitä ihmiset luulee.

Dynaamisesti ladattavat kirjastot voidaan myös uudelleentulkata ARM koodiksi siinä missä muutkin binäärit. Ehkä alkuvaiheessa näitä joudutaan ajonaikaisesti tulkkaamaan, mutta näin tehtäessä kyseinen kirjasto voidaan merkitä myöhemmin uudelleentulkattavaksi ja seuraavalla ajokerralla se voisi olla jo prosessoitu valmiiksi. Ohjelmien asentamisen yhteydessä voidaan myös analysoida että mitä kaikkia kirjastoja kyseinen softa voi ladata ja pitää huoli jo siinä vaiheessa että niistä on olemassa tulkattu versio.

Dynaamisia kirjastoja voi ladata mistä vaan, ja niitä mistä vaan ladattuja voi muokata kuka vaan. Tällöin aina kirjastoa ladatessa pitäisi ladata se alkup x86-kirjasto ja vähintään laskeskella hash siitä, ja verrata ARMiksi käännetyn versioon tallennetusta hashistä.

Loput pointtisi liittyvät jotenkin x86 ja ARM arkkitehtuurien käytännön eroihin ja miten emuloinnissa kyseiset erot pitää ottaa huomioon. Arvioisin että usein hyviä tuloksia voitaisiin saada takaisinmallintamalla (osittain x86 kääntäjän valitettavasti jo optimoima) ohjelmakoodi ja sitten kääntämällä se ARM alustalle.

Modernit takaisinmallintamistyökalut on jo aika tehokkaita. Tällöin noita x86 spesifejä detaljeja ei tarvitse (juurikaan) huomioida. Luonnollisesti tämä ei voi tapahtua ajonaikaisesti sillä se on liian hidasta moiseen, Apple on kuitenkin maininnut että ohjelmat ensisijaisesti muunnetaan yhteensopiviksi jo ohjelman asentamisen yhteydessä.

Optimoidun konekielikoodin takaisinkäännös on aivan eri asia kuin jonkun java- tai dalvik-bytekoodin takaisinkäännös.

Mikään "takaisinmallinnus" ei poista sitä tarvetta ottaa niitä yksityiskohtia huomioon, koska se, mitä ohjelma monen käskyn päästä tulevaisuudessa tekee voi aina riippua siitä jonkun käskyn hassusta sivuvaikutuksesta. Tai säikeen X tekemä toiminta voi ratkaisevasti riippua säikeen Y muistioperaatioiden järjestyksestä, joten takaisinmallinnuksen on pakko säilyttää nämä alkuperäisinä, koska siltä puuttuu paljon optimoinnin kannalta oleellista tietoa

Sen binäärikäännytyn softan mitään tehdä TISMALLEEN sama asia eikä "melkein sama asia".

ELi, jos meillä on "täydellinen takaisinkäännöstyökalu" niin sen "täydellisen takaisinkäänöstyökalun" tuottama koodi on rumaa ja sisältää paljon turhia hidastavia asioita (jotka on jouduttu generoimaan alkuperäisen konekielikoodin hassujen sivuvaikutusten takia)
Sen kääntäminen ARM-koodiksi tuottaa paljon hitaamman koodin kuin alkuperäisen lähdekoodin kääntö suoraan ARM-koodiksi.

Unohdin alkuperäiseltä listaltani muuten yhden asian:
x87-liukulukujen ylimääräiset bitit. x87 käsittelee lukuja sisäisestä 80-bittisinä. Modernimmat prosessorit tyypillisesti 64-bittisinä + pari ylimääräistä bittiä ennen pyöristystä.

Jotta saadaan tismalleen sama tulos kuin x87lla niin x87n emulointi on hyvin hidasta.

Onneksi toki hyvin harva softa enää käyttää x87aa vaan suurin osa laskee vähintään SSE2lla, jossa on laskentatarkkuus on maksimissaan 64 bittiä (+ ne pari pyöristysapubittiä)

 

[Juha Uotila]

Miksiköhän olisivat lähtemässä Macbook Prolla liikenteeseen? Eikö tässä olisi ollut saumaa tehdä kaikista pienin Macbook Air?

Kyllähän tuo Pro on olisi ihan järkeenkäytä vaihtoehto. Ei tuo Air taida kuitenkaan ihan niin myyvä vehje olla ja Pro:ssa on sitten jo muskelia nykyisellään sen verran että sillä moni hoitelee sitte ihan raskaampiakin duuneja.

Samalla voidaan näyttää mihin oikeasti uudella ensimmäisellä sirulla pystytään, kun varmasti sieltä tulee ulos jotain vähäh isompaa kuin nykyiset iPhonen ja iPadin piirit. Tilaa kun on kuitenkni lähtökohtaisesti enemmän, helpompi suunnitella jäähdytyskin. Ja onhan nuo Macbook Pro:t aika raskaita koneita siinä mielessä että varmasti saisivat näiden uusien piirien avulla painoa alas.

 

[pomk]

Sitä tekee mm. kaikki yhtään kehittyneemmät scriptikielien tulkit, jotka kääntävät palasia suorittamastaan koodista natiivikoodiksi.

Eli esim. selain ajaessaan javascriptiä. Ja nykyään vaikka missä softassa on sisäänrakennettu selain, joka saattaa tukea javascriptiä ja sisältää tällaista tekevän tulkin.

Samoin esim. peleissä saattaa pelilogiikka olla koodattu jollain korkeamman tason scriptikielellä, joka saatetaan ajon aikana kääntää natiivikoodiksi.

Se on poikkeustapaus, mutta oikeasti paljon yleisempi poikkeustapaus kuin mitä ihmiset luulee.



Dynaamisia kirjastoja voi ladata mistä vaan, ja niitä mistä vaan ladattuja voi muokata kuka vaan. Tällöin aina kirjastoa ladatessa pitäisi ladata se alkup x86-kirjasto ja vähintään laskeskella hash siitä, ja verrata ARMiksi käännetyn versioon tallennetusta hashistä.



Optimoidun konekielikoodin takaisinkäännös on aivan eri asia kuin jonkun java- tai dalvik-bytekoodin takaisinkäännös.

Mikään "takaisinmallinnus" ei poista sitä tarvetta ottaa niitä yksityiskohtia huomioon, koska se, mitä ohjelma monen käskyn päästä tulevaisuudessa tekee voi aina riippua siitä jonkun käskyn hassusta sivuvaikutuksesta. Tai säikeen X tekemä toiminta voi ratkaisevasti riippua säikeen Y muistioperaatioiden järjestyksestä, joten takaisinmallinnuksen on pakko säilyttää nämä alkuperäisinä, koska siltä puuttuu paljon optimoinnin kannalta oleellista tietoa

Sen binäärikäännytyn softan mitään tehdä TISMALLEEN sama asia eikä "melkein sama asia".

ELi, jos meillä on "täydellinen takaisinkäänstyökalu" niin sen "täydellisen takaisinkäänöstyökalun" tuottama ulosmeno on rumaa ja sisältää paljon turhia hidastavia asioita.
Sen kääntäminen ARM-koodiksi tuottaa paljon hitaamman koodin kuin alkuperäisen lähdekoodin kääntö suoraan ARM-koodiksi.

Unohdin alkuperäiseltä listaltani muuten yhden asian:
x87-liukulukujen ylimääräiset bitit. x87 käsittelee lukuja sisäisestä 80-bittisinä. Modernimmat prosessorit tyypillisesti 64-bittisinä + pari ylimääräistä bittiä ennen pyöristystä.

Jotta saadaan tismalleen sama tulos kuin x87lla niin x87n emulointi on hyvin hidasta.

Onneksi toki hyvin harva softa enää käyttää x87aa vaan suurin osa laskee vähintään SSE2lla, jossa on laskentatarkkuus on maksimissana 64 bittiä (+ ne pari pyöristysapubittiä)

Juu UE 4 ainakin tekee scriptikielestä x86 käännöksiä ajonaikaisestikkin joissain tilanteissa ja sen suorituskyky voi olla heikohko, mutta noista käytetyimmistä scriptikielitulkeista on jo ARM versiot olemassa (python, js, ruby, java etc.)

Dynaamisesti ladattavat kirjastot voi ajettavasta binääristä bongata etukäteen siinä asennuksen yhteydessä tehtävän tulkkauksen lomassa. Eli vaikka niitä voi ladata mistä vaan, niin ne voidaan tehokkaasti selvittää, ladata ja tulkata valmiiksi.

Korkealle optimoitu koodi on tosiaan vaikeampi takaisinkääntää kuin vähemmän optimoitu, mutta modernit työkalut hanskaa noi yllättävän hyvin. Osaavat jopa poistaa jotain optimointeja ja yksinkertaistaa sitä ohjelmakoodia enemmän siihen suuntaan mitä se on ehkä ollut kirjoitettaessa. Lisäksi vaikka uudelleenkäännetty softa olisi hitaampi kuin suoraan ohjelmakoodista ARM koodiksi käännetty softa, niin se voi siitä huolimatta olla tehokkaampaa kuin intel+alkup.x86 softa -kombinaatio. Toki poikkeuksia on olemassa, kuten olet jo sanonut. En usko että suorituskyky tai taaksepäinyhteensopivuus on isoja ongelmia kokonaisuuden kannalta, pl. pelit.

 

[demu]

Mitenkähän Intel suostuu tukemaan Applen ARM-koneissa Thundeboltia?
Todennäköisesti ei käy hankalaksi, mutta saataahan lisenssien hinta vähän nykyisestä nousta...

 

[user9999]

Mitenkähän Intel suostuu tukemaan Applen ARM-koneissa Thundeboltia?
Todennäköisesti ei käy hankalaksi, mutta saataahan lisenssien hinta vähän nykyisestä nousta...

Ainakaan siinä Developer Program Mac Mini koneessa ei ole ollenkaan Thunderbolt 3 tukea.

Apple's $500 Developer Program Includes Tools and Resources for Transitioning to Apple Silicon, Plus a Loaner A12Z-Based Mac Mini

To help developers prepare for the Mac transition from Intel processors to Apple Silicon, Apple has launched a Universal App Quick Start Program,...

www.macrumors.com

 

[pomk]

Mitenkähän Intel suostuu tukemaan Applen ARM-koneissa Thundeboltia?
Todennäköisesti ei käy hankalaksi, mutta saataahan lisenssien hinta vähän nykyisestä nousta...

Ei tarvitse. USB4 lisenssin saa kuka vaan ja se on yhteensopiva olemassaolevien TB laitteiden kanssa.

 

[demu]

Ei tarvitse. USB4 lisenssin saa kuka vaan ja se on yhteensopiva olemassaolevien TB laitteiden kanssa.

Applen tuntien sen USB4-toteutukseen tulee liittimeksi joku Firewiren ja Lightningin kombinaatio nurinpäin käännettynä...

 

[zepi]

Miksiköhän olisivat lähtemässä Macbook Prolla liikenteeseen? Eikö tässä olisi ollut saumaa tehdä kaikista pienin Macbook Air?

Ihan itse spekuloiden noilla vielä oma design maksaa vähemmän kuin Inteliltä ostettu, niin ei olisi edes hinnasta kiinni.

Koska tärkeintä on julkaista työkalut devaajille softan kehitykseen. Peruskäyttäjien siirtäminen uudelle alustalle on fiksumpaa sitten kun on paremmin natiivisoftaa, jotta käyttökokemus ei ole aluksi liian paska.

Jos ainoa markkinoilla oleva arm-mac on air, niin millä koneella ne devaajat porttaavat arm-versionsa?

 

[Juha Uotila]

Applen tuntien sen USB4-toteutukseen tulee liittimeksi joku Firewiren ja Lightningin kombinaatio nurinpäin käännettynä...

Eipä taida standardi tuota sallia vaikka se joistain niin hauskaa olisikin.

 

[KVahlman]

Jos ainoa markkinoilla oleva arm-mac on air, niin millä koneella ne devaajat porttaavat arm-versionsa?

Varmaan sillä koneella millä devaavat muutenkin. Ei esim. puhelin-armeillekkaan softaa tunkata ja käännetä niillä puhelimilla (paitsi joskus vähän eksoottisimmissä virityksissä). Koodia on kyllä mahdollista ja usein jopa paljon kätevämpää käännellä muualla ja sitten deployata kohdelaitteelle eri steppinä. Siihen käyttöön airit kyllä kelpaa ihan hyvin.

 

[zepi]

Varmaan sillä koneella millä devaavat muutenkin. Ei esim. puhelin-armeillekkaan softaa tunkata ja käännetä niillä puhelimilla (paitsi joskus vähän eksoottisimmissä virityksissä). Koodia on kyllä mahdollista ja usein jopa paljon kätevämpää käännellä muualla ja sitten deployata kohdelaitteelle eri steppinä. Siihen käyttöön airit kyllä kelpaa ihan hyvin.

Puhelinsofta kuitenkin testataan puhelimella. Tai ainakin kaikki sellainen softa joka oikeasti käyttää puhelimen ominaisuuksia ja suorituskykyä kunnolla.

Jos Apple haluaa, että on pro-softaa tarjolla Arm-MacOS:lle, pitää olla olemassa pro-tason rautaa, jolla sitä voi testata.

Vaikea Adoben tai kenenkään muunkaan on pro-softansa algoritmejään kunnolla optimoida, jos tarjolla ei ole rautaa jolla niitä algoritmin rajoja voi testata.

 

[kurkimies]

Testejä odotellessa. Eikös iPad pro ole nopeampi raw->jpeg ja 4k->1080p kuin macbook pro?
Edit: hinnat-alkaen mbp

Odotellaan, kun ajetaan esim. Redin kameroilla tai Canon EOS 1D Mark III 4K:ta. Tai Canonin 5.5K pakkaamatonta videota. Voi tehdä aika "tiukkaa" tehokkaammallekin raudalle videonkäsittely.

 

[KVahlman]

Jos Apple haluaa, että on pro-softaa tarjolla Arm-MacOS:lle, pitää olla olemassa pro-tason rautaa, jolla sitä voi testata.

Vaikea Adoben tai kenenkään muunkaan on pro-softansa algoritmejään kunnolla optimoida, jos tarjolla ei ole rautaa jolla niitä algoritmin rajoja voi testata.

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ää.

 

[JuhaH]

Applen tuntien sen USB4-toteutukseen tulee liittimeksi joku Firewiren ja Lightningin kombinaatio nurinpäin käännettynä...

Ei Applen tarvitse kehittää enää omaa liitintä, kun USB:n kanssa insinöörit saivat 20-vuoden räveltämisen jälkeen vihdoin kehitettyä kunnollisen liittimen (USB-C). Lightninghän tuli korvaamaan kaikkien aikojen pa..kinta ikinä kehitettyä liitintyyppiä, eli micro-usb:tä, ja minusta tuo oli hyvinkin perusteltua.

 

[Kaotik]

Ei Applen tarvitse kehittää enää omaa liitintä, kun USB:n kanssa insinöörit saivat 20-vuoden räveltämisen jälkeen vihdoin kehitettyä kunnollisen liittimen (USB-C). Lightninghän tuli korvaamaan kaikkien aikojen pa..kinta ikinä kehitettyä liitintyyppiä, eli micro-usb:tä, ja minusta tuo oli hyvinkin perusteltua.

Lightning tuli korvaamaan Dock-liittimen mitä Apple käytti ennen sitä, ei microUSBia

 

[Ormu]

Ei Applen tarvitse kehittää enää omaa liitintä, kun USB:n kanssa insinöörit saivat 20-vuoden räveltämisen jälkeen vihdoin kehitettyä kunnollisen liittimen (USB-C). Lightninghän tuli korvaamaan kaikkien aikojen pa..kinta ikinä kehitettyä liitintyyppiä, eli micro-usb:tä, ja minusta tuo oli hyvinkin perusteltua.

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.

 

[Hessu]

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.