Archives de l’auteur : dourouc05

Sortie de Qt Creator 4.0 RC 1

Publié le par
Répondre

Selon ses développeurs, la version finale de Qt Creator 4.0 ne tardera plus : la RC 1, sortie aujourd’hui, s’occupe de corriger un bon nombre de défauts détectés depuis la sortie de Beta, il y a à peu près un mois.

Les principaux changements depuis la dernière préversion concernent l’interface, avec un thème plat lustré : il est maintenant le thème par défaut de Qt Creator, les utilisateurs n’ayant jamais changé de thème le verront par défaut lors de la mise à jour. L’ancien thème est bien sûr toujours disponible, dans le menu Outils, Options, Environnement, Interface (option Classique).

Les binaires de cette nouvelle préversion sont disponibles sur la page des téléchargements de Qt.

Source : Qt Creator 4.0 RC1 released.

Les transistors nanomagnétiques atteignent les limites fondamentales

Publié le par
Répondre

Les processeurs actuels sont principalement limités par leur consommation énergétique : il n’est pas possible de garder tous les transistors d’une même puce allumés simultanément, car la densité d’énergie est beaucoup trop importante — chaque millimètre carré consomme trop d’énergie, la puce brûlerait à coup sûr sans désactiver des parties. Ce phénomène a conduit à la notion de silicium noir, c’est-à-dire les parties qui ne peuvent pas être utilisées à un instant donné dans un processeur. Un domaine de recherche dans les semiconducteurs concerne donc la création de transistors qui consomment nettement moins d’énergie (et donc dissipent moins de chaleur).

En 1961, des chercheurs d’IBM ont déterminé une limite absolue dans la consommation d’énergie d’un transistor (la limite de Landauer) : en effet, d’un point de vue thermodynamique, la bascule d’un transistor n’est pas réversible, ce qui s’accompagne inévitablement de pertes d’énergie (en application de la seconde loi de la thermodynamique). Cette valeur a été déterminée comme trois zeptojoules (3 10^-21 joules). A contrario, des transistors actuels optimisés pour la consommation d’énergie se placent au niveau de la picojoule, c’est-à-dire 10^-12 joules, soit un milliard de fois plus que le minimum théorique (!), pour la réalisation de puces mémoire magnétiques par transfert de spin (STT-MRAM). Les transistors plus courants consomment encore plus d’énergie.

En 2012, une équipe allemande a, pour la première fois, démontré expérimentalement que cette limite inférieure de consommation pouvait être atteinte. Ils ont, pour ce faire, utilisé une pince optique pour déplacer des perles de verre de deux microns de large (similaires à des bits) entre deux puits de potentiel. Une équipe américaine vient de montrer un résultat similaire, mais bien plus directement applicable à l’électronique : ils ont directement manipulé des bits faits d’aimants à l’échelle nanométrique. Ce genre d’aimants est déjà à la base des disques durs magnétiques actuels, mais également des mémoires de type STT-MRAM.

Des aimants nanométriques stockent l’information par la direction du champ magnétique de l’aimant. Avec un champ magnétique externe, les chercheurs ont pu inverser l’orientation du champ des aimants. En mesurant très précisément l’intensité et l’orientation du champ de l’aimant en fonction du champ extérieur, ils ont pu déterminer que cette opération consommait en moyenne six zeptajoules à température ambiante, soit le double de la limite de Landauer (sans compter, donc, la génération du champ utilisé pour manipuler les aimants). L’équipe estime que la différence par rapport à la limite théorique est principalement due à de légères variations dans l’orientation des nanoaimants : en effet, selon des simulations numériques, des nanoaimants idéaux atteignent exactement cette limite.

Cependant, ces progrès n’auront aucun impact sur les transistors utilisés dans les processeurs grand public à court terme, ni probablement à moyen terme : cette expérience marque un pas dans le passage entre la recherche fondamentale en physique et la recherche appliquée dans les transistors, mais il reste encore de nombreuses années avant une arrivée sur le marché.

Source (y compris l’image) et plus de détails : Zeptojoule Nanomagnetic Switch Measures Fundamental Limit of Computing.

NVIDIA annonce son architecture Pascal et CUDA 8

Publié le par
Répondre

NVIDIA en parle depuis un certain temps et dégaine, peu après AMD, sa nouvelle générations de processeurs graphiques, dénommée Pascal, un nom qui fait référence à Blaise Pascal, mathématicien et physicien français du XVIIe siècle. Les chiffres bruts donnent déjà le tournis : un tel GPU est composé de dix-huit milliards de transistors (huit milliards pour la génération précédente, Maxwell).

