Qualcomms vd: Vi ska bygga kretsar för stationära datorer

Känns ju onekligen som att detta är vägen mot framtidens processorer. Kommer de ikapp de stora aktörerna i prestanda och behåller energieffektiviteten de har så kommer det bli svettigt.

Spännande att se hur Intel och AMD gör framöver.

Såg en video igår där en fotograf testa på en ny Lenovo Yoga slim med copilot+ och Snapdragon 3K skärm 16gb ram mm. Han var inte imponerad.

Batteritid ca 4-5 timmar, AI delen var mest väldigt basic, och inte direkt till nån nytta, vid lite tyngre jobb i darkroom så orka inte datorn med alls.

Men för lättare jobb typ word, Excell kan den vara ok till, men inte bättre än tradionell PC med AMD/Intel.

Tror den dröjer ett tag innan detta blir nått att räkna med,

Jag köpte mig en laptop för några veckor sedan med X Elite, det för att kunna testa/debugga för den processorn. Är programmerare och vi har ganska tung utveckling som är nära hårdvaran. Men jag är positivt överraskad, hade förväntat mig mer problem än det varit även om Visual Studio då och då (några gånger per dag) kraschar.

Det är inte speciellt svårt längre att generera binärer för olika processorarkitekturer, speciellt eftersom Apple för några år sedan bytte ut sin x86 till en ARM så miljöer har redan anpassat sig. Mycket vanligt med programmering där det sitter utvecklare i både windows, linux och apple med olika processorer.

Det mesta av problem tror jag kommer vara lösta under året men jag tror inte de som idag skaffat en ARM för windows är besvikna.

Som konsument kan konkurrensen aldrig vara för bra.

Vi testar några HP och Surface på jobbet och det är mycket som inte fungerar. Även om det som fungerar fungerar väldigt bra.

Det är just den detalj om under året eller snarare åren för vissa av dessa mjukvarorna som vi kör att få stöd.

För mig personligen är det också hur långtid the kommer ta för den mjukvara och drivrutiner för sakerna jag gör hemma. (Im talking about you wacom you slow depressed pig of a company that is allergic to change.)

Intressant poäng från någon jag antar faktiskt hört uttalandet.

För att tydliggöra poängen för den som inte klickar på länkar så är alltså artikelns citat av Cristiano (Qualcomm):
"The first thing that we did, we launched [Snapdragon] X Elite. Then we launched the X Plus, plus the 10-core. Today, we’re launching the 8-core Plus to try to get at different price points. You’re going to see us with a lot of designs on desktops, mini desktops, and eventually, you won’t be surprised of us still thinking about high-performance desktop. We are on this journey. As I said, we’re here to stay."

Och det Ian kommenterar:
"Tbh when Cristiano said 'desktops, er mini desktops', he said 'mini-desktops' so quickly as to correct himself.
I don't see this much as a change from previous messaging. Part of the issue is that in some head spaces, a mini-desktop is a desktop, and you'd be splitting hairs."

Dvs, det låter som att Ian anser att det fetmarkerade rakt av är ett felcitat; någon som snubblat på orden och direkt rättat sig citeras som att ha räknat upp båda sakerna istället för att just ha rättat sig.

Och isf att det är först om man når hela vägen till "eventually, you won’t be surprised of us still thinking about high-performance desktop" som det skulle kunna finnas hopp för det vi typiskt menar med desktops.

Hoppas de sätter siktet högt, var väldigt taggad inför ARM för PC runt omkring när min Lumia 950 vart EOL, därefter vart det besvikelse efter besvikelse tills Apple kom in i bilden, och även därefter känns det som att Qualcomm verkligen inte tagit i så mycket.

Absolut men jag ser det som barnsjukdomar

Parallels är inte ett alternativ för oss, C++ kod. C# då fungerar det säkert
ARM är inte min primära dator för att utveckla och det kommer den inte bli heller.

Ok, japp men VS Code är bedrövlig om man skall utveckla i C++, Visual Studio är kung där

VS code har ett flertal problem där hastigheten kanske är värst (den är långsam på att uppdatera sig när projekten är stora)

Vad tror du majoriteten av de som använder en dator i jobb pysslar med på dagarna? Och det skulle kräva en stationär maskin?

Som redan nämnts. Att din arbetsdator är ”mobil” är mer eller mindre ett krav i många fall då du kan arbeta på distans, ta med på möten eller som många har, inte fasta arbetsplatserna i kontorslandskapet.

Det är inte så att majoriteten av företag går och plockar ihop en dator från iNet utan det mesta köps färdigt. Och i de flesta fall rullar en dator tills den är för gammal för att ens vara värd att lägga resurser på att lappa ihop.

Det skall vara en bra fin maskin för att man skall vilja lägga pengar/arbetstimmar på att felsöka, skaffa fram och byta ut något som är så gammalt att det inte går på garanti längre. Den går på återvinning och sen köper man in en ny HP, Dell, Apple, Lenovo osv…

