Spec rasar mot Intels optimeringar

Men...om en processor är optimerad för att få bra prestanda i ett visst test så är det väl snarare testerna som är dåliga om de inte testar processorerna på ett sätt som är relevanta i ett verkligt scenario?

Kompilatorn är optimerad, inte processorn.

Det påminner mig Wolksvagen skandal, då de ertappades med artificiella ändringar i sin programvara för att visa mindre CO utsläpp från deras bilar vid kontroll test.

Tror du missförstår? Det står inte nånstans att testet inte är relevant?
Hela grejen är att det här är ett benchmarkprogram som är byggt för att kunna jämföra olika CPU:ers relativa generella prestanda.
Då kan inte intel gå in och göra optimeringar (i kompilatorn) som är specifika till exakt bara det här testprogrammet!

Tanken är ju att du som konsument ska kunna jämföra resultat och extrapolera det generellt till vad du kan förvänta dig om du bygger ett liknande program själv… och det kommer förstås inte stämma om intel optimerar specifikt för testprogrammet!
Intel kommer ju inte handknacka optimeringar för ditt program så du får motsvarande prestandaboost…

VW satte sig i folks medvetande. Men de är knappast ensamma.

https://en.m.wikipedia.org/wiki/Diesel_emissions_scandal

Känns tyvärr som hela världen är så här ganska ofta. Trevligt att det upptäcks och hängs ut i media så de inte tror att någon vill ha dessa fusk

Annars kommer någon börja kalla uppskalning för riktiga pixlar och bättre än native

Jag tror du missförstår honom.

Real life kompilator är 100m häck
Denna kompilator testar 60m sprint

Intel tränar för 60m sprint och blir bättre. Men är lika dålig på 100m häck

Iaf så jag förstår honom

15 år sedan men detta glömmer man ju inte.
https://techreport.com/review/intel-graphics-drivers-employ-q...

Jag tycker inte det är en bra jämförelse:
Först och minst viktigt: Vi vet inte hur verklighetsnära testet är. Vad framgår det nånstans att det är mer 60 m sprint än 100 m häck?

Sen, och det här är det viktiga: om vi utgår från din jämförelse så har intel tränat och optimerat för 60m sprint på en specifik testbana som ägs av testföretaget. All specialträning de lärt sig som ger extra bra resultat där, kommer inte ge motsvarande resultat på någon annan 60 m sprint bana i världen!
Förstår du inte problemet med en sån specifik optimering?

Det är en annan sak på flera sätt men den viktigaste skillnaden är väl just att de i ditt exempel optimerar verklig användning, något som kommer användarna av deras produkter till gagn.

Men ja, om de hyperoptimerar för 3dmark-slingorna på ett sätt som inte även går att applicera på spel, då blir det mer jämförbart.

Värt att notera (och Linux skapare påpekade detta för ett gäng år sedan): ingen har lyckats göra ett "fusk" för kompilator-testet i någon av SPEC-versionerna. Enda sättet att få bättre resultat här är att faktiskt göra en bättre CPU. Sen just för Linus Torvalds och andra vars primära flaskhals i en dator är kompileringshastighet så är detta naturligtvis sagt med stark bias mot vad som är "viktigast i en CPU".

Som tur är finns ett väldigt enkelt sätt att filtrera SPEC-resultat. Nästan ingen kommer ändå använda någon annan kompilator än GCC eller Clang^*, så vid jämförelse tittar man bara på resultat gjorda med de kompilatorerna.

^* Inte helt sant om man råkar använda Intels MKL, hyfsat vanligt att man där kör färdiga binäre och de är kompilerade med Intels kompilator, men är definitivt en nisch

Då SweC nämner Geekbench: dagens GB version följer SPEC rätt väl när det kommer till relativ prestanda mellan CPU-modeller. Det är nog ändå ett styrkebesked för båda som benchmark i stort då de får ett sådant utfall trots att vad man testar sett till specifika deltester skiljer sig rätt mycket. Man har helt enkelt fått till en bra täckningsgrad av de viktiga aspekterna i vad som krävs av en CPU i moderna program.

SPEC-rate (det tester med _r suffix) har dock mycket bättre skalning med CPU-kärnor mer likt GB4/GB5 där MT tester i praktiken är att man kör en separat instans av programmet per CPU-tråd. GB6 är långt vettigare för desktop, där kör man ett program som försöker använda tillgängliga kärnor på ett vettigt sett. Det minskade rätt minskade skalningen med kärnor mot tidigare versioner, men är långt mer likt "verkligheten").

SPEC har motsvarande GB single-thread tester, SPEC-speed, de med _s suffix.

GB6 är förskonad för just den här typen av fusk då man där använder färdig-kompilerade binärer medan man i SPEC bygger allt från källkod med vald kompilator.

Site-note: för heltal står också gcc testet för ~50 % av SLOC, så även det gör det svårare att fuska i just det testet.