Sur la technique, ce GPU (nommé GP100) est le premier gravé en 16 nm, avec la technologie FinFET+ de TSMC, les précédents l’étaient en 28 nm. Pour un processus aussi récent, la puce est énorme : 610 mm², à comparer au 600 mm² de Maxwell sur un processus bien maîtrisé. Cette surface est utilisée pour les 3840 cÅ“urs de calcul (3072 pour Maxwell), ayant accès à un total de 14 Mo de mémoire cache (6 Mo pour Maxwell). Les cÅ“urs ont aussi augmenté en fréquence : 1,5 GHz au lieu de 1,1 pour Maxwell. Au niveau de la mémoire principale, la technologie HBM2 est utilisée au lieu de la mémoire traditionnelle GDDR5. Une puce Pascal dispose de seize gigaoctets de mémoire (contre douze, il n’y a pas si longtemps, chez Maxwell, maintenant vingt-quatre).

NVIDIA peut donc en profiter pour intégrer bon nombre de nouvelles fonctionnalités, tournées vers le segment HPC, comme sa connectique NVLink. L’une des fonctionnalités très utiles pour monter en performance concerne les nombres à virgule flottante : contrairement à Maxwell, les unités de calcul de Pascal traitent nativement des nombres sur soixante-quatre bits et seize bits ; ainsi, une telle puce peut monter jusque vingt et un mille milliards d’opérations par seconde (21 TFlops) en seize bits, cinq mille milliards en soixante-quatre bits (avec un facteur d’à peu près quatre entre les deux : les unités sur soixante-quatre bits sont grosso modo composées de quatre unités sur seize bits).

Toujours dans le HPC, la mémoire unifiée, entre la mémoire principale de l’ordinateur et celle du processeur graphique, a aussi vu quelques améliorations. Elles se comptent au nombre de deux. Tout d’abord, l’espace d’adressage a été considérablement élargi, ce qui permet d’adresser toute la mémoire centrale et celle du GPU (et non seulement un espace équivalent à la mémoire du GPU). Ensuite, les GPU Pascal gèrent les défauts de page : si un noyau de calcul tente d’accéder à une page mémoire qui n’est pas encore chargée sur le GPU, elle le sera à ce moment-là, elle ne doit plus être copiée dès le lancement des calculs sur le GPU.

L’apprentissage profond, le cheval de bataille de NVIDIA

Toutes ces avancées sont jusque maintenant principalement prévues pour le marché du HPC, plus particulièrement de l’apprentissage de réseaux neuronaux profonds, à l’origine de miracles récents dans le domaine de l’intelligence artificielle.

NVIDIA avance un facteur d’accélération de douze dans un cas d’apprentissage d’un réseau neuronal avec sa nouvelle architecture par rapport à ses meilleurs résultats l’année dernière. Ce facteur est énorme en seulement une année, mais il faut remarquer que la comparaison proposée n’est pas toujours équitable : les nouveaux tests utilisent deux fois plus de GPU que l’année dernière, de nouvelles fonctionnalités ont fait leur apparition sur les GPU spécifiquement pour accélérer ce genre de calculs (les nombres à virgule flottante sur seize bits). Il n’empêche, le résultat reste impressionnant.

Ces avancées réunissent cinq « miracles », selon la terminologie de Jen-Hsun Huang :

  • la nouvelle architecture Pascal ;
  • la technologie de gravure de puces de TSMC ;
  • la nouvelle génération de puces mémoire empilées (HBM2) ;
  • la technologie d’interconnexion entre GPU NVLink ;
  • des améliorations algorithmiques pour tirer parti des progrès précédents.

NVIDIA DGX-1, un supercalculateur dans une boîte

Les tests de performance ont été effectués sur une machine assemblée par NVIDIA, dénommée DGX-1, un monstre de puissance. Elle couple deux processeurs Intel Xeon E5-2698 v3 et huit processeurs NVIDIA Pascal avec 512 Go de mémoire vive et 1,92 To de stockage en SSD. Globalement, la machine peut fournir 170 TFlops pour la modique somme de 129 000 $. NVIDIA la résume comme deux cent cinquante serveurs rassemblés dans un boîtier. Elle est d’ores et déjà en vente, mais les livraisons devraient débuter en juin. Des bibliothèques existantes ont été adaptées pour cette machine pour en tirer le meilleur parti, comme TensorFlow de Google.

CUDA 8 et autres avancées logicielles

