Apple Macbook Air med M1 imponerar i första resultat

Permalänk
Medlem
Skrivet av Ortovox:

Skulle jag köpa en riktigt fet/dyr laptop så hade jag garanterat valt en Dell XPS 13, storleken är perfekt och kvaliten ska ju va bra. Hade tagit den hellre än en Mac men det är mest för att jag trivs bättre med Windows än MacOS. Men det låter ju oroande att den blir så varm.

Datorn i sig känns aldrig varm, så chassit fungerar för spridning av värmen. Däremot kan den aldrig hålla sina 4,6GHz vid burst pga hög värmeutveckling, utan lägger sig runt 2,8-3GHz istället vid hård last. Hade jag inte undervoltat processorn, så hade resultatet blivit ännu sämre.

Ville dock visa "energisparläget", då det är så jag använder datorn normat för slösurfning på nätet m.m. Skulle jag hela tiden köra i "Best performance", så är batteriet slut på 4 timmar. Jag vill ha så lång batteritid som möjligt, utan att systemet i sig känns slött. Hade bara "Power management" fungerat ordentligt på Intels CPU:er, så hade jag inte behövt bry mig. ARM är betydligt snabbare på att "väcka upp" processorn.

Permalänk
Medlem
Skrivet av Sidde:

Man bör nog läsa på hur säkerhet fungerar på alla system nuförtiden innan man ens drar slutsatser av det där.

Code signing har alltid ocsp-slagningar till exempel annars kan man inte validera om certet är revokerat. Detta måste köras vid varje gång binären startas för att öht ha en funktion. Applocker i windows är motsvarande.
Din webbläsare gör samma sak för varje https-anslutning du gör också btw.

Validera hash för binärer som körs är samma sak som alla antivirusprogram gör.
Även webbläsare gör detta för sidor och filer. Chrome scannar till och med disken...

Detta är naturligtvis inte kul ur ett privacy-perspektiv men datorsäkerhet och privacy går inte alltid hand i hand. I fallet av säkerhet på klienten så måste man därför välja hos vem man lägger trusten.

Dessa funktioner är heller inte nytt i Big Sur...
Finns i tidigare versioner av OS X, Windows etc.

Även i linux där code signing eller endpoint-skydd används.

TL;DR: De sänder det okryperat

Det var inte att Apple sänder data, Microsoft, Google och alla andra gör det som du nämner, var mer att de enligt blogginlägget (jag har ingen Apple-enhet så jag kan ha fel) skickar datan okrypterad och dessutom mer eller mindre geo-taggar den, har full förståelse att t.ex. anti-virus skickar iväg en hash för att validera en applikation, men varför behövs datan om vilken plats applikationen startades från? Är rätt säker på att Microsoft, Google, Huawei, Dancebyte, Oracle och Lelles Ved och Porr gör liknande saker så det gäller att göra dessa intrång på konsumenters privatliv uppmärksammat.

Visa signatur

kill -s SIGCHLD `pidof Kenny`
bash: Oh my god, they killed Kenny
init: You Bastards

Permalänk
Medlem
Skrivet av houze:

TL;DR: De sänder det okryperat

Det var inte att Apple sänder data, Microsoft, Google och alla andra gör det som du nämner, var mer att de enligt blogginlägget (jag har ingen Apple-enhet så jag kan ha fel) skickar datan okrypterad och dessutom mer eller mindre geo-taggar den, har full förståelse att t.ex. anti-virus skickar iväg en hash för att validera en applikation, men varför behövs datan om vilken plats applikationen startades från? Är rätt säker på att Microsoft, Google, Huawei, Dancebyte, Oracle och Lelles Ved och Porr gör liknande saker så det gäller att göra dessa intrång på konsumenters privatliv uppmärksammat.

Nu får du nog ta och läsa artikeln igen för jag tror du inte riktigt hängde med.
De geotaggar den inte. Artikeln beskriver att med en IP, kan man ta reda på x och y.
Men IPn skickas ju oavsett om det är transportkrypterat eller ej så jag tror du missuppfattat artikeln du läst.

