Intel: "Ice Lake-SP med 32 kärnor slår AMD:s 64 kärnor"

Ah, där kom den till sist: MKL, vilka minnen!
Ja det väldistribuerat och används nog i långt fler sammanhang än gemene användare anar.

https://en.wikipedia.org/wiki/Math_Kernel_Library

Intel MKL and other programs generated by the Intel C++ Compiler improve performance with a technique called function multi-versioning: a function is compiled or written for many of the x86 instruction set extensions, and at run-time a "master function" uses the CPUID instruction to select a version most appropriate for the current CPU. However, as long as the master function detects a non-Intel CPU, it almost always chooses the most basic (and slowest) function to use, regardless of what instruction sets the CPU claims to support. This has netted the system a nickname of "cripple AMD" routine since 2009.[9] As of 2020, Intels MKL, which remains the numeric library installed by default along with many pre-compiled mathematical applications on Windows (such as NumPy, SymPy).[10][11] Although relying on the MKL, MATLAB implemented a workaround starting with Release 2020a which ensures full support for AVX2 by the MKL also for non Intel (AMD) CPUs[12]

In older versions, setting the undocumented environment variable MKL_DEBUG_CPU_TYPE=5 could be used to override the vendor string dependent codepath choice and activate supported instructions up to AVX2 on AMD processor based systems resulting in equal or even better performance when compared to Intel CPUs.[13][14][15] Since at least Update 1 2020, the environment variable does not work anymore.[10][11]

At least two routes for hooking the MKL's internal routines to remove the discrimination have been discovered. The hook can be added at compile-time by linking or at run-time by injection. Agner Fog discovered that MKL and ICC binaries also have a non-discriminating dispatcher. A mkl_serv_intel_cpu_true function was discovered in 2019. Fog's intel_dispatch_patch provides code that hooks both routes.[16] According to Daniël de Kok, just patching the latter function on MKL 2020 Update 1 improves performance for AMD Zen.[17]

Rent spel? Döm själva. -Själv tycker jag att det är rätt patetiskt att det varit så under c:a 11 års tid.

Sedan är väl frågan om man skall ta nedan artikel med en nypa salt då den är publicerad: Apr 1st, 2020 08:01 Men test skall ha visat att det numera inte sker någon särbehandling i MATLAB.

https://www.techpowerup.com/265290/amd-processors-no-longer-c...

Mer vilseledande rubrik får man leta efter... känns ju som man är på Facebook och duckar click-bait.

Intel körde ett benchmark, du kan aldrig gissa vad som hände sedan...

Ja, ingressen säger mer, men en rubrik bör enkapsulera vad artikeln verkligen handlar om.

Ja fast överskrifter kan inte ge hela bilden på en mening.

Ser inte att någon gjort det - om jag missade någon så ber jag om ursäkt.

AVX = Advanced Vector Extensions, dvs en instruktionsuppsättning som kan behandla flera värden på samma gång. SIMD kallas det, och AVX är efterföljaren till SSE som i sin tur är efterföljaren till MMX. AVX kom i Sandy Bridge och AVX2 kom i Haswell. Skillnaden mellan de olika är främst att vektorerna (listorna med tal att jobba med) är längre. SSE jobbade med vektorer som var 128 bitar långa, AVX ökade till 256 och nu ökar AVX-512 till - du gissade det - 512 bitar. Du kan alltså köra 8 st 64-bitars flyttal (vanlig dubbelprecision) åt gången, vilket är dubbelt så många som gamla AVX.

Varje version har också lagt till en del nya instruktioner som är praktiska i vissa specifika fall. Gör man inte det så spelar inte funktionen någon som helst roll, men vill man ha den funktionen så är den värd massor. Exakt vad de instruktionerna är är lite utanför en ELI5 - det räcker att konstatera att det är extremt nischade instruktioner.

Förutom att dubbla exekveringsbredden igen, har AVX-512 dubblat antalet adresserbara register. Registren tar alltså fyra gånger så mycket plats som innan. På det hela taget är det här en instruktionsuppsättning som tar massor av transistorer att göra bra. AMD har varit rätt försiktiga med att spendera de transistorerna. De stödjer inte AVX-512 än, och Zen 1 stödde de bara 256-bitars instruktionerna lite halvhjärtat (genom att slå ihop två 128-bitars enheter). De kommer nog dit, men än så länge verkar de föredra att ha massor av kärnor istället.