Pascal vient avec des améliorations matérielles accessibles par CUDA 8, la nouvelle version de l’API de calcul sur GPU de NVIDIA. Par exemple, les opérations atomiques en mémoire, utiles pour les opérations en parallèle sur une même case mémoire sans risque de corruption, gèrent plus d’opérations sur les entiers (en parallèle avec une implémentation matérielle plus complète). Les développeurs peuvent exploiter une structure d’interconnexion NVLink explicitement depuis CUDA.

Le profilage d’applications est encore amélioré, notamment au niveau de la répartition de la charge entre le CPU et le GPU, pour déterminer les parties où l’optimisation serait la plus bénéfique globalement. Pour ce faire, le profileur visuel montre maintenant les dépendances entre les noyaux de calcul du GPU et les appels à l’API CUDA, afin de faciliter la recherche d’un chemin critique d’exécution.

De nouvelles bibliothèques font également leur apparition au sein de l’écosystème, comme nvGRAPH pour l’analyse de graphes : la planification du chemin d’un robot dans un graphe énorme (comme une voiture dans le réseau routier), l’analyse de grands jeux de données (réseaux sociaux, génomique, etc.). NVIDIA IndeX, une bibliothèque de visualisation de très grands jeux de données (répartis sur plusieurs GPU), est maintenant disponible comme extension à ParaView. cuDNN arrive en version 5, avec d’importantes améliorations de performance.

Sources : Pascal Architecture (images d’illustration), Nvidia Pascal Architecture & GP100 Specs Detailed – Faster CUDA Cores, Higher Thread Throughput, Smarter Scheduler & More, NVIDIA DGX-1 Pascal Based Supercomputer Announced – Features 8 Tesla P100 GPUs With 170 TFLOPs Compute, NVIDIA GTC 2016 Keynote Live Blog (transparents NVIDIA), Inside Pascal: NVIDIA’s Newest Computing Platform, CUDA 8 Features Revealed.

Quelques mythes sur moc

Publié le par
Répondre

Qt est un framework C++ complet, parti des interfaces graphiques dans les années 1990 (avant la normalisation de C++) et maintenant extrêmement généraliste. L’un de ses points forts est probablement la connexion entre signaux et slots pour écrire des applications interactives : lorsqu’il se passe quelque chose dans l’application (l’utilisateur appuie sur un bouton, un paquet arrive du réseau, etc.), un signal est émis ; ensuite, le programmeur peut connecter un slot à ce signal : ce bout de code sera exécuté chaque fois que le signal sera émis. Pour implémenter cette fonctionnalité, dans les années 1990, vu l’état disparate des compilateurs, utiliser les templates C++ était impossible : les développeurs de Qt ont alors utilisé un générateur de code, nommé moc (metaobject compiler), qui sert d’autres objectifs (l’introspection et la réflexion, notamment). Avec les années, le système a été conservé, malgré le bon nombre de critiques : son importance a encore un peu grandi lors de l’arrivée de Qt Quick. Olivier Goffart, actuel mainteneur de l’outil, tente de remettre les pendules à l’heure.

Quelques mythes

moc ne réécrit pas le code qui lui est passé, il ne le réécrit pas : il l’analyse et génère de nouveaux fichiers C++, qui sont ensuite compilés de manière totalement indépendante. Sans l’outil, pour utiliser l’architecture actuelle de Qt, il serait nécessaire d’écrire de grandes quantités de code pour les tables d’introspection et d’autres détails nécessaires pour le fonctionnement des signaux et slots.

Il se concentre sur une série de macros définies par Qt pour générer son code : Qt ne définit pas de « nouveaux mots clés » C++. Pour définir une classe héritant de QObject, la macro Q_OBJECT évite au programmeur d’écrire une série de déclarations de fonctions (dont le code est généré par moc). Les signaux sont définis dans un bloc signals:, qui n’est autre qu’une macro qui correspond à public:. Bon nombre d’autres macros utilisées par le moc ne génèrent aucun code. Globalement, le code Qt reste du code C++, ce qui fait que tous les outils C++ traditionnels restent utilisables.

Son utilisation ne complique pas la compilation ou le débogage : la plupart des systèmes de compilation traitent de manière native moc ; de toute façon, il s’agit simplement d’une commande supplémentaire à appliquer sur les fichiers d’en-tête. En cas d’erreur à la compilation (ce qui est très rare), le code généré est plus facile à comprendre que l’embrouillamini généré par les templates C++.

