Com evitar la funció ‘Cripple AMD CPU’ de Matlab

Una de les dificultats de les revisions de CPU és que representen el millor moment per avaluar noves funcions i programari, alhora que representen el pitjor moment possible per intentar fer una immersió profunda en qualsevol programari específic. De vegades, els revisors adopten proves perquè un proveïdor les ha recomanat, sense tenir en compte si la prova tindrà un rendiment idèntic en un sistema Intel o AMD. De vegades, el proveïdor no revela que una aplicació es compila de manera que condueixi a que les proves s’executin molt més ràpidament en una plataforma en lloc d’una altra. Aquest és un d’aquests moments.

Quan vaig publicar les dades de Matlab al nostre Threadripper 3970X / Cascade Lake X revisió conjunta, va ser perquè Intel havia recomanat aquesta prova i càrrega de treball com a aparador de la línia d’escriptori HEDT d’Intel. Vaig demanar recomanacions específicament, esperant que Intel tingués en compte algunes aplicacions que mostraran una escala relativament lleugera a la marca de 18 nuclis o per sobre amb la integració AVX-512. Fins i tot les aplicacions professionals no s’escalen perfectament per sempre i sabia que en aquesta revisió hi hauria una 'illa' de rendiment perquè Intel pogués mantenir-se a la intersecció de rellotges superiors i aplicacions de fils lleugers. En aquest context, s'hauria d'entendre per 'lleugerament' que significa 'aplicacions que no s'escalen fins a 64 fils' en lloc de 'aplicacions que no passen de 4 a 8 fils', que normalment volem dir quan cridem una aplicació amb un fil moderat. Era obvi que Threadripper 3960X i 3970X anaven a superar el 10980XE en totes les aplicacions que poguessin escalar per coincidir amb el seu nombre de fils, especialment en el cas del 3970X. Amb això, val la pena explorar les àrees que històricament havien estat les més fortes per a Intel per veure com es compararia el rendiment.



Intel va recomanar quatre càrregues de treball per a aquesta revisió: AIXPRT, Adobe Premiere Pro, Matlab i Sony Catalyst. Volia dedicar més temps a avaluar AIXPRT abans de començar a executar-lo en sistemes, cosa que el feia menys atractiu. Ara Adobe requereix que els proporcioneu una targeta de crèdit per iniciar una prova gratuïta de 7 dies del seu programari, de manera que no hi ha dubte. Vaig optar per provar Matlab i Sony Catalyst. jo era no conscient d’aquesta investigació i informe del redditor Nedflanders1976, realitzat fa uns vuit dies.



Ell escriu:

Matlab funciona notablement lent en CPU AMD per a operacions que utilitzen la biblioteca Intel Math Kernel Library (MKL). Això es deu al fet que l’Intel MKL utilitza un despatxador de CPU discriminatiu que no utilitza una ruta de codis eficient segons el suport de SIMD de la CPU, sinó basada en el resultat d’una consulta de cadena de proveïdors. Si la CPU prové d’AMD, el MKL no utilitza extensions SSE3-SSE4 o AVX1 / 2, però torna a SSE1, independentment de si la CPU AMD admet extensions SIMD més eficients com AVX2 o no.



No estic 100% segur que l’explicació anterior sigui del tot exacta respecte a les aplicacions modernes. El suport SSE2, per exemple, es basa bàsicament en les especificacions AMD64, de manera que sembla més probable que la biblioteca emeti almenys codi SSE2 per als xips AMD. Però SSE2 també té gairebé dues dècades d’antiguitat en aquest moment i els conjunts SIMD més nous com AVX i AVX2 ofereixen un rendiment molt més fort. És possible que els conjunts SIMD antics siguin compatibles amb els dos tipus de CPU, però els més nous es reservin a Intel. No puc parlar exactament de com optimitza Intel MKL, però, tal com mostren els resultats següents, podem demostrar categòricament que s’està aplicant un nivell diferent d’optimització de SIMD.

Hi ha una manera de desactivar aquest comportament a Matlab. Flandes escriu. Si sou un usuari de Windows amb Matlab instal·lat, creeu un fitxer per lots amb les dades següents:

