Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    août 2008
    Messages
    24 142
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 24 142
    Points : 157 848
    Points
    157 848

    Par défaut Unity se prépare à remplacer le C++ par C#

    Unity est un moteur de jeu extrêmement utilisé actuellement, notamment pour ses outils d'édition complets et conviviaux. Cependant, le moteur doit suivre l'évolution des machines : depuis une dizaine d'années, les processeurs ne montent plus en fréquence, mais plutôt en nombre de cœurs. En d'autres termes, pour exploiter la nouvelle performance disponible, les jeux doivent exécuter leur code sur différents cœurs, à travers différents fils d'exécution. Pourtant, depuis le temps que la technologie est disponible, peu de jeux y arrivent vraiment. De fait, les problèmes pour l'écriture de tel code sont nombreux : il faut s'assurer que deux fils ne tentent pas d'écrire en même temps dans la même variable, par exemple. Ceci implique que l'un des deux fils doit alors attendre l'autre : si le code est légèrement mal écrit, il n'est pas impossible qu'ils s'attendent mutuellement à l'infini (une situation nommée étreinte fatale).

    Pour éviter ces inconvénients, il est possible de suivre quelques séries de règles. Néanmoins, les développeurs ont peu d'outils pour s'assurer qu'elles sont suivies : un code qui ne les respecte pas continuera de compiler, pourrait fonctionner nonante-neuf fois sur cent. C'est une des raisons pour lesquelles Unity travaille sur un nouveau compilateur C#, dénommé Burst : le non-respect de ces règles provoquera une erreur de compilation.

    Pour y arriver, le code doit être écrit comme une collection de tâches à effectuer. Chacune de ces tâches effectue quelques transformations sur des données, mais n'a aucun effet de bord (en suivant les préceptes de la programmation fonctionnelle) indésirable. Le programmeur doit spécifier les zones de mémoire auxquelles il peut accéder en lecture seule et celles où il souhaite lire et écrire des données : le compilateur s'assurera qu'il n'utilise rien en dehors de ces déclarations. Elles permettent de gérer une très grande partie des besoins en calcul parallèle. Ensuite, un ordonnanceur détermine la meilleure manière d'exécuter ces tâches, en temps réel, grâce à ces informations supplémentaires : il peut s'assurer qu'aucune tâche ne viendra écrire des données là où une autre tente de lire ou d'écrire, par exemple. Ce mécanisme augmente fortement la sécurité du code écrit, bon nombre de défauts sont remarqués peu après l'écriture du code ; il est aussi impossible de créer une course de données ou une étreinte fatale, les résultats sont entièrement déterministes, peu importe le nombre de fils d'exécution utilisés pour gérer les tâches ou le nombre d'interruptions d'une tâche.

    Burst n'a pas que cet objectif de faciliter la programmation parallèle : il est aussi utilisé dans les parties les plus critiques (d'un point de vue performance) du code de Unity. Jusqu'à présent, ces endroits étaient écrits en C++, mais les compilateurs actuels ne sont pas entièrement satisfaisants. En effet, si un développeur souhaite qu'une boucle soit vectorisée, il n'a aucune garantie que le compilateur le fera, à cause de changements pourtant a priori sans impact (pour une addition entre deux vecteurs, par exemple, le compilateur doit prouver formellement que, dans tous les cas possibles et imaginables, les deux vecteurs ne correspondent pas aux mêmes adresses en mémoire). Et encore, il faut que tous les compilateurs utilisés pour Unity sur les différentes plateformes visées effectuent correctement cette vectorisation — sans oublier qu'une mise à jour du compilateur peut aussi être à l'origine d'une baisse de performance.

    Pourquoi Burst et pas un compilateur existant ? La performance est un point critique : si un boucle n'est pas vectorisée, ce n'est pas simplement dommage (ce que la plupart des compilateurs se disent), c'est un vrai problème qui doit être corrigé rapidement. De plus, le binaire généré doit être sûr : les erreurs de dépassement de tampon et de déréférencements hasardeux doivent être découvertes au plus tôt, avec de vrais messages d'erreur plutôt que des comportements indéfinis (à l'origine de nombreux problèmes de sécurité). Finalement, il doit gérer toutes les architectures sur lesquelles Unity existe : changer de langage parce qu'on développe un jeu pour console, PC ou mobile n'a pas de sens. Ce compilateur devrait effectivement être utilisé tant pour le moteur que les jeux.

    Ces besoins posés, il faut encore choisir le langage d'entrée de ce compilateur : une variante ou un sous-ensemble du C, du C++, de C# ou encore un nouveau langage ? Le nouveau langage semble à bannir, pour éviter de devoir former des gens à ce nouvel outil ; C# a la préférence du point de vue des utilisateurs, puisqu'il est déjà utilisé par eux : le moteur de jeu serait alors codé dans le même langage que les jeux eux-mêmes. De plus, C# dispose déjà d'un très grand écosystème (des EDI, des compilateurs ouverts). Au contraire, C++ souffre toujours de son héritage du C, avec des inclusions pas toujours évidentes à déterminer et des temps de compilation énormes — des défauts que C++20 vient corriger en partie —, malgré son obsession sur la performance (une chose que C# n'a pas).

    La décision a été prise de partir sur C#, mais en éliminant une série d'éléments qui nuisent à la performance : la bibliothèque standard, en bonne partie, la réflexion, le ramasse-miettes et les allocations (ce qui revient à interdire l'utilisation de classes, seules les structures restent autorisées), les appels virtuels. Autant dire qu'on se retrouve, à certains points de vue, aussi bien outillés qu'en C (avec les possibilités d'oubli de désallouer la mémoire qui n'est plus nécessaire) — mais ce sous-ensemble du langage n'est vraiment adapté qu'aux parties vraiment importantes d'un point de vue performance, pas à la globalité du moteur. Ce sous-ensemble est nommé High-Performance C# (ou encore HPC#).

    Burst ne fonctionne pas vraiment comme un compilateur complet : il ne prend pas en entrée une énorme quantité de code, mais seulement le point d'entrée vers une boucle cruciale. Il se limite à la compiler comme une fonction, ainsi que tout ce qu'elle appelle (puisque les appels virtuels sont interdits, les fonctions appelées sont faciles à déterminer). Le niveau d'optimisation est extrêmement élevé : puisque Burst se focalise sur certaines portions de code, il peut y passer du temps. Notamment, il n'existe presque plus un seul appel de fonction en sortie : importer tout le code permet bien souvent d'éliminer une série de vérifications d'usage en début de fonction. Puisque le seul type de tableau possible est NativeArray et que ces tableaux ne permettent pas de faire des références à d'autres tableaux, deux NativeArray seront toujours distincts en mémoire : la vectorisation peut toujours se faire. Dans le futur, Burst pourra utiliser le même niveau de connaissance sur les fonctions mathématiques utilisées : le sinus d'un angle est presque égal à cet angle s'il est très petit, c'est-à-dire qu'on peut alors remplacer sin(x) par x sans grande perte de précision (ou par un développement en série de Taylor d'un plus grand ordre, si l'angle est un peu plus grand).

    La première itération de Burst, avec HPC# et le système de tâches, est arrivée avec Unity 2018.1. Le code généré est parfois plus rapide que la version précédente en C++, parfois plus lente — mais les développeurs sont confiants qu'ils arriveront toujours à au moins atteindre le même niveau de performance que C++. Un élément crucial doit aussi être pris en compte : combien de temps et d'énergie a-t-il fallu pour atteindre ce niveau de performance ? Le code qui détermine les faces visibles d'un objet (culling) a été réécrit avec HPC# : alors que le code C++ était très complexe pour s'assurer qu'il soit toujours vectorisé (sans écrire d'assembleur spécifique à une plateforme), le code HPC# est quatre fois plus court… pour la même performance. Tout le reste du moteur fera la transition vers HPC#, un jour ou l'autre, tant que le bout de code concerné est critique d'un point de vue performance : le code HPC# est souvent plus facile à optimiser, le langage rend plus difficile l'écriture de code faux.

    Source : On DOTS: C++ & C#.

    Et vous ?

    Qu'en pensez-vous ?
    Vous souhaitez participer aux rubriques Qt ou PyQt (tutoriels, FAQ, traductions), HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  2. #2
    Rédacteur/Modérateur

    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    5 684
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 5 684
    Points : 25 005
    Points
    25 005

    Par défaut

    On a tous déjà entendu en réunion "J'ai corrigé un problème de course de données et une étreinte fatale"
    C'est là que la traduction française à tout va devient ridicule imo.

    Pour le reste, je suis surpris et un peu dubitatif.
    Déjà, il va bien falloir le créer ce nouveau compilateur, et il devra être spécifique à chaque plateforme.
    Puis écrire du C#, en supprimant tellement de trucs qu'on se retrouve avec du C, au final ça revient pas à dire qu'ils utilisent ça qu'en tant que langage de script simplifié ? Le compilateur serait donc plus un parser qu'un compilateur réellement.
    Réécrire l'engin avec ce nouveau langage est une tâche énorme, mais à terme ça colle avec les rumeurs/infos de leur souhait de passer le moteur open source, quand il sera complètement porté en C#.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  3. #3
    Membre actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2018
    Messages
    100
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 19
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2018
    Messages : 100
    Points : 227
    Points
    227

    Par défaut

    mais en éliminant une série d'éléments qui nuisent à la performance : la bibliothèque standard, en bonne partie, la réflexion, le ramasse-miettes et les allocations (ce qui revient à interdire l'utilisation de classes, seules les structures restent autorisées), les appels virtuels
    Voila du C# qui me parle

  4. #4
    Membre à l'essai
    Inscrit en
    juillet 2008
    Messages
    4
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 4
    Points : 10
    Points
    10

    Par défaut

    Hello, merci pour la news.

    Par contre arrivé à "une situation nommée étreinte fatale" j'ai commencé à décrocher, à "nonante-neuf fois sur cent" mes yeux ont pleuré du sang et à "une course de données ou une étreinte fatale" j'ai zappé l'article et suis passé directement au billet original sur le blog d'Unity.

    A vouloir en faire trop, cette article est devenu illisible, dommage.

  5. #5
    Membre extrêmement actif
    Homme Profil pro
    Inscrit en
    janvier 2014
    Messages
    521
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : janvier 2014
    Messages : 521
    Points : 2 484
    Points
    2 484

    Par défaut

    "Nonante" c'est mieux que "quatre vingt dix", plus logique et plus court.

  6. #6
    Membre expert Avatar de Zefling
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2007
    Messages
    1 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : avril 2007
    Messages : 1 001
    Points : 3 593
    Points
    3 593

    Par défaut

    Citation Envoyé par Bousk Voir le message
    Réécrire l'engin avec ce nouveau langage est une tâche énorme, mais à terme ça colle avec les rumeurs/infos de leur souhait de passer le moteur open source, quand il sera complètement porté en C#.
    C'est à cause de moteurs comme godot ou Xenko qu'il le passeraient on open source ? À mon avis, ça sera pas libre pour autant.

  7. #7
    Membre éprouvé
    Homme Profil pro
    chomeur
    Inscrit en
    avril 2015
    Messages
    482
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 74
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : chomeur
    Secteur : Distribution

    Informations forums :
    Inscription : avril 2015
    Messages : 482
    Points : 927
    Points
    927

    Par défaut

    on peut aussi écrire 99 c'est encore plus court.

  8. #8
    Membre actif
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2011
    Messages
    81
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2011
    Messages : 81
    Points : 299
    Points
    299

    Par défaut

    Je trouve le titre assez trompeur car C# n'a pas remplacé C++. C'est un petit sous ensemble de C#, tout petit.

  9. #9
    Membre éprouvé

    Profil pro
    Inscrit en
    janvier 2014
    Messages
    476
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2014
    Messages : 476
    Points : 1 065
    Points
    1 065

    Par défaut

    Citation Envoyé par melka one Voir le message
    on peut aussi écrire 99 c'est encore plus court.
    C'est vrai qu'en français dès lors qu'on dépasse "treize" il devient plus léger d'utiliser des chiffres et non des mots. Mais question rédaction typographique, on fait alors quelques entorses aux coutumes, qui pousserait plutôt à tout écrire en toutes lettres. ^^'
    Pensez à utiliser les pouces d’appréciation, pour participer à la visibilité de l'apport d'un propos, ou l'intérêt que vous y prêtez... qu'il soit positif ou négatif.

  10. #10
    Membre habitué
    Profil pro
    Inscrit en
    août 2005
    Messages
    100
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2005
    Messages : 100
    Points : 156
    Points
    156

    Par défaut

    Citation Envoyé par Steinvikel Voir le message
    C'est vrai qu'en français dès lors qu'on dépasse "treize" il devient plus léger d'utiliser des chiffres et non des mots. Mais question rédaction typographique, on fait alors quelques entorses aux coutumes, qui pousserait plutôt à tout écrire en toutes lettres. ^^'
    Au delà de 99, c'est le français qui est plutot agréable non ?

    Mille cent un <> one thousand one hundred and one

  11. #11
    Membre expérimenté
    Profil pro
    undef
    Inscrit en
    février 2013
    Messages
    524
    Détails du profil
    Informations personnelles :
    Localisation : France, Lot (Midi Pyrénées)

    Informations professionnelles :
    Activité : undef

    Informations forums :
    Inscription : février 2013
    Messages : 524
    Points : 1 546
    Points
    1 546

    Par défaut

    Si le truc fait du inline systématique, les gros jeux vont avoir des out of memory à tous les étages.

  12. #12
    Membre éclairé Avatar de Matthieu76
    Homme Profil pro
    Consultant informatique
    Inscrit en
    mars 2013
    Messages
    535
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2013
    Messages : 535
    Points : 784
    Points
    784

    Par défaut C# > C++ ?

    Tous ça me donne envie de réécrire mes project C++ en C#. Le C++ commence à devenir un language dépassé, non ? Quel intérêt de commencer un projet en C++ quand on a la possibilité de le faire en C# ?

  13. #13
    Expert éminent
    Avatar de Kannagi
    Homme Profil pro
    cyber-paléontologue
    Inscrit en
    mai 2010
    Messages
    2 536
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : cyber-paléontologue

    Informations forums :
    Inscription : mai 2010
    Messages : 2 536
    Points : 7 702
    Points
    7 702

    Par défaut

    Si tu te pose la question :
    1)Pourquoi le C++ est dépassé par rapport au C# , dans quoi au juste ?
    Surtout que en terme de paradigme le C++ dépasse probablement tout les autres langages vu qu'il permet de coder de façon très différente.
    2)Dans le Jeux vidéo (entre autre) on a besoin de faire du bas niveau et quel chance le C++ peut être bas niveau ,par exemple on l'utilise dans Arduino pour programmer dans l'embarquée et donc l'avantage du C++ c'est qu'il peut communiquer aisément avec le Hardware (ce n'est pas rien).
    3)Ils existent moult compilateur pour le C++ , qui est de plus très efficace donc le C++ est non seulement plus performant , mais il vise plus de plateforme.
    Quid des plateformes exotiques ?
    Rare sont les SDK sur consoles qui offre autre chose que du C/C++ , et refaire un compilateur qui vise autant de plateforme que Unity est loin d’être aisées ...

  14. #14
    Membre averti
    Profil pro
    Inscrit en
    septembre 2009
    Messages
    178
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2009
    Messages : 178
    Points : 442
    Points
    442

    Par défaut

    Citation Envoyé par Kannagi Voir le message
    Si tu te pose la question :
    1)Pourquoi le C++ est dépassé par rapport au C# , dans quoi au juste ?
    Surtout que en terme de paradigme le C++ dépasse probablement tout les autres langages vu qu'il permet de coder de façon très différente.
    2)Dans le Jeux vidéo (entre autre) on a besoin de faire du bas niveau et quel chance le C++ peut être bas niveau ,par exemple on l'utilise dans Arduino pour programmer dans l'embarquée et donc l'avantage du C++ c'est qu'il peut communiquer aisément avec le Hardware (ce n'est pas rien).
    3)Ils existent moult compilateur pour le C++ , qui est de plus très efficace donc le C++ est non seulement plus performant , mais il vise plus de plateforme.
    Quid des plateformes exotiques ?
    Rare sont les SDK sur consoles qui offre autre chose que du C/C++ , et refaire un compilateur qui vise autant de plateforme que Unity est loin d’être aisées ...
    Pour le point 2, je ne comprends pas ou tu veux en venir car tu parles de jeux vidéo et d'arduino dans la même phrase alors que les domaines n'ont rien à voir. Dans un domaine on est sur des machines très puissantes et dans l'autre sur des machines très lentes sans mémoire dynamique. Je ne vois pas de point commun entre les 2 domaines. De plus, tu veux dire quoi par bas niveau ? Utiliser un allocateur spécifique, utiliser des instructions SIMDs/NEON, contrôler l'alignement de structures de données ? Car une bonne partie de cela est faisable en C# pour peu que l'on se mette quelque contraintes (ce qui est le cas avec le compilateur Burst).

    Pour le point 3, Ça dépend du compilateur que tu utilises. En l’occurrence Burst, le compilo que développe Unity utilise LLVM pour le back-end. Donc en soit, ce n'est pas une tache démesuré que de faire un front-end à LLVM. Plein de langages le font déjà (Rust, Swift, CUDA et plein d'autres le font). Et je pense (à vérifier) que le fait d'utiliser LLVM permet de générer du code qui fonctionne sur les principales plateformes de jeux-vidéo (consoles, PCs, mobiles).

  15. #15
    Expert éminent
    Avatar de Kannagi
    Homme Profil pro
    cyber-paléontologue
    Inscrit en
    mai 2010
    Messages
    2 536
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : cyber-paléontologue

    Informations forums :
    Inscription : mai 2010
    Messages : 2 536
    Points : 7 702
    Points
    7 702

    Par défaut

    Pour répondre au point 2) Oui merci , il'ya pas de point commun entre les deux d'un point de vue puissance merci ce n'était pas évident...
    Sauf le coté bas niveau qui est exactement la même chose (je parle en connaissance de cause que communiquer avec le Hardware , c'est toujours pareil que ça soit sur Arduino , un PC, une console ou autre).
    Je parle de contrôler du hardware , ça veut dire en gros "affiche un triangle" , "lis la manette" , "envoyer un son PCM a la carte son" etc etc
    En C++ , tu peux contrôler finement le matériel (et donc exploiter le matériel assez bien) , et pour ça il faut des pointeurs nu et le mot clé volatile indispensable pour gérer les interruptions ou les I/O (le C possède aussi) .
    Tu peux te reposer sur un SDK existant , mais un SDK n'est pas toujours optimiser pour certaine tache.

    3)LLVM ne compile pas dans des formats propriétaire il me semble...
    Nintendo n'a jamais utilisé de format standard ,quid de convertir du elf en format proprio made in Nintendo ? (C'est pas infaisable mais faudra le faire)
    Il n'ya que Sony qui utilise le format ELF à ma connaissance (depuis la PS2).

  16. #16
    Membre expérimenté
    Profil pro
    undef
    Inscrit en
    février 2013
    Messages
    524
    Détails du profil
    Informations personnelles :
    Localisation : France, Lot (Midi Pyrénées)

    Informations professionnelles :
    Activité : undef

    Informations forums :
    Inscription : février 2013
    Messages : 524
    Points : 1 546
    Points
    1 546

    Par défaut

    Citation Envoyé par Kannagi Voir le message
    ...

    3)LLVM ne compile pas dans des formats propriétaire il me semble...
    Nintendo n'a jamais utilisé de format standard ,quid de convertir du elf en format proprio made in Nintendo ? (C'est pas infaisable mais faudra le faire)
    Il n'ya que Sony qui utilise le format ELF à ma connaissance (depuis la PS2).
    Il me semble que chez Nintendo le problème vient surtout d'une couche d'encryption anti-piratage.

  17. #17
    Membre averti
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    octobre 2008
    Messages
    158
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo

    Informations forums :
    Inscription : octobre 2008
    Messages : 158
    Points : 325
    Points
    325

    Par défaut

    Pour préciser un peu, il y a une chose que C++ fait très bien (et c'est l'un des seuls à le faire correctement), c'est la gestion des allocations et du layout mémoire. En C++ en peut contrôler de manière très précise l'alignement mémoire, la taille des structures utilisées et surtout à quel moment une allocation/déallocation a lieu, cet c'est extrêmement critique pour un jeu vidéo dans lequel une trame fait au plus 33ms.

    Dans la plupart des langages modernes type C#, la mémoire est gérées par le runtime et c'est un très gros problème pour plusieurs raisons:

    1) C'est impossible de définir de manière sûre a quel endroit une struct va être alloué alors qu'on a plutôt tendance à vouloir utiliser différentes stratégies d'allocation selon le type d'objets avec des pools etc. C'est surtout par principe de localité: si on veut itérer sur 10000 objets du même type, on a envie que ces objets soient alloués côté à côté pour éviter les cache miss.

    2) La philosophie globale de ces langage fait que la bibliothèque standard et la plupart des bibliothèques ne se posent pas trop de question sur les allocations puisque de toute façon tout est géré par le système. Or chaque allocation est assez coûteuse et encore une fois on ne peut pas dépasser 33ms par trame. Utiliser une expression lambda en C# déclenche des allocations (même quand on ne capture aucune variable), faire une requête LINQ déclenche des allocations, parfois même utiliser des algorithme de tri déclenche des allocations, etc. En tant que dev de jeu-vidéo on veut éviter ça absolument pour des questions de perfs.

    3) Au sujet du layout mémoire, on a besoin dans le JV de contrôler exactement le contenu de certains buffers parce qu'on va les envoyer à la carte graphique par exemple, ou encore parce qu'on sait qu'on a des ressources limitées sur consoles. Oui malgré la puissance des consoles actuelles on a encore des gros problèmes de mémoire sur les gros jeux AAA parce qu'on pousse toujours la machine dans ses derniers retranchements. En C# c'est très difficile et très verbeux de contrôler la mémoire, sans compter que l'allocateur utilise des "astuces" qui rendent un enfer la vie des progs. Exemple concret: si on alloue des objets en pool en C#, il arrive qu'il y ait des "trous" - ce qui normal pour garantir l'alignement - et ces trous sont parfois utilisé par l'allocateur pour allouer des petits objets de 1 ou 2 octets. On se retrouve avec une structure qui contient une autre structure et donc toute tentative de faire un memset(0) ou toute autre operation de ce type pourrait corrompre la mémoire...

    4) Mon dernier point et non le moins important, le garbage collector. Il peut se déclencher à n'importe quel moment, stoppe absolument tous les theads (même les threads critiques comme le son) et peut prendre facilement 100ms pour de grosses applications... Autrement dit 3 trames. Rien que pour cet argument, non on ne peut pas utiliser C# pour du gros jeu.

    Pour en revenir au HPC et Burst, le principe est justement d'utiliser un sous-ensemble de C# qui permet d'éviter la plupart des problèmes cités avant à moindre frais: on n'utilise que des struct et pas des class pour ne pas avoir d'overhead mémoire ni provoquer des allocs intempestives, etc. On aura toujours des problèmes de garbage collector mais qui seront moins prononcés vu qu'on aura moins d'objets alloués sur le tas. Bon en plus Unity n'est pas un moteur AAA donc c'est largement suffisant pour la plupart des utilisations.

  18. #18
    Expert éminent sénior

    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2003
    Messages
    5 660
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : juin 2003
    Messages : 5 660
    Points : 10 112
    Points
    10 112
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par Matthieu76 Voir le message
    Tous ça me donne envie de réécrire mes project C++ en C#. Le C++ commence à devenir un language dépassé, non ? Quel intérêt de commencer un projet en C++ quand on a la possibilité de le faire en C# ?
    La news est assez trompeuse. Il serait plus juste de dire qu'ils ont créé leur propre langage dont la syntaxe correspond à un sous ensemble de C# et qui est très spécialisé pour leur besoin très précis (ils ne s'agit pas recoder tout Unity avec ce langage). Sur leur blog ils donnent le liens vers quelqu'un qui a fait des tests assez poussés de perf C# "normal" vs C++, et je pense que ça résume pourquoi on utilise C++ malgré sa complexité:

    So the summary of C# performance so far:

    - Basic .NET Core performance is roughly 2x slower than C++ performance, on both Windows & Mac.
    - For simple types like “vector” or “color”, you really want to use struct to avoid allocation & garbage collection overhead. Otherwise your code will run 30 (!) times slower on a 16-thread PC, and 3 times slower on a 8-thread Mac. I don’t know why such a performance discrepancy.
    - Mono .NET implementation is about 3x slower than .NET Core implementation, at least on Mac, which makes it ~6x slower than C++. I suspect the Mono JIT is much “weaker” than RyuJIT and does way less inlining etc.; you might want to “manually inline” your heavily used functions.

  19. #19
    Membre à l'essai
    Femme Profil pro
    Développeur informatique
    Inscrit en
    mars 2017
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Santé

    Informations forums :
    Inscription : mars 2017
    Messages : 13
    Points : 17
    Points
    17

    Par défaut wtf

    il faudrait une traduction du belge vers le français... les nonante et les francisations à outrance, c'est bien de chez eux ça ... pourquoi parler de 'ramasse miettes' alors qu'on parle tous de 'garbage collector'? etc...
    et bien, si tout ce que raconte l'article est réel, ça devient beaucoup moins sexy de coder sous Unity ... :s berk

  20. #20
    Membre éclairé Avatar de Matthieu76
    Homme Profil pro
    Consultant informatique
    Inscrit en
    mars 2013
    Messages
    535
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2013
    Messages : 535
    Points : 784
    Points
    784

    Par défaut

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    Sur leur blog ils donnent le liens vers quelqu'un qui a fait des tests assez poussés de perf C# "normal" vs C++, et je pense que ça résume pourquoi on utilise C++ malgré sa complexité
    Moi j'avais regarder ça : https://www.codeproject.com/Articles...-Csharp-vs-NET

    Je sais bien de théoriquement C++ et plus rapide que C# mais je pense que s'il on optimise pas son code à la ligne près on ne verra pas la différence. Et je dirais même que c'est plus facile de faire un code lent en C++ qu'en C#.
    Tu oublies juste de passer un vector par référence et paf ton code est plus lent que si tu l'avais fait en C#.

    Et puis mon dans mon code C++ je ne fais aucun malloc, je ne fais que des news, j'utilise toujours les destructors par défaut, je n'utilise plus que des vectors car les tableaux trop compliqué quand tu dois copier des objets en contenant, etc...

    Je suis sur que plus de 90% des programmes fait en C++ serait plus rapide en C# car les développeurs font beaucoup d'erreurs qui ralentisse le code.

Discussions similaires

  1. [Système] Remplacer une chaine par un lien hypertexte
    Par Bisûnûrs dans le forum Débuter
    Réponses: 10
    Dernier message: 06/06/2007, 10h34
  2. Réponses: 2
    Dernier message: 26/07/2005, 22h44
  3. Réponses: 5
    Dernier message: 30/05/2005, 17h58
  4. Réponses: 2
    Dernier message: 15/03/2005, 16h40
  5. Remplacer plusieurs colonnes par un 'alias'
    Par zestrellita dans le forum Langage SQL
    Réponses: 7
    Dernier message: 22/04/2004, 17h51

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo