Améliorations de l’utilisation de mémoire et du processeur dans Qt 3D

La performance et la stabilité de Qt 3D ne cessent de s’améliorer, grâce au travail acharné de moult contributeurs. Sa performance est principalement due à son architecture très flexible, qui sépare la partie visible (le rendu) des calculs (les aspects, responsables de la gestion des entrées et des animations, notamment). Ces aspects fonctionnent en parallèle, sur d’autres fils d’exécution, afin d’exploiter au mieux les processeurs multicœurs modernes ; ils nécessitent également une certaine duplication des données, pour éviter les synchronisations inutiles. De plus, les aspects de Qt 3D exécutent leurs travaux en définissant un certain nombre de tâches et leurs dépendances, afin d’avoir une granularité maximale dans l’ordonnancement des tâches. Pour le moment, Qt 3D est beaucoup retravaillé, au vu des plans futurs pour Qt 3D Studio.

L’utilisation de processeur de Qt 3D a énormément diminué depuis sa première version, en Qt 5.6, jusque la prochaine à venir, Qt 5.11. Ces améliorations sont dues à bon nombre de facteurs : des améliorations du solveur de dépendances entre tâches (qui s’exécute plus rapidement et donne de meilleures solutions), de QThreadPool (une classe de Qt Core utilisée pour gérer une série de fils d’exécution, mais en quantité moindre que requise pour Qt 3D), des caches de certaines tâches très gourmandes en CPU (comme QMaterialParameterGathererJob, dont le code était entièrement réexécuté à chaque image).

Avec le même genre de travail, la consommation de mémoire a franchement diminué, surtout dans les applications les plus simples. Par exemple, la démo avec une bille qui tourne consomme quarante-cinq mégaoctets en moins (nonante-deux avec Qt 5.6.3, quarante-sept avec Qt 5.9.4). Une application plus complexe, du style de celles réalisées avec Qt 3D Studio, passe de deux cent vingt à cent trente-cinq (infographie).

Sources et images : CPU usage improvements in Qt 3D, Memory usage improvements in Qt3D.

Advertisements

Quelles sont les améliorations à venir dans l’extension Qt pour Visual Studio ?

L’intégration de Qt dans Visual Studio n’a pas toujours été très utilisable, il a fallu un certain temps avant que la deuxième version soit rendue publique et prenne en charge les versions les plus récentes de Visual Studio. La prochaine version sera numérotée 2.2 et apportera un grand nombre de changements pour en faciliter l’utilisation.

L’un des plus gros changements sera l’utilisation de MSBuild pour gérer la compilation et l’intégration des générateurs de code de Qt, à savoir moc, rcc et uic. Jusqu’à présent, ces outils sont appelés dans une étape supplémentaire de compilation, indiquée pour chaque fichier séparément. Cette approche était la seule possible pour les versions antérieures de Visual Studio, mais a maintenant de sérieux problèmes, surtout pour les plus gros projets. En particulier, on ne peut pas définir une telle étape pour tous les fichiers d’un certain type — avec comme inconvénients une performance réduite et des fichiers de projet extrêmement gros. Aussi, ces étapes ne peuvent pas avoir leur propre page de configuration, contrairement aux autres parties de la compilation comme l’édition des lien ou la compilation proprement dite.

MSBuild, au contraire, se base principalement sur les fichiers de projet (.vcxproj) pour définir les opérations de compilation. Des règles définissent tous les outils prédéfinis, que ce soit le compilateur ou l’éditeur de liens : chacun peut être appliqué sur un certain sous-ensemble de fichiers. Des outils externes peuvent aussi être ajoutés, en utilisant une syntaxe similaire à ceux qui sont prédéfinis, avec une flexibilité totale — et une page de paramètres pour l’utilisateur.

La prochaine version des Qt Visual Studio Tools inclura des règles MSBuild et des cibles spécifiques à moc, rcc et uic. Les nouveaux projets utiliseront automatiquement ces définitions (même lors de l’importation d’un fichier de projet Qt), les anciens devront être convertis (mais cette opération ne sera pas obligatoire). Cependant, les fichiers de projet Visual Studio resteront portables : ils ne requerront pas l’installation de l’extension.