Certains ont tenté de supprimer moc, comme CopperSpice, en promettant notamment une amélioration de performance. Cependant, cette affirmation n’est pas sous-tendue par des chiffres : le graphique ci-dessous indique que la taille des exécutables générés est bien plus grande avec CopperSpice (sans moc) que Qt (4 ou 5, avec moc). De manière générale, le code généré par moc est très efficace : il est entièrement statique et évite toute allocation dynamique de mémoire, ses données sont stockées dans les segments de données en lecture seule — là où CopperSpice génère ces mêmes données à l’exécution.

Finalement, moc évolue : depuis Qt 5, il gère complètement les macros, ce qui permet de les utiliser pour définir des signaux, des slots, des classes de base, etc. Q_PROPERTY n’autorisait pas, jusqu’il y a peu, les virgules dans ses arguments (par exemple, en lui passant un QMap), ce qui a été réglé en un rien de temps.

Des fonctionnalités absentes

Finalement, la plus grande critique de moc est probablement qu’il ne gère pas les classes avec des templates, des classes imbriquées ou l’héritage multiple. Cependant, si elles ne sont pas implémentées, c’est principalement parce qu’elles ne sont pas jugées importantes. Par exemple, une implémentation des templates a été rejetée il y a trois ans ; moc-ng, une implémentation de moc sous la forme d’extension du compilateur Clang, gère sans problème les templates et les classes imbriquées. L’héritage multiple reste possible à condition que QObject soit la première classe de base — ce qui permet bon nombre d’optimisations, de telle sorte que qobject_cast est bien plus rapide que la version standard dynamic_cast.

Et donc ?

moc n’est pas vraiment un problème, ses plus grands pourfendeurs sont généralement ceux qui le connaissent le moins. L’API et notamment le système de métaobjets et la connexion entre signaux et slots sont à la base du succès de Qt. Les avantages des autres solutions sont loin d’être clairs et moc n’est pas une limitation pour les développeurs.

Source : Moc myths debunked.

NVIDIA GameWorks : du code source libéré, de nouveaux modules

Publié le par
Répondre

Comme NVIDIA l’avait annoncé il y a peu, de grandes nouvelles traversent son programme GameWorks, avec de l’ouverture de code source sous licence libre et la mise à disposition de nouveaux modules. Cette boîte à outils est composée d’une série d’effets utilisables très facilement par les développeurs dans leurs jeux.

De nouvelles technologies

Trois nouvelles bibliothèques font maintenant partie du programme GameWorks, après avoir été testées dans des jeux déjà en vente, principalement pour l’éclairage et la gestion des ombres (toutes sont d’ores et déjà disponibles au téléchargement) :

  • NVIDIA Volumetric Lighting simule le trajet de la lumière et sa dispersion dans l’atmosphère et l’air, un effet utilisé dans Fallout 4, plus particulièrement dans les rayons crépusculaires ;
  • NVIDIA Hybrid Frustum Traced Shadows (HFTS) traite plus particulièrement les ombres et assure une transition plus douce entre les ombres bien droites à proximité de l’objet qui bloque la lumière et les ombres bien plus douces au loin, un effet utilisé dans Tom Clancy’s The Division ;
  • NVIDIA Voxel Accelerated Ambient Occlusion (VXAO) gère l’éclairage au niveau d’une scène avec une occlusion ambiante en temps réel : la différence par rapport aux techniques plus traditionnelles est l’utilisation de toute la géométrie de la scène, pas seulement la zone visible par la caméra ; cet effet a été utilisé dans Rise of the Tomb Raider.


NVIDIA Volumetric Lighting pour le rendu d’un rayon crépusculaire dans Fallout 4


NVIDIA Hybrid Frustum Traced Shadows pour le rendu des ombres dans The Division


NVIDIA Voxel Accelerated Ambient Occlusion pour l’éclairage global dans Rise of the Tomb Raider

De nouveaux solveurs physiques

À un autre niveau, dans la simulation physique pure, de nouvelles extensions ont été annoncées (des préversions privées sont actuellement disponibles) : l’une pour les corps rigies, NVIDIA PhysX GRB (GPU rigid body) ; l’autre pour les fluides combustibles, NVIDIA Flow.

NVIDIA PhysX GRB simule des corps rigides sur des processeurs graphiques, mais peut aussi exploiter le processeur principal en simultané (sans aucun écart en fonctionnalité selon la combinaison de processeurs choisie) : par rapport au code traditionnel, les calculs peuvent être accélérés d’un facteur six pour des simulations relativement lourdes ; une préversion privée est actuellement disponible, une version plus avancée devrait être rendue disponible dans les semaines à venir.

