Apple laajensi Arm-Macien valikoimaa uusilla värikkäillä 24-tuumaisilla iMac-tietokoneilla

[hkultala]

Käyttö ja varaus on eri asioita. Lisäksi ton härvelin SSD on niin nopea, että mitään read only paskaa (kuten se 5Gt kirjasto) on turha pitää välimuistissa.

Kaistanleveys ja viive on myös eri asioita.

Sillä, paljonko siihen SSDhen on kaistaa on hyvin vähän väliä sen kannalta, missä ajassa 16 kiB tai 4 kiB virtuaalimuistisivu sieltä SSDltä saadaan ladattua, kun viive dominoi tätä selvästi.

Kun softat tehdään M1 natiiveiksi, niin tälläiset asiat tulee suurelta osin tehtyä ns. oikein, koska uusimmat kirjastoversiot sitä joko vaativat tai vähintään voimakkaasti ohjaavat siihen suuntaan.

Ei.

Niin kauan kun se SSD on NAND-flashiä jota ei voi suoraan osoittaa, sen viive on ongelma, eikä sillä, onko prossuna Applen ARMv8-pohjainen vai Intelin x86-pohjainen ei ole tämän kannalta MITÄÄN merkitystä.


Tällä loppuu olemasta väliä silloin kun se NAND-flash korvataan jollain tavuosoitettavalla NVRAMilla, kuten esim. xPointilla/Optanella.

 

[pomk]

Niin kauan kun se SSD on NAND-flashiä jota ei voi suoraan osoittaa, sen viive on ongelma, eikä sillä, onko prossuna Applen ARMv8-pohjainen vai Intelin x86-pohjainen ei ole tämän kannalta MITÄÄN merkitystä.

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.

 

[hkultala]

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

Höpöhöpö.

Windows on tukenut tiedostojen mäppäystä näkyviin virtuaalimuistiosoitteissa ikuisuuden.

File Mapping - Win32 apps

File mapping is the association of a file's contents with a portion of the virtual address space of a process.

docs.microsoft.com

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.

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ä filenä tai "muistina" joka on swapattu ulos, se ladataan siten, että yritetää käyttää virtualiosoitetta, joka on sinne mapatty, tästä ensin tulee virtaalimuistin 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.

 

[saan]

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

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

 

[pomk]

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.

Höpöhöpö.

Windows on tukenut tiedostojen mäppäystä näkyviin virtuaalimuistiosoitteissa ikuisuuden.

File Mapping - Win32 apps

File mapping is the association of a file's contents with a portion of the virtual address space of a process.

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ä filenä tai "muistina" joka on swapattu ulos, se ladataan siten, että yritetää käyttää virtualiosoitetta, joka on sinne mapatty, tästä ensin tulee virtaalimuistin 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.

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.

 

[zepi]

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.

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

 

[Contay]

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.

 

[LaDeX]

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.

 

[pomk]

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

Kuinka paljon ne sit kestää kulutusta applen käyttämillä over provisioning asetuksilla? Pelkkä TBW ei tyhjiössä ole kovin merkityksellinen tieto.

 

[demu]

Nykyään tietokoneessa olisi hyvä olla sen verran muistia, että virtuaalimuistia ei tarvitse käyttää ollenkaan.
Itselläni ei ole virtuaalimuisti käytössä.

 

[Kaotik]

Nykyään tietokoneessa olisi hyvä olla sen verran muistia, että virtuaalimuistia ei tarvitse käyttää ollenkaan.
Itselläni ei ole viruaalimuisti käytössä.

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?

I'm studying computer architecture, more specifically, virtual memory. One thing that I can't seem to uderstand is why turning off Virtual Memory doesn't improve my computer's performance? I know ...

superuser.com

 

[pomk]

Nykyään tietokoneessa olisi hyvä olla sen verran muistia, että virtuaalimuistia ei tarvitse käyttää ollenkaan.
Itselläni ei ole viruaalimuisti käytössä.

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.

 