Den validerar att applikationen byggdes av rätt utvecklare, så att ingen har bytt ut binären mot något annat än helt enkelt. Eller någon utger sig från att vara någon annan.
Certifikatet som då finns med i varje applikation ska också valideras att det är giltigt genom tex timestamping och validering av timestamping-certifikatet. Men man validerar också att utgivarens certifikat inte är revokerat, om möjlighet finns, för har du inte internetkontakt kommer den bara strunta i detta.
Detta är normal säkerhet på i princip alla klientplattformar.

Revokeringsfrågan är det som skickas över OCSP. Och den skickar OCSP-frågan okrypterat.
OCSP-serverns adress inklusive protokoll är det som står i certifikatet som tillhör varje applikation.
Det är olika OCSP-servrar för olika certifikatsutgivare.
Det är traditionellt sett HTTP och inte HTTPS som branchstandard.

Det kan tyckas lite förlegat men min magkänsla säger mig att det har med att göra att om man revokerar root-certet eller intermediate-certet så skulle ju även hela OCSP-servern sluta svara eftersom den då inte är giltigt och då får du ju inget svar om att applikationens cert är revokerat. (om de inte tex använder ett annat certifikat från en annan part för just OCSP-servern, men då måste du ju ställa en OCSP-fråga för den, kedjan blir ju oändlig... Men man måste också fråga sig vad är det man ska skydda sig mot, eftersom OCSP-svar ändå är soft fail så får man inget svar är allt bra.)
Men ditt argument med geo-tagg kommer från att man ser source-ip och source-ipt ser du oavsett transportkrypto eller inte.

I detta fall får du fråga dig själv.
Är det bra att Apple har ett antivirusprogram eller inte, om just du anser att du du vill ha din dator helt tyst och ska inte prata med internet. Då får du antingen slå av av processen eller byta OS till ett tyst os som saknar en mängd säkerhetsfunktioner för att stoppa skadlig kod.
Men Apple har, likt andra, tyckt att det är värt att använda ett antivirusprogram, och validera certifikaten enligt x509-standarden.

Edit:
När din dator besöker sweclockers till exempel. Så kan din webbläsare skicka en okrypterad OCSP-fråga till http://ocsp.digicert.com förövrigt för att validera om sweclockers certifikat är revokerat eller inte. Det är alltså helt okrypterat! Däremot används ofta stapling för att minska den typen av slagning. Då är det istället sweclockers som pratar med digicert och lägger in en signatur från ocspn men det förutsätter att sweclockers slagit igång det, och din webbläsare har stöd för det.

Permalänk
Medlem
Skrivet av Oliver91:

Tyvärr och de få spel som funkade för mac innan kommer väl inte funka med den nya arkitekturen nu

Jag funderade starkt på en Macbook Pro innan eftersom jag nästan bara spelar World of Warcraft på min PC nuförtiden men kommer det ARM arkitektur där med i #framtiden kan man ju glömma det.

World of Warcraft har redan stöd för ARM sedan några builds sedan. Från juli verkar det som.
https://www.mmo-champion.com/threads/2557770-Shadowlands-Alph...

Permalänk
Medlem
Skrivet av Raevbur:

World of Warcraft har redan stöd för ARM sedan några builds sedan. Från juli verkar det som.
https://www.mmo-champion.com/threads/2557770-Shadowlands-Alph...

Trevligt, då är dom förberedda för framtiden, hoppas AMD hoppar på ARM istället för x86 så kan vi säga hejdå till Intel i princip.

Visa signatur

R7 5800X3D / RX 6950 XT / 32GB Ram / 1TB SSD / X570 Bräda / 850w Nätagg.
32 Tums Skärm 1440p 144hz Curved VA panel.

Permalänk
Medlem
Skrivet av Sidde:

Nu får du nog ta och läsa artikeln igen för jag tror du inte riktigt hängde med.
De geotaggar den inte. Artikeln beskriver att med en IP, kan man ta reda på x och y.
Men IPn skickas ju oavsett om det är transportkrypterat eller ej så jag tror du missuppfattat artikeln du läst.

Den validerar att applikationen byggdes av rätt utvecklare, så att ingen har bytt ut binären mot något annat än helt enkelt. Eller någon utger sig från att vara någon annan.
Certifikatet som då finns med i varje applikation ska också valideras att det är giltigt genom tex timestamping och validering av timestamping-certifikatet. Men man validerar också att utgivarens certifikat inte är revokerat, om möjlighet finns, för har du inte internetkontakt kommer den bara strunta i detta.
Detta är normal säkerhet på i princip alla klientplattformar.

Revokeringsfrågan är det som skickas över OCSP. Och den skickar OCSP-frågan okrypterat.
OCSP-serverns adress inklusive protokoll är det som står i certifikatet som tillhör varje applikation.
Det är olika OCSP-servrar för olika certifikatsutgivare.
Det är traditionellt sett HTTP och inte HTTPS som branchstandard.

Det kan tyckas lite förlegat men min magkänsla säger mig att det har med att göra att om man revokerar root-certet eller intermediate-certet så skulle ju även hela OCSP-servern sluta svara eftersom den då inte är giltigt och då får du ju inget svar om att applikationens cert är revokerat. (om de inte tex använder ett annat certifikat från en annan part för just OCSP-servern, men då måste du ju ställa en OCSP-fråga för den, kedjan blir ju oändlig... Men man måste också fråga sig vad är det man ska skydda sig mot, eftersom OCSP-svar ändå är soft fail så får man inget svar är allt bra.)
Men ditt argument med geo-tagg kommer från att man ser source-ip och source-ipt ser du oavsett transportkrypto eller inte.

I detta fall får du fråga dig själv.
Är det bra att Apple har ett antivirusprogram eller inte, om just du anser att du du vill ha din dator helt tyst och ska inte prata med internet. Då får du antingen slå av av processen eller byta OS till ett tyst os som saknar en mängd säkerhetsfunktioner för att stoppa skadlig kod.
Men Apple har, likt andra, tyckt att det är värt att använda ett antivirusprogram, och validera certifikaten enligt x509-standarden.

Edit:
När din dator besöker sweclockers till exempel. Så kan din webbläsare skicka en okrypterad OCSP-fråga till http://ocsp.digicert.com förövrigt för att validera om sweclockers certifikat är revokerat eller inte. Det är alltså helt okrypterat! Däremot används ofta stapling för att minska den typen av slagning. Då är det istället sweclockers som pratar med digicert och lägger in en signatur från ocspn men det förutsätter att sweclockers slagit igång det, och din webbläsare har stöd för det.

Jag ser fortfarande inte varför Apple behöver gå förbi VPN och skicka data okrypterat. Behövs ju inte att man validerar cert på OCSP-servern, att köra med ett hemmasnickrat cert mot att köra okrypterat tillför visserligen ingen validering att det är rätt server man pratar med men trafiken blir ändå krypterad så det är ändå bättre.

Och om de inte gick förbi VPN-klienter så skulle IP bli svårt att spåra samt att datan skulle skicka krypterat en bit på vägen iallafall.

Visa signatur

kill -s SIGCHLD `pidof Kenny`
bash: Oh my god, they killed Kenny
init: You Bastards

Permalänk
Medlem
Skrivet av houze:

Jag ser fortfarande inte varför Apple behöver gå förbi VPN och skicka data okrypterat. Behövs ju inte att man validerar cert på OCSP-servern, att köra med ett hemmasnickrat cert mot att köra okrypterat tillför visserligen ingen validering att det är rätt server man pratar med men trafiken blir ändå krypterad så det är ändå bättre.

Och om de inte gick förbi VPN-klienter så skulle IP bli svårt att spåra samt att datan skulle skicka krypterat en bit på vägen iallafall.

Att man går förbi VPN är en helt annan sak.
Apple har gjort flera saker som skapar denna situation och den är uppebart inte medvetet att stänga ute VPN. Det är såklart att de måste fixa det nämligen annars kommer ju inte företag kunna köra OS X.

Apple har stängt av möjligheten att applikationer ska installera kernel extensions själv. Det innebär att VPN och sådant som arbetar på kernelnivå inte kan laddas om man inte gör det manuellt. Se tex: https://www.obdev.at/support/littlesnitch/245913651253917

Apple erbjuder andra APIer för att istället hantera nätverkstrafiken, men dessa APIer är uppenbart inte tillräckliga för att de kan inte se innehållet när en applikation kör sin internataccess via AppProxyProvider från ramverket. Detta måste de fixa på ett eller annat vis som sagt för annars fungerar inte VPN. Detta finns tex lösningar för på iOS redan.

Om du inte förstår varför OCSP-frågan går okrypterat måste du läsa på om Application/Code Signing och OCSP.
OCSP-frågor går i nästan alla usecase okrypterat.
För det är så man gör för att validera certifikatet. Du verkar inte riktigt förstå vad OCSP är eftersom du pratar om hemmasnickrade cert heller men jag tänker inte lägga energi på att förklara ett ganska komplext scenario.

Och du skickar ju faktiskt ditt IP över internet om du pratar över VPN också. Bara så du vet. Din source-adress syns alltid, men i detta fall då till VPN-leverantören enbart isåfall och alla där mellan. Så vem är det du ska skydda dig från, och i vilket use-case är inte så självklart som du verkar tro.

Permalänk
Medlem

Angående en kommentar om Apples SSD prestanda är att lägga märke till att Apple faktiskt uttalat att M1 använder PCIe-4.
Vilket är lite anmärkningsvärt med tanke på att de inte sa ett ljud om t.ex. vilket RAM-minne de använder. Kanske är det en antydan om att SSD-prestandan tagit ett kliv upp. Kräver tester av de olika konfigurationerna. Under normal användning används både RAM kompression av inaktiva data och komprimerad datalagring.

Permalänk
Medlem
Skrivet av EntropyQ3:

Vilket är lite anmärkningsvärt med tanke på att de inte sa ett ljud om t.ex. vilket RAM-minne de använder.

Är inte det en ganska ointressant fråga, då minneskretsarna sitter som på bilden nedan (DRAM i rött):

De minnena sitter på samma krets som allt annat, så antar jag att det är "ruskigt snabbt". Det är väldigt ovanligt att Apple snålar med kvaliteten på sina komponenter och det finns säkert en anledning till att 8GB + 8GB kostar 2500:- jfm med modellen som med min killgissning har 4GB + 4GB kretsar.

Permalänk
Medlem
Skrivet av walkir:

Är inte det en ganska ointressant fråga, då minneskretsarna sitter som på bilden nedan (DRAM i rött):
https://i.imgur.com/KXEe6hV.png

De minnena sitter på samma krets som allt annat, så antar jag att det är "ruskigt snabbt". Det är väldigt ovanligt att Apple snålar med kvaliteten på sina komponenter och det finns säkert en anledning till att 8GB + 8GB kostar 2500:- jfm med modellen som med min killgissning har 4GB + 4GB kretsar.

Um, nej. Apple använder standard mobiltelefon-RAM. Som helhet kostar deras RAM-lösning något mindre än socklat RAM, men skillnaderna är små.
Vad det gäller hastigheten behövs inga killgissningar. Andrei Frumusani på Anandtech har testat A14:s minnessystem, och man kan direkt jämföra med AMD:s nya 5xxx serie. Desktopchippen har lägre latency mot RAM, medan A14 har en kanske strået vassare cache hierarki (AMD:s nya är riktigt bra den också) och M1 har högre absolut bandbredd mot minnet när man tar i beaktande att Apple har 128-bitar bred buss mot minnet (A14 har 64-bitars bredd mot minnet).

När vi däremot jämför med Intels i7-1185G7 (Tiger Lake) som precis som Apple testades med LPDDR4x-4266MHz, så har Intels produkt samma latens ut mot minnet, men sämre on-chip cache prestanda.

Som helhet har M1 lika bra eller bättre minnesprestanda än konsumentprodukterna på x86 sidan. Men det är inga jätteskillnader heller. Vi får se vilka lösningar Apple använder när de skall skala upp från 10W....

Permalänk
Medlem
Skrivet av Yoshman:

Tja vad ska man ha det till?