Ja, det är ju intressant i sig; vad används de flesta jobb-datorer till? På mitt arbete, i en fabrik, har vi ungefär lika många datorer som personer som arbetar. Men de flesta datorerna är ju inte personliga. Klar övervikt stationära datorer, varav en hel del är all-in-one numera, ofta med pekskärm. Laptopar? Det är inte många, klart det finns på "kontoret", och IT-personerna har med sig laptop när de ska felsöka osv. Men det är väldigt många datorer som står där de står, med en skärm (ofta äldre), tangentbord, pekmojäng (mus, platta). Vi skulle absolut se fördelar med fläktlösa datorer som inte drar i sig damm. Eftersom datorerna står på 24/7 och säkert drar mer ström än nödvändigt skulle strömsnåla CPUer säkert vara till nytta.

Men prestanda måste vara rätt bra (som en random core i3 eller nåt iaf), och de måste ha nätverk via kabel såklart. Wifi går fett bort.

Ah, du kanske menar att er applikation "kraschar ett par gånger per dag" om man kör med ARM64? Om så, det är nog "riktiga" buggar som "råkar" fungera på x86. Satt under väldigt många år med C och C++ projekt som behövde stödja Arm, MIPS, PowerPC och x86. Fanns då (men inte längre på ARM64) flera saker som gjorde rätt sak på x86, men kraschade i bästa fall (MIPS och PowerPC) eller kunde ge fel svar (vissa 32-bit Arm...).

Annars känns det lite märkligt att Visual Studio själv skulle kunna vara så skakigt givet erfarenheten jag haft (och även om det inte involverar C++ direkt är det involverat indirekt då bl.a. DirectX och App SDK används). Men skulle i.o.f.s. kunna vara C++ specifikt!

Nu börjar det bli några år sedan jag jobbade i C eller C++ mer än för mindre mikrokontrollerprojekt (där fungerar PlatformIO + VS Code perfekt). För mig är enda fungerade editor för stora C/C++ projekt Emacs, fungerar naturligtvis sedan länge på ARM64

Tydligen är Intellisense-delen för C++ borked ihop med VS Code, söker man är det många som klagar på att det blir segt med stora projekt. Annars tycker jag VS Code fungerar super och det är en betydligt bättre editor jämfört med VS Studio (det är en bra IDE med en, med dagens mått mätt, medioker editor). Stora Go, C# och Rust projekt fungerar lysande i VS Code!

Det jag fått för mig av de tester jag sett är att visserligen är det duglig prestanda, men energieffektiviteten är verkligen inte ens nära Apple, snarare som x86, eller?

Tror det kommer ta ett tag till för dessa att locka över entusiaster, framförallt på desktop. Ska dessa säljas i en sockel eller?

Om man måste använda Windows ja.
Annars är mjukvarustödet väldigt bra.

Nix den fungerar bra på ARM men visual studio fryser då och då till och sedan försvinner den. Den har kraschat då. Jag har inte många plugins så tror inte de ställer till det, de få jag har är vanliga men eventuellt skulle det kunna vara ett problem.

Annars så tog det ett bra tag innan stora cmake projekt fungerade bra med visual studio och jag är van vid att annat tagit tid innan det flyter. Har använt visual studio sedan version 1.0. Exempelvis tog det lång tid innan deras intellisense fungerade bra för stora C++ projekt. cmake var hemskt de första två åren.

Vad jag vet så kommer det uppdateringar i snabb takt för ARM så tror de betar av allt vad de kan.

Tippar på att antalet programmerare som kör C# och visual studio är kanske 10 gånger fler än de som kör C++ med miljön och C++ kräver betydligt mer av miljön, tror det spelar stor roll. För som jag skrev tidigare, stora projekt och man får räkna med att det blir knepigheter.

Jag tror det kan ha en del och göra med vad man normalt kör, har man inte testat visual studio och använt en del av de specialare som finns där så saknar man det inte heller. Självklart spelar det också roll vad man är van vid. Jag är van vid att visual studio snabbt markerar, knapptryckningar och annat så det är alltid en tröskel men försöker bortse från den.

Min främsta kritik är annars just att editorn är seg att uppdatera om man rättat och då litar man inte på den, den kan markera rött trotts att det är rättat ett bra tag. Annat problem är när man förändrar filer i projekt och då kan det vara lite si och så för vs code att fatta vad den skall göra när man kompilerar, man behöver göra en fullständig rebuild istället.

Kan säkert stämma, jag vet att detta historiskt varit ett sorgebarn i visual studio också.

Kan tänka mig att Go, Rust mm är enklare för editorn.

Gillar exempelvis vs code för webutveckling, där är det inga problem, bättre än visual studio. Kört en del Python i den med men det är så små program så kanske inte någon bra måttstock.

Nu försökte jag väl mest försvara ”chefens kompetens”

Men ja, datorer kopplade till maskiner, kassor logistik linjer etc är generellt stationära. Men är ändå av uppfattningen att anledningen inte är för att interna hårdvaran är lättare att reparera. Mest troligt för att kostanden vid inköp är lägre eller att, i fallet gällande maskiner, något kul ”instickskort” krävs. Bättre på att suga damm i 10år, svårare att ”råka” få med sig hem?