Cette modification en profondeur de l’extension a des avantages non négligeables en termes de performance. Ainsi, pour la version précédente, ajouter dix fichiers à un projet avec vingt configurations prenait presque quarante-cinq minutes ! Presque l’intégralité de ce temps était pris par la modification des propriétés pour les fichiers générés. Avec la version 2.2, la même opération ne prendra plus que… trois secondes ! En moyenne, les temps sont réduits de nonante-cinq pour cent.

Voir aussi : Qt in Visual Studio: A New Approach Based on MSBuild, Qt in Visual Studio: Improving Performance.

NVIDIA DRIVE détaille son SoC Xavier

NVIDIA s’est lancé depuis quelques années dans la productions de SoC, dans la famille Tegra, c’est-à-dire des puces intégrant tous les éléments de base d’un système informatique, avec un processeur central, de la mémoire et, dans le cas de NVIDIA, un processeur graphique. Ils ont notamment trouvé place dans certaines tablettes ainsi que dans la console de jeu Nintendo Switch. La dernière génération, Xavier, a été récemment dévoilée et il s’agit d’un des SoC les plus denses jamais conçus, avec neuf milliards de transistors sur trois cent cinquante millimètres carrés. La partie graphique est gérée par la dernière génération de cartes NVIDIA, Volta.

Le processeur est constitué de huit cœurs ARM 64 bits conçus entièrement par NVIDIA, sous le nom de code Carmel (les précédents processeurs Tegra mélangeaient des cœurs conçus par ARM et d’autres par NVIDIA). Il possède bon nombre de fonctionnalités orientées sécurités, comme la gestion de la mémoire ECC et le mode de calcul en double exécution (deux processeurs effectuent les mêmes calculs et vérifient qu’ils obtiennent les mêmes résultats). Côté GPU, on a droit à cinq cent douze cœurs de calcul Volta, pour une puissance de calcul totale de mille trois cent milliards d’opérations en virgule flottante à trente-deux bits par seconde. Nouveauté de l’architecture Volta, il comprend aussi vingt cœurs de calcul tensoriel. Ces deux parties ne consomment que vingt watts aux fréquences de base.

La production de masse devrait arriver fin 2018. Plus tard, ce processeur devrait être intégré dans la prochaine itération de la plateforme DRIVE PX, nom de code Pegasus, qui devrait intégrer deux cartes graphiques Volta indépendantes et deux processeurs Xavier, à destination des voitures autonomes.

Source : NVIDIA DRIVE Xavier, World’s Most Powerful SoC, Brings Dramatic New AI Capabilities.

TSMC confiant sur sa capacité de production

À l’occasion de la présentation de ses résultats annuels, le fabricant de semiconducteurs TSMC a rassuré sur le futur de ses processus de fabrication. Contrairement à Intel, TSMC ne fait que la fabrication de semiconducteurs, sans conception des circuits.

À court terme, dix produits devraient utiliser la première itération du processus en 7 nm de TSMC dès ce trimestre, pour un total de cinquante d’ici fin 2018. La phase de qualification des puces produites est en cours pour les deux usines du groupe. Contrairement au processus le plus avancé disponible à présent (10 nm), le 7 nm (CLN7FF) est prévu pour tous les clients à un tarif abordable : le 10 nm n’est utilisé que par Apple (et représente pas loin d’un quart du chiffre d’affaires de l’entreprise !). La production en volume devrait débuter vers juin 2018 pour les premiers produits en 7 nm (Apple ayant la priorité sur les autres clients).