Då det är en systemkrets med funktioner som alla Apples kommande datorer kommer inkludera samt det redan idag finns standardfunktioner i MacOS/iOS som kan accelereras m.h.a. NEON (SIMD i ARM, 128-bits likt SSE på x86), GPGPU (Metal Compute är minst lika enkelt som CUDA och OneAPI för GPGPU, skillnaden mot de andra två är att alla system som kör MacOS/iOS har stöd) samt NPU (bl.a. bild- och videoredigering använder allt mer AI för att utföra vissa moment).

M1 har en väldigt bra potential att utmana dyrare och betydligt mer effekthungriga PC-system i absolut prestanda runt de saker som kan accelereras av sådant M1-kretsen har integrerat.

Programutveckling är ett annat exempel. Det är ett fall som delvis kan skala riktigt bra med CPU-kärnor, men där det inte finns någon möjlighet att accelerera det hela m.h.a. GPGPU, NPU eller liknande. Det är något som kan vara extremt krävande, och där tyvärr enda sättet att göra saker snabbare är att göra CPU-delen snabbare. För egen del är största flaskhalsen enkeltrådprestanda, i lite mer komplicerade fall blir det väldigt frustrerade att köra "test-driven-development" när tiden att göra ett inkrementellt bygg (köra nytt test eller verifiera en fix) tar ~10s.

10s kanske inte låter så illa, men det är något man helst vill ska hända omedelbart. Tänkt själv hur irriterade det skulle vara att surfa om det tog 10s att hoppa mellan sidor hela tiden...

Har just nu två separata setup. 3900X maskinen används för att bygga hela system från scratch, t.ex. byggtest, systemtest etc. Har sedan en NUC för normal utveckling, detta då denna har bättre perf/kärna mot 3900X maskinen. Jobbar mot båda från en laptop, med M1 kan jag skippa NUC:datorn och köra utvecklingen lokalt med högre prestanda.

Även om många laptops skyltar med ~10 timmars batteritid så är det få som når dit i praktiken, vilket betyder att man inte riktigt har en hel dags batteri. Med 18-20 timmar listad batteritid når man rimligen över 10 timmar även i "riktig" användning, så tror MBA blir prefekt för dessa.

Har kanske lite svårt att se poängen med MBP. Verkar vara rätt liten skillnad i prestanda mellan MBA och MBP, den förra är billigare och lättare vilket normalt är positiva egenskaper för bärbara. Kanske finns någon som gillar MBP "touch bar", för egen del är det något som hållit mig ifrån en ny MBP.

Du är bortskämd med 10s. Här tar länkningen uppåt 6 minuter 🙈

Permalänk
Datavetare
Skrivet av icucode:

Du är bortskämd med 10s. Här tar länkningen uppåt 6 minuter 🙈

Windows?

För med LLVMs länkare körandes på Linux eller MacOS kan man länka clang (C/C++ kompilatorn som bygger på LLVM) på ~10s, vilket med debug-info ger en binär på nära 2 GB. Går också att länka t.ex. Chrome på ~20s.

Oavsett vad det är som tar 6 min, hoppas innerligt att det inte är tiden för att bygga ett unit-test. Var det jag refererade till ovan, och min känsla har tydligen blivit avtrubbad för sanningen var detta...

real 0m17,482s user 0m16,730s sys 0m0,773s

En "unit" här är en enskild C eller C++ fil. Ramverket som används är Google test, vilket i sig använder en hel del templates och mina tester använder både STL, closures och liknande -> inte roliga kompileringstider och som synes ovan är det tyvärr inget som skalar förbi en enda tråd. Är ju bara en enda fil som kompileras, är länkningen som till viss del använder >1 kärna men det är en rätt liten del.

Högre enkeltrådprestanda är det enda som hjälper här, ska bli riktigt kul att testa på M1. Nu är även en monitor på väg. Fick bli en 27" 4k skärm tillslut, ska tydligen bli fint i MacOS om man ställer in det hela för 5k rendering som nedsamplas till 4k.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Windows?

För med LLVMs länkare körandes på Linux eller MacOS kan man länka clang (C/C++ kompilatorn som bygger på LLVM) på ~10s, vilket med debug-info ger en binär på nära 2 GB. Går också att länka t.ex. Chrome på ~20s.

Oavsett vad det är som tar 6 min, hoppas innerligt att det inte är tiden för att bygga ett unit-test. Var det jag refererade till ovan, och min känsla har tydligen blivit avtrubbad för sanningen var detta...

real 0m17,482s user 0m16,730s sys 0m0,773s

En "unit" här är en enskild C eller C++ fil. Ramverket som används är Google test, vilket i sig använder en hel del templates och mina tester använder både STL, closures och liknande -> inte roliga kompileringstider och som synes ovan är det tyvärr inget som skalar förbi en enda tråd. Är ju bara en enda fil som kompileras, är länkningen som till viss del använder >1 kärna men det är en rätt liten del.

Högre enkeltrådprestanda är det enda som hjälper här, ska bli riktigt kul att testa på M1. Nu är även en monitor på väg. Fick bli en 27" 4k skärm tillslut, ska tydligen bli fint i MacOS om man ställer in det hela för 5k rendering som nedsamplas till 4k.

Ja, det är med statisk länkning både på Windows och Linux. Med dynamisk länkning går det snabbare. Det är inte unit test utan applikationen.

Vad blev det för skärm?

Permalänk
Datavetare
Skrivet av icucode:

Ja, det är med statisk länkning både på Windows och Linux. Med dynamisk länkning går det snabbare. Det är inte unit test utan applikationen.

Vad blev det för skärm?

Om länk-tiderna är ett problem borde ni testa länkaren som kommer med Clang/LLVM, den är i många fall en trave heltalsfaktorer snabbare än de flesta andra länkare.

Blev en LG 27UL650. Lite segt att den saknar USB-C, men att gå upp till LG 27UL850 bara för något som jag med hyfsat stor sannolikhet aldrig kommer använda kändes lite onödigt.

Vill gärna att bildkvalitén är "bra", håller inte på med bildbehandling eller videoredigering mer än i absolut undantagsfall så ingen mening att gå på modeller som är superkorrekta i färg. Ska vara en bra skärm att läsa/skriva kod på

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem

Verkar lovande med Rosetta2 (x86 emuleringen), 1313 single-core prestanda (emulerat) i geekbench:
https://www.macrumors.com/2020/11/15/m1-chip-emulating-x86-be...

Vilket då kan jämföras med nuvarande Intel och Ryzen 3xxx single-core prestanda när de kör native x86.

Visa signatur

Apple

Permalänk
Datavetare
Skrivet av Mindfighter:

Verkar lovande med Rosetta2 (x86 emuleringen), 1313 single-core prestanda (emulerat) i geekbench:
https://www.macrumors.com/2020/11/15/m1-chip-emulating-x86-be...

Vilket då kan jämföras med nuvarande Intel och Ryzen 3xxx single-core prestanda när de kör native x86.

Om det där visar sig vara normen, ca 75 % av prestanda hos ARM64 native, blir det den totala förnedringen av Intels sista generation CPUer för Mac: M1, Apples första försök till laptop CPU, är alltså något snabbare när de emulerar x86_64!

Nu är det i.o.f.s. inte helt korrekt, det stämmer när man jämfört mot Skylake och även Ice Lake (då dessa i.o.f.s. har betydligt bättre IPC, men kan inte klockas speciellt högt). Willow Cove når ~1600, fast Apple har så här långt inte använt den modellen.

Oavsett. Det som nog nästan ingen trodde skulle ske verkar ha skett, likt hur övergången från PowerPC till x86 gick relativt smidigt då de saker som ändå behövde emuleras ett tag fungerade rätt bra då x86 modellerna var så pass mycket snabbare. Nu har vi samma situation, men det är x86 som står på "från" sidan denna gång.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Om det där visar sig vara normen, ca 75 % av prestanda hos ARM64 native, blir det den totala förnedringen av Intels sista generation CPUer för Mac: M1, Apples första försök till laptop CPU, är alltså något snabbare när de emulerar x86_64!

