Je crois que tu te trompes sur les dev kernel. En sécurité, la plus part des bugs sont trouvé avec des fuzzers. Concernant l'analyse statique, il existe https://en.wikipedia.org/wiki/Sparse qui permet de vérifier des propriétés statiques (gestion de mutex, d'espace mémoire, etc...).
(1) il y a peu de moyens "simples" d'utiliser le multi-core
Les goroutines sont déjà un bon exemple. Tout ce qui est bas sur le passage de message simple ou les "grosses" boucles d'openMP.
C'est un peu pareil pour les instructions SIMD, si tu connais une façon simple de les ajouter au langage sans casser les garanties de sûreté du langage, raconte-nous.
Je ne comprends pas trop la question. gcc fait de la vectorisation automatique depuis un bail. Il a aussi proposé simplement des tableaux de 4 flottants ou 8 entiers avec les opérations qui correspondent directement sous forme de fonctions transformés ensuite en assembleur. Qu'est-ce qu'il y a de problématiques de donner accès à des fonctions qui correspondent aux instructions assembleurs ?
De plus, ocaml pourrait faire des map et fold sur des array de nombres, et proposer des versions vectorisés des opérations en question.
LLVM me semble être un exemple, ou alors les travaux sur des DSLs qui se compilent bien vers des GPU par exemple. Si tu veux des références plus précises, peux-tu en dire plus sur ce que tu cherches ? (Quel genre de code ?)
LLVM ? Dans quel domaine ? Je l'ai toujours vu comme un compilateur modulaire, mais qui n'arrive toujours au niveau de GCC en terme de perf. Pour les GPU, c'est openCL ou CUDA qui ressemble à du C pourris. Je n'ai pas vu de DSL. Un moment, j'avais vu la liborc qui proposait un pseudo assembleur qui avait un type de base "tableau" pour générer l'assembleur qui allait bien pour chaque architecture (x86,...).
Il y a pourtant eu pas mal de recherche sur des langages pour la programmation scientifique (X10, Fortress...) dont les aspects que tu mentionnes (à part l'assembleur je pense) étaient des aspects importants.
Forteress a l'air abandonné, je vais regarder X10 qui à l'air d'être un truc HPC pour du multicpu surtout.
Michael Hicks et ses collaborateurs à l'université du Maryland ont travaillé depuis 2001 sur le problème de "Dynamic Software Update"
[^] # Re: Le cerveau n'est pas logique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Je ne sais pas pourquoi j'avais raté ce message.
Je crois que tu te trompes sur les dev kernel. En sécurité, la plus part des bugs sont trouvé avec des fuzzers. Concernant l'analyse statique, il existe https://en.wikipedia.org/wiki/Sparse qui permet de vérifier des propriétés statiques (gestion de mutex, d'espace mémoire, etc...).
Les goroutines sont déjà un bon exemple. Tout ce qui est bas sur le passage de message simple ou les "grosses" boucles d'openMP.
Je ne comprends pas trop la question. gcc fait de la vectorisation automatique depuis un bail. Il a aussi proposé simplement des tableaux de 4 flottants ou 8 entiers avec les opérations qui correspondent directement sous forme de fonctions transformés ensuite en assembleur. Qu'est-ce qu'il y a de problématiques de donner accès à des fonctions qui correspondent aux instructions assembleurs ?
De plus, ocaml pourrait faire des map et fold sur des array de nombres, et proposer des versions vectorisés des opérations en question.
LLVM ? Dans quel domaine ? Je l'ai toujours vu comme un compilateur modulaire, mais qui n'arrive toujours au niveau de GCC en terme de perf. Pour les GPU, c'est openCL ou CUDA qui ressemble à du C pourris. Je n'ai pas vu de DSL. Un moment, j'avais vu la liborc qui proposait un pseudo assembleur qui avait un type de base "tableau" pour générer l'assembleur qui allait bien pour chaque architecture (x86,...).
Forteress a l'air abandonné, je vais regarder X10 qui à l'air d'être un truc HPC pour du multicpu surtout.
Vivement qu'un outil soit créé alors.
"La première sécurité est la liberté"