Intels VD: "Dags att sluta fokusera på benchmark-resultat"

Skrivet av ClintBeastwood:

Det känns mest som att du jagar likes men visst, säger du det så.

Jagar likes? Du tänker att sweclockers är youtube och facebook?

Vem bryr sig om likes.

Benchmark är som jag ser det synnerligen relevant för då kan jag välja den processor som ger bäst pris/prestanda för det som jag vill göra.

Och framförallt - det som är viktigt är att jag inte får en processor som gör att jag får sämre prestanda än med den gamla datorn för att det är någon arkitekturell förändring som gör att det finns en flaskhals som jag inte vill råka ut för.

Skrivet av Klappa:

Vill ej låta taskig men man börjar undra om du jobbar hos ARM eller har affilieringar med dem på något sätt.

Jobbar inte åt ARM, men däremot rätt mycket med ARM-baserade produkter.

Om man gillar CPU-teknik, varför skulle man inte hoppas x86 byts ut mot något bättre? Visst skulle det vara trevligare om RISC-V eller något annat som både är öppet och i teorin har samma potential som 64-bitars ARM, men just nu är ARM64 den enda realistiska ersättaren för high-end x86 (eller skulle kunna bli om Microsoft slutar att totalt misslyckas med Windows on ARM).

Ingen ifrågasätter om man hoppar upp och ned av upphetsning när det dyker upp AMD-nyheter. Och kan inte säga något annat än att jag är helnöjd med min 3900X. Men hur spännande är det egentligen att AMD först förra året lyckades matcha IPC hos Skylake, en design som nu är fem år gammal?

Jämför det med att en Iphone, en fläktlös enhet som väger ~200 gram och går enbart på batteri, matchar 3950X och inte är långt ifrån 10900K i absolut enkeltråd-prestanda i GB5. Och har då jämfört mot "hackintosh" där x86 prestanda är lite högre jämfört med Windows. För en CPU-interesserad publik här på SweC måste det ändå vara hyfsat uppenbart vilken total utskåpning det är, Tesla Roadster mot Dodge Hellcat Redeye (visst är den senare helcool med kompressormatad V8 på 797 HP i standardutförande, men det är framtiden mot stenåldern).

Fatta vilken prestanda vi skulle få om välden kunde släppa x86! (Något jag p.g.a. Windows tyvärr inte tror händer i närtid, hoppas på Apple)

I.o.f.s. hoppas jag en del på Xe. Inte som spel-GPU, utan för GPGPU! Någon kanske kommer ihåg denna bild, skulle bli en nyhet med Vega

Vet inte vad som hände med det, men är i alla fall exakt hur Intels genX arkitektur fungerat hela tiden vilket är orsaken till att deras GPUer uppför sig långt mer CPU-likt än Nvidia/AMD GPUer (d.v.s. som en CPU med rätt många kärna).

Det som Intel (egentligen alla) saknat tidigare är ett sätt att skriva program så man kan skriva en version som kan köras effektivt både på CPU och på GPU när sådan finns. Mycket talar för att oneAPI kan axla den rollen, men vi får vänta något år innan man kan uttala sig.

Skrivet av IKEA Billy Bokhylla:

