Frågor om Apples bärbara M1-datorer?

Enklast är väl att använda den som Apple tillhandahåller, den är baserad på LLVM/Clang, en mycket populär och kompetent ....

Och innan någon frågar, anledningen varför jag inte gick med 16-tummaren etc är för att jag inte vill gå x86 nu när Apples ekosystem går mot ARM.

Inga.
Skämt åsido, men det jag vill se är svårtestat och mer känslosaker. Det är en dator som folk bär med sig ofta och den kommer då utsättas för en hel del. Hur bra datorn tål fysisk skador, ja det kostar en slant att utsätta datorn för detta. Och det är bättre att vänta in att JerryRigEverything gör dessa tester.

Annars det stora dilemmat många tänkbara köpare står inför är att det är deras första version av Macbook med Arm. Den är säkert superbra, men om man bara väntar ett år på generation 2. Så hur mycket bättre dator får man ej då?
Så här kan man tänka i all evighet, men från generation 1 till 2 skulle det kunna hända saker. Och frågan jag ställer mig är vad? Kanske bättre GPU del?

Lightroom släpps snart, och Photoshop släpps under Q1 2021. Så inte native fullt ut än, men väntan ser inte ut att bli så värst lång i alla fall. I väntan på det tror jag nog att Rosetta 2-tolkad kod kommer rulla tillräckligt bra för att inte vara ett stort problem.

Stort tack för utförligt svar, om jag använder XCode skulle jag nog helst vilja skriva i Swift, antar att det är Apples huvudspråk för enmansutvecklare.
Min förhoppning var ju att kunna skriva C# på .Net 5...

Jag har inte kompilerat kod i terminalen i macOS. Men borde det inte vara effektivare och snabbare att göra allt i terminalen som i Linux?
Alltså att köra GCC i terminalen. Borde inte det innebära större kontroll? Dvs man kan skicka med flaggor som -mnative -Os -O2 -O3 - mxeon. Samt även flaggor för minneshantering som någon undrade över.
Men Apple vill ju göra allt enklare med appar för allt som XCode!
Men allt ovan kan kanske göras i XCode och LLVM/Clang?

Ja, självklart.
Xcode är ett seriöst IDE, inte en grundläggande leksak. Det är ju bara att gå till inställningarna för projektet och lägga till flaggorna.
Att utveckla stora projekt utan ett IDE är väl någon form av självplågeri? Jag drar gränsen när jag kör IDE vs editor vid kanske 50 rader.

Nu kanske du räknar VSCode och Emacs som IDE, själv ser jag dem som editorer med bra stöd för utökningar. Hanterar projekt med miljontals rader kod i dessa, skulle nog inte vilja göra det från en ren IDE likt Visual Studio eller Eclipse!!!

Det vi kommer se med M1X (?) är fler kärnor och större GPU, men det kommer troligen inte revilutionera prestandan på varje kärna. Inte heller kommer nästa generation göra det antagligen, de är redan på 5nm och har maxat sina stora kärnor och ökat extremt mycket senaste åren, men steget från A13 var minst hittils. Jag tror de börjar närma sig taket nu.

Stora skillnaden om ett år kommer vara mjukvara med bättre stöd

Jag skulle tro " M1x" får lite mer i/o också, t ex stöd för tre skärmar.

Mycket möjligt, men det fungerar ju redan? (2 externa och en intern), men 4 portar lär ju bli minimum igen som på de andra pro-datorerna

Gör det? Jag har läst att Macbook Air/Pro med M1 bara stödjer en extern skärm. Men det kanske inte stämmer.

Stämmer, de stödjer bara en skärm tyvärr. Det går att använda en DisplayLink-hubb men vet inte hur bra det fungerar: https://www.youtube.com/watch?v=gnBIorfD5YU

Har man behov av flera skärmar kanske det är värt att vänta på den fetare modellen som förhoppningsvis inte är alltför långt borta. Eller ta tillfället i akt att motivera ett ultrawide-köp

Kul med så många frågor om intressanta områden! I det avslutande testet ska jag försöka få med så många aspekter som möjligt, men jag kan svara lite kort på vissa av frågorna redan nu, men mer utförlig information landar i testet framöver. Under gårdagskvällen jobbade jag en del från säng och soffa, med datorn placerad i knäet och på täcket – två placeringar som inte alltid är optimala med fläktbestyckade datorer.

Större del av tiden ägnade jag åt skrivande i emulerade Chrome (M1-versionen fungerade inte för min del, pga krasch när jag försöker logga in med Google-kontot. Det kan säkert vara åtgärdat idag), vilket fortfarande kan räknas som en lättare uppgift. Jag blev något förvånad över att datorns botten faktiskt knappt blev ljummen, medan toppen fortsatt kändes sval.