[demu]

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?

I'm studying computer architecture, more specifically, virtual memory. One thing that I can't seem to uderstand is why turning off Virtual Memory doesn't improve my computer's performance? I know ...

superuser.com

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.

 

[hkultala]

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.

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.

 

[Kaotik]

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.

Muistaakseni tuon edellisenkin linkin takana oli syitä miksei kannata ja täällä lisää (ja miksi se kannattaa pitää nopeimmalla asemalla)
edit: se linkki unohtui

What Is the Windows Page File, and How Do You Configure It?

Windows uses a page file to store data that can’t be held by your computer’s random-access memory when it fills up. While you can tweak the page file settings, Windows 10 and Windows 11 can manage the page file just fine on their own.

www.howtogeek.com

 

[looz]

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

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.

 

[Foxy]

Toisaalta valkoinen ja musta olisi ollut tervetulleita värejä.

Silver/White löytyy

 

[pulssi]

Kännykän rautaa pöytäkoneen kuorissa, amazing. Eiköhän muistin määrän päätä kateprosentti, eli tämän hetken hintatasolla ja katteella ei enempää saa ilman lisähintaa.

 

[looz]

Kännykän rautaa pöytäkoneen kuorissa, amazing.

Tämä, mutta epäironisesti. M1:n energiatehokkuus on aivan naurettavan hyvä verrattuna X86-kilpailijoihin.

 

[escalibur]

Kännykän rautaa pöytäkoneen kuorissa, amazing. Eiköhän muistin määrän päätä kateprosentti, eli tämän hetken hintatasolla ja katteella ei enempää saa ilman lisähintaa.

Ilomielin ottaisin tuon kännykäraudan omaan PC:hen jos vain voisin.

 

[pomk]

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.

Näköjään menny väli- ja keskusmuistit sekaisin kirjoittaessa, pahoittelut.

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.

Jep. Swappaamisen sijaan pahimmassa tapauksessa koko käyttis kaatuu. Kätevää.

 

[user9999]

Ihan samalla tavalla noissa M1 mäkeissä loppuu muisti ja sitten swapataan. Tuolla läppärialueella on puhetta siitä kuinka SSD huutaa hoosiannaa ja TBW:tä tulee reilusti. Kiitos nopean SSD:n ja hyvän SSD-ohjaimen kone ei tunnu superhitaalta, mutta kyllä se silti on haitta vs. riittävä muistimäärä.

En suosittele kenellekään 8GB muistillista konetta. Jos ei ole varaa maksaa 200-250€:tä 16GB muistipäivityksestä, uusi Apple on todennäköisesti väärä kone ostettavaksi.

edit:


Tässä on nyt pieni pala oman Mäkkini muistinkäytöstä. Ja auki ei edes ole mitään erityistä. Tai siis outlook + vähän nettiselaintabeja joissa jotain firman intranet-sivua. Confluenceä, Jiraa ja lisäksi MS Teams ja jotain muita chatticlienttejä yms pientä.

Itse en tule enää ikinä ostamaan yhtäkään konetta alle 32GB muistilla. Seuraava työkone vaatii minimissään 64GB muistia. Nyt jos käynnistän tuohon jonkun oikean dev-environmentin kylkeen, niin muistia menee välittömästi gigatavukaupalla lisää.

Oma MacBook Pro M1 16GB. Ei ole muuta auki kuin Safari, jossa 34 aktiivista tabia. Yhdessä tabissa pyörii Twitch striimi.

Tuo 8GB malli voi olla monille liian vähän.

 

[JL79]

8gb on liian vähän, varsinkin jos streameja tai videoita paljon katselee.
Swappailua ihan älyttömästi. Ainakin jos tähän luottamista:

M1 MacBook Air 8gb kyseessä

 

[pomk]

8gb on liian vähän, varsinkin jos streameja tai videoita paljon katselee.
Swappailua ihan älyttömästi. Ainakin jos tähän luottamista:



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.