L’accélération sur le GPU concerne toutes les étapes du solveur, répliquées par rapport à la version CPU : les contraintes, les contacts, les phases de recherche. Cependant, au niveau de l’implémentation, la version GPU a été optimisée à certains points, comme la gestion d’îlots d’objets, pour gérer des scènes encore plus grandes. L’API est très similaire à celle de PhysX, ce qui facilitera l’utilisation de ce nouveau solveur ; cependant, tout le code GPU utilise NVIDIA CUDA, ce qui empêche son utilisation sur du matériel de fabricants concurrents mais devrait être compatible Linux et OS X.

NVIDIA Flow simule l’écoulement de fluides combustibles, ce qui modélise notamment le feu et la fumée ; la différence par rapport aux techniques précédentes est que ce solveur n’est pas limité à un volume prédéfini de simulation, puisqu’il adapte la grille de calcul aux nouveaux besoins. Contrairement à NVIDIA PhysX GRB, cette bibliothèque n’a pas de parti pris au niveau du matériel : elle utilise directement DirectX 11 et 12 et fonctionne donc sur du matériel AMD (mais pas sur des systèmes d’exploitation autres que Windows).

Toujours au niveau physique, la première version finale de FleX est maintenant disponible pour le grand public, un solveur GPU généraliste que NVIDIA a commencé à montrer en 2013, mais aussi intégré à Fallout 4 pour la gestion des débris.

Du code libéré

Il y a un an, NVIDIA montrait les premiers signes d’ouverture du programme GameWorks en mettant gratuitement à disposition les sources de PhysX, son moteur physique, à l’exception des parties GPU — mais pas sous une licence libre ; de plus, l’accès au dépôt GitHub est soumis à un enregistrement.

Cette semaine, d’autres composants ont été libérés de la sorte : NVIDIA Volumetric Lighting, récemment annoncé et détaillé plus haut ; NVIDIA HairWorks, pour la simulation et le rendu de cheveux et poils ; ainsi que NVIDIA HBAO+, un effet similaire au VXAO utilisé dans Rise of the Tomb Raider.

Ce qui est plus étonnant, cependant, c’est qu’un composant complet a été libéré : FaceWorks, pour le rendu de visages. La licence indique que tout développeur peut créer un travail dérivé et le redistribuer librement, tant qu’il indique qu’il exploite du code source venant de NVIDIA — ce qui ressemble très étrangement à du logiciel libre. Les les modèles 3D ne sont pas concernés par cette licence.

Sources : NVIDIA Advances Real-Time Game Rendering and Simulation With Launch of NVIDIA GameWorks SDK 3.1, GDC 2016: PhysX GPU Rigid Body and NVIDIA Flow (y compris vidéo de NVIDIA PhysX GRB et image de NVIDIA Flow), Fallout 4 Graphics, Performance & Tweaking Guide (image de Fallout 4), Tom Clancy’s The Division Graphics & Performance Guide (image de The Division), Rise of the Tomb Raider Graphics & Performance Guide (image de Rise of the Tomb Raider)

Google envisage de contribuer son StreamExecutor dans LLVM

Publié le par
Répondre

Google s’intéresse énormément aux différentes plateformes pour effectuer des calculs très intensifs en parallèle, notamment dans le cadre de sa solution libre d’apprentissage profond TensorFlow. La société a développé la bibliothèque StreamExecutor, qui simplifie la gestion des calculs parallèles par rapport aux flux de données, avec une exécution principalement prévue sur des accélérateurs comme des processeurs graphiques (GPU). StreamExecutor se propose comme une couche d’abstraction par rapport à OpenCL et CUDA (les deux technologies prédominantes pour le calcul sur processeurs graphiques), tout en proposant un modèle de traitement des flux similaire à celui de CUDA et une implémentation très proche des meilleures pratiques en C++ moderne. Notamment, cette bibliothèque pourrait être utilisée comme couche de base pour les algorithmes parallèles de la bibliothèque standard de C++17.

L’objectif est en réalité très similaire à celui d’OpenMP, dont les dernières versions permettent de décharger du code sur les accélérateurs. La grande différence est qu’OpenMP est une norme qui a évolué depuis 1997 dans un secteur qui a vu quelques révolutions depuis lors : cette API est très spécialisée et a du mal à bien s’adapter aux accélérateurs actuels. Là où OpenMP génère du code tant pour le processeur principal que l’accélérateur, StreamExecutor ne cherche pas à s’occuper du code qui sera exécuté sur l’accélérateur — le développeur reste responsable de cette partie, afin de l’optimiser au mieux. Grâce à cette différence, StreamExecutor peut ainsi gérer de nouveaux accélérateurs assez facilement.