Jag tankade även hem Steam och spelen Two Point Hospital samt CS:GO, delvis eftersom relativt få spel i mitt Steam-bibliotek stöds av Mac OS. Tyvärr ville CS:GO inte fungera, men TPH var inga större problem. Med de förvalda standardinställningarna på 2 560 × 1 600-upplösning och detaljer på medium rullade det på helt klart spelbart, men jag ska givetvis undersöka bildfrekvenser och sådant framöver. Här var däremot temperatursituationen en annan, och delen ovanför processorn blev rejält varm.

Därutöver testade jag en sväng i Photoshop och det kändes ungefär lika responsivt som det brukar på den stationära, men Lightroom och fler bildprojekt ska absolut undersökas! Youtube-video i 4K fungerar galant i både Safari och Chrome, men förstnämnda är märkbart rappare exempelvis på Youtubes startsida, när många miniatyrbilder ska laddas in samtidigt. Chrome har även en tendens att under batterifliken listas som "strömtörstig applikation", något Safari gjorde först när videoströmmen kördes igång. Med lättare arbete i Chrome åtgick dock endast ett fåtal procent av batteriet under ~en timme, den strömtörstiga stämpeln till trots.

Gällande kodmöjligheter ska jag kika lite närmare på det och se vad som kan göras. De kodprojekt jag sysslar med på fritiden och i skolan är främst av enklare karaktär och inget som direkt går att kolla kompileringstid på, men jag återkommer i tråden och/eller testet på denna punkt.

Jag kommer att försöka använda den så mycket som möjligt som primär dator de närmaste veckorna, men det kommer främst handla om skrivarbete i skol- och artikelsammanhang, men även lite programmering och eventuellt 3D-modellering. Den stationära burken kan dock inte ersättas när det kommer till CS-spelande och den större skärmytan, varför jag inte kommer att kunna köra helt uteslutande bärbart under testperioden. Ovan har du några mjuka värden från mina första timmar med datorn, men snabb uppstart och ett ganska trevligt tangentbord är ytterligare två detaljer som jag tänkt på

Då vi diskuterar programmering. Pushar för årets största händelse nu efter vi sett föråkarna i form av Ampere, Ryzen 5000, Apple M1 och Radeon 6000.

🕯️🕯️ Advent of Code 2020 🕯️🕯️

Passa på att lära er ett nytt programspråk, eller bara ha skön julstämning i något nu redan kan.
Kommer sätta mig i XCode och knacka mina första rader i Swift under 24 dagar i december. Perfekt start för mig om MacMini M1 att bli bekanta

Angående VSCode för MacOS/ARM64, det är på ingång och en beta är ute.

Ah, jag tänkte ju primärt på C och C++ då det är vad jag själv primärt använder. Swift är också baserat på LLVM. Det är en annan trevlig egenskap med LLVM: förutom att man kör allt till LLVM-IR vilket förenklar att stödja alla möjliga CPU-arkitekturer via olika LLVM "backends" som producerar x86_64, ARM64, RISC-V eller vad man nu vill köra på fungerar LLVM på liknande sätt i "front-end".

C++, Swift, Rust, m.fl. är alla olika "front-ends" som tar något programspråk och spottar ur sig LLVM-IR. Är därför LLVM är så trevligt för GPUer: man tar shaders och spottar ur sig en GPU-oberoende binärrepresentation som skickas med i applikationen som sedan via en LLVM-backend konverteras till den specifika GPU du vill köra på.

Gällnade .Net, har inte någon större koll på det längre. Antar att du menar .net-core. Givet att det redan finns .net-core stöd för ARM64 på Linux borde rimligen ARM64 stöd på MacOS inte vara långt borta.

Man har egentligen samma möjligheter att styra flaggorna även om man jobbar i en IDE.

Kommer testa på XCode, primärt för Swift. Lär fortsätta köra VSCode för JavaScript, TypeScript, Rust och Go.

Är inte lika övertygad om att jag överger Emacs som primär editor för C++, men det har mer att göra med att jag genom åren mejslat ut min .emacs så det är väldigt effektivt att göra saker som är rätt specifikt för mitt arbetsflöde. Har framförallt rätt mycket automatisering kring att debugga komplexa system.

Nu kanske du räknar VSCode och Emacs som IDE, själv ser jag dem som editorer med bra stöd för utökningar. Hanterar projekt med miljontals rader kod i dessa, skulle nog inte vilja göra det från en ren IDE likt Visual Studio eller Eclipse!!!

Gällande kodmöjligheter ska jag kika lite närmare på det och se vad som kan göras. De kodprojekt jag sysslar med på fritiden och i skolan är främst av enklare karaktär och inget som direkt går att kolla kompileringstid på, men jag återkommer i tråden och/eller testet på denna punkt.

Måste hitta en vettigare mus, kör faktiskt med trackpad på laptop.