- Liittynyt
- 29.10.2016
- Viestejä
- 4 431
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.
Apple siirtyy Arm-arkkitehtuuriin Mac-tietokoneissa
- Liittynyt
- 17.10.2016
- Viestejä
- 12 609
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 669
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
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ä
- 22 791
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
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ä
- 22 791
Kyllä. Mutta Apple saa nopeasti softat käännettyä mille vaan arkkitehtuurille ja nyt onkin mielenkiintoista nähdä, onko siellä
- lisätty ydinmäärää , että saadaan raakaa general purpose laskentatehoa
- 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 669
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.
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.
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ä
- 12 609
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.
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.
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
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
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
- Liittynyt
- 14.10.2016
- Viestejä
- 22 630
Mikäs vika niiden eGPU-tuessa on?
Juha Uotila
Ylläpidon jäsen
- Liittynyt
- 18.10.2016
- Viestejä
- 4 935
Hämärä muistikuva että vain tietyt kortit toimii. Ainakin NVIDIAn korttien kanssa ollu ongelmia
- Liittynyt
- 14.10.2016
- Viestejä
- 22 630
Käsittääkseni kyse ei ole muusta kuin NVIDIAn ajurituesta, nopealla vilkaisulla viimeiset ajurit ovat High Sierralle ja niidenkin tuki aika rajallista:
Quadro & GeForce macOS Driver Release 387.10.10.10.40.132 | 387.10.10.10.40.132 | macOS High Sierra 10.13.6 | NVIDIA
Download the English (US) Quadro & GeForce macOS Driver Release 387.10.10.10.40.132 for macOS High Sierra 10.13.6 systems. Released 2019.10.30
www.nvidia.com
- Liittynyt
- 17.10.2016
- Viestejä
- 12 609
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.
user9999
Platinum-jäsen
- Liittynyt
- 17.10.2016
- Viestejä
- 3 174
AMD näytönohjaimia ne suosittelee eGPU käyttöön.
support.apple.com
Ulkoisen näytönohjaimen käyttäminen Macissa - Apple-tuki (FI)
Tässä artikkelissa kerrotaan, miten voit tehostaa näytönohjausta yhdistämällä tietokoneen ulkoiseen grafiikkasuorittimeen.
- Liittynyt
- 27.10.2016
- Viestejä
- 338
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
Juu suksethan siellä meni ristiin.
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
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ä
- Liittynyt
- 20.10.2016
- Viestejä
- 665
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.
- Liittynyt
- 14.10.2016
- Viestejä
- 22 630
Ei taida ainakaan tämän syksyn iMac olla Armilla vielä
Core i9-109100 (ts kelloiltaan perusmallista erottuva Apple-versio) + Radeon Pro 5300
AAPJ1851,1 - Geekbench
Benchmark results for an AAPJ1851,1 with an Intel Core i9-10910 processor.
browser.geekbench.com
user9999
Platinum-jäsen
- Liittynyt
- 17.10.2016
- Viestejä
- 3 174
Juu sieltä pitäis tulla vielä Intel iMacit.
iMac: Features, Price, and Buying Advice
Apple's iMac is an ultra-thin all-in-one desktop computer that was refreshed with the new M3 chip and other upgrades in October 2023.
www.macrumors.com
Edit:
Unannounced iMac appears in Geekbench results with 10-core Intel i9 CPU, Radeon Pro 5300 GPU - 9to5Mac
Various rumors have suggested that Apple has a new family of iMac models on the way sooner rather than later....
9to5mac.com
Unreleased iMac With 10-Core Comet Lake-S Chip and Radeon Pro 5300 GPU Shows Up in Geekbench
Benchmarks for an unreleased iMac equipped with a 10th-generation Core i9 Intel Comet Lake-S chip and an AMD Radeon Pro 5300 graphics card have...
www.macrumors.com
Viimeksi muokattu:
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.
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ä
- 12 609
On ihan mahdollista, että iso tai pieni iMac tulee ARM:lla ja toinen Intelillä.
Foxy
• Artisti •
- Liittynyt
- 11.01.2019
- Viestejä
- 328
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:
- 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.
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.
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ä.
Applen A12Z-kehitysalusta kepittää emuloimallakin (tosin niukasti) Ryzen 4500U:n ja i7-1065G7:n GPU:t OpenCL-testissä.
wccftech.com
Tämä nyt on enemmän GPU- kuin CPU-kamaa, mutta ihan lupaavaa silti.
Apple’s A12Z Bionic GPU Running macOS 11 Through Rosetta 2 Beats Both Ryzen 5 4500U, Core i7-1065G7 iGPUs in OpenCL Test
It’s very surprising to see that even with Apple’s translation layer Rosetta 2, the A12Z Bionic GPU can best both Ryzen 5 4500U and Core i7-1065G7’s iGPUs
wccftech.com
- Liittynyt
- 17.10.2016
- Viestejä
- 12 609
OpenCL testi ei ole kauhean järkevää ajettavaa, koska Apple on lopettanut OpenCL:n kehittämisen omalla alustallaan.
appleinsider.com
A12Z:ssa on myös merkittävästi nopeammat LPDDR4X muistit kuin vertailukohteissa.
OpenGL, OpenCL deprecated in favor of Metal 2 in macOS 10.14 Mojave | AppleInsider
Apple has taken the first steps toward completely killing OpenGL and OpenCL in Mojave in favor of its own Metal technology.
appleinsider.com
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 174
- Liittynyt
- 17.10.2016
- Viestejä
- 12 609
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.
Viimeksi muokattu:
user9999
Platinum-jäsen
- Liittynyt
- 17.10.2016
- Viestejä
- 3 174
Erinomainen näyttö. Onkohan 2019 iMacissä sama paneeli? Molemmissa esim. kirkkaus sama 500 nits.
- Liittynyt
- 17.10.2016
- Viestejä
- 2 306
OT: Mikä 5k:ssa niin hankalaa on muille kuin Maceille?
e: Vai onko se Thunderbolt 3 joka tuossa tulee ongelmaksi?
user9999
Platinum-jäsen
- Liittynyt
- 17.10.2016
- Viestejä
- 3 174
Thunderbolt tuki pitäisi löytyä myös ARM versioista.
www.macrumors.com
Apple's Arm-Based Macs With Apple Silicon Chips Will Support Thunderbolt
Apple is working on Macs that use its custom Apple-designed Apple Silicon chips instead of Intel chips, but Apple has committed to continuing to...
www.macrumors.com
- 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 809
Jotain lähdettä näille huhuille?
- Liittynyt
- 22.10.2016
- Viestejä
- 11 809
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
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.
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.
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.
- Liittynyt
- 20.10.2016
- Viestejä
- 665
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 809
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.
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.
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
"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.
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ä.
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ä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ä
- 22 791
Häh?
Näitä ARM-läppäreitä on ollut jo tovi:
Lenovo Yoga C630 13,3" 2-in-1 (harmaa) - Gigantti verkkokauppa
13,3-tuumainen Lenovo Yoga C630 2-in-1 on täysin omanlaisensa kannettava laite. Siinä on uskomaton 25 tunnin akunkesto ja 4G LTE -
Nyt on mennyt vaan Applen propaganda läpi ja "Apple on aina ekana" valheet on uponneet täysin.
- Liittynyt
- 17.10.2016
- Viestejä
- 2 649
"DisplayPort 1.4 with Display Stream Compression is ready to power extreme refresh rates, frame rates, resolution, and color depth for next-generation displays, supporting up to 8K resolution at 60 Hz or 5K at 120 Hz."
Ei pitäisi olla mitään ongelmaa käyttää 5k-resoluutiota.
Uutiset
-
Uusi artikkeli: Testissä Intel Arc B580 Limited Edition
13.12.2024 16:21
-
Google esitteli uutta Gemini 2.0 -tekoälyään
13.12.2024 15:56
-
AMD:n tulevat Krackan ja Strix Halo Geekbench-testivuodoissa
13.12.2024 14:43
-
Live: io-techin Tekniikkapodcast (50/2024)
13.12.2024 12:28
-
Sharkoon julkaisi AK5 RGB -sarjan kotelot ja SHARK Lights RGB -tuulettimet
13.12.2024 02:56
Uutisia lyhyesti
-
PowerColor laajentaa kuulokemarkkinoille Alphyn AH10 -headsetillä- Kaotik
- Vastauksia: 6
-
-
OnePlus Pad ja Pad 2 ovat ensimmäisiä Android 15 -päivityksen saavia taulutietokoneita- Juha Kokkonen
- Vastauksia: 2