Oma MacBook Pro M1 16GB. Ei ole muuta auki kuin Safari, jossa 34 aktiivista tabia. Yhdessä tabissa pyörii Twitch striimi.


Tuo 8GB malli voi olla monille liian vähän.

Monille liian vähän, kyllä, mutta suurimmalle osalle ihan riittävästi. Foorumin käyttäjäkunnalle varmaan tuntuu lukuna liian pieneltä ja osa isommasta määrästä aidosti hyötyisikin.

edit: hölmöähän se on paria euroa säästää valmistuskuluissa jos menettää puolet keskusmuistista, mutta ei toi ole yhtä iso ongelma kuin mitä täällä ihmiset huutelee. Muuten netti olis täynnä ihmisiä valittamassa siitä kun niiden uus ja hieno mäkki on hidas tuhnu.

 

[JL79]

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.

Pääasiassa Safaria käytetty. Videostriimit, Facebook, ym vastaavat sivustot saa muistin äkkiä loppumaan kesken. Noin 10 tabia on auki.

 

[pomk]

Pääasiassa Safaria käytetty. Videostriimit, Facebook, ym vastaavat sivustot saa muistin äkkiä loppumaan kesken. Noin 10 tabia on auki.

Ja huomaako tuota muistin loppumista mitenkään konetta käytettäessä, vai mistä olet päätellyt että kyseessä on ongelma?

 

[hkultala]

edit: hölmöähän se on paria euroa säästää valmistuskuluissa jos menettää puolet keskusmuistista, mutta ei toi ole yhtä iso ongelma kuin mitä täällä ihmiset huutelee. Muuten netti olis täynnä ihmisiä valittamassa siitä kun niiden uus ja hieno mäkki on hidas tuhnu.

Et nyt ymmärrä alkuunkaan sitä Apple-kultin seuraajien Tukholma-syndoomaa.

Ei Applen tuotteista niiden käyttäjät valita.

 

[JL79]

Ja huomaako tuota muistin loppumista mitenkään konetta käytettäessä, vai mistä olet päätellyt että kyseessä on ongelma?

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

 

[pomk]

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.

 

[JL79]

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.

 

[hkultala]

Mutta siis miten sen huomaa? Kuvittelis että noin nopea swappi hoitaa esim. ei-aktiiviset välilehdet swappiin ja löytää sieltä uudestaan muutamassa millisekunnissa.

Voisitko nyt yrittää ymmärtää, miten virtuaalimuisti toimii, ja mitä se sivutuksen viive ja käyttisoverhead tekee sen nopeudelle?

Sitä sivutusta tehdään natiivisti x86lla 4 kibitavua kerrallaan, ARM-macillä ehkä 16 kibitavua kerrallaan.

Jokainen "ei-aktiivinen välilehti" koostuu vähintään TUHANSISTA virtuaalimuistisivuista. Jos sivutetaan 4 gigaa tavaraa, se tarkoittaa x86lla MILJOONAA virtuaalimuistisivua, Applen ARMilla ehkä 256 tuhatta virtuaalimuistisivua.

Seuraava asia tehdään siis TUHANSIA kertoja jokaiselle välilehdelle:

Että swapfileestä 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ä. Tiedostojärjestelmä hakee omasta kirjanpidostaan, että mistä kohtaa levyä löytyy swapfileen tämä kohta. (Ja se levykirjanpidon tarkastaminen voi joskus tarkoittaa ylimääräistä lukua levyltä, erityisesti tilanteessa kun muisti on vähissä, jolloin levyvälimuistia flushaillaan enemmän).

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 sivutauluihin 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, jolle tosiaan sitten seuraavien parintuhannen kellojakson ajan suuri osa musitiaccesseista mahdollisesti sujuu hyvin hitaasti mikäli koko TLB invalidoitiin.

Ja koko sen ajan kun se käyttis haki sitä dataa swapista, se ohjelman säie, joka sitä lukua yritti, oli täysin jumissa, se ei tehnyt yhtään mitään.