Har aldrig hört ”måste vara en stationär så vi kan byta CPU eller PSU när det går sönder”.

Största kravet nu är väl att datorn är ny nog att klara W11 om man sitter fast i det träsket.

Jobbar till sjöss, och det är samma hos oss. Man har en eller två datorer per befattning som behöver det, de är inte personliga i den meningen, man delar med sina avlösare. Den ende som har en laptop är elingenjören, som kan behöva koppla upp sig mot diverse utrustning ute i båten, typ telefonväxel, ECU:er, scrubbersystem, etc. I övrigt är det stationära datorer i miniformfaktor som gäller.

I sakens natur ligger också att det förstås är svårt att jobba hemifrån som sjöslusk. Det finns egentligen inga fördelar med laptops.

Qualcomm har uppförsbacke helt klart. Snapdragon X är en väldigt bra plattform, innan Lunar Lake så var det den odiskutabla ledaren i perf/W bland Windows-laptop. Men är ett problem att de bli så kraftigt slagna på iGPU-sidan av både AMD och Intel, än värre är det för dem att Intel nu verkar matcha (men inte gå förbi trots TSMC N3B vs TSMC 4 för QCOM) perf/W med Lunar Lake.

Intels slide där de säger att Lunar Lake nu matchar Snapdragon X (samtidigt som säger att Lunar Lake dubblar perf/W från Meteor Lake)

Lunar Lake lär, precis som Strix Point, vara rejält mycket dyrare jämfört med Snapdragon X. Något som faktiskt har betydligt större påverkan i en NUC-lik desktop jämfört med i en high-end laptop där många andra delar också är dyra.

Mer dåliga nyhet för Qualcomm, men potentiellt fantastiska nyheter för de som vill se ARM64 lyckas på Windows, är att Arms Cortex X925 (som lanserades av dem i maj) bör snart börja hitta ut på marknaden och mycket tyder på att det även inkluderar kretsar tänka för PC-marknaden.

Stämmer Arms påstående kring prestanda, och Arm är nog de där PR och verkligheten ligger närmast varandra historiskt sett, kommer X925 bli modellen när även Arm kliver in och hamnar på den ST-prestanda nivå AMD, Intel och Qualcomm är på. Nvidia är en het kandidat att bygga X925 kretsar med deras GPUer.

Prestandamässigt är det väldigt jämt mellan CPU-modellerna, Qualcomm når den prestandan trots att de har den CPU som tar klart minst kretsyta i anspråk. Skymont och Oryon är nog mer jämföra i storlek, det går 3 st Skymont på en Lion Cove sett till area...

Både Strix Point och Snapdragon X har 12 "stora kärnor", Strix Point är ~35 % större på samma TSMC 4 nm process.

Lunar Lake "compute die" är ~140 mm² (på TSMC N3B) + 46 mm² I/O-die (TSMC 6 nm?). Snapdragon X är ~170 mm² totalt.

Edit: en annan trevlig ARM64 nyhet. Man är påväg att få till stabilt stöd för 16 kB och 64 kB page-tables i Linux-kärnan, det är en funktion som finns i alla ARM64 CPUer då det är del av ARMv8.0 specifikationen.

Phoronix ser 15 % prestandaboost i genomsnitt med 64 kB pages på Ampere, lär inte vara mindre på Oryon givet att det är en mer högpresterande mikroarkitektur

https://www.phoronix.com/review/ampereone-64k-linux611

Om du menar Linux så har jag stött på problem många gånger som bråkar mellan ARM64 och AArch64. Det ska på tech specen vara fungera på bege två men det gör det inte. Så ja det funkar bra på Linux med en massa asterixer.

Jag kör Linux mer eller mindre dagligen på min Mac Studio genom qemu med hypervisor-framework för att arbeta med containrar och Kubernetes. Jag har vad jag vet aldrig stött på ett enda problem jag kunnat härleda till att det är ARM64. Och inte heller på min Pi400 har jag upplevt varken ARM32 eller ARM64-relaterade problem.

Däremot har jag stött på byggscript då och då från 3e-partsmjukvara som generellt utgår från att allt är x86 för att dra ner dependencies. Eller i vissa fall faktiskt i paket som man bygger från kod inkluderar/bundlar färdigkompilerad x86-libbar. Men det är oftast bara för att folk byggt script dåligt på sin egen dator och inte tänkt på att man kan använda variabler Och dessa script skulle stöta på samma problem med alla arkitekturer annat än x86_64 eller andra distros för den delen.

Så om dina asterixer är sådana saker som jag nämner ovan är det knappast ens något att tänka på till vardags.

Förstår inre riktigt vad du menar med AArch64 och ARM64
Det är väl samma sak: AArch64 är det officiella namnet och ARM64 är vad folk kallar det.
Liknande att det finns både AMD64 och x86_64 som används för att prata om samma sak.