Dites-nous en plus sur votre projet

Nous vous proposerons une formule adaptée à vos besoins, ainsi qu’une estimation de devis.
Laissez-vous guider

Pourquoi choisir Aneo pour votre projet ?

Aneo est une agence conseil en transformation qui vous accompagne tout au long de la vie de vos projets sur des problématiques de :

Le +  d’Aneo : le conseil sans frontière !

Notre richesse, c’est de vous proposer des équipes pluridisciplinaires, chaque membre avec une approche, une expérience et une sensibilité différente : coach agile, formateur soft skills, Data Scientist designer, Architecte etc. On mise sur la complémentarité des disciplines pour vous apporter la meilleure réponse !

Pourquoi choisir Aneo  pour votre projet ? - Aneo

Aneo, une organisation à part entière !

Depuis 2015, Aneo est une organisation plate à gouvernance plate. Aplatir la hiérarchie, supprimer les silos, instaurer des bonus collectifs, ce nouveau modèle d’organisation avec comme objectif: apporter plus de valeur  à l’entreprise, aux collaborateurs et aux clients.

Le + d’Aneo : l’inattendu !

La sérendipité, c’est « le don de faire par hasard des découvertes fructueuses ». Chez Aneo, nous croyons fermement que les meilleures solutions sont parfois les plus inattendues. Ne rien s’interdire, expérimenter, oser s’entourer de profils atypiques et avoir une obsession : apporter la juste valeur.

Aneo, une organisation à part entière !  - Aneo

Qui êtes-vous ?

Vous êtes pour

Votre secteur

1 seul choix possible
Assurance & Protection sociale
Banque et Finance
Industrie & Services
Santé

Vos besoins

Plusieurs choix possibles
IT & Digital
Transformation des Organisations
Stratégie Business
Pilotage de projets

Détails

Des précisions à ajouter sur votre projet ? (facultatif)
C'est noté !
Nous avons pris en compte les spécificités de votre projet.
Nos équipes vous contacteront sous 48h pour en discuter plus amplement.
Votre prénom *
Votre nom *
Votre adresse email pro *
Votre numéro de téléphone *
Bien reçu !
Nos équipes vous contacteront sous peu
pour discuter de votre projet.
Article

Outils de développement du SDK OpenCL d’Altera – Billet #3

Pour le billet du jour, nous allons nous intéresser aux outils de développement.

 

Le principal outil de développement utilisé dans le cadre de nos expérimentations a été le compilateur aoc. Celui-ci constitue la clef de voûte de ce SDK, nous permettant de générer un design FPGA à partir d’un kernel OpenCL. Il génère également un nombre important de fichiers, contenant des informations sur notre design qui seront d’une grande aide dans le processus d’optimisation.

 

La compilation avec aoc et Quartus II

 

Le compilateur aoc nous permet de générer une configuration du FPGA appelée « design », écrit en hardware description language (HDL) à partir du kernel OpenCL et des pragmas ajoutés à son attention. Cette phase représente un travail conséquent qui peut se traduire par une durée de compilation de plusieurs heures : il s’agit ici de mapper l’ensemble des instructions du kernel sur les ressources du hardware (portes logiques, blocs mémoires, digital signal processors …).

Le compilateur aoc génère donc essentiellement un binaire .aocx à partir d’un fichier .cl. Des flags bien utiles peuvent être passés au compilateur afin de pouvoir analyser le design généré, voire l’optimiser par la suite.
Notre ligne de compilation typique, ainsi que l’effet des flags de compilation appelés sont décrits ci-dessous :

>: aoc – v – – board s5phq_d8 – – report – – profile kernel.cl – o design.aocx

-v verbosité (succès / échec des différentes phases du processus de compilation)
–board désigne l’architecture ciblée (ici une board Stratix V, s5phq_d8)
–report génère un fichier précisant les optimisations réalisées sur le kernel, donne une estimation de l’utilisation du hardware durant la compilation
–profile instrumente le design pour pouvoir le timer et le profiler

 

A la fin de la compilation, un dossier contenant un grand nombre de fichiers décrivant notre design est produit. L’ensemble de ces fichiers est destiné à être lu par l’outil Quartus II, auquel nous avons eu accès. Cet outil semble être extrêmement riche et nous n’avons pas eu le temps de vraiment nous en servir; néanmoins les fichiers nous paraissant les plus intéressants sont lisibles en clair avec un éditeur de texte quelconque : il s’agit d’un log de la compilation et de l’area report donnant la quantité de hardware utilisée par notre design, sur le board FPGA ciblé. Ces fichiers seront utiles dans le processus d’optimisation, un aperçu de leur contenu « brut » est disponible ci-dessous.


Nous remarquons tout de même que le log de la compilation (en bas à droite de l’image précédente) n’est pas aussi complet que ceux à quoi nous nous attendions, qui était présenté dans la documentation Altera pour les kernels « single-workitem ». Celle-ci consignait des informations pour différentes parties du kernel, indiquant les boucles correctement déroulées (ou non), et des informations sur l’efficacité de nos transactions mémoire.