Har du hittat något mer runt rosetta2, som du skrev tidigare så verkar den "översätta" programmen vid första körning (därav av microsoft365 tar lång tid att starta första gången).

Varför har ingen tänkt på en sådan lösning tidigare utan istället har man ju alltid fokuserat på att emulera varenda liten bit vid varje exekvering?

Visa signatur

Apple

Permalänk
Datavetare
Skrivet av Mindfighter:

Har du hittat något mer runt rosetta2, som du skrev tidigare så verkar den "översätta" programmen vid första körning (därav av microsoft365 tar lång tid att starta första gången).

Varför har ingen tänkt på en sådan lösning tidigare utan istället har man ju alltid fokuserat på att emulera varenda liten bit vid varje exekvering?

Undrar om inte Microsoft gör något liknande i deras x86 emulering i Windows 10 för ARM64. Delen med att ersätta anrop till systembiliotek med anrop till motsvarande ARM64-native bibliotek är i alla fall något man gör även på Windows.

Då det primärt är ett temporärt plåster vill man inte plöja ned hur mycket resurser som helst. Ska bli intressanta att se hur länge Apple bryr sig om att stödja Rosetta 2. Förra gången släppte man stödet rätt snabbt (10.7 Lion saknade väl Rosetta 1?).

Har inte läst något mer. Förhoppningsvis kommer min MacMini under nästa vecka, då kan man ju testa själv

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Då det primärt är ett temporärt plåster vill man inte plöja ned hur mycket resurser som helst. Ska bli intressanta att se hur länge Apple bryr sig om att stödja Rosetta 2. Förra gången släppte man stödet rätt snabbt (10.7 Lion saknade väl Rosetta 1?).

Rosetta kom med 10.4.4 i januari 2006, de slutade installera rosetta1 i 10.6 som kom augusti 2009, i 10.7 tog de bort stödet helt, juli 2011. Så fem år i alla fall, antar att vi kan förvänta oss nåt liknande denna gång, vilket är fullt rimligt. Har man specifika behov får man köra en äldre OS version då. Inte konstigare än det fortfarande finns företag som snurrar WinNT 4.0.

Visa signatur

Apple

Permalänk
Medlem

Genomgång av vad Apple faktiskt gör vid sin kodsigneringskoll:
https://blog.jacopo.io/en/post/apple-ocsp/

Permalänk
Medlem

Jag har inte sett någon info om hur GPU:n presterar i M1:an, så tänkte dela med mig med ett länkfynd:

https://hothardware.com/news/apple-m1-gpu-for-macs-puts-up-st...

Det verkar som GPU:n presterar likvärdig ett Nvidia GTX 1050 Ti (eGPU). Helt klart imponerande i min bok.

Tror Intel behöver gå tillbaka till ritbordet helt enkelt... Jag syftar på Intel Iris Xe här:
https://in.pcmag.com/sound-cards/137813/intels-iris-xe-graphi...

För er som vill benchmarka själva:
https://gfxbench.com/device.jsp?benchmark=gfx50&did=90754264

Permalänk
Medlem
Skrivet av walkir:

Det verkar som GPU:n presterar likvärdig ett Nvidia GTX 1050 Ti (eGPU). Helt klart imponerande i min bok.

Tror Intel behöver gå tillbaka till ritbordet helt enkelt... Jag syftar på Intel Iris Xe här:
https://in.pcmag.com/sound-cards/137813/intels-iris-xe-graphi...

Är imponerade i valfri bok med tanke på att det är ultrabook kategorin vi pratar om!

Visa signatur

Apple

Permalänk
Medlem

MacBook Pro Cinebench: 1498, 7508. Tror AMD 4800U har högre värden.

Permalänk
Medlem
Skrivet av systra:

MacBook Pro Cinebench: 1498, 7508. Tror AMD 4800U har högre värden.

AMD 4800U har 1235, 10156. Vet dock inte om det är med TDP på 15W eller 25W.
https://www.cpu-monkey.com/en/cpu-amd_ryzen_7_4800u-1142

Hittade en länk ang. Cinebench på MacRumors:
https://www.macrumors.com/2020/11/16/m1-macbook-pro-cinebench...

