
Apple laajensi tänään pitämässään Spring Loaded -tilaisuudessa M1-järjestelmäpiirin käyttöä Mac-tietokoneiden katalogissaan. Uusimpana tulokkaana ARM-pohjaisten Macien joukkoon toimii uusi 24-tuumainen iMac, joka sai uuden järjestelmäpiirin lisäksi myös uuden muotoilun ja näytön.
Uudet M1-iMacit käyttävät jo viime vuonna julkaistuista MacBook-kannettavista ja Mac Ministä tuttua M1-järjestelmäpiiriä, joka Applen mukaan tuo mukanaan vanhempiin 21-5-tuuman iMaceihin verrattuna 85-prosenttia nopeamman prosessorisuorituskyvyn ja kaksi kertaa nopeamman grafiikkasuorituskyvyn.
Järjestelmäpiiri ei kuitenkaan enää tässä vaiheessa ole mitään uutta, vaan kyseessä on sama tuttu viime vuonna esitelty M1. MacBook Pron ja Mac Minin tavoin myös iMacin järjestelmäpiiri on jäähdytetty tuulettimilla MacBook Airin passiivisen jäähdytyksen sijaan. Tuuletinten luvataan kuitenkin pysyvän alle 10 dBA:n äänenpaineessa.
Viime vuoden Arm-Maceista poiketen uudet iMacit saivat kuitenkin osakseen myös täysin uudistuneen muotoilun. Vanhoista pyöreistä linjoista on luovuttu uuden enemmän iPad Pro -malleja ja Pro Display XDR -näyttöä muistuttavan kulmikkaan muotoilun tieltä. Samalla myös näytön laitoja on kutistettu selvästi, joskaan mitenkään erityisen ohuista näytön reunuksista ei voi puhua vieläkään.
Uusi 24-tuumainen iMac on 11,5 mm paksu ja painoakin sillä on alle 5 kiloa. Värivaihtoehtojen määrää uusi iMac kasvattaa reilusti ja perinteisen hopeisen lisäksi tarjolla on jatkossa myös sininen, vihreä, pinkki, keltainen, oranssi ja violetti. Mielenkiintoisena lisänä myös virtajohto on uudistettu ja uuden iMacin virtajohto on magneettinen, minkä lisäksi sen punotun pinnan väri on vastaava itse iMacin värin kanssa.
Uuden iMacin 24-tuumainen näyttö on ensimmäinen luokassaan, joten se on myös ymmärrettävästi täysin uusi. Sen resoluutio on 4,5K, se tukee DCI-P3-väriavaruutta ja yltää 500 nitin kirkkauteen. Myös näytön yläpuolelta löytyvä kamera päivitetty. Uuden webkameran resoluutio on 1080p, minkä lisäksi sen kuvanlaatua parantamassa on M1-järjestelmäpiirin kuvaprosessori.
24 tuuman iMacin mikrofonin Apple lupaa joidenkin aiempien Mac-tietokoneidensa tapaan olevan studioluokkaa ja suuntaavina myös taustamelua vaimentava. Kaiutinjärjestelmä puolestaan muodostuu kuudesta kaiuttimesta. Uusien iMac-värien lisäksi Apple toi myös uudet sävy sävyyn sopivat näppäimistöt, hiiret ja kosketuslevyt. Uudet Applen Magic Keyboard -näppäimistöt tuovat myös mukanaan ensimmäistä kertaa MacBook-kannettavien ulkopuolella Touch ID -sormenjälkilukijan.
Applen 24-tuumaisten iMacien ennakkomyynti alkaa 30.4. ja toimitukset toukokuun puolen välin jälkeen. Pohjamallin hinnat ilman USB 3 -portteja ja Ethernet-liitäntää alkavat 256 gigatavun tallennustilalla ja 8 gigatavun RAM-muistilla 1499 eurosta. USB 3 -porttien ja Ethernet-liitännän kera hinnat alkavat 1719 eurosta.
Lähde: Apple
Kyllä kyllä, mutta kehitysohjeilla ja API määrityksillä pystytään ohjaamaan esim. valokuvakatalogin kaltaisten juttujen käyttö sellaiseksi, että niitä ei välttämättä ladata muistiin. Kukaan ei toki edelleenkään estä käyttämästä koneen resursseja väärin. MS ei taida pahemmin tarjota rajapintoja, joita käyttämällä järjestelmä joko lataa muistiin, tai sitten ei, riippuen laitteistosta, vaan ohjelmoija joutuu itse tekemään sekä toteutuksen, että arvioimaan tarkkaan että mitä missäkin kohtaa kannattaa tehdä.
Välimuistia ei mikään NAND flash tule ikinä korvaamaan, mutta on monia käyttökohteita joissa se on ns. riittävän nopea ja muistiin ladataan ihan turhaan jotain read only roskaa, jolla ei ole tiukkoja latenssivaatimuksia.
Höpöhöpö.
Windows on tukenut tiedostojen mäppäystä näkyviin virtuaalimuistiosoitteissa ikuisuuden.
File Mapping – Win32 apps
docs.microsoft.com
Ei todellakaan ole.
NAND flash ei ole tavuosoitettavaa. NAND Flashin sisältö ei näy prosessorille fyysisinä muistiosoitteina.
Että sitä NAND-flashillä olevaa dataa voi lukea, se pitää lukea sieltä softalla käyttöjärjestelmän toimesta, eli jos se on siellä joko memory mapattynä fielenä tai "muistina" joka on swapattu ulos, se ladataan siten, että yritetää käyttää virtualiosoitetta, joka on sinne mapatty, tästä ensin tulee virtaalimusitin läsnäolopoikkeus, jonka käsittelijässä käyttöjärjestelmä käy lukemassa koko virtuaalimuistisivun levyltä.
ELi tässä tulee vaikka kuinka paljon softa-overheadia kun rauta ei sitä pysty lukemaan ilman softan(käyttiksen) apua.
xPoint/Optane on tavuosoitettavaa. Se voidaan laittaa näkymään normaalina fyysisenä muistina. Sieltä pystytään tällöin suoraan latamaan puhtaasti raudan toimesta, ilman mitään käyttis-overheadia. Käytännössä rauta sieltä Optanelta/xPointilta lukea yksittäisiä välimuistilinjoja (64 tavua) hyvin nopeasti, aivan kuten DRAMista.
Tässä puhutaan suuruusluokkaerosta satoja kellojaksoja vs vähintään kymmeniä tuhansia, ehkä jopa yli sata tuhatta kellojaksoa.
Lightroomin ja C1 kuvakirjasto ei myöskään ole valokuvakatalogi, vaan ohjeet miten mikäkin kuva käsitellään softan toimesta sitä näytettäessä, eli mitä muokkauksia kuvaan on tehty käyttäjän toimesta, alkuperäisen kuvan pysyessä koskemattomana. En tiedä kuinka oikein tai väärin softan tekijät on tuon tehnyt, mutta aika samalla tavalla muistia vie myös Lightroom classic.
Youtubesta löytyy kyllä videoita missä ainakin Photoshopilla on hyötyä isommasta muistista M1 Maceillä, kuten panoraamojen muodostus (~30% nopeusero). Ja ennenkuin siitä on tuntuvasti haittaa, alkaa swap käyttö kasvamaan reilusti, mikä lyhentää SSD:n elinikää.
Noitakaan tietoja tuskin tarvitaan koko katalogista kerralla muistiin, vaan niitä voidaan nopean kovalevyn mahdollistamana ladata esim. kansio tai näkymä kerrallaan. Hakua varten taas voidaan kaikki metadatatagit kerätä muistiin, ja ne eivät pahemmin muistia syö. PC versio varmaan lataa varmuuden vuoksi ties mitä roskaa muistiin, koska se olettaa käyttäjällä olevan verrattaen hidas kovalevy jolla kansioiden availusta syntyvät viiveet loisivat huonon käyttökokemuksen.
Isoissa satojen tai tuhansien megapikselien panoraamoissa toi kahdeksan gigaa jää pieneksi, kuten mainitsit. SSD:n elinikää en pitäisi kovin isona ongelmana, ellet sitten jatkuvasti työstä kotikoneellasi noita gigatavuluokan isoja panoraamojasi, sen sijaan että ostaisit ammattikäyttöön soveltuvamman laitteen. Panoraamahommissa tulee muisti lopulta vastaan melkein järjestelmässä kuin järjestelmässä, ja harvalla on oikeasti käyttöä noille gigatavujen kokoisille kuvatiedostoille, vaikka niiden työstäminen voi välillä ollakkin hauskaa.
Missään en maininnut tarkoittavani että sitä NAND muistia käytettäisiin tavuosoitettuna välimuistina. Kyse oli siitä, että kun 100% userbasesta omaa nopean nvme levyn, niin esim. noita kuvakatalogeja ei tarvitse enää latailla muistiin kokonaisuudessaan sulavan käyttökokemuksen takaamiseksi.
Oletko katsonut TBW lukemia joita 8GB M1 Macbookin omistajat raportoivat verkkokeskusteluissa? Siellä on ihan oikeasti ihmisillä aivan valtaisat määrät kirjoitusta kun swappi käy jatkuvasti "peruskäytössä".
Tuosta oli vasta puhetta laajasti; osa ei pidä minkäänlaisena ongelmana, osa näkee sen hyvin merkittävänä. Mutta onhan se merkittävä tekijä jos peruskäytössä tulee yli 50TBW vuodessa, siihen vielä "vähän harrastelee" ja ssd huutaa hoosiannaa swappauksessa kun RAMia on se massiivinen 8Gt.
Ehkä tämä onkin Applen tarkoitus. Ihmiset tuo koneen parissa vuodessa Genius Bariin kalliiseen "huoltoon" tai ostavat uuden.
Kuinka paljon ne sit kestää kulutusta applen käyttämillä over provisioning asetuksilla? Pelkkä TBW ei tyhjiössä ole kovin merkityksellinen tieto.
Itselläni ei ole viruaalimuisti käytössä.
katso liitettä 592761
Esimerkiksi täällä on monta hyvää syytä miksi väittämäsi on väärä (eikä tuossa ole kyse virtuaalimuistin disabloinnista vaan page filen):
Why turning off Virtual Memory doesn't improve my computer's performance?
superuser.com
Miksi? Mitä haittaa on pitää swappia käytössä niitä tilanteita varten kun muisti loppuu kesken? Järkevämmäksi se tulee IMO kuin uuden koneen ostaminen sen kerran kun eksyy jotain HDR panoraamaa rakentelemaan.
Totta, virtuaalimuistin sijaan piti puhua page filestä.
Mutta tässä keskustelussa olikin kyse siitä, että muistin loppumisen vuoksi käytetään SSD-levyä virtuaalimuistina/pagefilenä. Ja käyttäjät pelkäsivät, että SSD kärsii, kuin muistin loppumisen vuoksi koko ajan swapataan muistia SSD -levylle ja takaisin.
Kun pagefilen ottaa pois niin ei swapata.
Mitä ihmettä nyt oikein sotket jotain välimuistia tähän? Ei tällä ole mitään tekemistä välimuistin kanssa.
Opetteleppas nyt mitä mmap() tarkoittaa.
Muistaakseni tuon edellisenkin linkin takana oli syitä miksei kannata ja täällä lisää (ja miksi se kannattaa pitää nopeimmalla asemalla)
Onko tän ongelman laajuudesta tullut suurempaa näyttöä, kuin foorumikäyttäjien anekdootit? Kuulostaa aika selkeältä softabugilta, jos swappia laulatetaan 24/7 koneen ollessa päällä. Ja heittovaihdon kytkeminen kokonaan pois on aika luupäinen ratkaisu – parempi ratkaisu on tehdä siitä swap-osiosta/pagefilesta pienempi, jos levynkäyttö ahdistaa.
Tosin M1 maceissa taisi olla sellaista liikkeellä, että latauspiiri kärähti epävirallisista dockeista pysyvästi. Mutta pöytäkoneella toki pienempi ongelma.
Silver/White löytyy
Tämä, mutta epäironisesti. M1:n energiatehokkuus on aivan naurettavan hyvä verrattuna X86-kilpailijoihin.
Ottaisin ilomielin tuon kännykäraudan omaan PC:hen jos voisin.
Näköjään menny väli- ja keskusmuistit sekaisin kirjoittaessa, pahoittelut.
Jep. Swappaamisen sijaan pahimmassa tapauksessa koko käyttis kaatuu. Kätevää.
Oma MacBook Pro M1 16GB. Ei ole muuta auki kuin Safari, jossa 34 aktiivista tabia. Yhdessä tabissa pyörii Twitch striimi.
katso liitettä 592876
Tuo 8GB malli voi olla useille liian vähän.
Swappailua ihan älyttömästi. Ainakin jos tähän luottamista:
katso liitettä 593070
M1 MacBook Air 8gb kyseessä
Ja mitäs tolla on tehty, vai onko oma laite kyseessä? Kuinka paljon levy on kulunut, tuon kolme prosenttia? Kolmella prosentilla laskettaessa käyttöikää on jäljellä enää vaatimattomat 12000 tuntia ja todennäköisesti levy ei vielä silloinkaan ole entinen.
Monille liian vähän, kyllä, mutta suurimmalle osalle ihan riittävästi.
Pääasiassa Safaria käytetty. Videostriimit, Facebook, ym vastaavat sivustot saa muistin äkkiä loppumaan kesken. Noin 10 tabia on auki.
katso liitettä 593121
Ja huomaako tuota muistin loppumista mitenkään konetta käytettäessä, vai mistä olet päätellyt että kyseessä on ongelma?
Et nyt ymmärrä alkuunkaan sitä Apple-kultin seuraajien Tukholma-syndoomaa.
Ei Applen tuotteista niiden käyttäjät valita.
Tottakai huomaa kun tarpeeksi kauan käyttää. yleensä välilehden sulkeminen auttaa, mutta välillä täytyy Safari käynnistää uusiksi.
Kyllä tämän kanssa pärjää, kun osaa oikein suhtautua asiaan. Mutta suosittelen kyllä 16gigaa nykypäivänä.
Mutta siis miten sen huomaa? Kuvittelis että noin nopea swappi hoitaa esim. ei-aktiiviset välilehdet swappiin ja löytää sieltä uudestaan muutamassa millisekunnissa. Työmäkissäni (joku intel 8 ydintä) jopa 32 gigaa loppuu usein kesken ja isoimpana havaintona outlook alkaa jäätyilemään ja jossain testiajoissa kestää sen 20-40% kauemmin. Jotenkin kuvittelin että noi olis nyt hoitaneet tilanteen vähän paremmin.
Jos esim vaihtelee raskaiden tabien välillä niin välillä joutuu odottamaan useita sekuntteja tai pahimmassa tapauksessa lataamaan sivun uudestaan.
Voisitko nyt yrittää ymmärtää, mitä se swappauksen viive ja käyttisoverhead tekee sen nopeudelle?
Sitä swappaamista tehdään x86lla 4 kibitavua kerrallaan, ARM-macillä ehkä 16 kibitavua kerrallaan.
Jokainen "ei-aktiivnen välilehti" koostuu TUHANSISTA virtuaalimuistisivuista. Jos swapataan 4 gigaa tavaraa, se tarkoittaa x86lla MILJOONAA virtuaalimuistisivua, Applen ARMilla ehkä 256 tuhatta virtuaalimuisitsivua.
Seuraava asia tehdään siis TUHANSIA kertoja jokaiselle välilehdelle:
Että swapista ladataan jotain, latausta yrittävälle ohjelmalle lentää virtuaalimuistin läsnäolopoikkeus. Koko ohjelman liukuhihna flushataan.
Poikkeuskäsittelijä hyppää käyttiksen puolelle, koko prossun toimintatila vaihtuu.
Käyttis alkaa kaivella omista tietorakenteistaan, että hetkonen, mitäs tuossa virtuaaliosoitteessa pitäisi olla. Näissä tietorakenteissa pitää olla kirjanpito miljoonista virtuaalimuistisivuista.
Kun lopulta selviää, että jaa, se löytyy swapfilestä tuosta kohtaan, kutsutaan käyttiksen levyrytiineita hakemaan se. Ja kun swapfile ei ole omalla partitiollaan, tässä on vielä tiedostojärjestelmän koodi välissä. Tiedfostojärjestlemä hakee, että mistä kohtaa levyä löytyy swapfileen täm kohta.
Jossain vaiheessa sitten tehdään SSD:n suuntaan lukuoperaatio, jolla sieltä luetaan se 4 kiB tai 16 kiB blokki joka tämän muistisivun sisältää. Sitä SSDtä odotellaan joku luokkaa 50 mikrosekuntia, kunnes data tulee.
Sitten päivitellään sivutauluihn tieto, että tuo virtuaaliosoite osoittaa nyt tähän fyysiseen osoitteeseen, johon data ladattiin.
Ja sitten pitää vielä prossun TLB invalidoida ainakin osittaisesti, kun sivutauluja muutettiin.
Ja sitten tämän jälkeen palataan ohjelmaan, jolel tosiaa sittne seuraavat musitiaccessit mahdollsiesti kaikki sujuu hyvin hitaasti mikäli koko TLB invalidoitiin.
Tässä kun menee kokonaideuussaan n. 100000 kellojaksoa per sivu, ja jokainen ei-aktiivinen välilehti koostuu tuhansista virtuaalimuistisivuista, niin JOKAISEN ei-aktiivisen välilehden swappauksessa puhutaan tällöin sadoista miljoonista kellojaksoista (eli suuruus luokkaa 100 millisekunnista PER VÄLILEHTI). Parinkymmenen välilehden swappaamisessa menee sekunteja.
Että mutuilit vain n. 1000-kertaisesti pieleen
Eli yksi 16ms frame pitää naamioida kivalla animaatiolla. Ei kuulosta kovin huonolta käyttökokemukselta.
Tuon perusteella, jos haluaa pelkkiä testejä ajella niin silloin ehkä, mutta oikeassa työssä esim. videolla nähty videon renderöinti oli tuplasti nopeampaa Intelin i9 prossulla.
Ymmärrätkö, mitä sana "vähintään" tarkoittaa?
Tämä oli laskettu välilehdelle, jonka muistinkulutus on nelisen megaa, oletuksella, että käyttis yhdistää niputtaa aina kahdeksan virtuaalimuistisivua yhteen.
Välilehdellä, jonka muistinkulutus on 50 megaa aika on 12.5-kertainen. Ja jos käyttis ei niputa useita virtuaalimuistisivuja yhteen, aika on siitä 8-kertainen. Päästään aika helpolla siihen sekuntiin/välilehti.
Tässä vertailuksi MacBook Pro 2017 16GB, joka on Intel versio. Safari ainoastaan auki ja samat tabit ja yhdessä pyörii Twitch striimi.
katso liitettä 593401
Macrumors foorumilla pitkä ketju tuosta. Muuta en tiedä kuin noita 8GB malleja on ostettu paljon tehokäyttöön..
ssd swap – high usage of Terabytes Written
forums.macrumors.com
Nämä ovat suurinpiirtein aina auki koneessa. En varsinaisia hidasteluja ole huomennaut käytössä, toimii jouheasti.
Jos se sivutustiedoston käyttäminen on noin hidasta, niin eikö olisi järkevää vaan tallentaa inaktiiviset tabit blobeina levylle?
Ei.
Ensinnäkin, mitä oikein tarkoitat "blobilla"?
Toisekseen, miten määrittelet "inaktiivisen" tabin?
Joskus vuonna miekka ja kypärä oli käyttiksiä, jotka kirjaimellisesti swappasivat muistissa olevia ohjelmia. Tämä esti niiden ajamisen yhtä aikaa. Nyt ollaan jo kymmeniä vuosia käytetty sivutusta, joka mahdollistaa niiden ajautumisen yhtä aikaa. 80386 oli ensimmäinen PC-prossu joka tuki sivupohjaista virtuaalimuistia.
Tabi, joka ei ole vuorovaikutuksessa käyttäjän kanssa.
Tallentaa tabin käyttöön varatut muistialueet sinällään niin yhtenäisinä pätkinä kuin se ylipäänsä on mahdollista. Samaan tapaan kuin mitä vaikka uudessa xboxissa pelin tila tallennetaan levylle.
Jos tuo ei ole mahdollista esim. tuon sivutuksen takia, niin luulisin että on triviaalia tehdä joku megan tai kahden paloihin noita sivuja yhdistelevä komponentti esim. muistiohjaimeen niiden ulos/sisäänkirjoitusta varten. Jotenkin kuvittelisi että moinen noista jo löytyisi, kun ottaa huomioon miten ripeästi iluureissa vastaavat asiat tapahtuvat.
Miten määrittelet vuorovaikutuksen käyttäjän kanssa?
Jos minulla on vaikka webbipohjainen pikaviestin auki tabissa joka ei ole juuri nyt päällimmäisenä, niin todellakin haluan että ne viestit tulee silti läpi.
Tai jos minulla on youtubesta soimassa musiikkia tabissa joka ei ole juuri nyt päällimmäisenä, niin todellakin haluan, että se musiikki pysyy soimassa.
Kenen vastuulla tämän tekeminen olisi? Selaimen vai käyttiksen?
Ei todellakaan ole mitään järkeä, siinä, että softa itse alkaa tunkemaan dataansa levylle vain sen takia, ja latailemaan sitä takaisin sielä sen takia, että se epäilee, että käyttäjä ei ehkä juuri nyt tätä dataa tarvi.
Käyttöjärjestelmä taas käsittelee fyysistä muistia joka voi olla sivu (tai parin sivu rypäs) kerrallaan allokoituna mistä tahansa.
Ja käyttöjärjestelmä tietää vielä vähemmän siitä, mikä on "aktiivinen välilehti".
Vertaat tilanteeseen, jossa ohjelma suljetaan
Tervetuloa 2000-luvulle, nykyisin meillä on oikeissa tietokoneissa moniajo ja hyvä niin.
Muistiohjain ei piittaa yhtään mitään virtuaalimuistisivuista. Se käsittelee pelkästään fyysisiä osoitteita, ja tekee niitä accesseja käytännössä pelkästään välimuistilohko (64 tavua) kerrallaa,
Tällaiset asiat on käyttöjärjestelmän vastuulla, ja ne tehdään täysin softalla.
Ja kuten jo aiemmin sano, jotkut käyttikset käsittelee useampaa sivua kerrallaan.
Siinä on kuitenkin huomattavat haittapuolensa, joten liian montaa sivua ei kannata yhdistää, käytännössä näissä niputetuissa sivuissa mennään maksimissaan parissakymmenessä kilotavussa, jottei tuhlata sekä muistia että aiheuteta ihan liikaa levyliikennettä tällaisen takia.
Jos oikeasti tarvitaan vain 4 tavun kokoinen muuttuja, on paljon parempi tuhlata sille vain 4 kiB kokoinen yksi virtuaalimusitisivu kuiin vaikka megatavun verran dataa sen takia, että monta virutaalimuistisivua ollaan nuputettu yhteen.
Todella suuri osa muistiaccesseista osuu pinoon, Yhden pinoframen koko on tyypillisesti selvästi alle kilotavun luokkaa, ja kun meillä on muutamaa sisäkkäistä funktiokutsua, niin käytännössä lyhyellä aikavälillä pinoa usein accessoidaan kokoluokassa 1-4 kiB.
4 kiB virtuaalimuistisivulla ilman mitään niputusta se pinon aktiivinen osa vie sen 4 kiB fyysistä muistia. 16 kiB virtuaalimuistisivulla se vie 4 kertaa enemmän, 16 kiB. Eli jo tässä siihen kuluu nelinkertainen määrä. Tämä on kuitenkin vielä siedettävää.
Mutta jos alettaisiin niputtaa kymmeniä virtuaalimuisisivuja yhteen niin haaskattaisiin ihan älyttömästä muistia.
Testasin macos X:llä (Sierra) x86-64lla: Siinä sivujen niputusta yhteen ei tehdä, sivuja käsitellään yksi 4 kiB sivu kerrallaan.
Ja iLuurista: iLuuri ei sivuta mitään dataa DRAMista ulos flashille. Siinä on sivutus pelkästään read-only-datalle, jolloin swapfileä ei tarvita, vaan ulosswappaamisen sijnaa data voidaan vaan tuhota, koska se on jossain alkuperäisenä kuitenkin. Eli käytännössä:
1) Kun allokoidaan uutta muistia, se allokoidaan kaikille yhteiselle nollasivulle. Sitten kun ohjelma kirjoittaa sinne, käyttis luo sille uuden kopion muistista
2) Ohjelmien binääreitä ja kirjastoja ladataan laiskasti flashistä sivutusmekanismilla. Koko ohjelman binääriä ei tarvi ladata kerralla, vaan sitä mukaa mitä kohtia sitä luetaan. Ja monta eri ohjelmaa voi jakaa saman kirjastokoodin.
Jos iLelussa alkaa muisti loppua, sitten vaan
1) discardataan osa read-only-datasta
2) suljetaan kokonaisia prosesseja. Ja tämä menee melkoisella arvalla, että mitä suljetaan.
Tuo on melko epäreilu vertailu. m1 apple on hyvin pienellä virrankulutuksella ja passiivisella jäähdytyksellä ja paljon pienemmässä paketissa. i9:sta vastaan päästään myöhemmin tänä vuonna vertaamaan m1x soc:ia, joka tulee enemmän tehoa vaativiin laitteisiin. m1x:ssa on enemän resursseja käytössä ja isommat virrankulutusrajat.
13" m1 air on törkeän kova videoeditointiin, jos sitä vertailee vastaavan kokoluokan muihin laitteisiin. Ei kuumene juurikaan, ei puhise(passiivinen jäähdytys), akku kestää ja melkoisen nopea rautakiihdytetty videoeditointi, jos käyttää final cut pro:ta.
Nyt pitää vähän suhteuttaa todelliseen käyttöönkin, että kuinka moni karvalakkimallin ostaja pitää jatkuvasti 34 aktiivista välilehteä auki selaimessa. Se karvalakkimallin ostaja käyttää todennäköisemmin vain muutamaa aktiivista välilehteä ja muutamaa sovellusta taustalla auki. Ja vaikka se nyt joskus sattuisikin tarvitsemaan yli 30 aktiivista välilehteä ja kaikkia sovelluksia yhtäaikaa auki, niin tuo kone toimii silti ilman suurempia kyykkäilyjä.
Mikäli käyttö on ns. tehokäyttöä, kannattaa tilausvaiheessa jo miettiä isompaa muistikapasiteettia. Oma käyttö on ehkä 80% kevyttä, mutta loput 20% raskaampaa, joten valitsen tietenkin sen 16 gigaa muistia jo ostovaiheessa. Enkä pidä tuota parin sadan euron lisää mitenkään kynnyskysymyksenä ostolle, kun aikaisempien kokemusten perusteella mäkki kestää käytössä sen kymmenisen vuotta. Vielä porskutetaan vuoden 2012 iMacillä, mutta nyt alkaa olla sopiva aika miettiä päivitystä kun Bigsur tuki jäi pois näistä.
Ei se ole typerää, vaan äärettömän viisasta. Jos swappausta ei tehtäisi, niin liian vähällä fyysisellä muistilla olevissa tietokoneissa käyttis kaatuilisi vähän väliä, tai vähintään se OOM-killaisi enemmän tai vähemmän fiksusti jonkun algoritmin mukaisesti käynnissä olevia prosesseja.
On paljon parempi, että kone toimii, joskin vähän hitaammin. Etenkin kun suurimmassa osassa tapauksista SSD:llä se hidastuminen ei ole mitään maailmanlopun hidastumista, vaan juuri sitä että selaimen tabin vaihto toiseen kestää sekunnin sen sijaan, että se selain tai sen tabi kaatuu kokonaan.
Näin herran vuonna 2021 kaikki käyttävät useita tabeja, taustalla pyörii suhteellisen raskaita ja muistisyöppöjä electron appseja kun Spotify + Teams + Zoom ovat päällä yhtä aikaa, google docs:lla / office365:llä tehdään niitä koulutehtäviä etälukiossa yms.
Onko se nyt sitten tehokäyttöä vaiko ei, luulen sen olevan kuitenkin aivan arkipäiväistä käyttöä sadoille tuhansille yläaste- / lukioikäisille. Jopa ne 60v+ etätöihin ekaa kertaa elämässä pakotetut toimistosihteerit pyörittävät noita teamsejä ja zoomeja + officeita koneillaan yhtä aikaa.
Ja noissa i9 15" tuumaisissa on erillinen AMD näytönohjain. Olikohan Vega parhaimmissa siis tuossa 2018 versiossa, joka tuossa videossa.
Edit: Korjattu linkki. I9:ssä on AMD Vega HBM2 muisteilla.
MacBook Pro 15-Inch "Core i9" 2.9 Touch/2018 Vega Specs (Mid-2018 15" (Touch Bar), BTO/CTO, MacBookPro15,3, A1990, 3215): EveryMac.com
everymac.com
SSD:llä tilanne voi toki olla vähän parempi. HDD:llä muistin loppuminen saa koneen usein niin hitaaksi, että pakotettu uudelleenkäynnistys on ainoa käytännöllinen vaihtoehto.
Jos ohjelmien ei annettaisi varata enempää muistia kuin koneessa on oikeasti vapaana, ei muistin loppumisia sattuisi niin helposti:
– Prosessi yrittää varata muistia enemmän kuin on mahdollista –> varaus epäonnistuu, siitä eteenpäin toiminta on prosessin vastuulla
– Prosessi yrittää käyttää muuta kuin varaamaansa muistia –> prosessi suljetaan pakolla (kuten yleensä nykyäänkin)
Käynnissä olevien prosessien tappaminen tulisi eteen vasta sitten, jos käyttöjärjestelmälle tulisi pakottava tarve varata lisää muistia eikä sitä olisi saatavilla tarpeeksi.
Tämä olisi todella epätehokasta muistienhallintaa ja ohjelmat kaatuilisivat jatkuvasti muistin loppumiseen ja kone toimisi todella hitaasti.
Se, että koodissa on malloc() tai new() ei ole sama asia kuin se, että prosessi pyytää muistia käyttikseltä.
Ja se, että prosessi pyytää muistia käyttikseltä ei myöskään tarkoita sitä, että se prosessi saa sen pyytämänsä muistin täysin omakseen.
Kun koodissa suoritetaan se malloc() tai new, sen tekee tyypillisesti standardikirjaston malloc()-toteutus joka ajetaan ihan siellä user-tilassa, se ei yleensä mene käyttikselle asti.
Käyttikseltä saa muistia varattua minimissään virtuaalimuistisivun kokoisissa palasissa(*), ja käyttiskutsut on hitaita. Käyttikseltä pyydetään muistia harvemmin, ja paljon isommissa paloissa.
Käytännössä kuvio toimii siten, että ohjelmaa käynnistettäessä siellä saattaa olla jo valmiina saatuna käyttikseltä virtuaaliosoiteavaruutta tulevia malloc/new-kutsuja varten. Ja esimmäiset n malloc/new-kutsua käyttävät näitä osoitteita, eivätkä varaa käyttikseltä mitään.
Sitten kun tämä loppuu, varataan sitä käyttikseltä isompi pala kerrallaan.
Ja kun ohjelma pyytää käyttiseltä muistia, käyttis ei varaa sille oikeaa omaa fyysistä muistia. Kaikki se muisti, mikä prosessille palautetaan, saattaa olla viittausta samaan pelkkää nollaa sisältävään 4 kiB viruaalimuistisivuun, joka on jaettu ziljoonan muun ohjelman kanssa, ja se annetaan ohjelmalle read-only-moodissa.
Tällä tempulla säästetään huomattavasti muistia, koska tyypillisesti ohjelmat pyytävät paljon enemmän muistia kuin mitä oikeasti käyttävät.
Kun softa sitten myöhemmin yrittää kirjoittaa johonkin osaan tätä pyytämäänsä muistia, lentää poikkeus muistin laittomasta käytöstä. Käyttis toteaa että jaahas, nyt se sitten kirjoittaa sivuun jonka se joskus pyysi, tämä on ok, ja vasta tässä vaiheessa varaa softalle uuden ikioman fyysisen muistisivun. Softan virtuaalimuistin mäppäys päivitetään siten, että tämä virtuaaliosoite mihin kirjoitettiin osoittaa nyt tähän uuteen sivuun, ja softalle annetaan siihen sivuun kirjoitusoikeus. Tämän jälkeen palataan softaan ja softan suoritus jatkuu suorittamalla kirjoituskäsky uudestaan.
Kaikki se muu muisti mitä samalla kertaa varattiin pysyy kuitenkin edelleen yhteisenä osoittamassa nollasivuun. Softa siis todellisuudessa usein kuluttaa systeemiltä todella paljon vähemmän muistia kuin mitä se on käyttikseltä pyytänyt.
Se, että se softa kaadettaisiin vain koska sen standardikirjaston malloc-toteutus on optimoitu siten, että se pyytää käyttikseltä ison poolin muistia kerrallaan olisi vaan todella typerää. Ja se, että malloc/new-toteutus pyytäisi aina käyttikseltä pienimmän mahdollisen määrän muistia (varauksen koko pyöristetynä ylöspäin virtuaalimuistin sivukokoon) tarkoittaisi sitä, että malloc/new hidastuisi selvästi.
Käyttis saattaa kuitenkin tehdä sen, että varautuakseen pahimpaan se pitää kirjaa siitä, paljonko kaikki softat yhteensä ovat muistia pyytäneet, eikä anna tämän kasvaa suuremmaksi kuin mikä on swapfileen maksimikoko + fyysisen muistiin koko, jolloin se ei voi koskaan joutua tilanteeseen, että se ei pysty "lunastamaan lupaustaan" aiemmin tehdystä muistinvarauksesta. Mutta kun softat eivät kirjoita läheskään kaikkeen pyytämästään muistista, sitä ei usein koskaan tarvi heittää edes swapfileeseen vaikka softat yhdessä olisivat varanneet muistia jonkin verran enemmän kuin mitä fyysistä muistia koneessa on.
Lisäksi kuviota monimutkaistaa paljon vielä esim. jaetut binäärit (ohjelmien omat binäärit sekä kirjastot). Nämä jaetaan hyvin tehokkaasti eri prosessien kesken, ja niitä voidaan ladata levyltä laiskasti.
Ja muistia voidaan käyttää myös levyvälimuistina. Tilanteessa jossa ohjelmat käyttävät muistia esim. n. 95-100% fyysisen muistin kapasiteetista, systeemin suorituskyky on keskimäärin paljon parempi kun joku 5-10% tästä heitetään swappiin ja 10% muistista käytetään levyvälimuistina, kuin että levyvälimuistille ei jää käytännössä ollenkaan muistia, ja joka ikinen hyvinkin pieni ja samaan paikkaan tehtävä toistuva levyaccessi joutuu aina menemään levylle asti.
Nykyaikaisella moniajokäyttiksellä on siis täysin normaalia, että softat "käyttävät" muistia yhteensä todella paljon enemmän kuin mitä koneessa on fyysistä muistia, ja silti swapissa ei välttämättä ole (juuri) mitään.
(*) Joillain käyttiksillä tämä saattaa olla muutaman sivun yhdistetty isompi blokki eikä yksi sivu, macos X(Sierrassa) kuitenkin ainakin tasan yksi sivu.
Kuka selailee vain mutaamaa sivua ?
Juu, tiedä käyttäjiä jotka sulkee selaimenkin joka päivä, ja joka ohjelman jos lopettaa sen käytön hetkeksi.
mutta muutama kymmenen välilehtä ei ole mitään ihmeellistä edes mobiilissa. Saati työpöydällä jos tänäpäivänä selainta käyttää muuhunkin kuin fasebookkiin ja yotubeen. Jotkut käyttää selainta sähköpostiinkin, joten jo se käyttä generoi nopeasti monta välilehtä auki. Selain on netistä useasti tiedostojen katseluohjelma, mikä lisää entisestään avoimia välilehtiä.
Rahalla saa, sitä sitten valitsee mikä on tärkeintä. Uutisen laitteissa jos tekee väärän valinnan ostohetkellä, niin sitä sitten joutuu latomaan rahaa vielä enemmän, tai kärsiä valinnasta.
Tässä en kritisoida laitteita yleensä, vaan sitä että ahneuksissa valmistaja nuukailee perusmalleissa.