14 MBP M1 har också 120hz.
Du har helt rätt, var helt säker på att inte så var fallet men måste ha blandat ihop det med M1 MBA (har en sådan privat).
Från min M1 Pro
Då är det ännu en fördel, även om den kanske inte är superstor för om man mest programmerar (har uppenbarligen inte ens reflektera över att det är 120 Hz, min externa skärm är definitivt 4K 60 Hz och den används ofta tillsammans med denna).
Tycker inte det är något självklart val, så kommer ned till vad du prioriterar.
M1 Pro har snabbare GPU. Finns inte jättemycket spel till Mac, om man inte räknar Apple Arcade, men M1 Pro hanterar spel förvånansvärt väl (har själv en 16" MBP M1 Pro som jobb-laptop).
Du nämner också AI. Vissa (men långt ifrån alla) AI-fall vill ha mycket brandbredd mot RAM, för sådana fall kommer M1 Pro vara bättre än M3.
Men det är alltid väldigt trevligt att ha så mycket CPU-kraft man kan få vid programmering, framförallt är ST-prestanda guld för snabba iterationer. M3 kommer vara 25-30 % snabbare, ungefär samma fördel M1 Pro lär ha sett till GPU. Nu är Golang guld i hur otroligt snabbt det kompilerar, är helt OK-ish att jobba med på hyfsat enkla CPUer...
Båda har lysande skärmar, men 14" MBP är vassare. 120 Hz panelen kom med MBP M2, så det är inte en fördel för M1 Pro.
M3 MBA kan drivar två externa skärmar, något M1/M2 inte var kapabel till. M1 Pro kan driva totalt 3 skärmar, två externa och den interna (M3 kan driva en andra extern skärm eller den interna skärmen).
Personligen hade jag nog valt M3 MBA mellan dessa två, men vill du köra lite tyngre spel är M1 Pro det bättre valet...
https://www.youtube.com/watch?v=8FrNBsXtrsA
Tiden för högresterande ARM processorer är redan här. Det som framförallt hållit emot är att det vanligaste operativsystemet för desktop (windows) inte varit kompatibelt.
Som apple och microsoft visat så kan övergång skötas i mångt och mycket med kompabilitetslager som översätter x86-x64 till ARM64. De krävande applikationer där ett sådant kompabilitetslager kommer utvecklarna med all sannolikhet kompilera om sina program för ARM64, så som skett på OSX. Sedan finns det säker otaliga legacy program som inte kommer kompileras om för ARM64, men det kommer nog knappast märkas för den som använder dem då de oftare är mindre lättdrivna program.
Det finns ingen anledning att göra en hybrid CPU med både x86-x64 och ARM64, ARM64 kommer snart nog var bra nog för 99% av oss.
Mobile: ARM64
Server: ARM64
Laptop: ARM64 inom 3 år är min gissning
Desktop: ARM64 inom 6 år är min gissning
Att M-serien kretsarna presterar så brutalt bra i kompilering ställt mot x86 verkar upprepas med Snapdragon X Elite.
Så om inte annat borde denna CPU-plattform kunna bli för utvecklare vad M-serien kretsarna redan är om man är OK med MacOS.
Från videon du länkar
Sen verkar de ju ge en vink om att det är möjligt att kombinera denna plattform med en dGPU. Nvidias GPUer stödjer sedan tidigare ARM64, så borde kunna vara möjligt att stoppa in en Nvidia GPU om målet är mer "gaming laptop".
Den integrerade GPUn från Qualcomm verkar stå sig riktigt bra mot Intels och AMDs iGPUer, men man är rätt långt efter Apple.
Det enda trista är att jag misstänker ett de snarare kommer plocka andelar från AMD och inte Nvidia.
Initialt lär nog bli så. Potentiellt finns ändå en chans för Intel att plocka från Nvidia längre fram då man redan från start satsat väldigt medvetet på ett brett stöd av programvara för sina GPUer via OneAPI.
Utanför spel dominerar totalt Nvidia just p.g.a. överlägset programvarustöd, inte p.g.a. att man skulle ha någon gigantiskt ledning i HW-prestanda.
Intel var redan stora på liknande typ av bibliotek via deras Math Kernel Library (MKL) och en av sakerna OneAPI gör att är utöka stödet för MKL till FPGA, GPU och liknande acceleratorer.
Om det nu handlar om fördubblad prestanda skulle en efterföljare till A770 hamna runt RTX4070Ti-ish prestanda. Är nog tillräckligt för att ha något att komma med.
Såg denna nyhet ZenHammer comes down on AMD Zen 2 and 3 systems vilket i sig inte är superintressant, utan visar bara det uppenbara: att många sårbarheter initialt bara fungerade på Intel handla nästan uteslutande på att man lade långt mer resurser där vilket nu ändrats med ökande AMD-marknadsandel.
Denna del är den mer intressanta (står i slutet av artikeln), och tyvärr lite trista nyheten då man hoppas att DDR5 skulle vara skyddad mot Rowhammer
"They also note that for the first time they've demonstrated bit flips on a DDR5 device, an AMD Zen 4 system (Ryzen 7 7700X). While their success was limited – only 1 in 10 DDR5 devices succumbed due to improvements like on-die error correction code (ECC), and a higher 32 ms refresh rate – they anticipate that their findings "will make it easier to port Rowhammer attacks to newer platforms in the future, such as DDR5 devices.""
Rowhammer är otrevlig då
"Rowhammer began as a local attack – you had to have access to the target machine, meaning it was mainly an issue in scenarios involving a threat actor operating within a cloud service provider. But variations have since been demonstrated on smartphones, in web browsers, across VMs, and over the network."
Varför?
Smartare att köra Arm rakt av, finns ARM designer som har likvärdig IPC som moderna x86/x64 arkitekturer.
Om man med "IPC" menar "prestanda vid en specifik frekvens" (vilket jag tror avses här) så är det inte bara likvärdigt: ARM64 är långt före Intels/AMDs senaste x86_64 modeller.
Apples M3 har samma absoluta prestanda som Raptor Cove / Zen4, men M3 kör bara i strax över 4 GHz medan de senare ligger vid eller strax under 6 GHz.
Satte ihop denna för en tid sedan, Snapdragon X Elite ("Oryon") siffrorna var från de läckta resultat som fanns i januari. Oryon kommer vara snabbare än Arm Cortex X4 då den förra verkar gå att klocka till 4,2-4,3 GHz medan Cortex X4 verkar max:a någonstans runt 3,5 GHz.
https://cdn.sweclockers.com/forum/bild/21544?l=eyJyZXNvdXJjZSI6I...
Det som gör att ARM64 är framtiden är just att de tekniska fördelarna i den ISAn verkar motsvara 2-3 tillverkningsnoder över x86_64. Ju dyrare och långsammare det blir att ta fram nya noder, ju viktigare kommer en sådan fördel bli.
Frågetecknet är kanske hur bra/dålig x86 kommer vara när Intel får ut sin APX. APX är en rejäl förändring av x86 ISA, skulle hävda den största förändringen som någonsin gjorts.
Fördelen med APX är att dessa CPUer kommer fortfarande kunna köra dagens x86 program rakt av.
Problemet med APX är dock flera. En är att de första modellerna med tekniken verkar komma först 2025. Nästa är att APX ger bara en fördel om applikationer kompileras om med APX, varför inte bara kompilera om till ARM64 i så fall?
Och även om det blir en klar förbättring är det högst osannolikt att det blir fullt lika bra som ARM64 ändå. I Arm fallet visade det sig att fanns nackdelar att behålla stödet för 32-bit Arm (som är en helt annan ISA jämfört med ARM64). Apple var först att släppa stödet för 32-bit Arm, i samband med det blev deras CPUer snabbare. Vi såg sen samma för Arm, två senaste generationerna av Cortex X är ARM64 only och tog ett klart steg upp i prestanda.
Förutsätter att Snapdrag X Elite också är ARM64 only, Windows på Arm är numera likställt med Windows på ARM64 (Windows RT var däremot 32-bit Arm, vilket var rätt märklig timing givet att Windows för x86 då redan hade börjat lämna 32-bit).
Jag tror det viktigaste här är kompileraren, dvs. den mjukvara som översätter din programkod (alltså om du t.ex. programmerar i C-Sharp. C++. Python etc.) till Maskinkod.
Arm har alltid varit en form ut av RISC processor (som står för Reduced Instruction Set Computer), ARM är en Advanced Risc Machine som är en form av RISC. Dom har blivit mera och mera utvecklade och avancerade över tid, och kan absolut vara ett alternativ till t.ex. Intel och Amd's x86 arkitektur, men då RISC styrka har legat i att vara snabba o effektiva med vissa instruktioner, så är därför arkitekturen mycket annorlunda än en x86 processor, man kan säga att x86 har flera och kraftfullare kommandon som Mikroprocessor, men det går långsammare, medan en RISC processor har mindre kommandon men kan utföra dom snabbare.
Detta kräver egen kod för RISC arkitekturen, och om man vil t.ex. programmera i C-Sharp (C#) så går det utmärkt att kompilera för båda arkitekturer.
TL:DR; det kommer mycket mera an på programmeringsmiljön, alltså att det finns en översättare (Compiler!) som översätter till ARM Maskinkod (RISC) såväl som x86 Maskinkod smärtfritt och effektivt. Och att det finns ARM spelmotorer som också finns till x86 arkitekturen.
Historiskt var det helt klart så att samma program kompilerad till x86 tog mindre plats och innehåll färre instruktioner jämfört med t.ex. samma program kompilerad till MIPS eller SPARC.
Arm har alltid varit en uddafågel här. En fördel med 32-bitars Arm är att den tenderar leda till väldigt kompakt binär, ofta mindre än x86.
Problemet med 32-bit Arm ISA är att dessa "smarta" finesser visade sig sätta rätt många käppar i hjulen om man försökte skala upp en Arm-baserad mikroarkitektur till att bli väldigt superskalär. Så ARM64 och 32-bit Arm ISA skiljer sig rätt kraftigt på en rad områden.
Det som är "killer feature" för både ARM64 och även RISC-V är att de har designats mot bakgrund av att "ingen längre skriver assembler", allt går via en kompilator, JIT eller liknande. Man har fokuserat på att ha de instruktioner som passar bäst för en kompilator, något som gör att samma program tenderar bestå av färre ARM64 instruktioner än x86_64 instruktioner trots att den förra är "RISC".
Vilket i sig lite visar hur poänglös RISC/CISC separationen är idag, handlar mer om "load-store design" eller ej där den förra bara accepterar register som argument till instruktioner som utför något form av beräkning. De flesta, men inte alla RISC är "load-store designs" inklusive 32-bit Arm och ARM64.
Är man intresserad att testa lite är compiler explorer en lysande resurs. Där kan man jämföra kodsnuttar och se vad de kompilerar till på olika ISA.
Tar jag ett av de Go-program jag testade ovan består det av 208k instruktioner på x86_64 medan det är 171k instruktioner för ARM64 och 160k instruktioner för 32-bit Arm (alla kompileras då för Linux som OS).
Som framkommer i kommentarerna verkar CPU delen av körningen av spel inte vara något sörre problem. Men hur är det med GPU delen? Hur bra är Adreno på att köra Directx 12?. Som ett mobilt 3050?
Tror inte man ska förvänta sig en "gaming laptop"... De resultat som läck från lite olika benchmarks pekar på att denna kommer ligga någonstans mellan GPU i M3 och M3 Pro. För att sätta dessa i relation till något ligger M3 i nivå eller strax över AMDs 780M.
Så om Qualcomm vill bli relevanta som spelplattform behöver de längre fram släppa något med betydligt mer GPU-kraft. I ett första steg lär det vara långt viktigare att visa att det faktiskt fungerar.
Den här artikeln nämner "snabbare än M2", men Qualcomm har efter lansering av M3 också sagt, "snabbare än M3" (fast möjligen menar man där bara i MT ställt mot vanliga M3).
Om Snapdragon X Elite presterar på den nivå Qualcomm hävdar är ändå det viktigaste denna plattform tillför en CPU-design för bärbara som fixar lika CPU-tunga saker som Apple Silicon bärbara.
D.v.s. man kan få x86-desktop-klass-prestanda i en bärbar (så bättre än alla x86-baserad laptops utanför de "släpbara desktop-replacement modellerna på >3-4kg") som fortfarande är kompakt och inte försöker rymma från sin plats när fläktarna körs på maxfart. Det samtidigt som "det går att spela vissa spel, men glöm AAA-titlar i någon form av relevant kvalitétsnivå".
I presentationen kallas det tydligt emulation upprepade gånger, men i denna tråd påstås det vara översättning och inte emulering det handlar om. Om det stämmer har Qualcomm inte koll på terminologin runt sitt eget arbete, inte ens The Verge som skrev originalartikeln har noterat detta.
"Emulera" är ett exempel på ord vars betydelse är så överlagrat att det blir lite poänglöst att använda termen.
Processen att kunna köra en ISA på en annan ISA kallas normalt "CPU emulering" eller "CPU simulering". Så ur den aspekten är det en form av emulering.
Precis som @klein skriver betyder ofta "emulering" att man måste göra något som tappar rätt mycket prestanda. Är specifikt här jag tror det är väldigt viktigt att särskilja det man typiskt menar med "emulering" från vad som faktiskt görs här.
Det som Rosetta 2 och Windows motsvarighet gör har långt mer gemensamt med just-in-time kompilering som Java, C#, m.fl. använder sig av för att kunna köra en virtuell maskinkod (intermediate representation, IR) på alla ISA som tekniken har en implementation för. I detta fall råkar IR-dialekten vara x86_64 kod!
Viktigast i kontext av spel är denna del av The Verge texten
"And while Qualcomm sees some slight hit to CPU performance when it’s translating or transitioning between x64 and ARM64, it only happens the first time a block of code gets translated — “subsequent passes are direct cache access,” Khalil says."
D.v.s. väldigt likt hur JVM/CLR kör kod och tror inte speciellt många anser att dessa tekniker leder till hopplöst långsam kod. Det betyder också att när väl översättningen är gjort, handlar det inte längre om "emulering" då man kör en ARM64 binär från cache.
Det är en kostnad att göra detta, resultatet blir bättre optimerat om man kompilerar direkt till ARM64 jämfört med att ta källkoden->x86_64->LLVM IR->ARM64 (vilket är vägen jag förstått både Rosetta 2 och Windows motsvarighet använder).
Testade några av mina egna Go-program. Go är väldigt trevligt för att testa detta då man enkelt kan välja vilket OS/CPU resultatet ska kompileras för.
Skillnaden mellan darwin/arm64 (i.e. MacOS native) och darwin/amd64 är att den senare kör på ~80 % av den förra.
Motsvarande med windows/arm64 och windows/amd64 i Windows 11 under parallels desktop ger att den senare kör på ~75 % av den förra. Så redan nu verkar Microsofts teknik vara väldigt nära Rosetta 2 i prestanda.
Och med 75-80 % effektivitet är min M3 Max lika snabb eller snabbare än min jobb-desktop med 5950X på att köra x86_64 (vilket i sig är helt galet), så kostnaden för "emulering" är inte alls jämförbar med den "order of magnitude" kostnad man brukar associera med emulering. Men ändå, det är egentligen inte fel att kalla det emulering men man ska nog ändå låta bli att göra det då det ger helt fel idé om vad tekniken är kapabel till.
Ovanpå det: specifikt för spel tenderar den effektiva kostnaden bli ännu mindre då OS-kärna, vilket inkluderar GPU-drivare, kommer köra "native" även om spelet är x86_64. Ett spel som är primärt GPU-bundet kommer då har det mesta av den CPU-kritiska delen som "native-kod".
För just spel fungerar Rosetta 2 väldigt bra. För andra saker fungerar det OK, och för vissa direkt uselt (kompilatorer och liknande som är relativt kortlivade processer som är kraftigt CPU-bundna).
DMPS tillsammans med OoO ger högre prestanda ja, men du kan skapa en OoO CPU helt utan spekulativ exekvering och du kan skapa en spekulativ CPU helt utan OoO.
OoO innebär enbart att CPU:n kan sortera om loads och stores utifrån vad som den ser som den bästa ordningen oavsett vad du som programmerare har skrivit i koden. Spekulativ exekvering är att CPU:n exekverar kod innan den vet om ifall den verkligen skall exekvera den koden eller ej.
T.ex så är och var ARM väldigt OoO medan x86 är och väldigt lite OoO (x86 är enbart OoO under väldigt specifika situationer vilket gör att många som skriver låsfria algoritmer under x86 plötsligt ser dem crash and burn på en ARM) men x86 är sedan en tid extremt spekulativ, främst vid branch-prediction eftersom branchning är så extremt kostsamt på en x86 då den har så djup pipeline.
OoO och spekulativ exekvering är två helt separata saker. Vad de är är två olika sätt att försöka hålla hela pipelinen upptagen med att exekvera data.
Du har helt rätt i att spekulativ körning och OoO är två ortogonala koncept.
Fattar inte denna sårbarhet tillräckligt i detalj, men i flera andra fall och specifikt i Spectre är både spekulativ körning och OoO ett krav för att trigga problemet.
Så egentligen ska man säga både OoO och spekulativ körning. Men i praktiken är OoO meningslöst utan spekulativ körning, så det senare är underförstått och många av de här buggarna kommer av kombinationen av dessa två.
Enda OoO CPU jag kunde hitta som inte också har spekulativ körning är den första CPU som använde Tomasulos algoritm på mitten av 1960-talet. OoO började användas först på 90-talet i någon större utsträckning, det efter att in-order designer redan börjat med spekulativ körning.
För in-order designer finns varianter både med och utan spekulativ körning. När Spectre presterandes var ett frågetecken huruvida Arms moderna in-order designer, som har spekulativ körning, var påverkade. De är inte påverkade, däremot är Arms OoO designer påverkade precis som alla moderna OoO designer (som alla också använder spekulativ körning).
Så åter igen: du har rätt att det är separata koncept, men i praktiken betyder "djupare OoO" också både mer och fler varianter av spekulativ körning. Utan det senare vore det helt hopplöst att utnyttja potentialen hos OoO, speciellt i en design som Apple Silicon som både är extremt "bred" och har ett enormt "out-of-order" fönster att utnyttja.
Edit: och bara för att understryka hur komplext det hela är om man försöker få med alla detaljer är detta ett bra exempel
"x86 är enbart OoO under väldigt specifika situationer vilket gör att många som skriver låsfria algoritmer under x86 plötsligt ser dem crash and burn på en ARM"
Detta har varken med spekulativ körning eller OoO att göra. Det har att göra med minneskonsistensmodell.
x86 implementerar en modell som kallas Total Store Order (TSO) medan Arm (likt de flesta RISC:ar, men inte alla, använder en betydligt mer "relaxed" modell).
Om tråd A skriver till minnescell A och sedan till B (i program order), det utan explicita barriärer, och en annan tråd sedan läser B och får det nya värdet garanterar TSO att om man då läser A från den tråden kommer man få det nya värdet. På Arm kan man även i det fallet potentiellt läsa det gamla värdet på A i frånvara av explicita barriärer.
Finns bibliotek som medvetet utnyttja TSO, inte helt oväntat finns prestandakritiska bibliotek från Intel som gör detta. Att korrekt översätta det till ARM64 blir inte effektivt om CPUn inte har möjlighet att aktivera TSO (vilket Apple Silicon verkar göra när den kör i kontext av Rosetta 2).
Mer vanligt är nog att det egentligen är race-condition buggar som råkar fungera alt. gör race-bugg:en tillräckligt osannolik när man kör på TSO. På en CPU med en mer relaxed konsistensmodell smäller det istället direkt...
Jag fattar absolut, har många timmar både med Mac OS/iOS och andra OS ( inte valfritt dock ) och kan bara se fördelar och absolut noll nackdelar med en öppen plattform oavsett vad du eller någon använder tycker om just det.
Och om plattformen skulle öppnas upp så skulle allt det som finns idag finnas kvar, utöver allt extra man får, win-win för slutkunden, ser inte problemet med den lösningen, bara fördelar.
När du ändå tar upp Microsoft så kan jag installera och spela/köra vad jag vill på deras plattform utan att de tar ett öre för det, förutom det jag betalade för licensen, hur coolt är det... Nej just det, det är sunt förnuft förutom på vissa plattformar.
Klart som fan behovet för öppenhet finns, bara på företagsmarknaden så skulle det öppna upp hur mycket möjligheter som helst till skillnad från idag där man får köra med workarounds eller betala Apple extra för att ta total ägarskap av dina enheter.
Fast det här lär väl ändå bara vara ett problem på iOS. För hur menar du att MacOS på något sätt är begränsat, framförallt när ditt jämförande exempel är
"När du ändå tar upp Microsoft så kan jag installera och spela/köra vad jag vill på deras plattform utan att de tar ett öre för det, förutom det jag betalade för licensen, hur coolt är det..."
Man kan välja att köpa från App-store, där tar Apple 15 % eller 30 % lite beroende på vad det handlar om. Men går även att använda Homebrew eller bara ladda ned program från internet.
Sannolikheten att få in "skit" på sin dator lär var långt större med sista alternativet, men man har ändå valet.
I fallet iOS är jag själv lite mer kluven. Har svårt att se hur dess nedlåsthet inte kan vara en viktig komponent dess relativt höga säkerhet. Det är inte den enda komponenten, men det en av flera viktiga komponenter.
Hade MacOS vara lika nedlåst som iOS hade det inte funnits på kartan att använda det för egen del. Använder Homebrew väldigt mycket, fast uppskattar också AppStore (kör Apple Arcade och köpt flertalet spel/program i AppStore).
För iOS är kravet på AppStore för mig ett icke-problem. Hellre högre säkerhet än massa alternativa sätt att installera program.
Om det går att kombinera öppenhet med samma säkerhet, good-guys EU/USA. Men är skeptisk då det ingen annanstans är gratis att erbjuda fler möjligheter med bibehållen kvalité. Ett uppenbart sätt att ge en rejält välpolerad produkt är att kraftigt begränsa vad som produkten innefattar, ett annat är att slänga långt mer resurser på problemet.
Risken finns att detta blir ett fall av "be careful what you wish for you might just get it". Hoppas ändå på det bästa och skiter det sig helt finns ju alternativ.
Har inte Intel lovat att stämma skiten ur dem om de använder x86-delen av AMD64 utan x86-licens?
Visade det sig att det inte var juridiskt möjligt?
Hade någon av ARM64 tillverkarna lagt in möjlighet att direkt avkoda och köra x86-kod hade vi med 100 % säkerhet sett en stämning.
Det både Microsoft och Apple gör är samma sak: man översätter x86_64 koden till ekvivalent ARM64 kod, det som sedan körs är ARM64 instruktioner. Detta är långt mer effektivt jämfört med emulering och undviker patentproblematik då ingen x86_64 baserad teknik behöver läggas in i CPUn
Det enda Apple lagt in i "Apple Silicon" och som jag tror vi kan förutsätta Qualcomm kommer lägga in i Snapdragon X Elite (givet att det är samma person som är arkitekt bakom båda designerna) är stöd för minneskonsistens-modellen i x86, TSO.
TSO är mindre effektiv jämfört med modellen ARM64 normalt använder, så det används bara när man kör översatt x86_64 kod. Men är mer effektivt att implementera TSO i HW jämfört med att implementera det med ARM64 instruktioner. TSO är en välkänd teknik som används sedan länge och används av långt fler än x86.
Tror att det Qualcomm säger här kan stämma bra även i verkligheten. Kör ARM64 versionen av Windows 11 (på en M3 Max via Parallels desktop), blivit positivt överraskad hur bra Windows motsvarighet till MacOS "Rosetta 2" fungerar.
Just spel tenderar vara rätt kraftigt GPU-bundna, framförallt med så snabb CPU som Snapdragon X Elite kommer vara kopplat med en iGPU. Krävs typ 4090 i 1920x1080 eller ibland även 1280x720 för att man ska vara speciellt CPU-bunden med moderna Intel/AMD CPUer, så den 10-30 % prestandaförlust man får av att köra binäröversatt spelkod lär vara försumbar.
Finns ändå klara vinster om spel skrivs om till "native" ARM64. Dels drar då CPUn mindre effekt då koden är mer optimal. Dels tar det en del tid att göra binäröversättning, något man noterar som rätt långa laddningstider hos program som körs via Rosetta 2 eller motsvarande i Windows.
Nu kan jag för lite om effektiviteten i elmotorer, men det som skulle uppskattas av mig är längre räckvidd och mindre effekt.
Varför ska en elbil behöva göra 0-100 på under 4s?
Kan man inte göra en mindre motor, som drar mindre el, och därmed kommer längre på samma batteripack?
En ICE-motor har typiskt sin maximala effektivitet vid ~70 % av peak-effekt. Den typ av elmotorer som används i elbilar har tydligen (fick läsa på om det, har dålig koll på tekniken här...) sin topp vid ~30 % av peak-effekt.
Så ur den anledning finns en poäng att använda rätt kraftiga elmotorer, framförallt blir regenerering mer effektiv med större motorer då det oftare handlar om större effekt vid inbromsning (om man nu inte kör som om man befinner sig på LeMans...).
Det kanske delvis förklarar varför man ser så många elbilar med ICE-mått mätt galet många hästkrafter. Men känns ändå rätt suboptimalt att normalkonfiguration ska ha så hög effekt. Uppenbarligen är det dåligt för säkerheten, elbilar är iblandade i betydligt mer olyckor.
Precis som den amerikanska undersökning jag länkade ovan har liknande slutsats gjorts i Schweiz
"Electric cars cause around 50 % more collisions with self-inflicted damage on the road than conventional passenger cars, and the high-performance ones even more than twice as many."
"The risk here is not in reducing speed, but rather in accelerating. The so-called overtapping effect is often underestimated. Electric cars have a very high torque, which is immediately noticeable when the pedal is pressed, so that there is often unintended and jerky acceleration that is no longer controllable. This effect is likely to be the cause of increased damage frequency, among other things. In an initial crash in which a Tesla driver supposedly presses the pedal only briefly and loses control due to the strong acceleration. As a result of the rollover and the impact, there is sever damage to the underbody of the car, which brings up the next topic: the underbody."
Hur mycket effekt man kan få ut är långt mer en effekt av storleken på batteriet än något annat. Sen behöver saker som hjulupphängning, däck, bromsar, etc dimensionernas efter peak-effekt. Även där är det galet att ha massor med effekt som förval, det kräver dyrare bromsar och däckdimensioner som ger högre pris och sämre räckvidd.
Fördelen med elbilar är att man rätt enkelt kan begränsa effekten och än mer effekt-kurvan med programvara. Tror/hoppas man framåt kommer kunna något över de enklaste modellerna utan att automatiskt få 400-500 hp på köpet.
Massor med hästkrafter kan absolut vara kul, i rätt bil och när man själv valt att ta kostnaden det medför i försäkring, reservdelar, etc. Men känns bara korkat att trycka in "svensson-åk" bara för att det går, statistiken ovan visar att det inte heller gynnar säkerheten på vägarna.
Om Intel också har DMP varför har de inte lika bra prestanda per W som Apple?
Just nu har Apple bättre prestanda totalt sett i många fall. Det är tillräckligt jämnt mellan Apple, Intel och AMD för att det ska finnas specifika fall där någon av dessa hamnar högst.
Varför Intel/AMD inte har i närheten lika bra perf/W beror primärt på att Apple (och även Cortex X serien från Arm) har långt högre prestanda vid en specifik frekvens. Effekten ökar linjärt med frekvens och kvadratiskt med spänning, högre frekvens betyder i praktiken högre spänning om alla kretsar är jämförbara sett till tillverkningsprocess.
Blir då väldigt stor skillnad på två CPU-modeller där en kör ~4 GHz och den andra ~6 GHz för att nå samma absoluta prestanda.
Sen varför det är så är en mix av väldigt många parametrar. Givet hur extremt nära Intel och AMD presterar, trots att de ändå har flera rätt stora skillnader i mikroarkitektur pekar mot att dessa två har en gemensam flaskhals. ISA ansågs länge vara rätt irrelevant för prestanda, vilket nog också stämde så länge mikroarkitekturer var 2-4 wide och högre prestanda primärt kom från högre frekvens.
När man började skala på bredden verkar det som det rätt snabbt tog stopp. Var därför initialt helt obegripligt hur Iphones kunder prestera så brutalt bra i många benchmarks, initiala antagandet från de flesta var: det är något fel på testerna som råkar gynna Iphone. Var väl egentligen vid release av M1 som poletten trillade ned att Apple måste ha lyckats med något ingen annan lyckats med tidigare.
Lite kanske poletten trillat ned för de som jobbade med både 32-bit Arm och ARM64, även på RPi3/RPi4 är det inte ovanligt att se 20-30 % högre prestanda i samma program bara man kompilerar om det från 32-bit Arm till ARM64. P.g.a. av designen hos 32-bit Arm är det svårt att bygga vettiga "breda" mikroarkitekturer som stödjer den ISA, Apple var först att släppa 32-bit Arm och enbart stödja ARM64. Senaste generationerna ARM Cortex A/X stödjer inte heller 32-bit ISA, och i samband med det blev även Cortex X en väldigt bred design.
Intel verkar hålla med kring ISA. Deras kommande APX (finns indikation på att första modellerna kommer 2025) kommer bli den största förändringen av ISA hos x86 någonsin. Svårt att säga hur bra/dåligt det kommer bli innan det finns på marknaden, men på en hög nivå är det rätt mycket ARM64 portat till x86_64... Så är själv inte jättesugen på en ny x86_64 CPU innan den har APX.
Men det finns fler saker än DMP och ISA. Bl.a. har Apples CPUer ett out-of-order fönster som är så stort att många inte riktigt får ihop hur de lyckats med en sådan design. För att bara skala upp en Intel/AMD design till den nivån skulle ge galen transistorbudget.
Givet hur knöligt det kan vara med drivrutiner för Nvidia för Desktop korten hade jag inte vågat köpa en laptop med Nvidia GPU för att jobba i Linux med GPU stöd på den.
Nu kan jag absolut tänka mig att det blir strul på en laptop, men det primärt p.g.a. dual-GPU, inte för att det är en Nvidia GPU (vare sig Nvidias eller AMDs drivare är garanterade att fungera i dual-GPU setup på Linux, inte koll på hur det är med Intel iGPU/Intel dGPU kombo).
Har lite svårt att förstå vad folk generellt har för problem med Nvidia GPUer i Linux givet att Nvidia ger officiellt stöd för Linux med deras drivers och det är just Linux man kör i datacenter. Det man får ha lite koll på är att välja en av de ~5 distro som har officiellt stöd om man sätter stabilitet i topp. Kör själva i praktiken alltid Ubuntu, där stöds aktuella LTS-versioner av Nvidia.
Skulle säga att tvärtom är det Nvidia GPU som är enklast att få igång under Linux om man även vill ha fullt HW-stöd och fullt mjukvarustöd.
Det skrivet: har precis testat att köra Windows 11 + WSL2 + CUDA-acceleration under Ubuntu/WSL2 och det fungerar lysande. Även det har officiellt stöd från Nvidia/Microsoft.
Prestanda är väldigt nära "native Linux", känns rätt galet att man kan få 50-100 % bättre prestanda i WSL2 i t.ex. PyTorch jämfört med under Windows. Är trots allt i slutändan Windows-kärnan som hanterar Nvidia GPUn, men så blev det och det är ett helt väntat resultat (både PyTorch och TensorFlow har diskussioner kring varför prestanda under CUDA kan vara så mycket bättre under Linux).
Skulle det hjälpa att tvinga att processera krypto-kod på de små kärnorna kanske? Eller sätta i separat kryptokärna med separat minne (det är väl i någon mening vad TPM är iofs)
Att använda de små kärnorna är redan föreslaget som en potentiell fix. Är det som bl.a. Crystals kommer använda som "work-around".
OpenSSL kommer inte göra något, "outside of their threat model". Inte heller säkert att Go-teamet kommer göra något åt detta i deras kryptobibliotek, de anser att den reella risken denna sårbarhet är väldigt liten.
Nu är inte "proof-of-concept" släppt än, men givet att @lillaankan_i_dammen nämnde webbläsare: förstår jag attack-vektorn rätt fungerar inte JS. Det ger inte tillräcklig kontroll över hur saker läggs ut i RAM för att det ska fungera + man har inte heller tillräcklig kontroll över tidsmätning. Man behöver ett program skrivet i C, C++, unsafe Rust eller liknande som man kan köra fritt på maskinen för att utnyttja sårbarheten.
Elbil är bra om.
-kan ladda hemma.
-pendlar / kör i tjänst 10-30 mil per dag
Elbil är mindre bra om
-ej kan ladda hemma
-regelbundet kör resor om +40 mil
Har elbil sedan cirka 6 månader, i vardagen är den betydligt mycket trevligare än min gamla dieselbil men långresor som jag tidigare körde nonstop (50 mil) tar jag andra färdmedel pga. hålla lägre hastigheter för att inte suga ur batteriet samt slippa stanna och ladda.
Så 50 mils turen tog tidigare cirka 4H 15 min men med elbil cirka 6H. Så det positiva är att det är en mindre fartdåre på vägarna.
Håller med om det. Vi har 3 bilar, elbilen är den som kommer rulla flest mil men då vi har möjligheten att välja mellan bensin och elbil har det blivit så att om man ska köra "tillräckligt långt" hamnar valet på bensinbilen. Rätt mycket värt att kunna gå upp 30-40 min senare iväg på jobbresa direkt på morgonen.
"Körde" inne i stan i veckan, gissar att ingen gillar att sitta fast i bilkö men när man blir illa tvungen tycker i alla fall jag att det är ett område där BEV skiner över ICE. Har generellt sett lite svårt för one-pedal-drive, men i detta fall är det direkt lysande!
Eller finns en sak där "roliga bilen" (V8 med rätt aggressivt ljud) är bättre på inne i stan, det då de båda andra bilar är uppenbarligen så pass tysta att folk dräller ut i gatan utan att titta. Ljudet från en V8 med X-pipe och straight-through ljuddämpare verkar hålla folk ur vägen
Var helt inne på elbil även privat, men är rätt glad att jag skippade det "for now". Händer lite för mycket just nu på elbilsfronten. Perfekt att ha elbil via jobbet, men inköpspriset + värdeminskningen + försäkringskostnad ger ingen vidare ekonomi om man planerar behålla bilen lite längre.
Just försäkringskostnaden borde lösa sig. Fattar att det är väldigt enkelt att skruva upp effekten i en elbil och att det gör sig bra i produktbladet. Men hur vettigt är det egentligen, framförallt när vridmoment vid låga farter är långt viktigare än hästkrafter för den typ av körning man gör >99% av tiden en "normal" bil. En annan stor fördel med elbil är just väldigt högt vrid direkt, även utan att man skruvar upp hästkrafter (som alltid ligger "på toppen" då det är vrid*RPM).
Försäkringsbolagen har koll på statistik, korrelationen mellan många hästkrafter och kvaddad bil är glasklar. Knappast en slump att Tesla numera toppar statistik för bilmärket med högst olycksstatistik (att gömma allt i en ipad bredvid ratten hjälper nog inte heller till...).
Visst är det 2030 som är slutdatum för nyförsäljning av ICE bilar som går på bensin/diesel (ICE som körs på "förnybara" bränslen är som jag förstår undantagen, men just nu finns egentligen inget sådant tillgängligt för "svensson")? Varit lite fram och tillbaka mellan 2030 och 2035, men det gör oavsett att man rätt snart inte kommer ha något alternativ.
Och när det väl kommer till det: visst fungerar det att åka långt även med elbil, bara lite mer "fippel/planering" jämfört med att köra ICE.
Fast nu är det ju inte OoO som är problemet och har inte heller varit tidigare, alla problemen kommer från den spekulativa exekveringen i moderna CPU:er. OoO påverkar ju inte säkerheten, det gör bara att läsningar/skrivningar inte sker i exakt den ordningen som du som programmerare tror, de sker fortfarande sekventiellt.
Anledningen att man måste ta till saker som Data Memory-Dependent Prefetchers (DMPs) är att utan dessa kommer djupare OoO inte hjälpa för det kommer inte finnas data tillräckligt snabbt för att utnyttja alla beräkningskapacitet back-end i CPUn har. Det är specifikt DMP som denna sårbarhet utnyttjar.
Intel är inte out-of-the-woods, det enda som konstaterats att metoden som fungerar på M1/M2/M3 fungerar inte på Raptor Cove. Man kan mycket väl hitta andra sätt, likt hur vissa SMT sårbarheter bara fungerar på Intels modeller medan andra bara fungerar på AMDs modeller.
Apples CPU är i nuläget den "bredaste" mikroarkitektur som existerar, enda som är i närheten är Arm Cortex X4 (och snart även Snapdragon X Elite). Utan "trick" som DMP och ett gäng andra skulle det vara helt omöjligt för en CPU att utföra ~50 % mer instruktioner per cykel jämfört med Intel/AMDs bästa (nu har även Raptor Cove DMP, så räcker inte enbart med detta men det en sak av många för att nå dit).
OoO är specifikt det som orsakar Spectre. Så vitt jag vet är alla OoO-designer drabbade av Spectre, medan de utan OoO-stöd inte är sårbara.
Säkerhet och CPU-prestanda står i allt mer kontrast till varandra. Men känns inte som ett omöjligt problem att lösa givet att det i praktiken är en rätt liten delmängd av vad program utför som spelar roll för säkerheten. Se bara till att göra dessa på beräkningsenheter optimerade för säkerhet, då går det att köra full-steam ahead för resten m.a.p. prestanda.
@Yoshman: Rippar du själv finns inget problem, det finns inget förbud mot att kringgå/knäcka kopieringsskydd på programvara. Problemet där är att det kanske inte är så lätt att kopiera systemprogramvaran från konsolen när den behövs och inte kan återimplementeras.
@Keneay: Du kan inte privatkopiera spel. Du har däremot rätt att göra säkerhetskopior.
Well, det är betydligt mer komplicerat än "det finns inget förbud mot att kringgå/knäcka kopieringsskydd på programvara".
Det finns lagliga sätt att göra det, förutsatt att bl.a. detta är sant
du har inte skrivit på ett avtal i samband med anskaffande av programvaran där du går med på att inte göra kopior. När man hyr, eller kanske när man fortfarande hyrde, film godkände man i praktiken ett sådan avtal
ingen av verktygen som används för att göra kopian är något man köpt för pengar, är OK om det är gratis programvara (möjligen är det bara leverantören av HW/programvaran som gör något olagligt vid försäljning, är ingen jurist men lag kring detta finns här)
man kringgår kopieringsskyddet på sitt eget exemplar och man gör det för att det krävs för allt alls kunna konsumera innehållet
Det sista är lite problematiskt givet att man i praktiken verkar behöva en Switch för att rippa ett ROM. Det måste tydligen också vara en gammal modell där man sett till att inte uppgraderat programvara, de sårbarheter som används är tätade i senare generationer.
Sure, man kan rippa alla ROMs och sedan sälja sin Switch. Så sista delen kan man helt klart komma runt om man absolut vill göra saker "by the book".
Huvudpoängen är ändå: i praktiken är det tillräckligt komplicerat att jag gissar att Nintendo, Sony etc inte har en speciellt svår uppgift i en rättegång att på ett övertygande sätt lägga fram det som att just emulatorer för konsoler knappast har något relevant syfte mer än att köra spel som inte anskaffats på laglig väg.
Kan själv tycka att lagarna här är omoderna, men vill bara peka på varför Nintendo i nuläget nog ändå har lagen rätt mycket på sin sida.
Jag äger tex flera switch-spel, men ingen switch utan en Steamdeck med yuzu. Då är det ganska smidigt med romsites. Det är bara de tidiga serierna av switch som är lätta att hacka så är inte direkt så att alla kan skaffa sig en switch att hacka.
Nu är det väl inte så att detta sätt följer lagens bokstav till punkt och pricka, men jag anser att jag följer lagens intention, att jag betalar utvecklarna för det spela jag spelar. Visserligen betalar jag inte Nintendo något för plattformen, men det var ju inte Nintendo som utvecklade Yuzu, även om du absurt nog äger rättigheterna till yuzu...
Var precis så jag förstått det. Vet inte hur domstolarna ser på det, men givet att det inte verkar vara speciellt praktiskt genomförbart att köra spel på ett lagligt sätt. En lag som verkar fungera hyfsat lika i Sverige och USA, andra som Tyskland verkar ha striktare lagar kring att kringgå kopieringsskydd och verkar finnas länder som är ännu mer strikt där man i praktiken inte har rätt att köra sitt spel på "andra plattformar än de tillverkaren av verket avser" (så i detta fall, det är olagligt att köra spelen på något annat än Nintendo Switch).
Så även om man försöker göra rätt för sig, är det i praktiken rätt svårt om man spelar via en emulator. Man kan tycka det är fel, men ändrar inte de (ofta rätt föråldrade) lagar vi har rätt mycket gör det praktiskt omöjligt/väldigt svårt att lagligt spela spel på emulatorer.
Men vill ändå understryka att det inte alls finns några lagproblem med att använda emulatorer. Huvudproblemet med just detta är att de flesta i praktiken måste bryta lagen för att köra spel. Är det senare som gör det hyfsat lätt för Nintendo att angripa detta.
I fallet QEMU är det överlägset vanligast användarfallet fullt lagligt. Så att emulera HW är inte alls ett problem, tvärtom ser ju många HW-tillverkare positivt på sådant och de hjälper till med utveckling av projekt som QEMU.'
Sen om man nu tycker Nintendo är rövhattar här: hur svårt kan det vara att bara skita i att köra deras spel? Finns rätt många andra spel att välja på som fungerar på lämplig plattform.
Tester av chassi, grafikkort, processorer m.m.
Copyright © 1999–2024 Geeks AB. Allt innehåll tillhör Geeks AB.
Citering är tillåten om källan anges.