Google l’a récemment proposé en tant que sous-projet de LLVM, une suite de compilateurs libre. Ainsi, cette bibliothèque pourrait être profondément intégrée au niveau du compilateur, ce qui permettrait une série de tests statiques avant l’exécution de code sur un accélérateur. Notamment, en cas de problème d’arité d’une fonction appelée sur un accélérateur, StreamExecutor détecte le problème et reporte directement une erreur au programmeur (au lieu de ne la détecter que lors d’une tentative d’appel du code concerné).

Les développeurs de LLVM sont relativement partagés concernant cette contribution. Leurs griefs portent principalement sur la concurrence avec liboffload, développée dans le cadre de l’implémentation d’OpenMP pour décharger du code sur des accélérateurs — mais très liée à l’implémentation d’OpenMP. Quand StreamExecutor fonctionne avec des extensions pour CUDA et OpenCL, liboffload peut exécuter du code sur des GPU NVIDIA et des CPU Intel Xeon Phi. En réalité, les deux visent des publics fort différents : liboffload est prévue pour un compilateur, tandis que StreamExecutor se dirige vers tout type d’utilisateur, même si les fonctionnalités se recouvrent. Il n’est cependant pas question à l’heure actuelle d’exploiter cette interface de plus haut niveau pour l’implémentation d’OpenMP.

Source : RFC: Proposing an LLVM subproject for parallelism runtime and support libraries
Voir aussi : la documentation préliminaire de StreamExecutor, TensorFlow.

Sortie de Cutelyst 0.11

Publié le par
Répondre

Qt est principalement prévu pour le développement d’interfaces graphiques, il n’empêche que ses fonctionnalités sont suffisamment générales et découplées les unes par rapport aux autres pour implémenter une couche de développement Web complète comme Cutelyst. Ainsi, il devient très facile de partager du code métier entre une application mobile, une application traditionnelle de bureau et un site Web, le tout dans la sphère Qt.

Au niveau des améliorations principales, les classes d’envoi de courriels View::Email peuvent s’enchaîner avec d’autres vues, notamment avec Grantlee, ce qui permet d’utiliser les mêmes outils que pour les pages affichées. Au niveau de Utils::Sql, la compatibilité avec les classes du module Qt SQL est améliorée, avec des fonctions pour sérialiser des QSqlQuery en QVariantList, ainsi que la gestion des requêtes préparées.

De manière générale, la version de Qt minimale est maintenant la 5.5, ce qui permet de nettoyer une partie du code, notamment pour la lecture de fichiers JSON. Cette nouvelle version de Cutelyst n’apporte cependant pas d’amélioration notable au niveau de la performance pour les tests exécutés par rapport aux résultats de Cutelyst 0.10, même si les changements du côté de QString dans Qt 5.6 auraient pu apporter beaucoup. Les conclusions devraient être différentes pour des applications bien plus lourdes que celles essayées (notamment avec Grantlee et des requêtes SQL).

Source : Cutelyst 0.11.0 released!

Sortie de Qt 5.6

Publié le par
Répondre

Finalement, Qt 5.6 est sorti en version finale, prête pour le grand public, avec un certain retard — Qt 5.7 est d’ores et déjà bien sur les rails. Ces délais sont dus à une nouvelle infrastructure mise en place pour garantir la faisabilité de la promesse première de Qt 5.6 : une assistance technique à long terme (LTS). Ainsi, pendant les trois années à venir, de nouvelles versions seront publiées avec des correctifs pour tous les défauts qui seront découverts dans cette version, au niveau des fonctionnalités et de la sécurité.

Infrastructure

Le travail d’infrastructure a principalement porté sur un système d’intégration continue, nommé COIN, après une année de travail. Il remplace le système précédent, déjà enfanté dans la douleur, qui exploitait Jerkins. COIN a le principal avantage d’être incrémental, ce qui accélère fortement le test des modifications apportées au code source de Qt. Ce système utilise notamment les mêmes configurations que celles des paquets binaires fournis à chaque nouvelle version, ce qui limitera aussi fortement le temps requis pour la génération des paquets. En conséquence, grâce à COIN, les développeurs pourront tester leur code sur un plus grand nombre de configurations, pour s’assurer d’une très haute qualité.

Windows 10

Dès Qt 5.5, la compatibilité avec Windows 10 est assurée. Avec cette nouvelle version, elle est encore améliorée, avec notamment l’utilisation des API Win32 (classiques) et WinRT (modernes, pour les applications distribuées par le Windows Store). Ainsi, pour déployer son application dans le Windows Store, la principale modification à effectuer sera une recompilation avec la version adaptée de Qt.