Att kalla det patetiskt tycker jag är en rätt naiv inställning. MKL är "gratis", trots att det är helt uppenbart att Intel plöjer ned enorma FoU-resurser i biblioteket, ännu mer går in i OneAPI. Så är det då egentligen fel om man låter MKL vara "gratis" så länge man har en HW-dongel i form av Genuine-Intel CPU?

Varför ska man som AMD ägare på något sätt anse sig ha rätt att överhuvudtaget kunna köra MKL? AMD hade ett liknande bibliotek, men de har slutat utveckla det. Kör själv OpenBLAS på Zen, det är mer pålitligt än att köra MKL sett till prestanda men på Intel CPU har MKL i princip alltid bättre än något annat som man kan hitta.

Tack! Fint med återblicken på MMX, ett ord jag kände igen iaf. Ett tag sen jag sysslade med instruktionsuppsättningar (typ utbildningen runt millennieskiftet).

Vet du några konkreta exempel där man har fördel av dessa nischade instruktioner?

Om tredjepartsmjukvara är designad runt MKL, kan man som användare då bara välja ett annat bibliotek att använda istället? Om inte så ställer det ju till saken en hel del.

Ser inte att någon gjort det - om jag missade någon så ber jag om ursäkt.

AVX = Advanced Vector Extensions, dvs en instruktionsuppsättning som kan behandla flera värden på samma gång. SIMD kallas det, och AVX är efterföljaren till SSE som i sin tur är efterföljaren till MMX. AVX kom i Sandy Bridge och AVX2 kom i Haswell. Skillnaden mellan de olika är främst att vektorerna (listorna med tal att jobba med) är längre. SSE jobbade med vektorer som var 128 bitar långa, AVX ökade till 256 och nu ökar AVX-512 till - du gissade det - 512 bitar. Du kan alltså köra 8 st 64-bitars flyttal (vanlig dubbelprecision) åt gången, vilket är dubbelt så många som gamla AVX.

Varje version har också lagt till en del nya instruktioner som är praktiska i vissa specifika fall. Gör man inte det så spelar inte funktionen någon som helst roll, men vill man ha den funktionen så är den värd massor. Exakt vad de instruktionerna är är lite utanför en ELI5 - det räcker att konstatera att det är extremt nischade instruktioner.

Förutom att dubbla exekveringsbredden igen, har AVX-512 dubblat antalet adresserbara register. Registren tar alltså fyra gånger så mycket plats som innan. På det hela taget är det här en instruktionsuppsättning som tar massor av transistorer att göra bra. AMD har varit rätt försiktiga med att spendera de transistorerna. De stödjer inte AVX-512 än, och Zen 1 stödde de bara 256-bitars instruktionerna lite halvhjärtat (genom att slå ihop två 128-bitars enheter). De kommer nog dit, men än så länge verkar de föredra att ha massor av kärnor istället.

Svårt att argumentera emot här, intel har väl aldrig påstått att detta skulle vara någon slags öppen plattform så ingen anledning att öppna för andra processorer. Sweclockers har ju vart tydliga i att notera att detta inte motsvarade någon slags generell sanning om annan prestanda, och tror att de flesta som läser här förstår mer eller mindre att prestanda i AVX512 =/= generell prestanda på produkten i helhet.

Ang. MKL_DEBUG_CPU_TYPE=5 citerar jag texten från mitt tidigare inlägg, saxat från Wikipedia:

In older versions, setting the undocumented environment variable MKL_DEBUG_CPU_TYPE=5 could be used to override the vendor string dependent codepath choice and activate supported instructions up to AVX2 on AMD processor based systems resulting in equal or even better performance when compared to Intel CPUs.[13][14][15] Since at least Update 1 2020, the environment variable does not work anymore.[10][11]

Som sagt, rätt eller fel, döm själva.

Kan ju redogöra ytterligare varför jag tycker det är fel.