@echo off
defineix MKL_DEBUG_CPU_TYPE = 5
matlab.exe



Inicieu l'aplicació mitjançant aquest fitxer per lots. Podeu fer-ho permanent introduint: 'MKL_DEBUG_CPU_TYPE = 5' a les variables d'entorn del sistema. Nedflanders1976 també té detalls sobre com realitzar aquesta tasca per a Linux. Hem jugat a provar algunes idees de variants, com ara configurar 'MKL_DYNAMIC = FALSE' i 'MKL_NUM_THREADS = 64' per veure si aquestes opcions millorarien el rendiment. No ho van fer. Es va obtenir el millor rendiment mitjançant la configuració anterior.

Resultats Matlab actualitzats

He actualitzat els nostres resultats de Matlab amb dades noves, que mostren l'impacte d'executar l'aplicació en aquest mode. Mostra el temps de resum total de tota la càrrega de treball a la part inferior de cada conjunt de resultats. Els millors resultats mostren el rendiment de les nostres CPU comparades sense cap canvi; el gràfic inferior mostra l’impacte amb el senyalador “set MKL_Debug_CPU_Type = 5”. Això pot funcionar per a altres aplicacions que també utilitzin la biblioteca MKL. Cal tenir en compte que, en molts casos, la CPU només es carrega durant un 53-55% durant aquest test, un nivell de càrrega que es correlaciona amb els fils del processador 17-18. Tanmateix, en aquest cas, aquesta configuració va resultar més ràpida que obligar el MKL a utilitzar un nombre més gran de fils. Dir a la màquina que utilitzi 48 o 64 fils només va augmentar el temps d’execució total al 3970X.

Feu clic per ampliar

El rendiment d’AMD millora entre 1,32 i 1,37 vegades en general. Els guanys de les proves individuals de vegades són molt més grans. Resultsbviament, aquests resultats són molt pitjors per a Intel, canviant el que semblava una estreta victòria sobre el 3960X i una bona exhibició contra el 3970X en una pèrdua total.

Quan està bé provar aquest tipus d'aplicacions?

No era conscient del comportament de Matlab quan vaig acceptar comparar l’aplicació per al llançament del Threadripper 3960X / 3970X / Cascade Lake, però aquest és un moment excel·lent per debatre el tema. El fet és que Matlab s’inclou en una configuració que es polaritza automàticament contra AMD: es nega a executar codi SIMD en una CPU AMD, tot i que la CPU admet el codi SIMD en qüestió.

No està malament comparar una aplicació del món real. El rendiment d'una aplicació del món real tenir utilitzar-lo pot ser rellevant per a les opcions de maquinari que feu. Si el vostre treball depèn d’executar càrregues de treball en una aplicació que afavoreix en gran mesura els microprocessadors Intel, és probable que compreu CPU Intel, fins i tot si preferiu comprar xips basats en dissenys ARM o AMD. La gent mereix saber com funciona realment el programari que executen en el maquinari que utilitzen, i Matlab és un programari important que fan servir més de 3 milions de persones. El fet que Matlab afavoreixi les CPU Intel no significa que els usuaris de Matlab no mereixen conèixer el rendiment de l’aplicació. Per descomptat que sí.

Però quan escollim proves per fer-ne una revisió, diem intrínsecament que hauríeu de prestar atenció aquests proves específiques i extrapolar les comparacions generals de rendiment a partir d’aquí. MathWorks té tot el dret d’enviar les biblioteques de programari que triï. Però si Matlab s’envia amb biblioteques que executin codi SIMD en CPU Intel però es neguin a executar aquest codi en CPU AMD, ho hem de saber abans d’acceptar provar l’aplicació en una revisió. Això no és negociable. Utilitzem aplicacions de revisió per donar a la gent una idea del rendiment que tindrà en altres aplicacions que serveixen al mateix mercat. El fet de dir que AMD funciona malament a Matlab planteja la qüestió de si les CPU AMD funcionen bé en aplicacions similars a Matlab. Això no és una implicació justa a menys que revelem simultàniament que Matlab genera un codi intrínsecament optimitzat de manera que inclini el terreny de joc a favor d'Intel.