Nous retrouvons ici l’output du terminal, avec un log qui ne semble pas recéler d’informations intéressantes, nous laissant sur notre faim. Un log bien étoffé serait sans nul doute bien plus pratique pour nous guider dans les phases de profiling et optimisation !

 

Profiling et optimisation avec aocl

 

Le flag de compilation – – profile permet de générer automatiquement un fichier profile.mon après le run de l’application FPGA. Ce fichier contient un ensemble d’informations sur l’exécution du kernel , qui peuvent être visualisées à travers une interface graphique invoquée par aocl, de la façon suivante:

>: aocl – – report /path_to_design/file.aocx profile.mon

Les onglets présents dans l’interface contiennent notamment la timeline d’exécution du kernel et l’ensemble des lignes de code du kernel, avec plusieurs métriques attachées.

Dans l’onglet Kernel execution, la timeline présentée est plutôt simpliste comparée aux outils Nvidia sur GPU. Elle donne le temps d’exécution du kernel, et peut préciser les temps de lecture et d’écriture à la mémoire globale si la variable d’environnement ACL_PROFILE_TIMER a été mise à 1 avant le run de l’application.

En revanche, une quantité importante d’informations est disponible dans l’onglet source code, contenant toutes les lignes de code du kernel, auxquelles sont attachées des métriques de performance. Ceci permet de visualiser les instructions associées aux goulots d’étranglement du design (stalling du pipeline, lecture / écriture inefficace en mémoire …).

Attribute Informations sur la zone mémoire ciblée par l’opération (globale, locale, read/write, DDR/QDR, etc)
Stall % Pourcentage du temps durant lequel l’instruction ralentit / bloque le pipeline
Occupancy % Pourcentage du temps durant lequel l’instruction est exécutée par au moins un workitem
Bandwidth Bande-passante utilisée par l’opération de read / write, et efficacité de celle-ci

En particulier, le stall devrait permettre de savoir s’il peut être important de dérouler une boucle ou non, d’optimiser ou reformuler une certaine opération, alors que la bandwidth peut indiquer des transactions mémoire inefficaces / non vectorisées.

Le compilateur aoc constitue la clef de voûte de ce SDK et produit un nombre important d’informations accompagnant le design FPGA généré à partir du kernel OpenCL.Ces informations (utilisation de la board, log de la compilation…) peuvent être visualisées avec l’outil Quartus II, mais en tant que néophytes, nous sommes submergés par l’information et n’avons pas eu le temps de nous pencher sur ses capacités réelles. De plus, nos essais par la suite ne nous ont pas permis d’obtenir un log de compilation aussi détaillé que celui présenté dans la documentation Altera, ce qui aurait été bien utile.

Le processus d’optimisation est indissociable de la compilation, permettant d’instrumenter le design et de fournir des métriques à l’instruction prêt, mais aussi de visualiser la timeline d’exécution du kernel à travers une GUI appelée par aocl.

Nous poursuivrons dans le prochain billet avec une présentation de l’algorithme de cryptage AES 128-bit, qui sera notre cas pratique guidant le reste de l’étude. A bientôt !

La suite de la série FPGA est disponible ici.

Crédit : Damien DUBUC

Ça peut aussi vous intéresser
Les Femmes et le Numérique : une histoire de « Je t’aime, moi non plus … »
17 novembre 2021

Les Femmes et le Numérique : une histoire de « Je t’aime, moi non plus … »

Cet article sur les Femmes et le Numérique fait partie de la série sur le thème « Numérique et RSE ». Ils sont publiés par une équipe de consultants Aneo. Ada Lovelace, la pionnière ayant créé la machine analytique… Grace Hopper, « the Queen of software » témoin du premier…
En savoir plus
Article
DevOps et modèles organisationnels
14 septembre 2021

DevOps et modèles organisationnels

Le mouvement DevOps se présente comme une culture impliquant les process, l’outillage et l’organisation. Si les deux premiers axes semblent couverts par des démarches méthodologiques et techniques éprouvées (lean, agilité, automatisation, craft …etc), l’axe organisationnel manque – quant à lui – d’abaques fiables. De ce fait il devient primordial avant…
En savoir plus
Article
Tech Intelligence #6 – Développement du numérique en Afrique : où en est-on ?
20 juillet 2021

Tech Intelligence #6 – Développement du numérique en Afrique : où en est-on ?

La série Tech Intelligence explore des sujets variés de la tech : cloud, cybersécurité, blockchain … Aujourd’hui, découvrez un rapide coup d’oeil sur le développement du numérique sur le continent africain. Cliquez ici pour retrouver les autres sujets traités par Tech Intelligence.  Tout miser sur la téléphonie…
En savoir plus
Article
Vous avez un projet de transformation
digitale pour votre entreprise ?