Discussion:Cloud de FPGA
Apparence
Relecture Antoine Huyghe
[modifier le code]- Bonjour, l'article est très bon et bien documenté. Voici quelques notes que j'ai recueilli lors de ma relecture.
- Bonjour, merci pour ce commentaire. Nous traiterons les retours au plus vite. Vincent Raynaud (discuter) 26 janvier 2021 à 17:25 (CET)
Accélération des Calculs
[modifier le code]- " Les FPGA sont connus pour surpasser les GPU dans de nombreuses applications spécifiques" Quelles applications spécifiques ? l'article cité ne précise pas non plus, mais donne ses sources. On peut remonter : S. Che, J. Li, J. Lach, and K. Skadron. Accelerating compute intensive applications with GPUs and FPGAs. In Proc. of the 6th IEEE Symposium on Application Specific Processors, pp. 101-107, June 2008. DOI: 10.1109/SASP.2008.4570793.
- Merci pour ce complément, j'ai rajouter des exemples de domaine--JawedM2CC (discuter) 8 février 2021 à 21:36 (CET)
- Cette source fait la comparaison entre GPU et FGPA.
- On peut utiliser la page 104 : "To achieve global barrier functionality, the programmer must allow the current kernel to : complete and start a new kernel. This is currently fairly expensive,thus rewarding algorithms which keep communication and synchronization localized within thread blocks as long aspossible. In the case of the FPGA, it is flexible enough to implement different types of barriers—including counter- and tree-based varieties—directly in hardware".
- Ce passage ne fait pas la comparaison entre GPU et FPGA, il parle des performances du FPGA lors de la synchronisation, dans le cas de la programmation parallèle.--JawedM2CC (discuter) 8 février 2021 à 21:47 (CET)
- Il est précisé "calcul grâce à leur puissance et leurs délais d'exécution rapides3", ce qui n'est vrai que dans certains problèmes. D'une part, les FGPA réalisent plus rapidement les opérations binaires.
- On peut écrire que sur un FGPA autant de bloc logique que ce que la surface re-programmable le permet, et réaliser toutes les operations necessaire en parallele. La plus grande force des FGPA est la capacité de paralléliser les calculs, et de résoudre à faible cout les problèmes liés à la parallélisation comme la synchronicité.
- FPGAs redundant in the field of video processing?. In Proc. of the 2005 IEEE International Conference on Field-Programmable Technology, pp. 111-118, 2005. DOI: 10.1109/FPT.2005.1568533
- Cet article montre une expérience où les FGPA ont des meilleures performances que les GPUs lorsque l'utilisation de la mémoire est importante.
- Merci pour ce complément d'information. Ca confirme que les FPGA sont plus rapides que les GPU. — Le message qui précède, non signé, a été déposé par JawedM2CC (discuter), le 8 février 2021 à 21:58 (CET)
- page 104-105 de DOI: 10.1109/SASP.2008.4570793 : "FPGAs can sometimes be very useful, and provide efficient methods to implement some specific functions, suchas bit-wise operations, which are not well supported on GPUhardware"
- Et la page 105, à propos d'un cas d'utilisation sur l'Algorithme de Needleman-Wunsch : "Figure 4shows that our FPGA implementation again has the lowestoverhead. "
- L'algorithme de Needleman-Wunsch a des applications direct sur la bio-informatique pour aligner des séquences de protéines ou de nucléotides : https://doi.org/10.1016/0022-2836(70)90057-4
- On pourrait ainsi utiliser cette reference pour la partie Médecine ( D'ailleurs peut-être renomé bio-informatique ?).
- Merci pour cet article qui compare les FPGA et les GPU et montre l’intérêt des puces FPGA dans certains domaines. Cependant, le framework est mené dans un environnement qui n'est pas un environnement cloud et sort du cadre de cet article. Vincent Raynaud (discuter) 7 février 2021 à 20:23 (CET)
Virtualisation
[modifier le code]- "Au lieu de classer les travaux existants en fonction des techniques de virtualisation, les cas d'utilisation ou les modèles d’exécution utilisés. Ces classifications pouvant changer au cours du temps. Il est préférable de choisir de les classer au niveau de l'abstraction des systèmes de calcul qui utilisent la virtualisation. Ce qui nous donne des sous-sections au niveau ressource, au niveau d'un nœud et au niveau de multiples nœuds18."
- Je ne comprends pas cette partie. Elle semble avoir quelques soucis de syntaxe
- Bonjour, j'ai pris en compte ta remarque et changé la formulation de cette phrase. Merci pour ta remarque pertinente. Ajustand (discuter) 2 février 2021 à 10:34 (CET)
Sécurité
[modifier le code]L'impact de la sécurité sur l'architecture
[modifier le code]- Il y a plusieurs occurrences du mot "crypté". Il faut éviter d'utiliser crypté et utiliser chiffrer à la place (cf https://chiffrer.info/ ).
- Modifications effectuées. Merci pour cette alerte pertinente.Vincent Raynaud (discuter) 8 février 2021 à 18:00 (CET)
- La partie "L'impact de la sécurité sur l'architecture" propose une solution à un problème qu'il n'a pas annoncé. Il sera plus facile au lecteur de comprendre l'interet de chiffrer une seconde fois les données si l'on n'explique les risques et les enjeux de sécurité du cloud.
- Depuis la référence donnée, la majeure problème est la confiance accordée par l'utilisateur au service de cloud, et le que l'on cherche à résoudre est un problème de confidentialité plus que de sécurité.
- "Users have to trust the cloud service providers that they will not leak users' data. We propose adding black boxes to the public cloud for critical computation, which are tamper resistant to most adversaries." http://www.hipore.com/stcc/2015/IJCC-Vol3-No1-2015c.pdf
- On pourrait donc écrire :
- "Habituellement, l'utilisateur doit faire confiance au service de cloud pour que ces données soit gardé confidentiel. Un tel confiance n'est cependant pas nécessaire, si la nature des données de l'utilisateur reste inaccessible grace à un chiffrement. On peut donc garder les donnés utilisateurs chiffrées tout du long. Lorsque les données une fois traitées doivent être rendus à un autre utilisateur, il est habituellement nécessaire de déchiffrer ces données pour les chiffrer à nouveau avec la clé de cette autre utilisateur. Un déchiffrement n'est cependant pas nécessaire si l'on utilise un proxy de re-chiffrement."
- Merci, j'ai intégré cette phrase d'introduction à la partie. --JawedM2CC (discuter) 8 février 2021 à 22:16 (CET)
- Peut-être "Impact de la sécurité sur l'architecture" et "La confidentialité des données" : traite le même problème. Il faudrait peut-être fusionner les deux parties
- Non, ces parties sont bien distinctes. l'une parle de l'impact sur les architectures et l'autre aborde la problématique de la confidentialité des données. --JawedM2CC (discuter) 8 février 2021 à 22:03 (CET)
Machine Learning
[modifier le code]- On peut renommer cette partie "Apprentissage automatique" si l'on souhaite éviter les anglicismes
- Merci pour ce retour. Je viens de modifier l'article en conséquence. Vincent Raynaud (discuter) 26 janvier 2021 à 17:24 (CET)
- "Les CPU et GPU ne peuvent pas atteindre un parallélisme élevé et consomment beaucoup." Au contraire, les GPU repose généralement sur un parallélisme élever pour être puissant. L'article donné en référence précise que les CPU et GPU n'atteigne pas de haut niveau de parallélisme dans la résolution du LSTM (Long short-term memory) spécifiquement. "However, owing to the recurrent nature,LSTM implementation on general-purpose processors like CPUs and GPUs cannot achieve highparallelism and needs high power consumption." Je propose de reformuler la phrase ainsi : "Dans l'implémentation de certains algorithmes utilise pour l' Apprentissage automatique comme Long short-term memory (LSTM), les CPU et GPU ne peuvent pas atteindre de parallélisme élevé et consomment beaucoup." — Le message qui précède, non signé, a été déposé par AntoineHuyghe (discuter), le 26 janvier 2021 à 10:55 (CET)
- Je fais la modification en ce sens pour mieux cibler l'affirmation. Cependant, je maintiens le fait qu'en terme de parallélisme, le FPGA est nettement meilleur que les CPU et équivalent aux GPU qui eux consomment bien plus pour une même tache exécutée. Vincent Raynaud (discuter) 1 février 2021 à 14:01 (CET)
Catégories :
- Article du projet Électricité et électronique d'avancement BD
- Article du projet Électricité et électronique d'importance faible
- Article du projet Informatique d'avancement BD
- Article du projet Informatique d'importance faible
- Article du projet Télécommunications d'avancement BD
- Article du projet Télécommunications d'importance faible