Har aldrig tänkt på hur stor andel av SPEC som använder sig av Fortan (33 % av deltesterna använder det språket), när skrev någon här på SweC något i Fortran sist? Det förklarar ändå varför bl.a. Intel fortfarande investerar i något jag själv senast kom i kontakt med i x-jobbet 1997...

Lite så. SPEC är den överlägset mest kända benchmarksviten som finns för servermarkanden och som nämns på slutet i artikeln

"Det här är långt ifrån första gången en processortillverkare anklagas för att ha fuskat med optimering för benchmarktester. Intel, AMD, Apple och Nvidia har alla vid olika tillfällen upptäckts ha tagit fram särskilda optimeringar för att ge sina kretsar högre resultat i olika testsviter."

det påstående är nog tyvärr mer sant för just SPEC än någon annan benchmark.

Vissa deltester i äldre versioner av SPEC blev i praktiken värdelösa p.g.a. specifika optimeringar, oftast via kompilatorer men ibland även via HW. Värdelös då det var en fullt fungerade optimering för just SPEC-deltestet, men det hade i stort sätt noll påverkan i ett större sammanhang.

Den jämförelsen är som om Nvidia eller AMD skulle få kompilera om 3Dmark så det gynnar deras grafikkort. Tror du de resultaten skulle visa sig i spel?

Beror ju på vad du vill ha ut av testet.

SPEC används av vissa som ett viktigt underlag vid val av server HW. Rätt säker att de flesta inte bryr sig om de specifika programmen som testats utan de vill ha en generell gradering av prestanda. Det lär rimligen vara speciellt sant för de som bygger datacenter och hyr ut datorkraft, de vet ju inte ens vad kunderna kommer köra.

Sen givet vad jag skrev om SPEC-gcc (GB6 har ett liknande test baserat på LLVM/Clang): tillhör också de som primärt värderar en CPU efter hur snabb den är på att kompilera kod. Apples CPUer är i en egen klass där just nu, så något gör man väldigt rätt. M3 är ~30-40 % snabbare jämfört med 14900k/7950X räknat per kärna, vilket både SPEC-gcc och GB6-clang visar

Det märkliga här är just kompilering är en outlier, men en helt reproducerbar sådan. Finns andra fall där Apple CPU sticker ut, rendering med CPU är ett fall man sticker ut åt andra hållet.

Tar vi populära benchmarks: Cinebench är ju egentligen rätt värdelös som benchmark utanför ett par rätt specifika saker. Det är en OK indikation på prestanda för CPU-rendering (även om Blender och CB kan skilja sig en del) och det är en bra mått på om en CPU börjar throttla med tiden. Det är en rätt värdelös indikator på "generell prestanda", är enkelt att göra en CPU som rockar i CB men är rätt kass på det mest man gör på en dator (ju mer lik en CPU är en model GPU, ju mer sant blir detta påstående).

Geekbech förtjänade den kritik de tidigare versionerna fick, det var en rätt värdelös benchmark fram till version 4. I GB6 skulle jag hävda att det är den bästa benchmark man kan hitta. Historiskt var spelpretanda nog bästa indikatorn på "generell desktopprestanda", men vad som är viktigast för spel och för andra krävande uppgifter har divergerat en hel del.

GB6 + ett par speltester ger ändå det mesta, upp till var och en att vikta dessa beroende på vad man prioriterar.

TL;DR på den, att Apple dominerar prestanda för bärbara datorer sett till GB6 är en väldigt korrekt beskrivning av hur det faktiskt ser ut. SPEC skulle visa samma sak. Båda har rätt.

Alla modeller för testning som reducerar begreppet prestanda till en eller ett fåtal dimensioner är mer eller mindre meningslösa. Här är begreppet Goodharts lag relevant. Så fort ett mätetal blir ett mål (som poänger i prestandatester) upphör det att vara ett bra mätetal.

Sen kan anledningen vara mer eller mindre bedräglig. I detta fall är ett uppenbart fusk från Intels sida.

Va? Intel fuska? det har väl aldrig hänt förut? *

* = sarkasmus

rasa verb ~de ~t
1 störta om­kull el. ner; minska kraftigt: ​börsen rasade
2 riva ner, rasera
3 vara ur­sinnig: ​rasa mot ned­busningen

Från SAOL.

Vilket av ovanstående stämmer in på 'Spec rasar mot Intels optimeringar'? Tycker mest de verkar vara missnöjda med Intel i det här fallet.

Så trött på uttrycket 'rasar' som jag tror kvällspressen fick dille på någon gång i början av 2010-talet. Kan inte SweC hålla sig från Aftonbladet-stuket på rubriker, snälla, söta och rara?

OT: Intel gör väl vad som helst för att inte tappa mer mot AMD/ARM på serversidan, så inte förvånande alls.

Real-World Workloads!

3 rimligen?
Problemet är (åtminstone ur mitt perspektiv) inte att förstå vad som avses, det framgår väldigt tydligt, utan just clickbait-trenden på Swec.

Man börjar tröttna på era rubriker. Lämna gärna "rasar/raseri, ursinne" och liknande till kvällstabloiderna som inte har bättre förstånd.