Discussion :

[deadalnix]

Je me pose pas mal de questions sur D en ce moment, particulièrement dans sa gestion du bas niveau.

Je suis sur des projets dont certains sont critiques au niveau des perfs, et ou j'ai besoin de gérer des choses à la main.

Pour l'instant, j'utilise C++, car il permet de s'élever quand on en a pas besoin. par exemple en utilisant des smartpointer pour la mémoire.

D me semble un bon langage pour mes projets, et je m'y intéresse donc. Mais deux question restent entières peuvent avoir des conséquences terribles sur les perfs :

1/ Comment est géré le null ?
2/ Comment sont géré les tableaux ?

Je ne parle pas de comment ils sont gérés en D, mais ce que la machine fait réellement, quelle est la représentation en mémoire, etc . . .

[Invité]

Salut

1/ Le null

Le null est géré comme le NULL en C. Le D ne fait pas de runtime check sur la nullité d'un pointeur ou d'une référence, tu te tapera une erreur de segmentation comme en C/C++.

En D tu a les pointeurs, qui marchent comme en C, et aussi les références vers les objets qui sont l'équivalent des smart pointers C++ (sauf que les smart pointers font du comptage de référence alors que là le GC s'en charge).


Si tu veux de la performance je te conseille d'utiliser les struct plutôt que les class en D. En effet les struct sont des type valués, et seront alloués sur la pile quand il faut, alors que les "class" sont créés dans le tas a priori.

Pour te donner une idée précise :
struct en D = struct/class C++ sans méthode virtuelle (ie Plain Old Data)
class en D = smart pointer vers struct/class C++ avec méthodes virtuelles

Donc en manipulant des struct tu as une indirection de moins, et tu fais des copies.

2/ les tableaux
Il y en a plusieurs sortes :

- tu as les tableaux de taille constante comme en C, qui ont la même disposition en mémoire. La notation est différente toutefois.

En D: int[5][4] tableau;
En C: int tableau[4][5];

- tu as aussi les tableaux dynamiques qui correspondent plus ou moins à un vector<> C++.
En interne c'est un couple (pointeur, taille). Donc une indirection de plus par rapport à un tableau de taille fixe.

En D: int[] tableau;
En C++: vector<int>& tableau;

Pour ces deux types de tableaux de toute façon, tu peux obtenir un pointeur vers le premier élément en écrivant tableau.ptr

En mode debug, le compilateur fait un runtime check pour chaque accès à un tableau. Ton code ira donc plus lentement en debug.
Tu peux shunter ca en écrivant tableau.ptr[i] si tu as besoin de perf même en debug.

Mais en mode release ca ira aussi vite que du C++, c'est le même layout mémoire.

