3 pièce(s) jointe(s)
.NET 6 apporte jusqu'à 40 % de gain de vitesse par rapport .NET 5
Microsoft annonce la sortie de la première release candidate de .NET 6, disponible pour Linux, macOS et Windows,
elle résout les problèmes fonctionnels et les régressions des fonctionnalités
L’équipe de développement de .NET, le Framework de développement de Microsoft pour les applications d'entreprises, a annoncé le 14 septembre la sortie de la première release candidate de .NET 6. « Nous sommes heureux de publier Release Candidate 1 (RC1)de .NET 6. Il s'agit de la première de deux versions candidates "go live" qui sont supportées en production. Depuis environ un mois, l'équipe se concentre exclusivement sur les améliorations de la qualité qui résolvent les problèmes fonctionnels ou de performance des nouvelles fonctionnalités ou les régressions des fonctionnalités existantes », a déclaré Microsoft dans un billet de blog.
Microsoft .NET est le nom donné à un ensemble de produits et de technologies informatiques de l'entreprise Microsoft pour rendre des applications facilement portables sur Internet. .NET 6 RC1 a été testé et est pris en charge par la Preview 4 de Visual Studio 2022. Visual Studio 2022 permet de tirer parti des outils Visual Studio développés pour .NET 6, tels que le développement dans .NET MAUI, Hot Reload pour les applications C#, le nouveau Live Preview pour WebForms, et d'autres améliorations de performances dans l’expérience avec l’IDE. Les fonctionnalités présentées ci-dessous sont axées sur ce qui sera possible avec .NET 7 et au-delà. En effet, ces fonctionnalités n'ont pas encore atteint leur pleine maturité.
Source build
Source build est un scénario et une infrastructure sur lesquels Microsoft a travaillé en collaboration avec Red Hat avant de livrer .NET Core 1.0. Plusieurs années plus tard, Microsoft est sur le point de livrer une version entièrement automatisée de ce scénario. Pour les utilisateurs .NET de Red Hat Enterprise Linux (RHEL), cette capacité est très importante. Selon Red Hat, .NET est devenu une plateforme de développement importante pour son écosystème.
Le standard d'or pour les distributions Linux est de construire du code source ouvert en utilisant des compilateurs et des chaînes d'outils qui font partie de l'archive de la distribution. Cela fonctionne pour le runtime .NET (écrit en C++), mais pas pour le code écrit en C#. Pour le code C#, Microsoft utilise un mécanisme de construction en deux étapes pour satisfaire aux exigences.
Red Hat construit les sources du SDK .NET en utilisant la version Microsoft du SDK .NET (#1) pour produire une version purement open source du SDK (#2). Ensuite, le même code source SDK est reconstruit à l'aide de cette nouvelle version du SDK (n°2) pour produire un SDK open source prouvé (n°3). Ce SDK final (n°3) est ensuite mis à la disposition des utilisateurs de RHEL. Après cela, Red Hat peut utiliser ce même SDK (n° 3) pour créer de nouvelles versions de .NET et n'a plus besoin d'utiliser le SDK de Microsoft pour créer des mises à jour mensuelles.
Ce processus peut être surprenant et déroutant. Les distributions open source doivent être construites par des outils open source. Ce modèle garantit que la version Microsoft du SDK n'est pas nécessaire, que ce soit intentionnellement ou par accident. Le projet de compilation de la source a permis à .NET de répondre à certaines exigences. Le livrable pour la construction de la source est une archive source. Cette archive contient toutes les sources du SDK (pour une version donnée). À partir de là, Red Hat (ou une autre organisation) peut construire sa propre version du SDK. La politique de Red Hat exige l'utilisation d'une chaîne d'outils construite à partir de la source pour produire le tar binaire, c'est pourquoi ils utilisent une méthodologie à deux passages. Mais cette méthode à deux passages n'est pas requise pour la construction de la source elle-même.
Il est courant dans l'écosystème Linux d'avoir à la fois des paquets ou des archives sources et binaires disponibles pour un composant donné. Microsoft disposait déjà des archives binaires et nous maintenant des archives sources également. Ainsi, .NET correspond au modèle de composant standard.
La grande amélioration de .NET 6 est que l’archive source est maintenant un produit de la construction Microsoft. Auparavant, sa production nécessitait un effort manuel considérable, ce qui entraînait également une latence importante dans la livraison de l'archive source de Red Hat. Aucune des deux parties n'était satisfaite de cette situation.
Microsoft travaille en étroite collaboration avec Red Hat sur ce projet depuis plus de cinq ans. Il a réussi, en grande partie, grâce aux efforts des excellents ingénieurs de Red Hat avec lesquels nous avons eu le plaisir de travailler. D'autres distros et organisations bénéficieront de leurs efforts. Cependant, l'un des principaux problèmes restants est l'utilisation d'algorithmes de compression stables pour le contenu compressé dans les assemblages.
Amélioration de la sécurité
Microsoft a publié une feuille de route sur la sécurité en début d’année afin de mieux comprendre comment aborder les techniques de sécurité et les caractéristiques matérielles standard du secteur. La feuille de route a également pour but d'alimenter la conversation. Microsoft a ajouté la prise en charge de deux mesures d'atténuation de sécurité clés dans cette version : CET, et W^X. L’entreprise souligne sa volonté de les activer par défaut dans .NET 7.
CET
La technologie CET (Control-flow Enforcement Technology) d'Intel est une fonction de sécurité disponible dans certains processeurs Intel et AMD récents. Elle ajoute des capacités au matériel qui protègent contre certains types d'attaques courantes impliquant le détournement du flux de contrôle. Avec les piles fantômes CET, le processeur et le système d'exploitation peuvent suivre le flux de contrôle des appels et des retours dans un thread dans la pile fantôme en plus de la pile de données, et détecter les modifications involontaires du flux de contrôle. La pile fantôme est protégée contre les accès à la mémoire du code d'application et permet de se défendre contre les attaques impliquant la programmation orientée retour (ROP).
En début d’année, Google Chrome et Microsoft Edgeont annoncé qu’ils prendront en charge la fonction de sécurité CET d'Intel, pour maintenir la sécurité et prévenir des vulnérabilités. Elle est conçue pour protéger les données des utilisateurs contre les attaques de la programmation orientée retour (ROP) et de la programmation orientée saut (JOP). Ces attaques de type ROP et JOP sont dangereuses et particulièrement difficiles à détecter ou à prévenir, car elles modifient le comportement normal d’un programme pour exécuter le code malveillant. Intel a collaboré activement avec Microsoft et d'autres partenaires industriels pour lutter contre ces types d’attaques en utilisant la technologie CET comme complément aux précédentes solutions implémentées.
Avec ROP, le cybercriminel s'appuie sur l'instruction RET (return) pour assembler un flux de code malveillant, récupère l'adresse de l'instruction suivante dans la pile et exécute les instructions à partir de cette adresse. Dans le cas d'attaques basées sur des ROP, l'acteur de la menace recherche a priori l'exécution d'une séquence d'octets dans le code du programme existant en analysant le programme sur le disque ou en mémoire. Windows 10 prend en charge la fonction de sécurité CET d'Intel grâce à un exécutable appelé "Hardware-enforced Stack Defense". Dans un tweet, Johnathan Norman, le responsable de l'étude des vulnérabilités de Microsoft Edge, a laissé entendre que Microsoft Edge 90 prend en charge la technologie CET d'Intel dans les procédures sans moteur de rendu
W^X
W^X est l'une des mesures d'atténuation les plus fondamentales. Elle bloque le chemin d'attaque le plus simple en empêchant les pages de mémoire d'être accessibles en écriture et exécutables en même temps. L'absence de cette mesure d'atténuation nous a conduit à ne pas envisager des mesures d'atténuation plus avancées, car elles pourraient être contournées par l'absence de cette capacité. Avec W^X en place, Microsoft ajoute d'autres mesures d'atténuation complémentaires, comme CET.
Apple a rendu W^X obligatoire pour les futures versions du système d'exploitation de bureau macOS dans le cadre de la transition Apple Silicon. « Cela nous a motivés à programmer la mise en œuvre de cette mesure d'atténuation pour .NET 6, sur tous les systèmes d'exploitation pris en charge. Notre principe est de traiter tous les systèmes d'exploitation supportés de la même manière en matière de sécurité, dans la mesure du possible », déclare Microsoft. W^X est disponible sur tous les systèmes d'exploitation avec .NET 6 mais n'est activé par défaut que sur Apple Silicon. Il sera activé sur tous les systèmes d'exploitation pour .NET 7.
HTTP/3
HTTP/3 est une nouvelle version de HTTP. HTTP/3 résout les problèmes de fonctionnalité et de performance des versions précédentes de HTTP en utilisant un nouveau protocole de connexion sous-jacent appelé QUIC. QUIC utilise UDP et intègre TLS, ce qui permet d'établir plus rapidement les connexions car la poignée de main TLS fait partie intégrante de la connexion. Chaque trame de données est chiffrée de manière indépendante, de sorte que le protocole n'est plus confronté au défi du blocage de la tête de ligne en cas de perte de paquets. Contrairement au TCP, une connexion QUIC est indépendante de l'adresse IP, de sorte que les clients mobiles peuvent se déplacer entre les réseaux wifi et cellulaires, en conservant la même connexion logique, et peuvent poursuivre de longs téléchargements.
À l'heure actuelle, la RFC pour HTTP/3 n'est pas encore finalisée, et peut donc encore changer. Nous avons inclus HTTP/3 dans .NET 6 pour que vous puissiez commencer à l'expérimenter. Il s'agit d'une fonctionnalité en avant-première, qui n'est donc pas prise en charge. Il peut y avoir des imperfections et des tests plus larges doivent être effectués avec d'autres serveurs et clients pour garantir la compatibilité.
.NET 6 n'inclut pas la prise en charge de HTTP/3 sur macOS, principalement en raison de l'absence d'une API TLS compatible avec QUIC. .NET utilise SecureTransport sur MacOS pour son implémentation TLS, qui n'inclut pas encore d'API TLS pour supporter la poignée de main QUIC.
Source : Microsoft
Et vous ?
:fleche: Quel est votre avis sur le sujet ?
Voir aussi :
:fleche: Microsoft annonce la disponibilité de .NET 6 Preview 4 qui apporte l'expérience Hot Reload, à Visual Studio et aux outils de ligne de commande
:fleche: Google Chrome et Microsoft Edge prendront en charge la fonction de sécurité CET d'Intel, pour maintenir la sécurité et prévenir des vulnérabilités
:fleche: Visual Studio 2022 Preview 4 est disponible et s'accompagne d'améliorations sur la productivité personnelle et d'équipe, le chargement à chaud dans ASP.NET Core et la gestion de thèmes
:fleche: Red Hat annonce un RHEL sans frais pour les petits environnements de production, notamment pour les charges de travail de production avec jusqu'à 16 serveurs de production
6 pièce(s) jointe(s)
Microsoft annonce .NET 6, version la plus rapide à ce jour avec prise en charge des puces Apple Silicon
Microsoft annonce .NET 6, version la plus rapide à ce jour avec prise en charge des puces Apple Silicon,
des containers Windows isolés des processus et une amélioration des E/S de fichiers
L’équipe de développement de .NET, le Framework de développement de Microsoft pour les applications d'entreprises, a annoncé le 8 novembre la sortie de .NET 6. « Bienvenue à .NET 6. La version d'aujourd'hui est le résultat d'un peu plus d'un an d'efforts de la part de l'équipe .NET et de la communauté. .NET 6 est la première version qui prend en charge de manière native les processeurs Apple Silicon (Arm64) et a également été améliorée pour Windows Arm64 », a déclaré Richard Lander, responsable de programme au sein de l'équipe .NET Core.
Microsoft .NET est le nom donné à un ensemble de produits et de technologies informatiques de l'entreprise Microsoft pour rendre des applications facilement portables sur Internet. .NET 6 RC1 a été testé et est pris en charge par la Preview 4 de Visual Studio 2022. Dans la version 6 de .NET, les diagnostics du cloud ont été améliorés avec dotnet monitor et OpenTelemetry. La prise en charge de WebAssembly est plus performante. De nouvelles API ont été ajoutées, pour HTTP/3, le traitement de JSON, les mathématiques et la manipulation directe de la mémoire.
Voici, ci-dessous, quelques-unes des améliorations apportées à .NET 6 :
Une plateforme unifiée et étendue
.NET 6 offre une plateforme unifiée, pour les applications web, cloud, de bureau, d'IoT et mobiles. La plateforme sous-jacente a été mise à jour pour répondre aux besoins de tous les types d'applications et pour faciliter la réutilisation du code dans toutes les applications. Les nouvelles capacités et améliorations sont disponibles pour toutes les applications en même temps, de sorte qu’un code exécuté dans le cloud ou sur un appareil mobile se comporte de la même manière et bénéficie des mêmes avantages.
La portée des développeurs .NET continue de s'élargir à chaque version. L'apprentissage automatique et WebAssembly sont deux des ajouts les plus récents. Par exemple, avec l'apprentissage automatique, il est possible d’écrire des applications qui recherchent des anomalies dans les données en continu. Avec WebAssembly, il est possible d’héberger des applications .NET dans le navigateur, tout comme HTML et JavaScript, ou les combiner avec HTML et JavaScript.
L'un des ajouts les plus intéressants est l'interface utilisateur multiplateforme de .NET (.NET MAUI). Il est désormais possible d’écrire du code dans un seul projet qui offre une expérience d'application client moderne sur les systèmes d'exploitation mobiles et de bureau. .NET MAUI sera publié un peu plus tard que .NET 6.
Contrôle et casting plus rapides d'interface
Les performances de casting d'interface ont été améliorées de 16 % à 38 %. Cette amélioration est particulièrement utile pour la correspondance de modèle de C# vers et entre les interfaces. Le graphique ci-dessous illustre l'ampleur de l'amélioration pour un benchmark représentatif.
L'un des principaux avantages du passage de certaines parties du moteur d'exécution de .NET de C++ à C# géré est qu'il réduit la barrière à la contribution. Cela inclut le casting d'interface, qui a été déplacé vers C# lors d'un changement précoce de .NET 6. Beaucoup plus de personnes dans l'écosystème .NET maîtrisent le C# que le C++ (et le runtime utilise des modèles C++ difficiles). Le simple fait de pouvoir lire une partie du code qui compose le moteur d'exécution est une étape importante pour développer la confiance dans la contribution sous ses différentes formes.
Arm64
L’équipe de développement de .NET a ajouté le support initial pour Arm64 avec .NET Core 3.0 et Arm32 avant cela. L'équipe a fait des investissements majeurs dans Arm64 dans chacune des dernières versions. Dans .NET 6, elle s’est principalement concentrée sur la prise en charge des nouvelles puces Apple Silicon et du scénario d'émulation x64 sur les systèmes d'exploitation macOS et Windows Arm64.
« L'Arm64 suscite beaucoup d'enthousiasme en ce moment, que ce soit pour les ordinateurs portables, le matériel informatique et d'autres appareils. Nous ressentons cette même excitation au sein de l'équipe .NET et faisons de notre mieux pour suivre cette tendance industrielle. Nous collaborons directement avec les ingénieurs d'Arm Holdings, d'Apple et de Microsoft pour nous assurer que nos implémentations sont correctes et optimisées, et que nos plans s'alignent. Ces partenariats étroits nous ont beaucoup aidés », souligne Richard Lander.
Il est possible d’installer les versions Arm64 et x64 de .NET sur les systèmes d'exploitation macOS 11+ et Windows 11+ Arm64. Pour parvenir à ce résultat, l’équipe de développement de .NET a dû faire plusieurs choix de conception et modifier ses produits pour que cela fonctionne. Par défaut, si une application .NET 6 est exécutée avec le SDK Arm64, elle s'exécutera en Arm64. Il est possible de passer facilement à l'exécution en x64 avec l'argument -a, comme dotnet run -a x64. Le même argument fonctionne pour les autres CLI.
Lorsque -a x64 est utilisé, le SDK s'exécute toujours de manière native en Arm64. Il existe des points fixes dans l'architecture du SDK .NET où les limites de processus existent. La plupart du temps, un processus doit être tout Arm64 ou tout x64. En réalité, le .NET CLI attend la dernière création de processus dans l'architecture du SDK et lance celui-ci comme l'architecture de puce qui a été demandée, comme x64. C'est dans ce processus que le code s'exécute. De cette façon, le développeur bénéficie des avantages de l'Arm64 en tant que développeur, mais le code s'exécute dans le processus dont il a besoin. Ceci n'est pertinent que s’il a besoin d'exécuter du code en x64. Si ce n'est pas le cas, il est tout simplement possible de tout exécuter en Arm64 tout le temps.
Windows Arm64
Microsoft dispose d'un outil simple qui démontre l'environnement sur lequel tourne .NET.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| C:Usersrich>dotnet tool install -g dotnet-runtimeinfo
You can invoke the tool using the following command: dotnet-runtimeinfo
Tool 'dotnet-runtimeinfo' (version '1.0.5') was successfully installed.
C:Usersrich>dotnet runtimeinfo
42
42 ,d ,d
42 42 42
,adPPYb,42 ,adPPYba, MM42MMM 8b,dPPYba, ,adPPYba, MM42MMM
a8" `Y42 a8" "8a 42 42P' `"8a a8P_____42 42
8b 42 8b d8 42 42 42 8PP""""""" 42
"8a, ,d42 "8a, ,a8" 42, 42 42 "8b, ,aa 42,
`"8bbdP"Y8 `"YbbdP"' "Y428 42 42 `"Ybbd8"' "Y428
**.NET information
Version: 6.0.0
FrameworkDescription: .NET 6.0.0-rtm.21522.10
Libraries version: 6.0.0-rtm.21522.10
Libraries hash: 4822e3c3aa77eb82b2fb33c9321f923cf11ddde6
**Environment information
ProcessorCount: 8
OSArchitecture: Arm64
OSDescription: Microsoft Windows 10.0.22494
OSVersion: Microsoft Windows NT 10.0.22494.0 |
L'outil fonctionne en mode natif sur Windows Arm64. Voici, ci-dessous, le résultat en ASP.NET Core.
Performances de l'Arm64
Les projets de prise en charge d'Apple Silicon et de l'émulation x64 étaient très importants, mais les performances de l'Arm64 ont également été améliorées. L’image ci-dessous montre une amélioration de la mise à zéro du contenu des cadres de pile, qui est une opération courante. La ligne verte représente le nouveau comportement, tandis que la ligne orange représente une autre expérience (moins avantageuse), toutes deux améliorées par rapport à la ligne de base, représentée par la ligne bleue. Pour ce test, plus bas est mieux.
PGO dynamique
Le Dynamic Profile-guided Optimization (PGO) ou encore l'optimisation dynamique guidée par le profil peut améliorer sensiblement les performances en régime permanent. Par exemple, PGO permet une amélioration de 26 % (510K -> 640K) des requêtes par seconde pour la suite TechEmpower JSON "MVC". PGO dynamique s'appuie sur la compilation par niveaux, qui permet aux méthodes d'être d'abord compilées très rapidement (niveau 0) pour améliorer les performances au démarrage, puis d'être recompilées (niveau 1) avec de nombreuses optimisations une fois que la méthode s'est révélée efficace. Ce modèle permet d'instrumenter les méthodes au niveau 0 afin d'effectuer diverses observations sur l'exécution du code.
Lorsque ces méthodes sont réintroduites au niveau 1, les informations recueillies à partir des exécutions du niveau 0 sont utilisées pour mieux optimiser le code du niveau 1. C'est l'essence même du mécanisme. Les temps de démarrage de Dynamic PGO seront légèrement plus lents que ceux du runtime par défaut, car du code supplémentaire est exécuté dans les méthodes de niveau 0 pour observer le comportement de la méthode.
Pour activer PGO dynamique, il faut definir DOTNET_TieredPGO=1 dans l'environnement où l’application sera exécutée. Il faut également s’assurer que Tiered Compilation est activé (il l'est par défaut). Dynamic PGO est opt-in parce qu'il s'agit d'une technologie nouvelle et importante. Le PGO dynamique est pris en charge et est déjà utilisé en production par au moins un très grand service Microsoft.
Code:
1
2
3
4
| private IEnumerator<long> _source = Enumerable.Range(0, long.MaxValue).GetEnumerator();
[Benchmark]
public void MoveNext() => _source.MoveNext(); |
Voici le résultat, avec et sans PGO dynamique :
C'est une différence assez importante, mais la taille du code a également augmenté, ce qui pourrait en surprendre plus d'un. Il s'agit de la taille du code d'assemblage généré par le JIT, et non des allocations de mémoire. Une optimisation courante dans les implémentations PGO est le « fractionnement chaud/froid », où les sections d'une méthode fréquemment exécutées ("chaudes") sont rapprochées au début de la méthode, et les sections d'une méthode rarement exécutées ("froides") sont déplacées à la fin de la méthode. Cela permet une meilleure utilisation des caches d'instructions et minimise les charges de code probablement inutilisé.
Comme contexte, la répartition d'interface est le type d'appel le plus coûteux dans .NET. Les appels de méthodes non virtuelles sont les plus rapides, et encore plus rapides sont les appels qui peuvent être éliminés par inlining. Dans ce cas, le PGO dynamique fournit deux sites d'appel (alternatifs) pour MoveNext. Le premier, le chaud, est un appel direct à Enumerable+RangeIterator.MoveNext et l'autre, le froid, est un appel à l'interface virtuelle via IEnumerator<int>. C'est une grande victoire si le chaud est appelé la plupart du temps.
Lorsque le JIT a instrumenté le code de niveau 0 pour cette méthode, il a notamment instrumenté cette répartition d'interface pour suivre le type concret de _source à chaque invocation. Et le JIT a trouvé que chaque invocation était sur un type appelé Enumerable+RangeIterator, qui est une classe privée utilisée pour implémenter Enumerable.Range à l'intérieur de l'implémentation Enumerable. En tant que tel, pour le niveau 1, le JIT a émis une vérification pour voir si le type de _source est ce Enumerable+RangeIterator : si ce n'est pas le cas, alors il saute à la section froide que a été précédemment mise en évidence qui effectue la répartition normale de l'interface. Mais si c'est le cas, ce qui, d'après les données de profilage, devrait être le cas dans la grande majorité du temps, il peut alors invoquer directement la méthode Enumerable+RangeIterator.MoveNext, non virtualisée. De plus, il a décidé qu'il était rentable de mettre en ligne cette méthode MoveNext. L'effet net est que le code assembleur généré est un peu plus gros, mais optimisé pour le scénario exact qui devrait être le plus courant.
Améliorations des entrées-sorties de fichiers
FileStream a été presque entièrement réécrit dans .NET 6, en mettant l'accent sur l'amélioration des performances des entrées-sorties de fichiers asynchrones. Sous Windows, l'implémentation n'utilise plus d'API bloquantes et peut être jusqu'à plusieurs fois plus rapide. Microsoft a également apporté des améliorations à l'utilisation de la mémoire, sur toutes les plateformes. Après la première opération asynchrone (qui alloue généralement la mémoire), l’équipe de développement de .NET a fait en sorte que les opérations asynchrones ne nécessitent aucune allocation. De plus, elle a uniformisé le comportement pour les cas limites où les implémentations Windows et Unix étaient différentes. Les améliorations de performance de cette réécriture profitent à tous les systèmes d'exploitation. Les utilisateurs de macOS et de Linux devraient également constater une amélioration significative des performances de FileStream. Le benchmark suivant écrit 100 Mo dans un nouveau fichier.
Code:
1
2
3
4
5
6
7
8
9
| private byte[] _bytes = new byte[8_000];
[Benchmark]
public async Task Write100MBAsync()
{
using FileStream fs = new("file.txt", FileMode.Create, FileAccess.Write, FileShare.None, 1, FileOptions.Asynchronous);
for (int i = 0; i < 100_000_000 / 8_000; i++)
await fs.WriteAsync(_bytes);
} |
Sous Windows avec un disque SSD, une accélération de 4 fois et une diminution de l'allocation de plus de 1200 a été observée :
L’équipe de développement de .NET a également reconnu le besoin de fonctionnalités d'E/S de fichiers plus performantes : lectures et écritures simultanées, et E/S de type scatter/gather. Elle a introduit de nouvelles API dans les classes System.IO.File et System.IO.RandomAccess pour ces cas.
Code:
1
2
3
4
5
6
7
8
| async Task AllOrNothingAsync(string path, IReadOnlyList<ReadOnlyMemory<byte>> buffers)
{
using SafeFileHandle handle = File.OpenHandle(
path, FileMode.Create, FileAccess.Write, FileShare.None, FileOptions.Asynchronous,
preallocationSize: buffers.Sum(buffer => buffer.Length)); // hint for the OS to pre-allocate disk space
await RandomAccess.WriteAsync(handle, buffers, fileOffset: 0); // on Linux it's translated to a single sys-call!
} |
L'exemple présente :
- l'ouverture d'un handle de fichier à l'aide de la nouvelle API File.OpenHandle ;
- pré-affectation de l'espace disque à l'aide de la nouvelle fonctionnalité Taille de pré-affectation ;
- écriture dans le fichier à l'aide de la nouvelle API Scatter/Gather IO.
La fonctionnalité Size de préallocation améliore les performances car les opérations d'écriture n'ont pas besoin d'étendre le fichier et il est moins probable que le fichier soit fragmenté. Cette approche améliore la fiabilité puisque les opérations d'écriture n'échoueront plus en raison d'un manque d'espace puisque l'espace a déjà été réservé. L'API Scatter/Gather IO réduit le nombre d'appels système requis pour écrire les données.
Sécurité
La sécurité a été considérablement améliorée dans .NET 6. Elle constitue toujours une priorité pour l'équipe, y compris la modélisation des menaces, la cryptographie et les mesures de défense en profondeur. Sous Linux, l’équipe de développement de .NET s’appuie sur OpenSSL pour toutes les opérations cryptographiques, y compris pour TLS (requis pour HTTPS). Sous macOS et Windows, elle s’appuie sur les fonctionnalités fournies par le système d'exploitation dans le même but. Avec chaque nouvelle version de .NET, elle doit souvent ajouter la prise en charge d'une nouvelle version d'OpenSSL. .NET 6 ajoute la prise en charge d'OpenSSL 3.
OpenSSL a annoncéle 21 septembre la disponibilité de la version 3.0 et le renouvellement de la Licence Apache-2.0, avec l'utilisation du nouveau module FIPS dans les projets de développement d'applications. « Après 3 ans de développement, 17 versions alpha, 2 versions bêta, plus de 7 500 commits et des contributions de plus de 350 auteurs différents, nous avons finalement publié OpenSSL 3.0 ! », a annoncé Matt Caswell sur le blog officiel dédié à la plateforme.
.NET 6 requiert OpenSSL 1.1 ou plus et préférera la plus haute version installée d'OpenSSL qu'il peut trouver, jusqu'à et y compris la v3. Dans le cas général, l’utilisation d’OpenSSL 3 commencera probablement lorsque la distribution Linux utilisée l'adoptera par défaut. La plupart des distributions ne l'ont pas encore fait. Par exemple, l’installation de .NET 6 sur Red Hat 8 ou Ubuntu 20.04, ne permet pas (au moment de la rédaction de cette news ) d’utiliser OpenSSL 3.
L’équipe de développement de .NET a également publié une nouvelle feuille de route sur l'atténuation de la sécurité des runtime. Il est important que le moteur d'exécution utilisé soit à l'abri des attaques de type manuel. Dans .NET 6, elle a construit les premières implémentations de W^X et de la technologie Intel Control-flow enforcement (CET).
CET
La technologie CET (Control-flow Enforcement Technology) d'Intel est une fonction de sécurité disponible dans certains processeurs Intel et AMD récents. Elle ajoute des capacités au matériel qui protègent contre certains types d'attaques courantes impliquant le détournement du flux de contrôle. Avec les piles fantômes CET, le processeur et le système d'exploitation peuvent suivre le flux de contrôle des appels et des retours dans un thread dans la pile fantôme en plus de la pile de données, et détecter les modifications involontaires du flux de contrôle. La pile fantôme est protégée contre les accès à la mémoire du code d'application et permet de se défendre contre les attaques impliquant la programmation orientée retour (ROP).
En début d’année, Google Chrome et Microsoft Edgeont annoncé qu’ils prendront en charge la fonction de sécurité CET d'Intel, pour maintenir la sécurité et prévenir des vulnérabilités. Elle est conçue pour protéger les données des utilisateurs contre les attaques de la programmation orientée retour (ROP) et de la programmation orientée saut (JOP). Ces attaques de type ROP et JOP sont dangereuses et particulièrement difficiles à détecter ou à prévenir, car elles modifient le comportement normal d’un programme pour exécuter le code malveillant. Intel a collaboré activement avec Microsoft et d'autres partenaires industriels pour lutter contre ces types d’attaques en utilisant la technologie CET comme complément aux précédentes solutions implémentées.
Avec ROP, le cybercriminel s'appuie sur l'instruction RET (return) pour assembler un flux de code malveillant, récupère l'adresse de l'instruction suivante dans la pile et exécute les instructions à partir de cette adresse. Dans le cas d'attaques basées sur des ROP, l'acteur de la menace recherche a priori l'exécution d'une séquence d'octets dans le code du programme existant en analysant le programme sur le disque ou en mémoire. Windows 10 prend en charge la fonction de sécurité CET d'Intel grâce à un exécutable appelé Hardware-enforced Stack Defense. Dans un tweet, Johnathan Norman, le responsable de l'étude des vulnérabilités de Microsoft Edge, a laissé entendre que Microsoft Edge 90 prend en charge la technologie CET d'Intel dans les procédures sans moteur de rendu
W^X
W^X est l'une des mesures d'atténuation les plus fondamentales. Elle bloque le chemin d'attaque le plus simple en empêchant les pages de mémoire d'être accessibles en écriture et exécutables en même temps. L'absence de cette mesure d'atténuation nous a conduit à ne pas envisager des mesures d'atténuation plus avancées, car elles pourraient être contournées par l'absence de cette capacité. Avec W^X en place, Microsoft ajoute d'autres mesures d'atténuation complémentaires, comme CET.
Apple a rendu W^X obligatoire pour les futures versions du système d'exploitation de bureau macOS dans le cadre de la transition Apple Silicon. « Cela nous a motivés à programmer la mise en œuvre de cette mesure d'atténuation pour .NET 6, sur tous les systèmes d'exploitation pris en charge. Notre principe est de traiter tous les systèmes d'exploitation supportés de la même manière en matière de sécurité, dans la mesure du possible », déclare Microsoft. W^X est disponible sur tous les systèmes d'exploitation avec .NET 6 mais n'est activé par défaut que sur Apple Silicon. Il sera activé sur tous les systèmes d'exploitation dans .NET 7.
Containers Windows
.NET 6 apporte la prise en charge des containers Windows isolés des processus. Si des conteners Windows sont utilisés dans Azure Kubernetes Service (AKS), Il s’agit des conteners à processus isolé. Les conteneurs à processus isolé peuvent être considérés comme très similaires aux conteneurs Linux. Les conteneurs Linux utilisent des cgroups et les conteneurs Windows à processus isolés utilisent des Job Objects. Windows propose également les conteneurs Hyper-V, qui offrent une plus grande isolation grâce à une plus grande virtualisation. Il n'y a pas de changement dans .NET 6 pour les conteners Hyper-V.
La valeur principale de ce changement est que Environment.ProcessorCount rapportera maintenant la valeur correcte avec les conteners Windows isolés des processus. Si un conteneur à 2 cœurs est créé sur une machine à 64 cœurs, Environment.ProcessorCount indiquera 2. Dans les versions antérieures, cette propriété indiquait le nombre total de processeurs sur une machine, indépendamment de la limite spécifiée par le CLI de Docker, Kubernetes ou tout autre orchestrateur/exécutant de conteners. Cette valeur est utilisée par diverses parties de .NET à des fins de mise à l'échelle, notamment le ramasseur miettes de .NET (bien qu'il s'appuie sur une API connexe de niveau inférieur). Les bibliothèques communautaires s'appuient également sur cette API pour la mise à l'échelle.
Source : Microsoft
Et vous ?
:fleche: Que pensez-vous des améliorations apportées par .NET 6 ?
Voir aussi :
:fleche: Microsoft a publié la version stable de Visual Studio 2022 avec une nouvelle expérience de rechargement à chaud pour les applications natives C++, cette version est disponible uniquement en 64 bits
:fleche: Google Chrome et Microsoft Edge prendront en charge la fonction de sécurité CET d'Intel, pour maintenir la sécurité et prévenir des vulnérabilités
:fleche: OpenSSL annonce la disponibilité de la version 3.0 et le renouvellement de la Licence Apache-2.0, avec l'utilisation du nouveau module FIPS dans les projets de développement d'applications
:fleche: Microsoft annonce la sortie de la première release candidate de .NET 6, disponible pour Linux, macOS et Windows, elle résout les problèmes fonctionnels et les régressions des fonctionnalités
2 pièce(s) jointe(s)
.NET 6 apporte jusqu'à 40 % de gain de vitesse par rapport .NET 5
.NET 6 apporterait jusqu'à 40 % de gain de vitesse par rapport .NET 5
les tests de mise en cache et de boucles serrées serraient jusqu'à 30 % plus rapide
« .NET 6 est vraiment le .NET le plus rapide à ce jour », déclare Alex Yakunin, Directeur technique chez ServiceTitan, une plateforme de technologie logicielle. Selon Yakunin, .NET 6 apporte jusqu'à 40 % de gain de vitesse par rapport .NET 5. Le 9 novembre, Microsoft a annoncé .NET 6, comme la version la plus rapide à ce jour avec prise en charge des puces Apple Silicon, des containers Windows isolés des processus et une amélioration des E/S de fichiers.
« Bienvenue à .NET 6. La version d'aujourd'hui est le résultat d'un peu plus d'un an d'efforts de la part de l'équipe .NET et de la communauté. .NET 6 est la première version qui prend en charge de manière native les processeurs Apple Silicon (Arm64) et a également été améliorée pour Windows Arm64 », a déclaré Richard Lander, responsable de programme au sein de l'équipe .NET Core. Suite à des tests de comparaison entre .NET 6 et .NET 5, Alex Yakunin conclut que :
- les tests de mise en cache et de boucles serrées serraient jusqu'à 30 % plus rapide avec .NET 6 ;
- l’ajout du cache de Fusion à une API web ordinaire, obtient une accélération de 15 % avec .NET 6 ;
- le test du pipeline HTTP "classique" (HttpClient frappant un contrôleur ASP.NET Core qui héberge un service EF Core de type CRUD) obtient une accélération d'environ 4,5 %.
Il y a un an, Alex Yakunin a écrit un article comparant les performances de .NET 5 avec celles de son prédécesseur sur les tests de performance de Fusion, les résultats sur les améliorations de performances de .NET 5 étaient simplement impressionnants. Cette année, il conclut que .NET 6 est vraiment le .NET le plus rapide à ce jour.
Microsoft a déclaré que les performances du casting d'interface ont été améliorées de 16 % à 38 %. Cette amélioration est particulièrement utile pour la correspondance de modèle de C# vers et entre les interfaces. Le graphique ci-dessous illustre l'ampleur de l'amélioration pour un benchmark représentatif.
L'un des principaux avantages du passage de certaines parties du moteur d'exécution de .NET de C++ à C# géré est qu'il réduit la barrière à la contribution. Cela inclut le casting d'interface, qui a été déplacé vers C# lors d'un changement précoce de .NET 6. Beaucoup plus de personnes dans l'écosystème .NET maîtrisent le C# que le C++ (et le runtime utilise des modèles C++ difficiles). Le simple fait de pouvoir lire une partie du code qui compose le moteur d'exécution est une étape importante pour développer la confiance dans la contribution sous ses différentes formes.
.NET 6 avec PGO activé pourrait apporter :
- plus de 15 % pour un code moyen qui ne dépend pas du réseau et des E/S ;
- plus de 30 à 40 % de vitesse sur des boucles serrées et une logique favorable au cache ;
- Plus de 5 % pour un service web typique qui dépend principalement du réseau et des entrées/sorties.
Et vous ?
:fleche: « .NET apporterait jusqu’à 40 % de gain de vitesse par rapport à .NET 5 », partagez-vous cette analyse ?
:fleche: Que pensez-vous de .NET 6 ?
:fleche: Avez-vous une expérience avec .NET ?
Voir aussi :
:fleche: Microsoft annonce .NET 6, version la plus rapide à ce jour avec prise en charge des puces Apple Silicon, des containers Windows isolés des processus et une amélioration des E/S de fichiers
:fleche: Microsoft a publié la version stable de Visual Studio 2022 avec une nouvelle expérience de rechargement à chaud pour les applications natives C++, cette version est disponible uniquement en 64 bits
:fleche: Microsoft annonce la sortie de la première release candidate de .NET 6, disponible pour Linux, macOS et Windows, elle résout les problèmes fonctionnels et les régressions des fonctionnalités
:fleche: Google Chrome et Microsoft Edge prendront en charge la fonction de sécurité CET d'Intel, pour maintenir la sécurité et prévenir des vulnérabilités
