avatar de brokensoul

brokensoul

INpactien depuis le mardi 16 mai 2006

223 commentaires

28
avril
2016

GCC 6.1 disponible : la norme C++14 utilisée par défaut

ninja + ccache sur un ramdisk :D miam miam

@guy02 :
- Intérêt ci-dessus, c'est effectivement super casse-pieds quand tu codes.
- Un autre intérêt, c'est pour de l'intégration continue, quand le code de tout le monde est compilé en permanence à chaque commit (envoi incrémental sur un serveur). Ça permet de détecter les erreurs plus tôt, mais dans ce cas un compilateur 30% plus rapide peut te sauver un serveur (exemple pratique dans ma boîte : je code sous linux, mais notre code doit être cross-platform, windows/mac/linux. Du coup mes commits sont testés à chaque envoi sur les autres plate-formes, et souvent ça casse, alors que c'était invisible sur ma machine (par exemple si j'utilise quelque chose qui n'est pas géré par le compilo microsoft). Les serveurs qui font ça se retrouve à faire des centaines ou milliers de compilations par jour, alors un compilo 50% plus rapide c'est pas mal..
- Un dernier intérêt pour la compilation rapide, c'est qu'à un moment ça devient mieux de compiler puis d'exécuter plutôt que d'interprêter directement un truc moisi. On perd un peu au début, mais ensuite c'est tellement plus rapide que ça vaut le coup. C'est ce qui se passe sur le Web avec le JIT (Just-In-Time, compilation à la volée). Si la compilation prend trois plombes, ça ne marche pas

Après chacun ses priorités, tu peux avoir des secteurs d'activités dans lesquels la vitesse du binaire est effectivement le plus important
28
avril
2016

GCC 6.1 disponible : la norme C++14 utilisée par défaut

"Performant" pour un compilo, ça peut prendre pas mal de colorations différentes :
- binaire plus ou moins rapide
- binaire plus ou moins gros
- compilation plus ou moins rapide
- support des standards

Le compilateur de Visual Studio (msvc) est super lent (plus que gcc, c'est dire... surtout qu'il ne connait pas ccache par exemple), les binaires de sortie sont à ma connaissance comparables à gcc, mais il est super en retard sur le support des standards (C++11 vient tout juste d'être supporté). Par contre Clang (llvm) met tout le monde d'accord sur la vitesse de compilation, de loin
28
avril
2016

GCC 6.1 disponible : la norme C++14 utilisée par défaut

blague ? Vulkan c'est une API C, qui n'a pas grand chose à voir avec C++14 (dommage, ça la rendrait sans doute plus digeste). Des interfaces C++ existent, mais pas grand chose à voir avec GCC dans tous les cas.
 Si c'est le support HSA qui te fait penser à ça, c'est pas trop pour le même but a priori : Vulkan est orienté graphismes et très bas niveau (vise à maximiser l'utilisation GPU pour du rendu), alors que le support HSA est plutôt pour le calcul (ou les tâches lourdes et parallélisables en général, mais pas que graphisme) et vise à remonter l'abstraction, à rendre l'utilisation conjointe CPU/GPU plus facile (par exemple en fusionnant les espaces mémoire CPU/GPU)
28
avril
2016

GCC 6.1 disponible : la norme C++14 utilisée par défaut

Toutes depuis 4.8 effectivement il me semble, mais le support par défaut était resté à C++98 (il fallait passer le flag -std=c++11 pour activer). Je ne sais pas quoi en fait (:oops:), mais quelques cas doivent être gérés différemment par les deux standards, et l'idée était de garder la rétro-compatibilité. 
28
avril
2016

GCC 6.1 disponible : la norme C++14 utilisée par défaut

Sans doute pas trop d'intérêt, la compilation c'est une tâche pleine de branches, pas spécialement adaptée aux GPU (SIMD : Same Instruction Multiple Data, autrement dit tout le monde fait la même chose ou presque).
25
avril
2016

Raspberry Pi Camera v2.1 : capteur Sony de 8 Mpixels, toujours pour 25 dollars

Pour info, noir = no IR = pas de filtre IR = sensible IR
08
mars
2016

Rust 1.7 : le langage de Mozilla renforce encore ses bibliothèques


 Comme je disais plus haut, Rust oblige a réfléchir a ce qu'on fait de la mémoire, mais du coup on a pas plus a s'en inquiéter. Noter les lifetime est il est vrai déroutant au début, mais quand on s'y est fait c'est pas vraiment compliqué. Vu le temps que j'ai passé à débugger des erreurs mémoire louches en C++, je suis convaincu que ça en vaut la peine.
 
Un GC apporte une partie de la sécurité de Rust sans avoir a réfléchir à la mémoire, mais on a un runtime qui fait perdre le coté système du langage : le comportement bas niveau est beaucoup moins prédictible, il y a un impact sur les  performances et l'intégration avec d'autre langages devient hasardeuse voire impossible.
 

Hmm ok, il faudra que j'y consacre un peu plus de temps alors. L'argument de sécurité mémoire ne me convient pas complètement, tous les projets récents en C++ passent par des tests en CI et des vérifications par valgrind ou thread/memory sanitizers par exemple, ce qui doit arriver pas très loin de la sécurité de Rust. Je suis un peu pragmatique là dessus, pourquoi pas un peu plus de sécurité inhérente si ça ne devient pas un calvaire à coder, j'avais un peu testé Rust et le côté calvaire l'avait emporté, sans doute à tort. Une bonne IDE de conseillée ?
 
08
mars
2016

Rust 1.7 : le langage de Mozilla renforce encore ses bibliothèques


La gestion des références en Rust n'est pas plus compliquée que la gestion de la mémoire en C++ : ce sont les mêmes questions qui se posent. La différence est qu'avec Rust la question du cycle de vie est explicitée dans le système de types, ce qui est une excellente chose par rapport au C++, notamment pour la libisilité et la maintenabilité.

Maintenant soit tu as besoin d'un langage où la mémoire est gérée manuellement et dans ce cas il te faut C, C++, Rust, Ada ou autre, soit ce n'est pas le cas et ces langages sont complètement inadaptés et il te faut leur préférer un langage avec ramasse-miettes. Ces derniers conviennent à la très grande majorité des besoins mais pas à tous. Notamment lorsque la latence est problématique voire inacceptable et soumise à une exigence de preuves, ou sur les plateformes matérielles rudimentaires ou en mode kernel.

La comparaison avec le Go est dénuée de sens. Peut-être as-tu été intoxiqué par le marketing de Google qui le présentait comme un "langage système", ce qui a toujours été une absurdité.


Non, ça ne poutre pas, sauf si tu estimes que les effets secondaires sont un tel problème pour toi qu'il justifie d'ajouter des couches et des couches d'abstraction (complexité accidentelle++++).

En revanche il y a de bonnes idées, comme le fait de laisser le compilo décider de l'ordre d'exécution et que tout soit expression. Mais ne te laisse pas intoxiquer par la propagande Haskell.

Si la question de la complexité t'intéresse, out of the tar pit est l'un des meilleurs papiers jamais écrits dans notre domaine.

Pas besoin de spécifier de temps de vie en c++, c'est plus lisible et plus rapide à programmer, même si ça se fait au prix de la fiabilité. Rust est objectivement plus compliqué de ce point de vue, une simple structure qui stocke des pointeurs est pénible à écrire.
La comparaison avec Go vient de la jeunesse des langages de mon côté, des petits écosystèmes et des usages pas encore bien définis. Je travaille principalement en c++ et python, les deux ont des points forts très clairs, rust n'en est pas là. Les langages n'arrivent pas dans le vide, plein de gens savent faire du python et veulent du plus rapide par exemple, ils vont naturellement considérer java, go, rust ou c++.  En quoi est-ce que Rust est vraiment bon, c'est quoi la "killler app ?" Sûr OK, c'est un peu court. Pas vraiment plus concis que c++11, moins naturellement concurrent que Go, c'est une comparaison qui en vaut une autre, utiliser un "language système" est rarement un prérequis.
07
mars
2016

Rust 1.7 : le langage de Mozilla renforce encore ses bibliothèques

Langage intéressant IMHO, un peu testé, mais la gestion des références est à s'arracher les cheveux (définir le scope des références à la main est très bizarre par exemple).
 Dommage qu'à vouloir faire du 'safe' on arrive à quelque chose moins simple à programmer que du Go par exemple, sans être forcément plus fiable (à moins que quelqu'un puisse me contredire, je n'attends que ca).
27
janvier
2016

Firefox 44  : H.264, Brotli et système de notifications

un programme en espace utilisateur qui bloque le pc, c'est pas forcément normal.. Au delà des critiques sur l'OS, c'est peut être aussi signe que firefox n'y est pour rien