Les binaires de Qt sont maintenant aussi disponibles pour Visual C++ 2015. par contre, pour l’intégration à Visual Studio 2015, il faudra encore attendre un peu : l’extension utilise des mécanismes de Visual Studio désapprouvées depuis quelques années et maintenant supprimés. Elle est actuellement en cours de réécriture complète, ce qui aura aussi pour avantage de la rendre compatible avec l’édition Community (gratuite) de Visual Studio (précédemment, l’extension Qt n’était disponible que pour les éditions payantes de Visual Studio).

Écrans à haute résolution

Les développeurs de Qt 5.6 ont beaucoup porté attention aux écrans à haute résolution (comme l’écran Retina des MacBook d’Apple), sur toutes les plateformes : le niveau de qualité autrefois disponible uniquement sur OS X est maintenant atteint pour Windows et Linux. Les applications écrites pour une résolution traditionnelle s’adapteront automatiquement aux densités de pixels bien plus importantes des écrans haut de gamme actuels — même lors du passage d’un écran à l’autre quand les densités varient. Ces modifications s’appliquent tant aux applications Qt Widgets que Qt Quick.

Qt WebEngine

Le nouveau moteur Web, Qt WebEngine, basé sur Chromium (le moteur de Google Chrome), a vu bon nombre d’améliorations depuis Qt 5.5. Une mise à jour de Chromium a été effectuée vers la version 45, ce qui apporte moult nouvelles fonctionnalités et corrections de défauts. De plus, les extensions Pepper (PPAPI) sont maintenant gérées : il est possible d’afficher des animations Flash, par exemple. La configuration des serveurs mandataires de Qt est aussi utilisée, au lieu des paramètres par défaut de Chromium. L’API WebActions est maintenant disponible, comme elle l’était pour Qt WebKit. Pour Linux, afin de contrer les griefs exprimés par certains mainteneurs de distribution, les bibliothèques système sont privilégiées par rapport à des versions non partagées.

Un autre module a fait son apparition : Qt WebEngineCore, qui n’expose que des API de bien plus bas niveau. Ainsi, il devient possible de définir de nouveaux protocoles pour les URL, par là d’intercepter ou de bloquer des requêtes qui passent sur le réseau, mais aussi de tracer et de bloquer les témoins de connexion.

Télécharger Qt 5.6.

Source : Qt 5.6 released

Sortie de Qt Creator 3.6.1

Publié le par
Répondre

En simultané avec Qt 5.6.0, une nouvelle version de Qt Creator est disponible, numérotée 3.6.1.

Elle corrige principalement des défauts, comme des plantages inopinés, une intégration améliorée avec Clang et quelques régressions au niveau du débogage. Qt 5.6 est maintenant disponible dans les assistants de création de projet Qt Quick. Les Microsoft Visual C++ Build Tools sont maintenant détectés automatiquement comme kit de compilation.

Les paquets binaires sont maintenant compilés avec Qt 5.6.0.
Liste complète des modifications.
Télécharger Qt Creator 3.6.1.

Lithographie par rayonnement ultraviolet extrême : l’arrivée en production se précise

Publié le par
Répondre

Le rayonnement ultraviolet extrême (en anglais, EUV) correspond à un rayonnement électromagnétique de très haute énergie, avec des longueurs d’onde de 124 à 10 nm (avec une énergie par photon de dix à cent fois supérieure à celle de la lumière visible). Cette technologie est en cours de déploiement chez bon nombre de fabricants de semi-conducteurs comme Intel ou TSMC. En effet, pour créer des circuits électroniques de plus en plus petits (ou emmagasinant autant de transistors sur une même surface) et consommant moins d’énergie, leur stratégie principale est d’augmenter la finesse de gravure de leurs circuits : un transistor plus petit a un courant de fuite plus faible, ce qui diminue sa consommation énergétique et donc le refroidissement nécessaire des composants.

Grâce à ces nouvelles techniques, ils pourront descendre encore dans leur finesse de gravure, actuellement à 14 nm chez Intel (même si ces appellations sont trompeuses, chaque fabricant décidant de la définition physique de cette finesse de gravure). À titre de comparaison, actuellement, la lithographie moderne se base sur des processus d’ultraviolets profonds, avec une longueur d’onde de 193 nm ; la technologie EUV propose une longueur d’onde à 13,5 nm. Initialement, cette dernière était prévue pour le 10 nm en 2016, mais les plans actuels font plutôt état d’une arrivée vers le 7 nm, voire 5 nm (sans compter les pistes d’amélioration en remplaçant le silicium par un autre semi-conducteur, comme l’arséniure de gallium et d’indium).