En 2019, les premiers processus faisant appel aux ultraviolets extrêmes devraient arriver sur le marché dès le premier trimestre : les premiers tests déjà effectués semblent concluants (une bonne partie des puces SRAM produites est fonctionnelle), tant en CLN5FF (5 nm) pour le CLN7FF+ (7 nm deuxième génération). Ce dernier a des caractéristiques très proches du 7 nm, mais utilisera de l’EUV au lieu de techniques plus traditionnelles pour la fabrication, avec des caractéristiques légèrement améliorées (on parle de puces plus petites de 10 %, avec une performance améliorée de 10 %). TSMC utilise actuellement des sources de 160 W, celles à 250 W sont proches de l’utilisation en production. Les premiers produits en CLN7FF+ devraient donc arriver en 2019, ceux en 5 nm en 2020.

En 2018, cependant, TSMC utilisera surtout son processus 12 nm, avec cent vingt nouveaux produits attendus. D’ailleurs, la société ouvrira plus tôt que prévu une nouvelle usine à Nanjing, en Chine, pour combler l’augmentation forte de la demande avec ces processus bien maîtrisés.

Toujours au niveau construction, une autre usine est en cours de construction à Tainan, du côté de Taiwan : elle devrait être complètement achevée d’ici fin 2021, mais commencera sa production début 2020. Elle devrait débuter directement avec le processus en 5 nm, les phases suivantes de construction apportant le processus en 3 nm (production en 2022).

Sortie de Qt Creator 4.6 Beta

Qt Creator 4.6 s’annonce comme une version avec un certain nombre d’améliorations d’utilisabilité, mais sans révolution majeure ; la première préversion Beta est maintenant de sortie. Le modèle de code C++ utilisant Clang a été fortement retravaillé. Notamment, il utilise maintenant Clang 5.0 (au lieu de l’antique 3.9), ce qui lui ouvre la compatibilité avec C++17 ; les informations de type sur les symboles proviennent également de Clang, de telle sorte que les variables auto sont correctement résolues. Également, clang-tidy et Clazy peuvent être intégrés aux diagnostics affichés dans l’éditeur de code. Toutes ces fonctionnalités doivent cependant être activées manuellement.

Pour faciliter la navigation dans le code, la barre d’outil correspondante dispose de trois filtres supplémentaires. “b ” (avec un espace, donc) permet de sauter directement à un favori dans le code. “t ” lance un item du menu principal (Fichiers pour la plupart des plateformes) : ainsi, “t sess expe” correspond à File > Sessions > Experimental Stuff. “= ” évalue une expression JavaScript, avec le même moteur d’exécution que Qt Quick ; la seule exception est que les fonctions de l’objet Math sont directement disponibles : ainsi, on peut directement taper max(1, 2) au lieu de Math.max(1, 2).

L’éditeur de modèles a été fortement retravaillé pour cette version. Il gère désormais l’alignement du texte et les noms d’objet sur plusieurs lignes. L’export vers une image peut se faire sur certains éléments ou sur tout le diagramme. Plus de panneaux comprennent le glisser-déposer.

Voir aussi : la liste exhaustive des changements.

Source : Qt Creator 4.6 Beta released.

Sortie de Clazy 1.3

Clazy est un outil d’analyse statique prévu spécifiquement pour Qt. Ses versions précédentes ont déjà permis d’inciter les développeurs à suivre moult meilleures pratiques, mais ne se sont pas encore attaquées aux signaux, slots et connexions : Clazy 1.3 vient combler ce manque.

Un premier cas géré est celui où quelque chose qui n’est pas un signal est pourtant connecté comme s’il en était un. Cependant, sans Clazy, un code comme celui-ci compilerait sans problème, puisqu’il n’y a pas d’erreur de syntaxe C++ — juste une erreur de sémantique Qt.

// warning: MyObj::mySlot is not a signal [-Wclazy-connect-non-signal]
connect(obj, &MyObj::mySlot, &MyObj::mySlot2);

Une variable locale ne peut pas être capturée dans une fonction anonyme si elle est utilisée dans une connexion : en effet, quand le signal correspondant sera appelé, le contexte courant sera probablement détruit… et le code plantera lamentablement.

void myFunction()
{
    int localVar = ...;
 
    // program will crash when signal is emitted!
    connect(m_object, &MyObj::mySignal, [&localVar] { ... }); 
}

