
Applen on jo vuosia huhuttu siirtyvän myös Mac-tietokoneissa Arm-prosessoreiden käyttöön. Nyt tuo hetki alkaa olemaan käsillä, sillä Apple ilmoitti virallisesti tuovansa itse kehittämänsä prosessorit Mac-tietokoneisiin.
Apple ei kertonut toistaiseksi vielä tarkempia yksityiskohtia tulevista Mac-siruistaan, mutta kertoi siirtymän tapahtuman vaiheittain. Ensimmäisen Arm-Macin toimitukset aiotaan aloittaa vielä tänä vuonna ja koko mallisto tulee siirtymään niiden pariin suurin piirtein kahdessa vuodessa. Yhtiö varmisti myös, että se tulee julkaisemaan ainakin toistaiseksi myös Intel-pohjaisia Mac-tietokoneita ja tulee luonnollisesti tukemaan macOS:n x86-versiota hamaan tulevaisuuteen.
Kehittäjät pääsevät työhön niin ikään tänään esitellyn macOS Big Surin kanssa, jonka pariksi on tarjolla A12Z Bionic -järjestelmäpiiriin perustuva Developer Transition Kit. Xcode 12 työkaluineen ja Universal 2 -binäärit mahdollistavat yhtiön mukaan helposti sen talon sisällä kehitettyjen prosessoreiden hyödyntämisen sovelluksissa menettämättä kuitenkaan samalla yhteensopivuutta Intel-Macien kanssa. Lisäksi tarjolla tulee olemaan Rosetta 2, mikä mahdollistaa Intelille suunniteltujen sovellusten ajamisen Arm-prosessorilla vaikkei kehittäjä olisikaan tehnyt siitä natiivia versiota uusille prosessoreille.
Lähde: Apple
Ei tuollaista enää ole olemassa vaan on vain macOS. OS X nimeämisestä luovuttiin jos muutama vuosi takaperin. Ja Big Sur on tosiaan macOS 11.
Tämäkin taitaa osoittaa, miten huono olen tottumaan asioihin. Kiitos korjauksesta.
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.
Uudet softat käännetään molemmille, fat binaries.
Ei varmasti tule mitään RM-emulaatiota x86lle.
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ä,
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.
(*) 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.
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.
Hitaampi, joo.
Yhteensopivuus saadaan kyllä kuntoon kun vaan korjataan emulaattorisoftasta/binäärikääntäjäsät 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 hyvini oleellinen vaikutus siihen, kuinka helppoa kaikki on saada toimimaan.
PPCssä taas data oli sijoitelut muistin aivan eri tavalla kuin x86ssa ja ARMissa.
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.
TÄLLÄ HETKELLÄ.
Ja ne pärjäävät jo IPCssä esim. skylakelle ja zen2lle, mutteivät 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
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
6) ARMissa ei ole mitään niitä idioottimaisuuksia mitä muissa RISCeissä on
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ää.
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, dataa yhä enemmän aivan turhaan siirrellään "pilveen".
Ja datansiirrossa on myös viiveet.
Eli kehitys menee nimenomaan aivan väärään suuntaan.
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.
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
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..
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.
Minulla tuo 32 bittisten esto pilasi suurimman osan peleistä, kun olen tällä vanhalla MBP:lla tykännyt tuollaisia kevyempiä pelejä pelata, joista monet vielä 32 bittisiä.
Kun tämä ARM homma sekoittaa lisää pakkaa, en itselle ostaisi uutta MBP:ta ennenkuin nuo ARMit kunnolla kehissä ettei ole Pekka kädessä muutaman vuoden päästä, ja sillä ARM:llakin taas sitten voisin nähdä lisää noita yhteensopivuusongelmia. Kun hinnatkin aika kovia niin alkaa pahasti seuraava taipua johonkin muuhun itsellä..
Työkäytössähän tuo ARM on varmaan ihan toimiva, Linuxikin pyörinee sillä hyvin ja sitä kautta lähes kaikki softankehityskikkareet. Mutta vaikka noilla tulee itsekin leikittyä niin olisi se "ihan kiva" että voi välillä pelatakin. Steamilla voisi ehkä streamata Windows desktopilta pelejä, mutta se ei taas esim. GOG:lla auta.
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 noin kolmen tonnin paketti 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.
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
support.apple.com
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ä.
T -.-
Ainakin näyttää tulevan ajureiden päivitys rumba.
ARM's next Mali GPU will support updateable drivers via Play Store
http://www.xda-developers.com
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.
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 kladatessa 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?
Pitää mm. tunnistaa, että jos ylikirjoitetaankin koodia, joka on jo käännetty, ja tässä tilanteessa invalidoida se käännetty koodi.
2) Vaikka asia, mitä x86-käsky korkealla tasolla tekee kääntyisi yhdeksi ARM-käskyksi, sen x86n-käskyn tarkka semantiikka ei 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 funktiokutsujen, järjestelmäkutsujen, virtuaalimuistin läsnäolopoikkeuksein yms. yli, sitä ei voi vaan ignorata, vaan sen käytös pitää oikeasti emuloida kunnolla.
3) ARMilla on löysempi muistimalli kuin x86lla. Monisäikeistety 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 kaikissa tilanteissa varmasti oikein, joudutaan siihen lisäämään ylimääräisiä synkronointikäskyjä, joita alkuperäisessä x86-koodissa ei ollenkaan tarvita.
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 erikositapaukset toimimaan oikein.
Apple ei käytä Armin Maleja vaan imaginationin PowerVR:ää. Toki ajuripäivityksiä niillekin varmasti tulee mutta eiköhän ne toimiteta Applen toimesta suoraan
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.
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.
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.
Intel insider claims it finally lost Apple because Skylake QA 'was abnormally bad'
http://www.pcgamer.com
Siis käytti PowerVRää. Ei enää A11 jälkeen.
Jotain huhua tuohon
First Arm-Based Macs to Be 13-Inch MacBook Pro and Redesigned iMac, Launches Coming in Late 2020 or Early 2021
http://www.macrumors.com
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.
Tulkattavien ja ajon aikana 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.
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.
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…
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.
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ä)
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.
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.
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
http://www.macrumors.com
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ä…

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?
Eipä taida standardi tuota sallia vaikka se joistain niin hauskaa olisikin.
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.
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.
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.
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ää.