Sortie de Qt 3D Studio 1.0

Après de longs mois d’efforts acharnés, voici que les développeurs de Qt annoncent Qt 3D Studio 1.0, un système de création d’interfaces graphiques tridimensionnelles prévu tant pour les développeurs que les designers (ce qui n’est pas sans rappeler les objectifs de Qt Quick).

Qt 3D Studio Editor est l’outil de création de 3D Studio. Il s’agit d’une application multiplateforme qui peut importer des textures et des modèles de logiciels comme Photoshop, Maya ou MODO.

Qt 3D Studio Viewer est un outil de test pour les interfaces en cours de développement, avec une fonctionnalité de connexion à distance : on peut donc changer un paramètre dans Editor et voir directement son effet dans Viewer. Cette application est par exemple disponible dans Google Play.

Ces outils sont précompilés tant pour Windows que macOS et sont disponibles dans l’installateur en ligne ; pour Linux, il faut les compiler soi-même pour le moment. Quelques démos sont déjà disponibles, d’autres viendront s’ajouter dans les mois à venir. Bien évidemment, la documentation est en ligne.

Au niveau de la licence, tout Qt 3D Studio est disponible sous la licence GPL 3, à l’exception de Qt 3D Studio Runtime : un accord spécifique doit être signé pour les plateformes embarquées.

Dans le futur proche, la version 1.1 devrait sortir début février, avec le composant Data Node. L’avantage sera un meilleur découplage entre interface et logique du code utilisant Qt 3D Studio. Une nouvelle version de Qt 3D Studio Runtime, entièrement basée sur Qt 3D, sera disponible pour Qt 3D Studio 2.0, c’est-à-dire début mai 2018.

Source : Qt 3D Studio 1.0 Released.

Advertisements

Les fonctionnalités de Julia 1.0 seront arrêtées le 15 décembre

Julia est un langage de programmation de haut niveau, dynamique, mais orienté applications de haute performance (surtout pour le calcul scientifique). Malgré son jeune âge (il est apparu pour la première fois au grand public en 2012), il a déjà réussi à fédérer une certaine communauté (on estime à 250 000 son nombre d’utilisateurs en 2017).

Il s’apprête à voir sa première version finale, numérotée 1.0, après de longues années de développement. Toutes les fonctionnalités ne sont pas encore implémentées, mais cela ne devrait tarder : plus aucune ne sera acceptée dès le 15 décembre. À cette date, la première préversion Alpha de la 0.7 sera disponible, six mois après la 0.6. Julia 0.7 et 1.0 devraient être disponibles dans deux mois, si tout va bien.

Bon nombre d’évolutions attendues font leur apparition, comme la macro @isdefined pour déterminer si une variable locale existe ou encore un conteneur de type dictionnaire pour les arguments passés par nom à une fonction (en réalité, des tuples nommés, une autre nouveauté). Les valeurs manquantes, très utilisées en science des données, font leur apparition au sein même du langage (auparavant, elles l’étaient dans les paquets qui en avaient besoin). La macro @nospecialize est utilisée pour indiquer que le compilateur ne peut pas spécialiser une fonction sur le type d’un argument.

Certaines constructions peu lisibles ne sont plus acceptées dans le langage : 1.+2 pouvait être compris comme la somme d’un nombre à virgule flottante (1.) et d’un réel (2) ou bien comme la somme élément par élément entre listes (d’un côté, 1, de l’autre, 2 : 1 .+ 2) ; la juxtaposition de nombres en notation binaire, octale et hexadécimale ne pouvait être qu’illisible (0xapi était compris comme 0xa * pi). La bibliothèque standard a été considérablement allégée, en suivant un mouvement lancé depuis belle lurette : les fonctionnalités moins souvent utilisées (ou qui mériteraient d’être mises à jour plus souvent que le compilateur) ont été déplacées dans des paquets.

La sortie de la version 1.0 se fera en deux temps : tout d’abord, la version 0.7, qui aura exactement les mêmes fonctionnalités, mais avec des avertissements pour ceux qui utiliseraient d’anciennes syntaxes maintenant déconseillées ou supprimées ; très rapidement après, la 1.0, expurgée de ces messages. Ainsi, il sera conseillé de migrer son code vers la version 0.7 pour profiter des messages d’avertissement plus nombreux ; ensuite, le passage à la 1.0 se fera instantanément. Pour les nouveaux, par contre, seule la version 1.0 sera mise en avant.

Toutes les fonctionnalités souhaitées pour Julia 1.0 ne sont pas encore implémentées, toutefois. Si les développeurs ont le temps, tout ce qui sera possible sera implémenté d’ici au 15 décembre, pour laisser le temps aux tests avant la version finale. Les autres fonctionnalités seront ajoutées lors du cycle de vie de Julia 1.x, quitte à laisser des syntaxes indésirables acceptées : elles ne seront supprimées que lors du passage à Julia 2.0.

Voir aussi : la liste des changements apportés jusqu’à présent à Julia 0.7.0.

Source : 1.0 Feature Freeze Dec 15th.

Zinc : Scala se met à la compilation rapide

Ces derniers temps, Scala a vu quelques améliorations notables dans ses outils de compilation. Notamment, le compilateur incrémental Zinc a atteint la version 1.0.

Zinc est utilisé par bon nombre de développeurs Scala sans vraiment qu’ils s’en rendent compte : il est intégré dans sbt (pour lequel il a d’abord été prévu), pants, CBT, IntelliJ ou encore Scala IDE. Son seul objectif est d’améliorer les temps de recompilation en limitant le nombre de fichiers traités : Zinc analyse les dépendances entre parties du code et n’en recompile qu’une partie, celle qui a été changée depuis la dernière compilation et tout ce qui en dépend. Il est prévu pour que le résultat de cette compilation soit identique à une compilation depuis zéro — quitte à être conservatif et à recompiler des choses qui n’en auraient pas eu besoin.

Une des nouveautés de cette version 1.0 est l’analyse de dépendance au niveau des classes : auparavant, cette analyse était effectuée par fichier. Cependant, vu qu’un fichier Scala peut contenir un grand nombre de classes, cette manière de procéder menait à de grandes inefficacités. Grâce à ce changement, les temps de recompilation ont pu être améliorés d’un facteur quarante dans certains cas. Ce code était en partie prêt depuis mars 2016, mais a dû être retravaillé avant d’arriver en production, notamment au niveau de la compatibilité avec Java.

En pratique, sur ScalaTest, l’évolution entre Zinc 0.13 et 1.0 est très importante : la recompilation de ce projet de 40 377 lignes prend sept fois moins de temps avec la nouvelle version, en ajoutant simplement une nouvelle méthode.

Avec Zinc 0.13, la compilation incrémentale prend vingt et une secondes :

Zinc 1.0 réduit ce temps à trois secondes :

D’autres améliorations de Zinc 1.0 concernent de rares cas de sous-recompilation (qui causaient des problèmes de correction), des améliorations dans le pont avec Java ou dans la gestion des types. Les API ont été améliorées et le code a été entièrement migré vers Scala 2.12 : Zinc est maintenant prêt pour Java 8.

Sources : Speed up compile times with Zinc 1.0.

Les Intel Xeon Phi tirent leur révérence

Ils sentaient déjà le sapin depuis août : après avoir arrêté la production de cartes d’extension Xeon Phi, Intel annule la génération Knights Hill, pourtant déjà annoncée en grande pompe. Cela fait suite à une nouvelle stratégie pour atteindre l’échelle de l’exaflops pour les superordinateurs. Les Xeon Phi Knights Hill seront remplacés par “une nouvelle plateforme, une nouvelle microarchitecture spécifiquement prévues pour l’exaflops”.

Cette annonce suit de peu le retard du projet Aurora, un superordinateur du Département de l’Énergie américain qui devait montrer la voie vers l’exaflops à la fin 2018, à grands renforts de Xeon Phi. En octobre, le projet a été retardé à 2021 sans détail autre que la puissance cible passe de cent quatre-vingts pétaflops à mille pétaflops (c’est-à-dire un exaflops). Les explications vont bon train. Peut-être Intel aurait du mal à développer la troisième génération des Xeon Phi, surtout dans l’optique d’atteindre l’exaflops. Peut-être serait-ce la concurrence d’AMD et de ses EPYC. Peut-être le processus de fabrication 10 nm (pour lequel devait être prévus les Knights Hill) a-t-il encore du retard, avec peut-être une intervention du gouvernement américain face à cette annonce de retard. Officiellement, il s’agit de “changements dans la dynamique du marché”, afin d’atteindre dès que possible l’exaflops.

Ceux qui envisageaient de passer aux Xeon Phi sont invités à plutôt regarder du côté des Xeon plus traditionnels. Ils ne correspondent pas du tout au même besoin, toutefois : les Xeon Phi avaient cette particularité d’offrir un très haut niveau de parallélisme (même si les opérations sur chaque cœur sont plutôt lentes). Certains pourraient toutefois lorgner du côté des puces Xeon hybrides Nervana,

La nouvelle plateforme arrivera pour 2021, exactement pour Aurora. Elle inclura probablement des éléments de Nervana pour l’apprentissage profond, puisqu’elle sera prévue pour les applications des mégadonnées et de l’intelligence artificielle.

Source : Intel Dumps Knights Hill, Future of Xeon Phi Product Line Uncertain.

Sortie de Cutelyst 1.10