@Yoshman: Angående 3D-rendering: Ja de funktioner som fungerar att utföra med ett grafikkort är alltid snabbare. Däremot är vi fortfarande i en tidig övergångsfas och det är fortfaranfe otaliga funktioner som inte stöder GPU-rendering. Arnold (Maya's numera inbyggda renderingsmotor) är ett praktexempel på en sådan renderingsmotor.

Visst kan man hålla kvar vid gammal teknik, verkar ju vara ett populärt tema på SweClockers...

Även om Arnold verkar ha lite yxigare1 GPGPU-stöd än de flesta andra finns ändå sådant stöd sedan förra året, de benchmarks jag hittade pekar på ~10x prestandaökning mot Intels snabbaste HEDT mot RTX2080Ti.

Men pekar ändå på en viktig poäng: vissa saker kommer ändå behöva köras på CPU för GPU utför inte alla saker långt mer effektivt. Problemet med den typ av benchmark som nu görs för 3D-rendering är att den testar totalt fel egenskaper hos CPUn. När saker blir GPGPU-accelererade så kvarstår de saker som skalar dåligt med CPU-kärnor för CPU att hantera (GPUer är värdelösa på sådant). Så det man borde testa i CPU-test är dessa kvarvarande moment!

1Arnold verkar (så här långt) inte stödja GPGPU för scener som inte helt får plats i VRAM. Nvidias kort har HW-stöd för att använda CPU RAM medan VRAM mer blir en väldigt stor cache sedan Pascal (och ryktet gör gällande det stödet skulle få fler optimeringar med Ampere).

Senast redigerat 2020-06-07 22:58

AMDs senaste CPUer är grymma, men hade jag uppgraderat idag hade jag nog ändå köpt en 10700k, pga prestandan i spel.
Men till hösten när Ryzen 4000 släpps är det inte omöjligt att Comet Lake-S är lika intressant som Bulldozer.

Skrivet av Yoshman:

Visst kan man hålla kvar vid gammal teknik, verkar ju vara ett populärt tema på SweClockers...

Även om Arnold verkar ha lite yxigare1 GPGPU-stöd än de flesta andra finns ändå sådant stöd sedan förra året, de benchmarks jag hittade pekar på ~10x prestandaökning mot Intels snabbaste HEDT mot RTX2080Ti.

Men pekar ändå på en viktig poäng: vissa saker kommer ändå behöva köras på CPU för GPU utför inte alla saker långt mer effektivt. Problemet med den typ av benchmark som nu görs för 3D-rendering är att den testar totalt fel egenskaper hos CPUn. När saker blir GPGPU-accelererade så kvarstår de saker som skalar dåligt med CPU-kärnor för CPU att hantera (GPUer är värdelösa på sådant). Så det man borde testa i CPU-test är dessa kvarvarande moment!

1Arnold verkar (så här långt) inte stödja GPGPU för scener som inte helt får plats i VRAM. Nvidias kort har HW-stöd för att använda CPU RAM medan VRAM mer blir en väldigt stor cache sedan Pascal (och ryktet gör gällande det stödet skulle få fler optimeringar med Ampere).

Det handlar inte om att vi blint försöker hålla oss kvar vid det gamla. Det är bara så att vi endast kan använda det som faktiskt fungerar här och nu. Vad ska man göra en viss ljustyp ej fungerar med GPU i en scen, vänta tills nästa år i hopp om att Maya 2021 ska inkludera den? Det är lite som att man skulle ogiltigförklara alla spelbenchmarks som bygger på rastrering bara för att raytracing är framtiden.

Skrivet av IKEA Billy Bokhylla:

Det handlar inte om att vi blint försöker hålla oss kvar vid det gamla. Det är bara så att vi endast kan använda det som faktiskt fungerar här och nu. Vad ska man göra en viss ljustyp ej fungerar med GPU i en scen, vänta tills nästa år i hopp om att Maya 2021 ska inkludera den? Det är lite som att man skulle ogiltigförklara alla spelbenchmarks som bygger på rastrering bara för att raytracing är framtiden.

Utgår från att du hört talas om "disruptive technology", vad vi just nu ser kring övergång från CPU till GPGPU för just 3D rendering är ett exempel på detta.

Det kommer finnas en övergångsfas, vissa som tidigare vad dominanterna kommer hålla kvar allt för länge i deras superoptimerade, men nu föråldrade teknik. I fallet vi har här är det primärt val av programvara som gör att man kan tänkas sitta fast, för det borde ju inte råda några tveksamheter i att vi inte ens kommer fundera att ha den här diskussionen om ett par år för då kommer GPGPU-rendering vara lika självklart som det blev att köra rastrering på GPU efter Voodoo kortens intåg. Intel försökte ju med MMX, en av huvudpoängerna med den tekniken var att accelerera rastrering men det var för lite för sent.

Tänkte inte kommentera specifika renderingback-ends, saknar detaljkunskaperna om skillnader så kan inte tillföra speciellt mycket. Men är ju rätt uppenbart att det inte finns några fundamentala tekniska hinder längre att köra på GPGPU. Att vissa scener inte går att rendera i t.ex. Arnold beror enbart på att de allt för sent insåg var det hela är på väg så de stannade för länge på en tekniken underlägsen modell och de ligger nu efter rätt många konkurrenter vad det gäller GPGPU-stöd.

Anser att Bob Swan har helt fel i sitt uttalande om benchmarks, de är superviktiga som instrument att göra informerade val av system. Han har dock rätt om "system", HW är värdelös utan stöd i programvara (Nvidia dominerar GPGPU just p.g.a. överlägsen programvara, inte p.g.a. överlägsen HW).

Vad Bob Swan möjligen borde peka på är att vissa benchmark-resultat är idag direkt missvisade. Denna video går igenom flera olika arbetsmoment i Blender, alla kan vara väldigt CPU-krävande.

Grejen är att resultatet blir väldigt annorlunda jämfört med vad vi ser hos i princip alla webbplatser som testar Blender då de enbart testar ett specifikt moment.

För den som inte orkar kolla videon, han testar bl.a. i9-10900K och TR-3970X:

  • Viewport-tester: i9-10900K är 22 % snabbare än TR-3970X

  • Simulerings-tester: i9-10900K är 3 % snabbare än TR-3970X

  • Rendernings-tester: TR-3970X är hela 155 % snabbare

Så självklart är TR-3970X bäst! Eller?
Kollar man lite benchmarks nu när Blender fått initialt OptiX stöd (så RT-kärnorna kan börja användas) räcker det med en RTX2060 för att rendera i nivå med TR-3970X. RTX2070S lägger renderingen-prestanda på TR-3990X nivå, tänk vad som kommer hända med Ampere...

Ett tag till kan det vara vettigt att testa rendering på CPU, men man borde nog också börja lägga in en mellanklass GPU och en high-end GPU som referens. Med tiden borde man börja köra t.ex. simulerings-tester som del av CPU då de (än så länge) helt körs på CPU.

Och är inte så att GPUer kommer göra CPU-delen irrelevant, finns till och med nischer som skalar extremt bra med CPU-kärnor men ändå inte kan effektivt accelereras med GPUer. Det gäller fall som utför massor med sinsemellan oberoende uppgifter, men där varje uppgift utför potentiellt väldigt olika sekvenser av instruktioner. Exempel är kompilering av stora kodbaser, databashantering, webbservers och liknande. Testa sådant i CPU-tester i stället för att ha 50 % renderingstester som idag mer effektivt körs på GPGPU!

Sådär uttalar man sig bara om man är på efterkälken eller är pressad av en konkurrent!

Skrivet av UndaC:

Hej nu blir det väldigt off topic här förvisso:

Anledningen att vi bumpar nyheter är för att genomsnittsläsaren inte är inne på sidan varje dag (eller ens varje vecka). Därför lyfter vi de nyheter som genererat mest intresse, artiklar vi lagt mycket tid på att skriva osv. då och då.

Jag förstår att det kan upplevas som irriterande att saker hamnar i en ordning som inte är kronologisk och vi ska försöka hitta ett sätt att antingen markera dem tydligare som reposts eller låta användare sortera bort det.
Jag har ingen riktig ETA på när det kan vara på plats, det kan röra sig om många månader.

Men då vet ni iaf varför vi gör det och att vi också är medvetna om att inte alla gillar det och därför ska försöka hitta en lösning för dem.

Jag antog att alla gjorde som jag. Har man varit borta en vecka så går man till arkivet o läser igen allt man missat....

Inte säker på vad ja tycker om er nya taktik med ompostningar. Hjälper det er så kör på.

Synd om käre Bob om nu detta presenteras. Dråpslag Deluxe!

- https://www.theverge.com/2020/6/9/21284960/apple-arm-based-ma...

Skrivet av Nucky:

Synd om käre Bob om nu detta presenteras. Dråpslag Deluxe!

- https://www.theverge.com/2020/6/9/21284960/apple-arm-based-ma...

Har ju spekulerats om just ARM i Mac ett bra tag (åravis), men kan nog vara så att utspelet om benchmark är i skuggan av att intel vet om att dom kommer att förlora en stor kund. Mindre tokiga (och större) utspel har skett vid press, så...

Menar att inköp och avtal för produktsäkring löper på en rätt lång tid, så att detta skulle vara en överraskning (om det stämmer) är mindre troligt.

Skrivet av Yoshman:

Jobbar inte åt ARM, men däremot rätt mycket med ARM-baserade produkter.

Om man gillar CPU-teknik, varför skulle man inte hoppas x86 byts ut mot något bättre? Visst skulle det vara trevligare om RISC-V eller något annat som både är öppet och i teorin har samma potential som 64-bitars ARM, men just nu är ARM64 den enda realistiska ersättaren för high-end x86 (eller skulle kunna bli om Microsoft slutar att totalt misslyckas med Windows on ARM).

Ingen ifrågasätter om man hoppar upp och ned av upphetsning när det dyker upp AMD-nyheter. Och kan inte säga något annat än att jag är helnöjd med min 3900X. Men hur spännande är det egentligen att AMD först förra året lyckades matcha IPC hos Skylake, en design som nu är fem år gammal?

Jämför det med att en Iphone, en fläktlös enhet som väger ~200 gram och går enbart på batteri, matchar 3950X och inte är långt ifrån 10900K i absolut enkeltråd-prestanda i GB5. Och har då jämfört mot "hackintosh" där x86 prestanda är lite högre jämfört med Windows. För en CPU-interesserad publik här på SweC måste det ändå vara hyfsat uppenbart vilken total utskåpning det är, Tesla Roadster mot Dodge Hellcat Redeye (visst är den senare helcool med kompressormatad V8 på 797 HP i standardutförande, men det är framtiden mot stenåldern).

Fatta vilken prestanda vi skulle få om välden kunde släppa x86! (Något jag p.g.a. Windows tyvärr inte tror händer i närtid, hoppas på Apple)

I.o.f.s. hoppas jag en del på Xe. Inte som spel-GPU, utan för GPGPU! Någon kanske kommer ihåg denna bild, skulle bli en nyhet med Vega
https://i.redd.it/72f1onz2sf7y.png
Vet inte vad som hände med det, men är i alla fall exakt hur Intels genX arkitektur fungerat hela tiden vilket är orsaken till att deras GPUer uppför sig långt mer CPU-likt än Nvidia/AMD GPUer (d.v.s. som en CPU med rätt många kärna).

Det som Intel (egentligen alla) saknat tidigare är ett sätt att skriva program så man kan skriva en version som kan köras effektivt både på CPU och på GPU när sådan finns. Mycket talar för att oneAPI kan axla den rollen, men vi får vänta något år innan man kan uttala sig.

Visst kan man hålla kvar vid gammal teknik, verkar ju vara ett populärt tema på SweClockers...

Även om Arnold verkar ha lite yxigare1 GPGPU-stöd än de flesta andra finns ändå sådant stöd sedan förra året, de benchmarks jag hittade pekar på ~10x prestandaökning mot Intels snabbaste HEDT mot RTX2080Ti.

Men pekar ändå på en viktig poäng: vissa saker kommer ändå behöva köras på CPU för GPU utför inte alla saker långt mer effektivt. Problemet med den typ av benchmark som nu görs för 3D-rendering är att den testar totalt fel egenskaper hos CPUn. När saker blir GPGPU-accelererade så kvarstår de saker som skalar dåligt med CPU-kärnor för CPU att hantera (GPUer är värdelösa på sådant). Så det man borde testa i CPU-test är dessa kvarvarande moment!

1Arnold verkar (så här långt) inte stödja GPGPU för scener som inte helt får plats i VRAM. Nvidias kort har HW-stöd för att använda CPU RAM medan VRAM mer blir en väldigt stor cache sedan Pascal (och ryktet gör gällande det stödet skulle få fler optimeringar med Ampere).

Fast nu är ju det Skylake+++ du borde jämföra med inte Skylake första iterationen. Egentligen betvivlar jag inte heller att Intel hade haft ledartröjan nu om de inte varit så bekväma och strulet på tillverkningssidan. Jag håller med om att X86 är en utdöende instruktionsteknik men det betyder inte att ARM kommer få fotfäste inom närmaste framtid förutom på Apples kommande Macbook-serie. Det är Apples processorer som börjar närma sig med IPC inte ARMs (Qualcomm med flera).

Hur tänker du att man ska sätta ditt Apple ARM-processorer i Windows burkar? Och jag förstår inte varför du hoppas på GPGPU? Det är inget som konsumeter har nytta av. Inga grafikkort gjort för konsumenter har GPGPU funktioner och Vega var väl sista grafikkortet som hade det?

Skrivet av Klappa:

Fast nu är ju det Skylake+++ du borde jämföra med inte Skylake första iterationen. Egentligen betvivlar jag inte heller att Intel hade haft ledartröjan nu om de inte varit så bekväma och strulet på tillverkningssidan. Jag håller med om att X86 är en utdöende instruktionsteknik men det betyder inte att ARM kommer få fotfäste inom närmaste framtid förutom på Apples kommande Macbook-serie. Det är Apples processorer som börjar närma sig med IPC inte ARMs (Qualcomm med flera).

Hur tänker du att man ska sätta ditt Apple ARM-processorer i Windows burkar? Och jag förstår inte varför du hoppas på GPGPU? Det är inget som konsumeter har nytta av. Inga grafikkort gjort för konsumenter har GPGPU funktioner och Vega var väl sista grafikkortet som hade det?

Håll isär "IPC" och "prestanda per kärna".

Apples A13 är långt förbi alla x86 vad det gäller utfört arbete per kärna, sett till SPECInt, SPECFp och Geekbench 5 har Apple en ledning på ~80 % i mängd utfört arbete per cykel.

Är inte meningsfullt att direkt jämföra faktiskt IPC i dess tekniska korrekta mening, det p.g.a. vad jag belyser i detta inlägg. En av orsakerna att ARM64 (Aarch64) kan ha ett sådant övertag över x86 i utfört arbete per cykel beror bl.a. på att instruktionsuppsättning är specifikt designade för att vara effektivt för kompilatorer -> att översätta en viss C++, C#, Java, Rust snutt till maskinkod tar ofta färre Aarch64 instruktioner jämfört med x86 instruktioner.

Sett till just utförd mängd arbete per cykel har ARMs Cortex A serie historisk legat rätt långt efter high-end x86. Men efter ARM blev uppköpt av Softbank och avnoterade från börsen har man börjat introducera modeller som inte bara är billiga mer hög perf/W, man har allt mer skruvat upp absolutprestanda. Redan för två år sedan, med Cortex A76, nådde man en nivå där lika mycket arbete utförs per cykel som hos Skylake/Zen2.

Varken Apple eller ARM har gjort designer som kan klockas lika högt som AMD/Intels toppmodeller, så att matcha mängd utför arbete räcker inte för att nå samma absoluta prestanda. Vad som precis lanserats från ARM är Cortex X1, en CPU som verkar specifikt vara framtagen för desktop-användning. Cortex X1 förväntas gå att klocka till 3,0-3,3 GHz och den utför ~60 % mer per cykel jämfört med Skylake/Zen2 i program som är kompilerade "native" för respektive CPU.

DET är en CPU som kommer användas i nästa års Windows baserade ARM-laptops. Problemet är att Intel får ut Tiger Lake redan nu i sommar, den förväntas nå 4,4-4,5 GHz och ha ~25 % högre IPC jämfört med Skylake.

Så Tiger Lake motsvarar en Skylake på 4,5 * 1.25 = 5,6 GHz
Medan Cortex X1 motsvarar en Skylake på 3,3 * 1.6 = 5,3 GHz

Tror inte det räcker, ARM måste nog vara bättre än x86 för det börja hända något rejält på Windows-sidan.

GPGPU
Varför GPGPU? Därför att GPGPU är det enda som kan ge någon relevans till "stark" iGPU. Faktum är att iGPU har flera fördelar över dGPU i just GPGPU. Då CPU och GPU delar RAM är det otroligt låg kostnad att flytta jobba mellan dessa delar, vidare finns ingen begränsning av storlek (även om Pascal och senare har stöd att även utnyttja system RAM krävs att applikationen också använder en tillräckligt modern version av CUDA för att det ska fungera).

AMD pushade något de kallade "Fusion" rätt hårt efter uppköpet av ATI. Tanken har alltid varit helt rätt, vissa saker utförs långt mer effektivt på en GPU så dessa bör därför utföras på en GPU når sådan finns. Att man aldrig kommit någonstans med detta är primärt ett programvaruproblem, AMD har aldrig lyckats skapa någon vettig programeringsmodell för sina GPUer eller APUer.

Nvidia knäckte dGPU delen med CUDA. Enda problemet med CUDA är att det drar upp kostnaden, man måste alltid skriva två versioner. En för GPUer och en för CPUer om man alls vill kunna köra programmet på system som saknar Nvidia GPU.

Intel har nu knäckt den sista delen av detta. Dels har Intel tagit GPGPU-programmering ännu ett litet steg närmare "vanlig" programmering jämfört med CUDA. CUDA är nästan standard C, men bara nästan då man har en del icke-standard utökningar. OneAPI använder helt standard ISO C++20, självklart med extra bibliotek men språkmässigt finns inga icke-standard utökningar.

Ovanpå det blir normalfallet när man skriver mot oneAPI att programmet kommer automatiskt välja om det ska köra på CPU eller GPU. Det kommer föredra GPU, om kompatibel sådan saknas väljs CPU. Och handlar inte bara om att det "fungerar" på CPU, den testning jag gjort så här långt pekar på att det är riktigt effektiv CPU-kod man får. Det betyder att merkostnaden för att nu använda GPGPU är extremt låg.

CUDA används i de fall där man får x10 eller något sådant. D.v.s. vinsten är så stor att det är värt extrakostnaden i utveckling. OneAPI har långt mindre tröskel, finns egentligen ingen anledning att inte använda det så länge det är en nettovinst. Givet förväntad prestanda hos Tiger Lakes GPU lär den prestera minst i nivå med välskriven AVX-kod körandes på en 3950X.

Det sista är tyvärr dåliga nyheter för ARM på Windows, för om mycket prestandakritisk kod hanteras av GPGPU har man ju en "work-around" för att x86 inte är lika effekt som ARM64...

Skrivet av Nucky:

Synd om käre Bob om nu detta presenteras. Dråpslag Deluxe!

- https://www.theverge.com/2020/6/9/21284960/apple-arm-based-ma...

Årets presentation kommer jag verkligen inte vilja missa. Händer att jag kollar på dessa trots att Apple och deras produkter inte berör mitt liv det minsta. Nostalgiska känslor för iPod Classic finns dock kvar.

Lite märkligt men det enda som dyker upp i mitt huvud är en bild av Titanic när det har blivit vit uppenbart att skeppet kommer att sjunka.