GEMM oneAPI : jusqu’à 2,58× plus rapide sur Iris Xe
Un benchmark sur Iris Xe annonce un gain de 2× avec oneAPI face à NumPy, jusqu’à 2,58× avec cache. Analyse des résultats, limites et méthode pour les vérifier.
Intel oneAPI sur Iris Xe : un gain réel ou un benchmark à relativiser ?
Faire tourner un calcul matriciel sur le GPU intégré d'un ordinateur portable peut-il vraiment aller plus vite que de le confier à NumPy et OpenBLAS sur le processeur ? Un benchmark consacré à Intel oneAPI 2026.1 apporte un début de réponse.
Sur un Core i7-1195G7 avec une Iris Xe (Gen11, Xe-LP), l'implémentation oneAPI annoncée à 0,062 s réalise le calcul environ deux fois plus vite que NumPy/OpenBLAS à 0,124 s. Une variante avec cache descend à 0,048 s, soit un gain d'environ 2,58×.
C'est intéressant, mais ce n'est pas suffisant pour conclure que oneAPI « fait toujours mieux », ni que le GPU intégré est automatiquement le meilleur choix. Les dimensions des matrices, le type de données, le nombre de répétitions et surtout le rôle exact du cache ne sont pas détaillés dans ce qui est partagé. En calcul haute performance, ces paramètres changent souvent la donne.
L'idée ici n'est pas de jouer au devin : on va plutôt voir ce que ce benchmark permet vraiment de dire, puis comment vérifier le gain sur votre propre machine, pour éviter de transformer une mesure isolée en promesse générale.
Les chiffres du benchmark oneAPI
Le test compare trois temps pour un calcul GEMM (multiplication de matrices, avec la forme généralement écrite comme une combinaison de produit et d'addition). La configuration est un Core i7-1195G7 et un GPU intégré Intel Iris Xe Gen11 (Xe-LP). Le logiciel indiqué est Intel oneAPI 2026.1.
| Implémentation rapportée | Temps mesuré | Gain par rapport à NumPy/OpenBLAS |
|---|---|---|
| NumPy/OpenBLAS | 0,124 s | Référence |
| oneAPI DPC++ | 0,062 s | 2,00× |
| oneAPI avec cache | 0,048 s | 2,58× |
Les ratios collent avec les durées annoncées : 0,124 / 0,062 = 2 et 0,124 / 0,048 ≈ 2,58. Sur ce cas précis, les deux variantes oneAPI sont donc plus rapides que NumPy/OpenBLAS.
Ce que signifie le gain annoncé
Un facteur 2 ne veut pas dire que « l'ordinateur devient deux fois plus rapide » partout. On parle ici d'une opération donnée, mesurée dans des conditions pas assez détaillées pour généraliser.
Et surtout : si votre application ne passe qu'une petite partie de son temps sur GEMM, accélérer ce morceau ne changera pas grand-chose au total. La seule mesure vraiment utile, c'est la durée bout en bout de votre application, sur votre cas réel.
La variante avec cache mérite d'être lue avec prudence
Le meilleur temps du tableau est 0,048 s, mais la source ne dit pas clairement ce qui est mis en cache : données brutes, préparation, étape de compilation, noyau déjà prêt ou autre chose.
Ça peut totalement se justifier si votre application réutilise la même structure de calcul (mêmes dimensions, mêmes entrées ou préparation identique) sur plusieurs exécutions. Mais si, dans votre cas, chaque GEMM arrive avec des matrices nouvelles (ou des paramètres qui changent), comparer « avec cache » à une référence qui inclut toutes les étapes peut répondre à une question différente.
Bref : la mesure peut être correcte - elle répond juste à un problème plus étroit que « oneAPI est plus rapide dans tous les cas ».
Pour situer le contexte, Intel présente oneAPI comme un ensemble de bibliothèques et d'outils pour développer sur plusieurs architectures. Le modèle de programmation mentionné, DPC++, explique le cadre. Tout ça aide à comprendre la technologie, mais ça ne remplace pas un test sur votre charge de travail.
Pourquoi un GPU intégré peut accélérer GEMM
GEMM correspond généralement à une forme du type C = alpha × A × B + beta × C : beaucoup de multiplication matricielle, puis une addition pondérée. On en croise en algèbre linéaire, dans certains traitements d'image et dans des morceaux de calcul utilisés par des modèles d'apprentissage automatique.
La multiplication matricielle expose souvent beaucoup de calculs qui peuvent être faits en parallèle. Un GPU est justement conçu pour exécuter énormément de tâches similaires en même temps. Quand l'implémentation est adaptée et que les matrices sont assez grandes, ça peut devenir très efficace.
Sauf que l'Iris Xe, comme tout GPU intégré, partage des ressources et la mémoire avec le processeur. Ce n'est pas une carte dédiée haut de gamme : les gains existent, mais ils dépendent beaucoup de la configuration.
La taille des matrices change le résultat
Sur des petites matrices, le temps passé à préparer l'exécution, répartir les données ou faire le « chemin » vers le périphérique peut dominer le coût du calcul lui-même. Dans ces cas, le GPU ne récupère pas assez de temps par le parallélisme.
Quand les matrices grossissent, le volume de calcul augmente et ces coûts fixes pèsent moins. C'est précisément pour ça que le benchmark devrait idéalement indiquer les dimensions exactes. Sinon, on risque de passer à côté de l'information qui explique le gain.
La précision compte aussi. En simple précision, double précision ou formats réduits, la quantité de travail matériel n'est pas la même. Et si les deux implémentations ne produisent pas exactement le même résultat (dans les tolérances attendues), le « meilleur temps » peut ne pas être comparable au bon niveau.
NumPy n'est pas une seule « vitesse »
NumPy est une interface Python, et les performances viennent souvent de bibliothèques BLAS en dessous. Le résultat dépend donc de l'OpenBLAS installé, de sa configuration et des instructions activées sur le processeur.
« NumPy/OpenBLAS » donne une idée, mais pas forcément toute la chaîne (versions, options, paramètres d'exécution). En face, oneAPI passe par DPC++ et une implémentation spécifique pour le GPU. Dans ce benchmark, le chemin oneAPI est avantageux pour le cas mesuré. Ça ne prouve pas que « toute opération NumPy est moins rapide », ni qu'« OpenBLAS est toujours derrière ».
Ce que les résultats ne permettent pas encore de conclure
Un benchmark n'est pas une propriété universelle. C'est une mesure avec un programme, des données, un environnement et une méthode précis. Ici, les temps sont assez concrets pour justifier un test, mais plusieurs éléments manquent pour comparer proprement.
Les informations manquantes pour comparer sans tricher
Pour reproduire ou interpréter sérieusement le résultat, il faudrait au minimum :
- les dimensions des matrices et le nombre de calculs ;
- le type numérique (et la précision attendue) ;
- le nombre de répétitions, et idéalement la moyenne, la médiane et la dispersion ;
- si la mesure inclut une phase de compilation, d'initialisation ou de transfert ;
- ce que le « cache » conserve exactement ;
- les versions de NumPy, OpenBLAS, du compilateur et des pilotes graphiques ;
- la température, le mode d'alimentation et la charge de la machine pendant le test.
Sur un ordinateur portable, ce genre de détails compte vraiment : les fréquences varient avec la température et l'énergie. Une mesure isolée peut aussi être biaisée par une première exécution plus lente (initialisation ou compilation), tandis que les suivantes « profitent » d'un état déjà prêt.
Ne pas mélanger des résultats qui ne parlent pas de la même chose
La source mentionne aussi un gain de 9,83× sur des données creuses et une réduction d'erreur 584× avec une méthode RK4. Ces chiffres ne portent pas sur le même sujet : matrices creuses et amélioration d'une méthode numérique ne sont pas directement comparables au benchmark GEMM du tableau.
Sans le même protocole de mesure et la même logique de comparaison, il serait facile de surestimer la portée de ces résultats. Au mieux, ils signalent qu'il y a d'autres expériences intéressantes à regarder - mais chacune doit être jugée sur son protocole propre.
En pratique, la question utile n'est pas « oneAPI est-il plus rapide ? ». C'est plutôt : cette implémentation est-elle plus rapide pour mon opération, avec mes données, sur la machine où ça tournera ? Et ça oblige à tester le cas réel, pas seulement la performance « théorique ».
Conclusion : choisir d'après votre charge de travail
Le benchmark publié donne un résultat clair sur son périmètre : 0,062 seconde pour oneAPI DPC++ contre 0,124 seconde pour NumPy/OpenBLAS, puis 0,048 seconde avec cache. Ça fait 2× et environ 2,58× par rapport à la référence, sur un Core i7-1195G7 avec Iris Xe. En clair : c'est une piste crédible pour accélérer certaines multiplications de matrices.
Mais comme les informations clés manquent, on ne peut pas en faire une promesse générale. Avant d'adopter oneAPI, documentez les matrices, la précision, le comportement du cache et le coût des transferts, puis refaites les mesures sur votre environnement. Et regardez le temps total de l'application, pas seulement celui de la fonction GEMM.
La prochaine étape est simple : prenez votre charge GEMM la plus représentative, comparez CPU et oneAPI dans des conditions proches, puis décidez à partir du gain réellement utile. Un benchmark « qui fait rêver » n'est pas toujours celui qui vous aide à décider.
Comment reproduire le test dans de bonnes conditions
Commencez par définir ce qui doit être accéléré. Si votre application fait une seule multiplication, mesurez cette opération. Si vous avez une suite de calculs, incluez aussi ce qui vient autour : chargement des données, préparation, transferts. Un benchmark doit refléter ce que vous voulez réduire.
Construire une comparaison équitable
Un protocole simple peut suivre ces étapes :
Le point 4 est crucial : distinguer la première exécution des suivantes change tout si vous compilez ou préparez un noyau au premier appel. Pour une tâche ponctuelle, ce coût compte. Pour un service qui enchaîne des milliers d'exécutions après initialisation, le temps récurrent compte davantage.
Vérifier le coût opérationnel
oneAPI peut apporter un vrai gain, mais il ajoute aussi de la complexité : dépendances logicielles, comportement de branchement selon l'environnement et gestion du cas où le GPU attendu n'est pas disponible.
Pour un outil interne utilisé sur quelques machines, ça peut être acceptable. Pour un logiciel distribué à des clients avec du matériel varié, la charge de support et de tests multiplateformes peut vite dépasser le gain mesuré sur un seul cas.
Et c'est souvent une bonne idée d'avoir un « chemin CPU » en repli. Ça rajoute un peu de code, mais ça évite de rendre toute l'application dépendante d'un périphérique spécifique. Le bon compromis dépend du volume de calcul, du parc matériel et du support que vous pouvez réellement maintenir.
Quand le gain vaut la peine d'être exploité
L'accélération est plus intéressante si GEMM représente une part importante et régulière du temps total, si les matrices sont assez grandes et si vous pouvez réutiliser des données (ou une préparation) de manière efficace. Et il faut surtout que le gain soit stable dans vos conditions réelles.
À l'inverse, si c'est ponctuel, si les matrices sont petites ou si vous devez couvrir des plateformes hétérogènes, optimiser l'algorithme ou réduire les copies peut être plus rentable. Le GPU n'est pas une fin en soi : c'est un levier parmi d'autres.