Inlägg

Man kan ana att ca 10-20% är skeptiska till detta och resten verkar tror att man måste installera windows 11 redan idag fastän Microsoft 10 existerar flera år till.
https://i.imgur.com/IYAg39g.gif
omg, jag måste ha detta nuuu... eller inte alls.

Jag tror för övrigt att de flesta som kör igång nu inte heller är speciellt kritiska till att Amazon har en fot med i spelet så länge datorn fungerar och tänker inte på hur den fungerar.

Ett mer inlåst(fungerar datorn utan microsoft Store, Onedrive eller Microsoft Teams till exempel?) och bakåtsträvande system(jämfört med windows 7 som på sin tid har rundade hörn och andra utseenden inbyggt från början...) där Microsoft gör som vanligt fast värre och avsaknaden av kritiskt självtänkande och lång framförhållning för att de kan. Och för att "alla" är uppkopplade och då måste man vara det...
Hela presentationen vill känna oss hemma, men du ska flytta efter några år och det blir mer Big Brother för varje gång

Microsoft requires all windows 11 laptop to have webcam från 2023
https://www.reviewgeek.com/90185/microsoft-requires-all-windo...
Alla har redan detta idag men det är inte ett krav att ha dessa funktioner i windows idag, vad händer om något strular, som det brukar göra?

Sen hur folk blir helt galna här över TPM....suck. Det är väl inte användarens uppgift att få det att fungera, låt Microsoft fixa detta! Beta testa inte jobbet åt dem, speciellt inte när de själva inte ens nämner sådant i sin presentation.
https://wccftech.com/most-modern-pcs-will-have-no-issues-runn...

TPM aktiverat och en alldeles för sen konvertering från Legacy BIOS till UEFI gjord, vilket var det jag saknade för att bli kvalificerad.

Har nån hittat nån info om vilken nivå man behöver som Insider för att få tillgång nästa vecka, är det dev Insider?
E:Yes, dev insider nästa vecka.

Tror kombinationen 8 "stora" x86_64 kärnor kombinerat med 8 "små" (fast här är grejen, de är av allt att döma inte speciellt små givet förväntad IPC) är långt vettigare på desktop är vad man spontant kan tro.

Orsaken är att både Intels och AMDs senare x86_64 drar löjligt mycket ström vid de frekvenser de nu nått. Kollar man effekten när en kärna jobbar vid sin maximala stock-frekvens ligger den nu på 40-50 W. Vi kan utgå från att om Golden Cove ens når i närheten av den IPC som ryktas lär 50 W vallen för enkeltrådarbete passeras.

Finns då ett par alternativ

• låta bli att stoppa i så många kärnor, men tror Intel vill ta tillbaka initiativet även för program/benchmarks som skalar bra med kärnor i detta segment (och det är bara möjligt om de "små" kärnor är starka nog!)

• bara köra med "stora" kärnor, problemet är att om man vill ligga kvar på 100-150 W TDP betyder det markant nedskruvade frekvenser när alla kärnor jobbar, det är inte optimalt om man vill kunna lasta sin CPU fullt ut men ändå få en riktigt bra upplevelse i interaktiva program som körs parallellt

• optimera primärt för energieffektivitet, problemet är att det offrar single-core prestanda så då får man alltid en sämre upplevelse i interaktiva program, vare sig man kör saker i bakgrunden eller ej

Det svåra med en asymmetrisk design är balansen mellan de olika delarna. Mycket möjligt, till och med sannolikt, att Intel inte får till den balansen perfekt på första försöket. För att det "små" kärnorna ska ha en poäng i en desktop-CPU måste de ge ett relativt signifikant tillskott till totala beräkningskraften.

Ett exempel där denna balans inte alls är optimal är Microsofts/Qualcomms SQ1/2 krets. Där är de "små" kärnorna allt för klena, de tillför knappt något alls längre och om det är allt för stor skillnad hamnar man lätt i att jobb som läggs ut på alla kärnor få kass latens då latensen dikteras av vilken CPU-tråd som blir klar sist (långt klockade in-order designer kan tugga rätt länge på ett enskilt jobb...).