Flandes us ho demana contacte Matlab farà una sol·licitud de funció si voleu una solució a aquest problema, però haureu de ser subscriptor de Matlab per enviar res. Independentment de si l’empresa canvia el seu enfocament, creiem que els usuaris finals han de ser conscients de com evitar aquest problema i restaurar el rendiment complet de les CPU AMD.

Podria haver inclòs la prova Matlab fins i tot si Intel hagués revelat que utilitzaria camins d'optimització específics d'Intel; Buscava proves que afavoritIntel compararà amb el recompte de nuclis molt més alt d’AMD. No tenia la intenció de situar aquestes proves com una altra cosa que el que eren: escenaris en el millor dels casos per a Intel, però escenaris realistes. He provat y-cruncher 0,78 per a aquesta revisió específicament perquè és un exemple d’aplicació optimitzada AVX-512 en què aquest conjunt de SIMD dóna a Intel un augment significatiu de la velocitat. No tinc cap problema en mostrar les CPU Intel o AMD al seu màxim avantatge. Només vull saber quan ho faig.

Els lectors es preguntaran per què no he saltat per la gola d’Intel basant-me en els fets històrics del problema del compilador 'Cripple AMD'. Permeteu-me que us tranquil·litzi, que en sóc plenament conscient. Els fets d’aquesta situació són la raó per la qual Intel s’hauria d’assegurar de tenir cura de quines proves es recomanaven i què comunicava sobre aquestes proves. Però tampoc tinc còpies de totes les restes de la guia d'Intel en els darrers cicles de llançament de HEDT i no puc dir que la prova s'hagi afegit per a aquest cicle en lloc de ser un programa que Intel també hauria recomanat en cicles anteriors. . Fins i tot si Matlab no s’esmentava en les anteriors directrius públiques de referència per a les CPU anteriors, havia contactat específicament amb Intel per demanar dades sobre proves que poguessin incorporar funcions com l’AVX-512. Intel hauria de tenir pràctiques per assegurar-se que els revisors coneguessin trampes com aquesta, però no puc dir amb seguretat que això no ha estat un error.

Dit això:

Els lectors han de ser conscients que també he escanejat Sony Catalyst amb el fitxer Pedaços de cua d'oreneta capaç d’eliminar la funció “Cripple AMD” dels executables i no va trobar cap signe de biaix pro-Intel després d’haver-lo executat; el Threadripper 3970X va executar la càrrega de treball de Sony Catalyst en el mateix període de temps després de l'execució de l'aplicació. En aquest punt, però, els pegats de Swallowtail tenen deu anys. Tot i que he confirmat que funcionen amb programari antic, no està clar que siguin capaços de detectar els mètodes que encara s’utilitzen per evitar que el codi s’executi de manera òptima en processadors AMD. Ja no estic segur de si Sony Catalyst Edit representa el tipus d’aplicació de fils lleugers que esperava provar per a la revisió 10980XE o si utilitza camins de codi preferents encara no detectats per millorar el rendiment de les CPU Intel. Si més no, no estic tan segur com voldria ser.

Diré una cosa més sobre aquest tema. Pel que fa a mi personalment, qualsevol programari que afirma que és compatible amb AVX, AVX2, SSE o qualsevol altre codi SIMD hauria d’indicar de manera destacada si aquest codi s’executa únicament si s’admet Intelmicroprocessadors. Si no informeu els clients que el vostre programari no executarà el codi ideal a la seva plataforma a causa dels límits codificats a la vostra aplicació, hauria de constituir una publicitat falsa. AMD anuncia les seves CPU basant-se en factors com l’assistència AVX2, però els proveïdors de programari no tenen l’obligació d’informar-vos si podreu utilitzar les funcions que heu pagat literalment. No hauria de ser així. Els desenvolupadors de programari multimilionaris poden realitzar la diligència necessària per ser honest sobre les seves pràctiques d’optimització. Nathan Kirsch a Ressenyes legítimes també té dades de proves i anàlisis sobre aquest tema, si voleu llegir-ne més.

Copyright © Tots Els Drets Reservats | 2007es.com