Le fait qu'Unity en interne soit du C++ ne change rien au fait que des milliers de développeurs créent des jeux en C# grâce à cette bibliothèque. Je le mentionnais dans mon message pour expliquer que le nombre de domaines applicatifs perçus comme "ne tolérant pas un GC" diminue, longtemps les jeux vidéos ont été cités en exemple, ce n'est plus pertinent aujourd'hui.
(Le fait qu'en interne des bouts de code critiques soient écrits dans un autre langage que le reste de l'application n'est pas nouveau. Tous les langages managés ou presque ont un runtime en C (plus rarement en C++), par exemple.)
Le problème des GC est qu'il rajoute des latences à peu n'importe où, et un peu n'importe quand.
C'est un peu simplificateur. On peut écrire du code à faible latences dans un langage à GC—mais il faut un GC raisonnablement prévu pour ça. En OCaml par exemple, les latences du GC sont courtes pour la plupart des types de charge de calcul (il y a des cas particuliers mauvais, comme sur tous les systèmes).
Golang dispose d'un gc avec des latences ajouté super courte (9ms de mémoire), mais au pris d'un usage du cpu plus gros.
Dans ce billet de blog, qui part d'un benchmark des latences (sur un workload spécifique) que j'ai contribué à écrire / alimenter, on voit que les latences du GC OCaml sont inférieures à celles de Go 1.7—OCaml a une implémentation plus simple car le GC n'est pas concurrent.
[^] # Re: Phobie du GC
Posté par gasche . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 5.
Le fait qu'Unity en interne soit du C++ ne change rien au fait que des milliers de développeurs créent des jeux en C# grâce à cette bibliothèque. Je le mentionnais dans mon message pour expliquer que le nombre de domaines applicatifs perçus comme "ne tolérant pas un GC" diminue, longtemps les jeux vidéos ont été cités en exemple, ce n'est plus pertinent aujourd'hui.
(Le fait qu'en interne des bouts de code critiques soient écrits dans un autre langage que le reste de l'application n'est pas nouveau. Tous les langages managés ou presque ont un runtime en C (plus rarement en C++), par exemple.)
C'est un peu simplificateur. On peut écrire du code à faible latences dans un langage à GC—mais il faut un GC raisonnablement prévu pour ça. En OCaml par exemple, les latences du GC sont courtes pour la plupart des types de charge de calcul (il y a des cas particuliers mauvais, comme sur tous les systèmes).
Dans ce billet de blog, qui part d'un benchmark des latences (sur un workload spécifique) que j'ai contribué à écrire / alimenter, on voit que les latences du GC OCaml sont inférieures à celles de Go 1.7—OCaml a une implémentation plus simple car le GC n'est pas concurrent.