Om nu Golden Cove når ~40-50 % högre IPC över Skylake medan Gracemont når ungefär Skylake IPC kommer de små kärnorna ändå ge ett signifikant tillskott för "all-core" prestanda. Det samtidigt som de drar långt mindre per kärna än Golden Cove kärnorna, så de "stora" kärnorna kan ligga kvar på högre frekvens utan att spränga total strömbudget -> lägre latens för interaktiva applikationer som kör parallellt med tunga batch-jobb i bakgrunden.

Samtidigt, för att faktiskt nå 40-50 % högre IPC lär dessa kärnor vara gigantiska och därmed rejält strömtörstiga vid de frekvenser vi vant oss vid, d.v.s. runt 5,0 GHz.

För att Alder Lake ska bli vettig måste Gracemont dra väsentligt mycket mindre än Golden Cove samtidigt som Gracemont verkligen får IPC runt Skylake och rimliga frekvenser. En orsak att Atom-linjen kan nå högre IPC per transistor jämfört med Core serien är att den förra är designad för lägre maximal frekvens, d.v.s. de är optimerade för maximal perf/W. Problemet med en sådan design är just att IPC * frekvens (d.v.s. IPS) blir lägre och därmed en sämre design för interaktiva applikationer.

Apple kan inte emulera x86_64 i samma hastighet som de kan köra ARM64, man når ~70-80 % av ARM64 hastigheten.

Men då deras CPU är så brutalt bred räcker 70-80 % effektivitet för att man kan köra programmen snabbare än vad AMD/Intel kan om de klockade sina CPUer till 3,2 GHz (vilket är frekvensen M1 kör i).

Självklart kan andra göra detta givet tillräckligt med FoU. Det tekniskt riktigt intressanta med detta är att AMD/Intel borde fundera på att själva köra något likt Rosetta 2, d.v.s. bygga en CPU som inte kan avkoda x86_64 utan den avkodar något annat som möjliggör väsentligt bredare designer och sedan översätter man x86_64 programmen statiskt (första gången man kör programmet) för att sedan köra denna "nya" ISA.

Det är naturligtvis bara ett plåster, rätt lösning är pensionera x86_64. Men givet hur viktigt x86_64 är för Windows är det ändå en möjlighet att fortsätta boost prestanda.

En långsiktigt bättre lösning är nog att byta till t.ex. ARM64 eller RISC-V men bygga in riktigt bra x86_64 emulering likt vad Apple gjort i M1.

En problem med x86_64 är rätt rejäl "overhead" i avkodning. Går inte att skala ned en x86 till riktigt små och enkla CPUer, vilket nog var en stor orsak till att första generationen Atom var rätt kass samt Quark var DoA (Quark var i princip en mikrokontroller som kunde köra x86, har en SBC med Quark men såg aldrig ett vettig use-case).

Det har uppenbarligen även Intel insett om man kollar på utvecklingen av Atom, man har skruvat upp IPC rätt rejält men man fortsätter att designa inom ramen för relativt låg maximal frekvens. Att kunna klocka högt kräver ofta designbeslut som sänker IPC och vice versa. Fördelen med Atom blir då att man kan få bättre perf/W genom att släppa kravet på hög frekvens, i stället lägger man sig på samma nivå som Arm-tillverkarna (ingen slump att de håller sig runt 3 GHz).

Fördelen här är att Intel kan få till en Atom design (Gracemont) som ryktas få IPC på Skylake nivå, fast då den dels är tillverkad på en nyare process och designad för en maximal frekvens på ~3-3,5 GHz kommer Gracemont har väsentligt mycket högre perf/W jämfört med Skylake.

Om man skulle stoppa in 16 st "stora" kärnor i Alder Lake får man ju endera klocka dessa lägre, för att inte knäcka totala effektbudgeten, eller så får man göra dem mindre komplexa, vilket offrar IPC och därmed maximal absolut prestanda.