Fin février a eu lieu la conférence SPIE pour la lithographie avancée, où les différents fabricants ont pu présenter leurs avancées dans le domaine de la lithographie EUV : c’est l’occasion de se plonger dans les principes de fabrication des processeurs.

Techniques de lithographie

Plus précisément, la lithographie est la partie de la fabrication de puces qui impose la forme des transistors sur les galettes de silicium, à l’aide d’un masque : à certains endroits, le masque laisse passer le rayonnement électromagnétique, pas à d’autres ; là où il passe, la couche supérieure de la galette est abîmée, ce qui forme un morceau de transistor. Le processus est très similaire à la photographie argentique, où la lumière expose le film (ce qui correspond à la lithographie), des étapes ultérieures étant nécessaires pour exploiter l’image.

Le problème, c’est que la source d’ondes a une longueur d’onde de 193 nm, alors que les détails de gravure sont de l’ordre de 14 nm. Pour compenser la différence, un appareillage d’optique est utilisé pour augmenter la résolution et limiter la zone d’exposition, tout en réduisant les aberrations optiques (qui produisent des circuits défectueux). Plusieurs passages avec des masques différents peuvent être requis.

Les mêmes techniques sont utilisées depuis des années pour la production de puces, en raffinant l’emploi des différents outils, notamment l’usage de masques de plus en plus nombreux. C’est pourquoi les fabricants ont souvent du mal à produire de grandes quantités de processeurs rapidement lors du passage à la génération suivante : il faut adapter finement toute une série de paramètres qui limitent le nombre de puces viables produites par ce processus. Une telle transition est donc toujours risquée d’un point de vue financier.

Et l’EUV ?

Une nouvelle technologie comme l’EUV réduirait fortement ces risques : grâce à la longueur d’onde bien plus courte (13,5 nm), il deviendrait plus facile de générer des motifs très précis sur les galettes sans devoir utiliser un trop grand nombre d’expositions. Cependant, la source lumineuse doit avoir une puissance suffisante : sinon, une exposition prendra trop de temps pour avoir l’effet escompté sur la galette de silicium. Cette difficulté a beaucoup ralenti l’emploi de l’EUV dans la lithographie actuelle : la production horaire de puces est trop faible pour une échelle industrielle.

Là où les processus actuels utilisent directement un laser dans les ultraviolets (dit « Ã  excimère »), une technologie maîtrisée dès les années 1970, l’EUV nécessite un plasma, c’est-à-dire de la matière chauffée à très haute température ou insérée dans un champ électromagnétique très intense. ASML produit les machines d’exposition aux EUV utilisées par tous les fabricants de puces pour le moment.

Il y a deux ans, la puissance maximale était de 40 W ; l’année dernière, ils arrivaient à produire des sources à 85 W, maintenant à 185 W en laboratoire, puis 250 W d’ici à 2017, le niveau requis pour une utilisation commerciale. Des puissances supérieures sont prévues dans le laps de temps 2018-2019. Les plans initiaux prévoyaient cependant d’atteindre les 250 W en 2013, puis en 2015… la différence est que la cible est maintenant beaucoup plus proche (il leur reste à augmenter la puissance d’un quart, pas de la multiplie par plus de cinq). Ces progrès ont surtout été possible en comprenant plus finement la physique derrière la génération des plasmas.

Globalement, l’arrivée en production se précise. Intel arrive déjà à produire des puces 22 nm avec cette technologie. Les machines d’ASML atteignent des taux de disponibilité de 70 % (ils plafonnaient à 55 % il y a deux ans), un seuil encore loin des 95 % des machines actuellement utilisées en production. Intel et TSMC arrivent à produire jusque 500 galettes par jour pendant quatre semaines d’affilée — chez TSMC, les technologies actuelles permettent de produire 50 000 galettes par jour. TSMC envisage d’utiliser ce processus pour les puces à 5 nm, Intel ne se risque pas à avancer de date — rejoignant implicitement les rangs des plus pessimistes, qui prédisent que l’EUV n’a de chance d’être utilisé que s’il arrive suffisamment tôt en production, avant d’autres améliorations.

Sources et images : EUV Lithography Makes Good Progress, Still Not Ready for Prime Time, An Introduction to Semiconductor Physics, Technology, and Industry, EUV Lithography’s Prospects Are Brightening, TSMC and Intel on the Long Road to EUV.

Merci à Claude Leloup pour ses corrections.