Ja sitten kun osutaan vähän myöhemmin seuraavaan swapissa olevaan virtuaalimuistisivuun, koko sama raskas homma tehdään uusiksi seuraavalle 4kiB sivulle, ja taas jumitetaan yhtä pitkään.

Tässä kun menee kokonaisuussaan n. 100000 kellojaksoa per sivu, ja jokainen hyvin kevytkin ei-aktiivinen välilehti koostuu tuhansista virtuaalimuistisivuista, niin JOKAISEN ei-aktiivisen välilehden swappauksessa puhutaan tällöin sadoista miljoonista kellojaksoista (eli suuruusluokkaa 100 millisekunnista PER VÄLILEHTI). Parinkymmenen välilehden sivutuksessa menee sekunteja.

Että mutuilit vain n. 1000-kertaisesti pieleen (tai no, ehkä vain 100..200-kertaisesti, allaoleva)

Käyttiksen virtuaalimuistinhallinta voi toki niputtaa aina muutaman sivun yhteen, että kun sivutetaan yksi sivu, sivutetaan samalla 1-7 viereistä sivua, mutta tässä puhutaan käytännössä korkeintaan kertoimesta 2-8, koska muuten muistia tuhlaantuisi liikaa ja tulisi liikaa turhaa levyliikennettä. Menee silti vähintään ~10 millisekuntia PER VÄLILEHTI ja parinkymmenen välilehden sivutuksessa menee silti satoja millisekunteja.

 

[pomk]

Menee silti vähintään ~10 millisekuntia PER VÄLILEHTI

Eli yksi 16ms frame pitää naamioida kivalla animaatiolla. Ei kuulosta kovin huonolta käyttökokemukselta.

 

[jkaart]

Ilomielin ottaisin tuon kännykäraudan omaan PC:hen jos vain voisin.

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.

 

[hkultala]

Eli yksi 16ms frame pitää naamioida kivalla animaatiolla. Ei kuulosta kovin huonolta käyttökokemukselta.

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.

 

[user9999]

Oma MacBook Pro M1 16GB. Ei ole muuta auki kuin Safari, jossa 34 aktiivista tabia. Yhdessä tabissa pyörii Twitch striimi.


Tuo 8GB malli voi olla monille liian vähän.

Tässä vertailuksi MacBook Pro 2017 16GB, joka on Intel versio. Safari ainoastaan auki ja samat tabit ja yhdessä pyörii Twitch striimi.

 

[abish]

Hyvä uudistus kyllä, jottei ihmisten enää tarvitse ostaa tuota 21,5-tuumaista kikkaretta. Yleisestihän on sanottu, ettei kannata alle 8 gigaa laittaa muistia, kun se on niin halpaa. Tämä vain ei ole koskaan koskenut Applea (paitsi jos on itse järkevästi lisättävissä). Onkos tuo swappailu nyt uusikin ongelma vai miten vaikka jotkin vanhat Macit ovat edelleen käytössä?

 

[user9999]

Onkos tuo swappailu nyt uusikin ongelma vai miten vaikka jotkin vanhat Macit ovat edelleen käytössä?

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

Please read the update at the end of this post. Hi, I have Mac mini m1 256/16 for almost 8 days. After those 8 days I can see 0.9 TB written. From what I found on the web this ssd should last for ~~150 TBW. After 8 days I have 0.9 TBW :) I checked on my MacBook Pro 13" from 2018, 256/16 as...

forums.macrumors.com

 

[iccb]

No laitetaas oma kone kanssa, eli MacBook Pro M1 8GB muistia. Auki Safari n. 20 tabia mail, word, kalenteri, pages, twitter, outlook, discord, whatsapp, viestit ja esikatselu jossa pari pdf tiedostoa.
Nämä ovat suurinpiirtein aina auki koneessa. En varsinaisia hidasteluja ole huomennaut käytössä, toimii jouheasti.

 