Min slutsats är att ingen bör kasta ut sina gamla renderingsburkar än i förmån för M1:an
Väntar med spänning på test rörande videoredigering, då det är där jag hoppas på en större vinst för M1.

Själv är jag nyfiken på hur "stabil" M1:an kommer vara under last. Det jag märkt när jag benchmarkat datorer (speciellt laptops) är att de är känsliga för värmeutveckling och presterar sällan på topp. Att benchmarka i en rumstemperatur på 22 grader jfm 30 grader en varm sommardag gör stor skillnad.

Tittar jag på resultatet för AMD 4800U på Geekbench, så är det stor variation i sifforna:
https://browser.geekbench.com/v5/cpu/search?utf8=%E2%9C%93&q=...

Har exempelvis sett Multi-Core värden på allt mellan 3500 till 7500 där! Min egna i7:a är lika "oberäknelig".

Jag går nära nog igenom en checklista för att få bra benchmarks här.

1. CPU-temp på 30 grader - Check
2. Strömsladd inkopplad - Check
3. Undervolt - Check
4. Power mode: Best Performance - Check
5. Säkerställ att datorn står fritt för optimal kylning - Check

Vill helst slippa stegen ovan bara för att få min dator att prestera optimalt.

Permalänk
Medlem
Permalänk
Medlem

Cinebench 23 för både MacBook Pro och Air.
MacBook Pro CineBench 23 ST: 1498
MacBook Pro CineBench 23 MT: 7508
MacBook Air CineBench 23 ST: 1477
MacBook Air CineBench 23 MT: 6304
I praktiken ingen prestandasänkning alls för MBA i ST, och MT klockar ner 6304/7508 = 0.84 => 16% när alla kärnor kör för fullt.
Det är (IMHO) ett kanonbra resultat. Behövs ingen fläkt för att upprätthålla god prestanda ens för evighetsrendreringar. Och vem köper en ultralätt laptop för det?

Permalänk
Medlem
Skrivet av walkir:

1. CPU-temp på 30 grader - Check
2. Strömsladd inkopplad - Check
3. Undervolt - Check
4. Power mode: Best Performance - Check
5. Säkerställ att datorn står fritt för optimal kylning - Check

Vill helst slippa stegen ovan bara för att få min dator att prestera optimalt.

Personen som tog fram dessa resultat för gjorde nog inget av detta utan blev terroriserad av nyfikna twittrare

Vi får se vad det blir när riktiga testare tar fram resultat.

Permalänk
Medlem
Skrivet av walkir:

Min slutsats är att ingen bör kasta ut sina gamla renderingsburkar än i förmån för M1:an
Väntar med spänning på test rörande videoredigering, då det är där jag hoppas på en större vinst för M1.

Själv är jag nyfiken på hur "stabil" M1:an kommer vara under last. Det jag märkt när jag benchmarkat datorer (speciellt laptops) är att de är känsliga för värmeutveckling och presterar sällan på topp. Att benchmarka i en rumstemperatur på 22 grader jfm 30 grader en varm sommardag gör stor skillnad.

Tror samma som dig. Det man ska komma ihåg är ju också att detta är deras "low end"-produkter. Vänta bara tills de lite mer kraftfulla alternativen kommer. Då du

Visa signatur

SPELA: 13900K - Gaming X Trio 4090
LEVA: OnePlus 12 - MacBook Air M2 13"
PLÅTA: Canon C70, R3, 1DX mkII, BMPCC6K
LYSSNA: KRK Rokit RP8 G4, Beyerdynamic DT 1990 PRO
FLYGA: DJI FPV, Avata

Permalänk
Medlem
Skrivet av systra:

MacBook Pro Cinebench: 1498, 7508. Tror AMD 4800U har högre värden.

Och länk för den som vill läsa mer:
https://www.macrumors.com/2020/11/16/m1-macbook-pro-cinebench...

Visa signatur

Apple

Permalänk
Medlem

Sweet!

Väldigt lite berättar om M1 på förpackningen

Hinner dock inte testa så mycket under dagen, blir väl mer till helgen