Jag har min åsikt klar i fallet givet den information som dykt upp under ett decennie, om det nu är tänkt att vara så, ett gravt etiskt klavertramp, varför åtgärdar dem det i senare versioner alls?

Istället för att förklara eller fortsätta hävda hur det ligger till och att det är "by design" för att produkten är bundlad till Intels CPU:er.
-Svepskälet de kört med under drygt ett decennium nu, är ju att de inte testar på annan hårdvara än Intel's vilket, på sätt och vis kan vara en godtagbar förklaring då de trots allt utvecklar både plattform och mjukvara.

Men när de har parametrar vars funktion är att förpassa andra system, baserat på varumärkesskyddad identifikation, till en mindre optimal väg istället för att använda samma tekniker som Intel själva gör, då hävdar jag att det snarare handlar om fulspel, att man vill hämma konkurrens och att det är ett medvetet val av tilltag p.g.a. den ställning man har på marknaden eller den spridning ens programvara har.

Finns väl många exempel på där företag plöjt ner enorma resurser i produkter/programvara som de sedan givit bort "gratis" i utbyte mot insamling av t.ex. användardata, inflytande, mindshare för branschstandard eller hopp om att "casha in" på det vid ett senare tillfälle, utan att för den delen försämra prestanda för konkurrenter?

Det är väl ändå ett lite smålustigt sätt som Intel använt sig av för att (vad man, givet ovan information, starkt kan misstänka) särbehandla andra tillverkare på plattformen.

Istället för att fråga:

-Vad kan du? Vad har du för färdigheter?

Frågar man här:

-Vad heter du?

Scenariot blir lite som att dra parallellen om att någon med t.ex. utländskt namn skall få ta den långa vägen in på arbetsmarknaden medan någon med inhemskt namn får förtur, orelaterat till vilken kompetens personen besitter för arbetsuppgiften det handlar om.
Så om personen med utländskt namn byter till ett svenskt så blir den helt plötsligt legitim i det fallet?
-Det var bara namnbytet som saknades?
Det viktiga är att personen som hanterar uppgifterna heter "Kalle" och inte "Steve" för då går det långsammare?

Jag tycker det vittnar om en ganska dyster trend om allt på x86-plattformen vore uppdelat på det viset.

-Vill du att ditt Radeon-kort skall funka bra, se till att du parar det med en "AuthenticAMD", inte för att den skulle efterfråga någon specifik teknik eller funktion utan endast för att namnet skall vara "rätt".

-Vill du att ditt spel skall flyta på? Se då till att det står AMD på hela ditt system annars får du patcha vartenda program eller spel utifrån vilka andra konponenter du kan ha stoppat in i din dator!

Just sådana tilltag är ju vad som förstör en annars rätt homogen plattform som x86, det som varit plattformens absoluta styrka, som öppnat upp för att så många företag skall kunna anamma plattformen och konkurrera på den samt driva utvecklingen framåt, det är här jag ofta känner att Intel är väldigt anti-competitive i sammanhanget. De tar hellre till fulknep än konkurrerar med bättre produkter och det är tyvärr så att historien upprepat sig på det området.

Så hela konceptet tycker jag är barnsligt. Särskilt när det kommer från ett företag av Intel's dominans och storlek.
Skall det vara bundlat, gör det då, men försämra inte prestandan baserat på vilket namn som dyker upp.
Som med det den ursprungliga artikeln handlar om AVX512, enbart Intel kan erbjuda det i nuläget, helt fine enl. mig om de boastar med vad de kan åstadkomma när det är en exklusiv teknik då den är helt fråntagen allt vad konkurrens heter. Det är ganska lätt att genomskåda.

Om däremot någon annan får möjlighet att konkurrera med Intel om AVX512, skall den tekniken då "få" inte användas i vissa sammanhang p.g.a. att fel namn står på produkten? -Fastän stödet mycket riktigt finns implementerat och fungerar?

-Hej, köp vår plattform med stöd för alla de senaste teknikerna, men det är inte säkert att du får eller kan nyttja dem, just beroende på att det råkar stå vårt varumärke på någon av produkterna i ditt system...

Det du beskriver är helt korrekt, men det hade inte varit x86 om förklaringen vore så enkel totalt sett