Till skillnad från många andra tror jag faktiskt big.little kan vara vettigt även på desktop. Detta då moderna x86 CPU-kärnor är så komplexa och klockar så högt att de drar hjärndött mycket ström per kärna. 100-150 W TDP är definitivt en flaskhals för x86 när man går upp till 16 kärnor, det verkar fungera bra upp till 8 st (bra = man behöver inte klocka ned dem allt för mycket när alla kärnor jobbar).

Alder Lake S kan därför bli vettig i att majoriteten av allt man kör kommer använda <8 kärnor, bättre då att de Golden Cove kärnor man stoppar in har så hög IPC och kan klockas så högt som bara möjligt.

För de applikationer som kan använda väldigt många kärnor, fler än 8 st i detta fall, är det enda som spelar roll perf/W. Man får bättre perf/W med fler långsammare kärnor, men att bara ha långsamma kärnor suger för interaktiva laster (som är i klar majoritet på en typisk PC). Kombination av små och stora, förutsatt att de små är "tillräckligt snabba" så de har en poäng, kan ge en riktigt bra medelväg.

TL;DR är att en fördel blir att man kan maximera absolut prestanda hos de stora kärnorna med denna design.

Beror väl på hur bra Windows hanterar det? Är Windows bra på att sortera rätt jobb till rätt kärna?

Fixad. Det spelar egentligen ingen roll hur många kärnor och vilken frekvens saker kör på, Apple har ju världens snabbaste CPU i rätt många lägen trots att den bara har 4 "stora" kärnor som endast klockar 3,2 GHz.

Personligen tycker jag Rocket Lake S känns som för lite för sent. Det kommer rimligen ändå räcka för att Intel utan större diskussion ska ta tillbaka ledartröjan i spelprestanda.

Alder Lake S känns långt mer spännande, förutsatt att den nu kommer ut 2H 2021. Där lovar man ju upp till 50 % högre IPC ställd mot Skylake och med hjälp av "big.little" kommer modeller med 16 kärnor. Ja, hälften är Atom kärnor, men allt pekar på att dessa Atom kärnor kommer ungefär matcha Skylake i IPC!

GF har fabiken i Drestden. De har kommit till 12 nm så det är inte så illa om nu inte TSMC eller Samsung kan leverera.

Arm vs x86 plus att Apple är det överlägst största it bolaget och har nästan oändligt med resurser. Om de ser nått bolag med intressant teknik kan de köpa upp dem. Samma sak med talangfulla indevider, de har råd att betala mer för att få dem att komma och arbeta för dem istället. Sen så har ju Apple väldigt hög status som företag, så de är nog många som har dem som #1 potentiel arbetsgivare om de fick välja.

Jag är en SW-person, inte HW-person. Tänkte på det när jag lyssnade på Intel och AMD intervjuerna igår, där pratade HW-människor som inte är SW-personer (kort och gott, ibland var de i spenaten vilket jag lär vara för HW till och från).

Men i grunden finns i alla fall två stora problem med x86_64 som inte finns i ARM64

1. ARM64 hanterar minneskonsistensen mellan saker som kör på olika CPU-trådar på ett sätt som skalar bättre med stort antal kärnor. Detta kan absolut fixas i x86 om man skippar bakåtkompatibilitet, metoden man har nu råkar bara vara något man tyckte kändes rätt för ~30 år sedan när det definieras (när första dual-socket x86 dök upp)

2. ARM64 har fix storlek på alla instruktioner, de är 4 bytes vilket gör det trivialt att hitta gränserna mellan instruktionerna, vilket gör det möjligt för Apple att avkoda 8 instruktioner per cykel. x86 instruktioner är 1-15 bytes, idag är det bara nackdelar för genomsnittligs längden på en instruktion passerar ofta 4 bytes idag så x86_64 program är något större än motsvarande ARM64. Fixar man detta är det inget kvar av x86.

Nej, av principiella skäl. Samma anledning till att jag går till ICA istället för lidl trots att det är typ samma avstånd.