La forme de connect() avec trois arguments ne devrait pas être utilisée, puisque celle avec un argument de contexte permet d’effectuer certaines vérifications à l’exécution et donc d’éviter certains plantages (dans l’exemple suivant, si m_receiver est supprimé).

connect(m_widget, &MyWidget::textChanged, [this] (const QString &text) {
    m_receiver->update(text, false);
});
connect(m_widget, &MyWidget::textChanged, m_receiver,
        [this] (const QString &text) { (....) });

Qt::UniqueConnection ne peut pas être garanti quand le receveur du signal est un foncteur, une fonction anonyme ou une fonction globale, mais aucun avertissement ne peut être généré par le compilateur, d’où l’apport de Clazy.

Ajouter des slots dans une classe qui hérite de QThread n’est pas forcément un problème en soi, mais est souvent un signe de code mal conçu : en effet, ces slots sont exécutés dans le fil d’exécution correspondant à l’objet QThread, mais pas dans le fil QThread. Il vaut souvent mieux utiliser des objets travailleurs.

Toute utilisation de l’ancienne syntaxe avec SIGNAL() et SLOT() est aussi signalée : en effet, elle ne permet pas au compilateur d’effectuer beaucoup de vérifications, contrairement à celle utilisant des pointeurs vers des fonctions membre.

Si certains types ne sont pas normalisés avec les macros SIGNAL(), SLOT(), Q_ARG() ou Q_RETURN_ARG(), quelques allocations de mémoire inutiles sont effectuées.

// warning: Signature is not normalized. Use void mySlot(int) instead of void mySlot(const int) [-Wclazy-connect-not-normalized]
o.connect(&o, SIGNAL(mySignal(int, int)),
          &o, SLOT(void mySlot(const int)));

Les API surchargeant les signaux d’une classe de base sont souvent difficiles à utiliser et causent des défauts difficiles à trouver. De plus, syntaxiquement, Qt permet de surcharger un signal avec une méthode qui n’en est pas un et vice-versa. Clazy signale tous ces cas, ainsi que ceux où un signal est marqué comme virtuel (moc affichait déjà un avertissement à l’exécution dans ces cas).

Souvent, un slot n’est pas une méthode constante (comme pourrait l’être un accesseur). Un signal n’a pas besoin d’être marqué comme constant. Ces cas arrivent cependant fréquemment lors d’une interaction avec du code QML, mais il vaut mieux utiliser Q_PROPERTY ou Q_INVOKABLE qu’un slot.

Pour des raisons de lisibilité, les signaux devraient toujours être émis avec le mot clé emit (ou la macro Q_EMIT), non comme de simples méthodes. De même, ces mot clé et macro ne devraient être utilisés qu’avec des signaux.

Les connexions par nom sont une vieille fonctionnalité, qui n’a jamais été très populaire et ne devrait plus être utilisée. De fait, simplement renommer un objet pourrait casser des connexions — ces constructions sont donc extrêmement fragiles. La nouvelle syntaxe de connexion rend les choses explicites à la compilation.

Les propriétés Q_PROPERTY non constantes devraient toujours avoir une méthode NOTIFY, pour prévenir de tout changement de valeur. Bien que les utilisations de ces méthodes ne se soient réellement popularisées que depuis QML, n’importe qui pourrait en avoir besoin — GammaRay, par exemple.

Source : Nailing 13 signal and slot mistakes with clazy 1.3.

La lithographie à ultraviolets extrême fin prête

Les processus actuels de fabrication de semiconducteurs semblent être en bout de course. Les nouvelles évolutions sont de plus en plus difficiles et bon nombre de pistes ont été évoquées pour que la technologie continue à évoluer au niveau de la lithographie (passer d’un masque définissant les processeurs à la réalisation effective sur un matériau semiconducteur) : changer de matériau (remplacer le silicium par l’arseniure de gallium et d’indium, par exemple) ou changer de bande de fréquence pour créer les circuits sur le silicium (la bande optique — 193 nm pour le moment — par des rayons ultraviolets extrêmes, dits EUV en anglais — 13,5 nm).