[pomk]

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.

Jos se sivutustiedoston käyttäminen on noin hidasta, niin eikö olisi järkevää vaan tallentaa inaktiiviset tabit blobeina levylle?

 

[hkultala]

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, kaikista ohjelmista voi eniten käytetty data pysyä muistissa ja vähemmän käytetty data voidaan sivuttaa ulos levylle. 80386 oli ensimmäinen PC-prossu joka tuki sivupohjaista virtuaalimuistia.

Se, että kokonaisia prosesseja heitettäisiin jatkuvasti levylle ja ladattaisiin sieltä takaisin vasta hirveää turhaa levyliikennettä olisikin.

 

[Ormu]

Tämä on nyt mutupohjainen ja asenteellinen näkemys (ja reippaasti offtopicin puolella), mutta minusta massamuistin (hitaan) käyttäminen minkäänlaisena keskusmuistin jatkeena on järjetöntä, koska suorituskyky kuolee heti, kun sinne massamuistille mennään. Nähty monta kertaa sellaisessa tilanteessa, jossa keskusmuisti loppuu - usein kone on pakko käynnistää uudelleen väkisin. Tähän liittyen on typerää, että ohjelmien annetaan varata enemmän muistia kuin koneessa on oikeasti käytettävissä.

 

[pomk]

Toisekseen, miten määrittelet "inaktiivisen" tabin?

Tabi, joka ei ole vuorovaikutuksessa käyttäjän kanssa.

Ensinnäkin, mitä oikein tarkoitat "blobilla"?

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.

 

[hkultala]

Tabi, joka ei ole vuorovaikutuksessa käyttäjän kanssa.

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.

Tallentaa tabin käyttöön varatut muistialueet sinällään niin yhtenäisinä pätkinä kuin se ylipäänsä on mahdollista.

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

Samaan tapaan kuin mitä vaikka uudessa xboxissa pelin tila tallennetaan levylle.

Vertaat tilanteeseen, jossa ohjelma suljetaan

Tervetuloa 2000-luvulle, nykyisin meillä on oikeissa tietokoneissa moniajo ja hyvä niin.

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.

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) kerrallaan.

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 virtuaalimuistisivu kuin vaikka megatavun verran dataa sen takia, että monta virtuaalimuistisivua ollaan niputettu 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 suurinpirtein 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ä virtuaalimuistisivuja yhteen niin haaskattaisiin ihan älyttömästi 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 sijaan 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.

 

[finWeazel]

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.

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.

 

[Lämpöpumppu]

Oma MacBook Pro M1 16GB. Ei ole muuta auki kuin Safari, jossa 34 aktiivista tabia. Yhdessä tabissa pyörii Twitch striimi.


Tuo 8GB malli voi olla monille liian vähän.

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

 

[zepi]

Tämä on nyt mutupohjainen ja asenteellinen näkemys (ja reippaasti offtopicin puolella), mutta minusta massamuistin (hitaan) käyttäminen minkäänlaisena keskusmuistin jatkeena on järjetöntä, koska suorituskyky kuolee heti, kun sinne massamuistille mennään. Nähty monta kertaa sellaisessa tilanteessa, jossa keskusmuisti loppuu - usein kone on pakko käynnistää uudelleen väkisin. Tähän liittyen on typerää, että ohjelmien annetaan varata enemmän muistia kuin koneessa on oikeasti käytettävissä.

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.

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

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.

 

[user9999]

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.

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 "Core i9" 2.9 15" Touch/2018 Vega Specs (Mid-2018 15" (Touch Bar), BTO/CTO, MacBookPro15,3, A1990, 3215): EveryMac.com

Technical specifications for the MacBook Pro "Core i9" 2.9 15" Touch/2018 Vega. Dates sold, processor type, memory info, hard drive details, price and more.

everymac.com

 

[Ormu]

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.

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.

 

[hkultala]

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 tai bugailisivat 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.

 

[pulatunnus]

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.

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.