Fin octobre, la mouture 1.10 de Cutelyst, le framework Web en C++ utilisant Qt, est sortie. Par rapport à la version 1.7, on peut compter une extension pour la gestion des droits d’une application (ACL), du nom de RoleACL. Au niveau des améliorations de performance, la logique du contrôleur devrait être 30 % plus rapide ; l’analyse des données encodées dans l’URL devrait prendre moins de mémoire dans une série de cas. Le module WSGI fonctionne mieux sous Windows. Cutelyst s’intègre mieux à Qt Creator lors du développement d’applications.

Dans les projets connexes, on peut aussi noter html-qt, un analyseur de fichiers HTML5 entièrement développé selon la norme, ou encore simple-mail, une implémentation du protocole SMTP pour l’envoi de courriels.

De manière globale, la documentation a été améliorée, ainsi que la couverture des tests unitaires. Pour la petite histoire, ces deux derniers points sont largement inspirés d’une demande d’un utilisateur, qui posait une question sur la documentation : problème, le code de Cutelyst était faux, l’exemple proposé ne pouvait donc pas fonctionner. Depuis lors, son développeur est parti dans une course à la couverture du code.

Sources : Cutelyst 1.10, 1.9, 1.8.

Intel détaille ses possibilités en tant que fondeur, avec des processeurs pour smartphone en 10 nm pour 2018

Samsung et TSMC ne sont plus les seuls gros acteurs sur le marché : comme annoncé, Intel se lance dans la fonderie pour d’autres sociétés, en particulier pour des processeurs ARM. En d’autres termes, Intel recevra des commandes sous la forme de plans de puce à fabriquer. À l’horizon 2018, c’est ainsi le processus 10 nm qui sera disponible, notamment pour des smartphones. Pour diminuer les coûts, le processus 22 nm sera également disponible (il date de 2011), avec d’autres caractéristiques.

Un des objectifs de cette division est de regagner des parts de marché dans le segment mobile, après l’échec des puces x86 dans les téléphones (de nouvelles puces Atom ne sont plus développées). Les clients d’Intel pourront néanmoins faire fabriquer d’autres types de puces, comme des FPGA (au risque d’entrer en concurrence avec sa filiale Altera), des modems ou encore des puces spécialisées pour le HPC.

Deux variantes du 10 nm seront disponibles dans un premier temps : GP, pour la haute performance (comme les processeurs traditionnels) ; HPM, pour le mobile et la faible consommation d’énergie. La production “risquée” devrait débuter au printemps 2018. Deux autres générations sont prévues : en 2019, les GP+ et HPM+ devraient améliorer les fréquences, la consommation et la densité par des modifications incrémentales ; en 2020, les GP++ et HPM++ bénéficieront de couches métalliques repensées, ce qui devrait améliorer la fréquence et l’efficacité énergétique.

Pour d’autres marchés, notamment quand le prix est sous pression, Intel proposera un processus 22FFL, qui baisse la consommation avec une puissance de calcul limitée (par rapport au 10 nm). Deux autres générations sont également prévues.

Du côté ARM, grâce au partenariat avec le concepteur des processeurs, Intel peut proposer des cœurs Cortex-A55 à 2,35 GHz (ce qui ne devrait pas dénoter par rapport à la concurrence). Sur le processus 10HPM, les premières puces de test (des Cortex-A75) peuvent monter à 3,5 GHz, une fréquence très élevée pour des smartphones. Ces cœurs sont disponibles comme des blocs que les clients d’Intel pourront utiliser directement pour concevoir leurs puces.

Source et images : Intel will 10-nm-Smartphone-SoCs ab 2018 produzieren.

Clazy Web UI, une interface Web pour visualiser les messages de Clang

Clazy est une extension au compilateur Clang qui effectue une analyse statique principalement orientée Qt, afin de faciliter le déploiement de bonnes pratiques, mais aussi de limiter les allocations de mémoire dues à une mauvaise utilisation de l’API.

KDAB annonce maintenant, après Clazy, une interface Web pour faciliter la visualisation des résultats, ainsi que des messages produits par le compilateur en général : Clazy Web UI. KDAB en héberge une instance pour Qt, ce qui permet de voir l’outil en situation réelle.

L’interface est prévue pour être simple à utiliser : après avoir sélectionné un module Qt, elle montre tous les types d’avertissement trouvés lors de la compilation et les endroits dans le code. Il est aussi possible de filtrer les résultats bruts, afin d’éliminer les faux positifs ou encore les mentions les moins intéressantes.

Outre l’amélioration de l’outillage C++, l’objectif est bien évidemment d’attirer plus de contributeurs à Qt, en leur montrant une série de tâches relativement simples à accomplir. Cela pourrait les aider à franchir la barre de gerrit.

Source : Clazy Results Visualizer for Qt, Web UI to view clazy and gcc warnings.