Cette dernière piste faisait l’objet de développements intensifs ces derniers temps, mais sans que tout le monde s’accorde sur le fait que la technologie sera prête à temps (avant que d’autres ne donnent de meilleurs résultats à des coûts similaires). Il y a six mois, ASML, le principal fournisseur de machines pour l’EUV, annonçait atteindre une puissance de 250 W… avec quatre ans de retard et uniquement en laboratoire.

Samsung promettait d’être le premier à produire des puces avec ce procédé, dès la seconde moitié de 2018. La compétition n’est pas en reste : GlobalFoundries, TSMC et Intel pourraient suivre dans les trois à six mois. Il n’empêche que ces derniers ne sont pas toujours aussi ouverts quant à leurs annonces : les plans d’Intel ne sont pas toujours clairs, mais la société a néanmoins acheté bien plus d’outils EUV que toute autre société active dans le domaine.

La mise en production devrait se faire pour toutes ces sociétés de la même manière : au niveau d’un nœud dénommé 7 ou 10 nm, mais en deuxième itération. Les premiers processeurs gravés avec cette finesse le seront avec des outils plus conventionnels (qui n’ont pas tellement évolué depuis les années 1980), poussés à leur extrême limite ; les suivants le seront avec l’EUV. La technique de l’EUV continuera de s’améliorer avec les années : si une puissance de 250 W sera suffisante pour le moment, il faudra probablement monter à 500 W pour le nœud suivant (3 nm), voire 1 kW pour celui d’après (1 nm) — alors que la consommation électrique d’une telle machine atteint déjà 1 MW pour émettre des ultraviolets à 250 W.

Le raisonnement est que cumuler ces deux changements fondamentaux (finesse de gravure et processus de lithographie) risque d’être trop difficile. Par contre, se passer de l’EUV serait catastrophique, la technologie pouvant réduire fortement les coûts et augmenter les vitesses de traitement : vu la différence de longueur d’onde, GlobalFoundries a déclaré qu’une puce qui nécessite aujourd’hui quinze étapes de production au niveau de la lithographie n’aurait plus besoin que de cinq avec l’EUV.

Un dernier problème doit toujours être résolu pour que l’ère de l’EUV s’avance : les masques utilisés. Avec l’EUV, ils ne ressemblent pas vraiment à ceux utilisés précédemment : avec une source de lumière à 193 nm, le faisceau traverse le masque pour imprimer les composants nécessaires sur le silicium ; avec l’EUV, la lumière est réfléchie sur le masque et ses dizaines de couches de matériaux divers. Ces masques peuvent avoir des imperfections lors de leur fabrication : dans ce cas, les processeurs imprimés ne pourront pas fonctionner. Il faut donc les inspecter précisément pour voir s’il y a des défauts et les corriger le cas échéant. On peut toujours utiliser les outils précédents, mais ils fonctionnent avec une longueur d’onde de 193 nm : ils peuvent détecter une série de défauts, mais ils ne sont pas assez précis pour tout voir. Les outils d’inspection par faisceau d’électrons ont une résolution suffisante (ASML a produit les premières machines), mais sont bien trop lents. Au lieu de vérifier le masque, il est aussi possible de vérifier les processeurs fabriqués, mais ce procédé est extrêmement lent. Samsung semble le plus avancé sur ce point, avec un outil d’inspection par actinisme.

Un autre problème, bien que moins sérieux, se présente au niveau des masques. En effet, malgré toutes les précautions prises, toutes les machines utilisées produisent de la poussière. Il faut protéger les masques de cette poussière, sinon les processeurs produits auront un défaut dû l’ombre produite par ce grain de poussière. La technique actuelle est d’apposer une pellicule de protection sur les masques, mais il n’y a pas encore vraiment de matériau qui laisse passer les EUV et résiste à toutes les conditions particulières (subir les déformations mécaniques et les photons de très haute énergie). Pour le moment, les fabricants de semi-conducteurs préfèrent utiliser des masques nus

Source et détails : EUV Lithography Finally Ready for Chip Manufacturing.