Perso je dirais que le D est un bon langage pour les applications qui doivent aller vite. D'ailleurs j'en fait avec. Ca va vite comme du natif quoi, il faut faire attention à pas lancer le GC quand il ne faut pas (par exemple en minimisant le nombre d'allocations, en utilisant des pools ou des placement new).
Globalement, donc, c'est pas un problème.

Au fait, si tu as Linux, tu peux utiliser le compilateur LDC qui produit du code plus optimisé que DMD.

Si tu as d'autres questions n'hésite pas.

[TSalm]

Salut,

J'ajouterais qu'il est de toute façon très facile de ré-utiliser du code en C/C++ en D.
Côté vitesse d'éxécution, dire que le D est aussi rapide que le C++ est discutable (et la discussion peut durer longtemps ;-) ). Pourtant, il doit bien y avoir quelques benchmarks...

[Invité]

Bof, c'est assez simple
Avec DMD c'est souvent plus lent (et même des fois pas mal plus lent car par exemple les méthodes virtuelles ne sont pas inlinées). Avec LDC c'est souvent plus rapide (et un jour LLVM fera plus d'optimisations que GCC).

Mais bon il n'y a pas trop de benchmark pour appuyer ca. Ayez confiance

Si D gagne en popularité, je suis certain que les compilos pourront aller beaucoup plus loin question optimisation qu'avec C/C++.

Par exemple:
- le const en C/C++ ne donne quasiment pas de garanties qui permettent au compilateur d'optimiser. C'est pour ca qu'ils ont inventé restrict qui n'est pas dans C++.
- le final switch dans D2 pourra aller plus vite qu'un switch normal (pas de check)
- les expressions tableaux permettent de vectoriser les boucles plus facilement (même si les compilos D ne le font pas). La solution C++ c'est des librairies ou des intrinsics SIMD. Bof.
- on peut calculer beaucoup plus de trucs à la compilation.

Perso je suis confiant vu les cafouillages de C++.

[deadalnix]

Génial, je ne m'attendais pas à des réponses aussi complètes !

Je crois qu'il va me falloir un peu de temps pour être aussi compétant en D qu'en C++, mais à la vue de ce que tu me raconte, ça semble convenir parfaitement à l'usage que je veux en faire.

Questions subsidiaire : ou trouves tu ces informations ?

Et enfin, que vaut gcd ?

[Invité]

Je crois qu'il va me falloir un peu de temps pour être aussi compétant en D qu'en C++

Oui c'est pas si évident en fait (même si c'est quand même moins compliqué au final que le C++).
Moi le C++ je garde ca seulement pour le taf , il est mieux là où il est.

Questions subsidiaire : ou trouves tu ces informations ?

Avec le temps passé avec le langage

Plus raisonnablement, tu peux lire les newsgroups de Digital Mars :
digitalmars.D (engueulades techniques entre ceux qui font le D)
digitalmars.D.announce (annonces de compilos notamment)
digitalmars.D.learn (pour poser des questions)



Si tu as IRC, je te conseille fortement le channel #D sur freenode. Parce qu'il y a des gens compétents et disponibles dessus.

Et enfin, que vaut gcd ?

Tu veux dire GDC ?
Pas grand chose pour le moment, il n'est pas à jour.
Il était abandonné depuis deux ans mais j'ai vu aujourd'hui que quelqu'un travaillait dessus.

Si tu as Linux tu peux utiliser DMD ou LDC.
Si tu as Windows seulement DMD.

Si tu commences le D : utilises D1 et Tango, même si Tango a l'air plus lourd d'un premier abord.

Perso j'utilise Phobos depuis le début mais maintenant j'aimerais bien migrer tout mon code. Le problème des deux librairies standards est en train d'être réglé avec D2, mais pour le moment il existe bien.

Ah oui, au fait, tu veux faire quoi avec le D ?

[deadalnix]

Ah oui, au fait, tu veux faire quoi avec le D ?

Dans un premier temps m'y mettre !

Mais pour mieux répondre à la question, de la physique temps réel (cad que le but n'est pas que le résultat soit exact mais qu'il soit calculé rapidement, et suffisamment bien pour bluffer l'utilisateur).

Dans la mesure ou il a certains algo assez lourds, comme la détection de collision, ou la résolution de contrainte, ou exécuter des actions dans le passé (du par exemple à du lag dans le transferts des infos), il n'est pas négligeable d'avoir un peu de contrôle sur ce qui se passe.

Typiquement, ils y a des algos ou un garbage collector se retrouverait à gérer un graphe de données absolument abominable.

J'aimerais tester tout cela en D car ce langage me semble prometteur.

[Invité]

OK informe nous de tes progrès

Bonne chance

[deadalnix]

Et bien voila, j'ai franchis le pas et commence le D. Je bute encore souvent sur des problèmes idiots, et c'est parfois frustrant de redevenir un débutant (d'autant je me débrouille plutôt bien en C++). Mais franchement, ce langage est ce qu'auraient du être java et C++. Dommage qu'il ne soit pas plus utilisé.

[Invité]

Attention, une fois qu'on a pris le virus on a du mal à repasser au C++

Hésite pas à poser des questions ici (ou sur digitalmars.D.learn ou tu auras une réponse très vite)