IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

.NET 5.0 Preview 7 est disponible et s'accompagne d'améliorations au niveau de la récupération mémoire
Ainsi que de nouvelles fonctionnalités

Le , par Stéphane le calme

175PARTAGES

9  0 
Microsoft a annoncé la disponibilité de .NET 5.0 Preview 7, l'avant-dernière des versions Preview (avant de passer à RC). La plupart des fonctionnalités devraient être proches de leur version stable à ce stade.

Récupération de mémoire (garbage collection - GC)

Le récupérateur de mémoire affiche maintenant des informations détaillées sur la récupération la plus récente, via la méthode GC.GetGCMemoryInfo, qui retourne une structure GCMemoryInfo. GCMemoryInfo fournit des informations sur la mémoire de la machine, la mémoire de tas (allocation dynamique) et la récupération la plus récente ou alors la récupération la plus récente du type de GC que vous spécifiez.

Les cas d'utilisation les plus probables de l'emploi de cette nouvelle API sont la journalisation / le monitoring ou pour indiquer à un équilibreur de chargeur qu'une machine doit être retirée de la rotation pour demander un GC complet. Elle pourrait également être utilisée pour éviter les limites strictes des conteneurs en réduisant la taille des caches.

Un autre changement, mineur, mais important, a été apporté pour reporter l'opération coûteuse de réinitialisation de la mémoire aux situations de mémoire insuffisante. Microsoft s'attend à ce que ces changements de politique réduisent la latence du GC (et l'utilisation du CPU du GC en général).


System.Text.Json

Microsoft a ajouté une fonctionnalité à la nouvelle API JSON. Les fonctionnalités suivantes sont nouvelles dans Preview 7 (et d'autres devraient venir dans la Preview 8) :
  • [Breaking change] Possibilité d'ignorer les valeurs par défaut des propriétés de type valeur lors de la sérialisation - peut être utilisée pour réduire les coûts de sérialisation.
  • Capacité à gérer les références circulaires lors de la sérialisation - la forme de l'API devrait maintenant être définitive.

RyuJIT

RyuJIT est le générateur de code d'assemblage pour .NET qui cible à la fois les puces Intel et ARM. La plupart des investissements dans RyuJIT sont axés sur la performance.
  • Améliorations générales
    • Possibilité d'activer l'élimination de certaines vérifications de limites
    • Optimisation de Enum.CompareTo après avoir été réécrit en C# - les performances sont désormais à parité avec l'implémentation C++ précédente.
    • Amélioration de l'allocation des registres pour les structs
    • Améliorations de la suppression des initialisations zéro redondantes
    • Amélioration de la duplication de la queue
    • Correctif CQ de copie de structures basées sur la pile
    • Nettoie une affectation de champ mort après avoir supprimé les initialisations de zéro redondantes

  • ARM64
    • Mise en œuvre de la majorité des éléments intrinsèques « par élément »
    • Implémentation de fcvtxn, fcvtxn2, sqabs, sqneg, suqadd, usqadd intrinsèques
    • Optimisation de SpanHelpers.IndexOf(byte), SpanHelpers.IndexOf(char)
    • Optimisation de SpanHelpers.IndexOfAny(byte)
    • Optimisation de WithLower, WithUpper, Create, AsInt64, AsUInt64, AsDouble
    • Optimisation de AsVector, AsVector128, GetUpper, As and WithElement


Rappelons certains des objectifs de haut niveau pour .NET 5 :
  • Expérience du SDK .NET unifié :
    • BCL (Base Class Library) unique dans toutes les applications .NET 5. Aujourd'hui, les applications Xamarin utilisent le Mono BCL, mais vont utiliser le .NET Core BCL, améliorant la compatibilité entre nos modèles d'application.
    • Le développement mobile (Xamarin) est intégré dans .NET 5. Cela signifie que le SDK .NET prend en charge les mobiles. Par exemple, vous pouvez utiliser « dotnet new XamarinForms » pour créer une application mobile.

  • Native Applications prenant en charge plusieurs plateformes : projet Single Device prenant en charge une application pouvant fonctionner sur plusieurs appareils, par exemple Windows Desktop, Microsoft Duo (Android) et iOS à l'aide des contrôles natifs pris en charge sur ces plateformes.
  • Web Applications prenant en charge plusieurs plateformes: projet Single Blazor qui prend en charge une application pouvant fonctionner dans les navigateurs, sur les appareils mobiles et en tant qu'application de bureau native (Windows 10x par exemple)
  • Cloud Native Applications: hautes performances, fichier unique (.exe) <50 Mo de microservices et prise en charge de la création de plusieurs projets (API, web front end, conteneurs) à la fois localement et dans le cloud.
  • Améliorations continues, telles que: algorithmes plus rapides dans la BCL, meilleure prise en charge des conteneurs lors de l'exécution, prise en charge de HTTP3.

Dans sa Preview 4, .NET 5 a apporté :
  • Des améliorations du compilateur RyuJIT JIT : qui comportent une nouvelle implémentation, beaucoup plus rapide et portable, des assistants tailcall ; la poursuite des progrès de la mise en œuvre du matériel ARM64 ; l’amélioration de la vitesse du JIT dans un cas qui affectait la compilation d'expressions régulières ; l’amélioration des performances de l'architecture Intel grâce à de nouvelles caractéristiques matérielles BSF/BSR et l'implémentation de Vector{Size}.AllBitsSet.
  • Les exportations natives (exportations pour les binaires natifs qui font appel au code .NET) : Microsoft a activé cette fonctionnalité à la demande des développeurs. La composante de base de cette fonctionnalité est l'hébergement de l'API pour l'attribut UnmanagedCallersOnlyAttribute.
  • La suppression du support WinRT intégré dans .NET 5.0 (une annonce anticipée pour la Preview 6) : les avantages de ce changement sont : WinRT interop peut être développé et amélioré séparément du runtime .NET ; la suppression rend WinRT interop symétrique avec les systèmes interop fournis pour d'autres systèmes d'exploitation, comme iOS et Android, d’après l’équipe .Net ; elle peut également tirer parti de nombreuses autres fonctionnalités de .NET (AOT, fonctionnalités C#, liaison IL) et simplifier la base de code du runtime .NET.
  • Extension du System.DirectoryServices.Protocols à Linux et MacOS : System.DirectoryServices.Protocols est une API de niveau inférieur à System.DirectoryServices, et permet (ou peut être utilisé pour permettre) un plus grand nombre de scénarios. Les deux ensembles d'API permettent de contrôler un serveur de services d'annuaire, comme LDAP ou Active Directory, et d'interagir avec lui. L’équipe .NET a ajouté un support multiplateforme pour les protocoles System.DirectoryServices.Protocols. Dans la Preview 5, la prise en charge de Linux a été ajoutée et la prise en charge de MacOS sera ajoutée dans la Preview 6. La prise en charge de Windows était préexistante.
  • Support d'Alpine Linux 3.12 : Microsoft a ajouté, cette semaine, la prise en charge d'Alpine 3.12 (sorti en le 29 mai), de .NET Core 3.1 et de .NET 5. L’équipe continue de travailler sur l'ajout de la prise en charge des nouvelles versions de distribution de Linux.


Télécharger .NET 5.0 Preview 7 (Windows, macOS, Linux)

Source : Microsoft

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 17/11/2020 à 17:07
Je suis en train de regarder cette série de benchmarks Java (OpenJDK 15) vs C# (.NET 5) et je dois bien avouer que C# a prit les devants sur Java concernant le temps d'exécution et la consommation mémoire.
5  0 
Avatar de Captain Spic
Membre à l'essai https://www.developpez.com
Le 02/09/2020 à 13:37
Citation Envoyé par CaptainDangeax
Je ne vois pas trop l'intérêt de la chose. dotNet ne tourne qu'en environnement windows, donc sur nos PC windows. Et nos PC sont 32/64 bits, c'est à dire qu'un registre du processeur sera toujours en 32 bits. Un LD ou un MOV en assembleur se fera sur un registre en 32 bits. Sur un microcontrolleur où la place est limitée, je vois bien l'intéret de la chose, pour avoir un peu plus de précision avec 16 bits... Mais sur un PC / Windows, non vraiment je ne vois pas.
Même si le programme tourne en 32 ou 64 bits, et utilisera ces 32 ou 64 bits par cycle, en RAM, les valeurs sont stockées par lots de 8 bits (un octet).
On divise par deux l'espace nécessaire.
Pour un programme classique, je ne suis pas sûr que l'impact soit significatif.
Mais pour un programme qui manipule beaucoup de données de ce genre (Big Data, BDD, etc) ça peut faire beaucoup d'économie :
  • Pour un million d'entrée, on gagne 16 Mo
  • Pour un milliard, on gagne 16 Go !


Voilà pourquoi c'est intéressant

P.S. Sinon .NET est cross-plateforme depuis maintenant un certain temps (d'abord Roslyn, Xamarin, puis .Net Core et enfin .NET 5 qui va fusionner .Net Core et .Net Framework)
4  0 
Avatar de redcurve
Membre extrêmement actif https://www.developpez.com
Le 02/09/2020 à 12:11
Citation Envoyé par CaptainDangeax Voir le message
Je ne vois pas trop l'intérêt de la chose. dotNet ne tourne qu'en environnement windows, donc sur nos PC windows. Et nos PC sont 32/64 bits, c'est à dire qu'un registre du processeur sera toujours en 32 bits. Un LD ou un MOV en assembleur se fera sur un registre en 32 bits. Sur un microcontrolleur où la place est limitée, je vois bien l'intéret de la chose, pour avoir un peu plus de précision avec 16 bits... Mais sur un PC / Windows, non vraiment je ne vois pas.
Toi t'as rien capté depuis 10 ans
5  3 
Avatar de redcurve
Membre extrêmement actif https://www.developpez.com
Le 02/09/2020 à 16:28
Citation Envoyé par CaptainDangeax Voir le message
Prends un programme compilé et regarde les instructions MOV ou LD : elles sont toutes en 32 bits. Alors si c'est pour charger 2 fois 16 bits puis faire un SWAP pour accéder à l'autre mot, non je ne vois pas l'intérêt. Mais bon je parle à des développeurs dotNet, pas à des développeurs C ou ASM.
Toujours à coté de la plaque

Top pour nos programmes de machine learning
2  0 
Avatar de LinxBe
Membre à l'essai https://www.developpez.com
Le 05/09/2020 à 1:01
Citation Envoyé par CaptainDangeax Voir le message
C'est bien ce petit ton moqueur depuis le début. Et sinon, c'est quand la dernière fois que tu as pondu un programme en ASM ?
Pourquoi parlez-vous de ASM ?
Il ne s'agit pas d'un problème de programmation, mais de STOCKAGE !
1  0 
Avatar de gstratege
Membre actif https://www.developpez.com
Le 22/07/2020 à 12:21
Je comprend pas trop l'idée derrière .Net 5, au lieu d'avoir .Net Core et .Net Framework séparés, on les réunis, mais comment ? juste on les mets côtes à côtes dans un même package ?
0  0 
Avatar de Pol63
Expert éminent sénior https://www.developpez.com
Le 22/07/2020 à 13:27
.net 5 est surtout un .net core 4, qui inclut la clr de xamarin et celle de .net framework
les apps windows sont encore en package séparés (mais inclus) comme sur .net core 3
mais les framework (qui ne sont qu'un ensemble de classes codées en c#) contiennent des pans entiers identiques (même si certaines choses de .net 4.8 ne seront pas dans .net 5 car déclarées obsolètes)

le but devant être entre autre de faire comprendre avec le 5 que c'est la version la plus récente au dessus du fx 4.8 parce que .net core et .net framework sont actuellement sur une branche chacun.
et ceux qui sont sur .net core suivent donc sauront que .net 5 est la suite de .net core 3.1 (alors que ceux qui sont sur 4.8 ne sont peut etre pas au fait concernant .net core et seront peut etre tenté de migré et seront forcés de se renseigner)
0  0 
Avatar de redcurve
Membre extrêmement actif https://www.developpez.com
Le 23/07/2020 à 7:02
Citation Envoyé par gstratege Voir le message
Je comprend pas trop l'idée derrière .Net 5, au lieu d'avoir .Net Core et .Net Framework séparés, on les réunis, mais comment ? juste on les mets côtes à côtes dans un même package ?
Hein .Net Framework est figé depuis l'an dernier MS fait juste des patch de sécu dessus

.NET5 prend la suite de .Net Core (le Core dans le nom était la juste pour éviter la confusion avec .Net Framework 1,2,3,4)
0  0 
Avatar de Kropernic
Expert confirmé https://www.developpez.com
Le 22/09/2020 à 9:18
C'est bien beau de fusionner tout ça mais quid des types spatiaux ?

Aux dernières nouvelles, ils ne sont toujours pas supporté par .Net Core. Enfin il y a bien un moyen détourner en utilisant Net Topology Suite mais pour avoir tester cette librairie, je ne suis pas convaincu du tout...

Est-ce que cette fusion .Net Fx et .Net Core fera qu'on pourra utiliser la librairie Microsoft.SqlServer.Types (SqlServerSpatial140.dll) ?
0  0 
Avatar de JackIsJack
Membre éclairé https://www.developpez.com
Le 15/11/2020 à 7:52
Très content que cette série ".net Core" se termine...
0  0