Reprise du message précédent :

 
justement, c'est ce  qui est proifitable et qui fait que l'on est plus efficace en java/C# qu'en C++./ Fini de se tirailler la tête sur de la gestion de la mémoire, fini les arithmétiques d'alignement. Fini la quicaillerie.
 
De la même façon que lorsque les premiers langage de programmation sont arrivé, on a pu s'éloigner du comportmeent interne de la machine. Fini la quicaillerie.

J ai dis qu il y avait des chances que ce soit plus rapide en C# qu en C++.
Maintenant j en ai discuté avec deux chercheurs en IA (donc face a eux j ai pas grand chose a dire).
Ensuite j ai la flemme de reinstaller VS 2005 chez moi et puis quand je rentre du boulot la derniere chose que j ai envie de faire c est programmer.
Donc install VS 2005 ... fait toi un petit programme a base de list a 100000 maillons (voir plus si ce n est pas assez), un bon gros sort et test (en mode release, le mode debug de C# et vraiment tres gourmand).

Mais moi je l aime justement cette quincaillerie et si ca continue, dans quelques annees on saura meme plus ce qu ils se passent au niveau machine quand on developpera un programme.
Les langages avances sont bien dans une optique de productivite et certainement pas dans une optique d apprentissage. Je ne conseille pas le C# a qui veut debuter en programmation (meme si c est facile et intuitif et tout et tout)

 
bah justement, de la même façon qu'on ne debugge pas un oscilloscope, pourtant des programmes sont des flux de courant au final.

Tu n'as peut-être pas remarqué, mais c'est le concept même d'un langage de haut niveau
 
Le principe, c'est d'abstraire le bas niveau pour créer des langages plus humains, et plus productifs
 
Si tu trouves déjà le C# trop éloigné du métal, juste un conseil, ne fait jamais de Python, de Ruby, de Haskell, d'Erlang, de Perl, de ML, de Prolog, de Lisp, de Smalltalk, d'Effeil, de Mozart/Oz ou de Clean

Pas exactement quand même, vu que la séparation plus ou moins complète de la machine a été faite à la création du 2e langage de programmation (si on considère le Fortran comme le premier)

Rien de très concré/argumenté...

Et en quoi est-ce un problème, fondamentalement? Les gens appréciant ou bossant dans le domaines (programmation de drivers, de kernels, ...) utiliseront des langages bas niveau, les autres utiliseront des langages de haut niveau  
 
Pour moi, ce qui se passe au niveau de la machine quand j'exécute mes codes n'a aucun intérêt, le fait de devoir l'apprendre pour comprendre les bottlenecks issus de l'architecture me fait chier plus qu'autre chose et classiquement plus un langage m'isole du métal et plus je l'apprécie  

plus  
 
http://c2.com/cgi/wiki?HeroicDebugging chercher la première histoire de JimWeirich (dans la première dizaine)

et bien teste et tu verras par toi meme ... c est pas compliqué de tester une chose aussi simple. Ensuite c est completement algorithmique (google est ton ami) ... l algo employé pour les listes en C# est le meilleur qui soit actuellement. Je vais repeter qu il y a des chances que soit plus rapide  combien de fois ??? Il y a des chances = theoriquement possible.
 

Tous les gouts sont dans la nature

Pas la peine de t'énerver, je demande juste une explication concrète.
 

Quel algo pour les listes Une liste chainée (ou doublement chainée ou autre...) reste une liste, il n'y a pas d'algo particulier derrière ça. Tu dois vouloir parler d'autre chose probablement, comme des tris ou des recherches dans des conteneurs triés.

 
Oui c est bien ca je parlais des tris et recherches.

 
Note : desole pour l enervement ... le taffe me rend completement con en ce moment faut vraiment penser aux vacances.

 
en meme temps je suis pas sur que le D soit super utilisé en entreprise

Justement, le D devient un avantage pour ta boite dans la mesure où il est aussi performant et plus productif
 
C'est l'arme secrète qui permet de sortir le produit débuggé avant la concurrence, et avec plus de fitioures

 
+ quand t'es pro, plein le cul de refaire 100x les mêmes choses. Vive java/C#.

C'est pas pour être méchant, mais ces deux déclarations sont quelque peu contradictoires

 
ouais d'un autre coté entre :
 
- perdre du temps à découvrir un langage (le D) et ses outils associés (IDE, outils de testing etc...)
- perdre du temps à convaincre le client
- perdre du temps à chercher des libs ou des snippets sur le D
 
et  
 
- réutilisation massive des libs de la boite (par exemple, en .net 2 on utilise une architecture SOA et on a dev un petit outil qui se connecte à une base de données SQL et a partir d'une table ou d'une proc stoc (merveilleux ce truc) te crache l'Entity et la couche business/service/dal correspondante )
- utilisation de mes 4 années d'expérience pro en C#
 
je ne sais pas si je serais gagnant niveau temps en fait

Ca tu le fais dans ton temps libre, c'est marrant d'apprendre de nouveaux langages

 
je passe 9h par jour a faire du code ou du design (mcd, uml etc...) voir des specs pour le client, donc bon, quand je rentre chez moi, j'ai un peu autre chose a faire (non, nerdizer sur HFR ne compte pas)
 
Edit : 9h "théorique"

j'ai été trop vite en parlant de java, ca fait 5 ans que j'en ai pas fait

Dév Java = SSII = marre de faire 100x les mêmes choses.
Dév Jeux vidéos (oui je sais, je suis moulu ) = des choses différentes tout les jours = vice le C++ ! Aucun rapport mais c'est pas grâve, c'était  pour troller.

Bon bah je continue si c'est comme ça :X
 
C / C++ c'est pour les papys qui ne savent pas s'adapter et qui sont degoutés que n'importe quel etudiant puisse faire aussi bien et deux fois plus rapidement qu'eux en utilisant C#  

Faire du Haskell, du Python, de l'Erlang, du Ruby, du SML ou du Mozart/Oz, ça détend, parce que ça évite de bosser sur des trucs pourris (Java, UML, MCD, ...)

Ouais enfin là stu veux pour les jeux vidéos, le C# c'est pas encore ça
 
Et le C# c'est pour les papys qui arrivent pas à se débarasser de leur héritage C++ et qui sont dégoutés que n'importe quelle étudiant puisse faire mieux qu'eux deux fois plus rapidement qu'eux et en 4 fois moins de ligne en utilisant Haskell

Dans le futur, il n'y aura plus du tout de languages de programmation. On indiquera juste à quelques 100 milliards d'ordinateurs en cluster via le supernet quels sont les résultats corrects de ceux qui sont abberrants, et le cluster trouvera tout seul tous les bons résultats.
 
D'ailleurs les languages de programmation, ça craint franchement. Le top de la fumisterie c'estait le language Z. Ils nous ont fait croire que l'on pourrait se passer de programmer, mais en fait on était toujours obligé d'utiliser au moins un logiciel de reconnaisance vocal.
 
Maintenant avec le système d'information moderne plus besoin de ces archaïsmes, le supernet comprends les humains, et nous reprends même quand on commet des fautes. Par exemple, il ne faut pas dire: salut!, mais: <<bonjour maître>>. Comme le système est corrigé en temps réel, c'est sûr que le supernet a fait les calculs nécessaires pour optimiser les relations homme-machine.
 
C'est marrant quand on écoute les conversations des anciens programmeurs (c'est comme ça qu'on appelait les gens qui tapaient sur des claviers dans le temps), on a l'impression qu'ils ont bien galérés pour contruire le supernet, et que maintenant ils n'y comprennent plus rien. De nos jours tu n'a rien à faire qu'à te laisser guider, tout est contrôlé et normalement, d'ici à 2144 le supernet devrait avoir terminer de calculer la façon optimale de gérer les humains pour qu'ils ne meurent jamais.
 
God save the supernet.
 
{Source: retransmission de pensée d'un internaute; temps origine: 20/02/2038,13:07UTC3.46; temps destination: 22/08/2006:00:14UTC0; mode: compatibilité internet}

J'pense que tu devrais arrêter la coke

+1

 
je sais pas ce que tu prends mais je veux le même  

"I'll be back"

 
harko, ça donne quoi C# et DX ? Tu avais essayé non ?

 
moi j'ai essayé et ca marche nickel... y'a plein d'exemple en plus en C# dans le SDK DX... pas eu de pbm de perfs.

Selon crosoft C# et DX c est l avenir du jeu video ... ils ont oublié de preciser dans combien de temps ca le sera et tout ce qui est sur c est qu il y a encore beaucoup de boulot (pour l IA ca marche bien mais pour le graphique c est pas au top)

 
pourquoi cela ? Attention, je veux une réponse technique de qualité.

+1 j'ai installé le dernier sdk ce weekend, les samples tournent au poil

Je rappelle surtout la sortie le 30 août 2006 de la béta 1 de XNA : Le "Game Express" de Microsoft, qui se trouve est une surcouche de DX basée sur .NET
D'après les premiers feedbacks des testeurs des alpha et les personnes qui bossent au développement de l'appli, ça se présente comme une véritable révolution.
Microsoft compte largement imposer XNA pour tout ce qui est dev de jeux Windows/XBox (notamment parcequ'on peut faire rigoureusement le même code pourles deux plateformes).
Microsoft indique aussi "qu'actuellement" seule la XBox360 est prise en charge pour ce qui est des consoles de jeu, ce qui laisse sous-entendre un portage possible sur d'autres consoles.
 
Bref, outre les performances avancées par Microsoft comme identiques ou presque au C++ (notamment, tout comme les méthode "Sort()" d'un objet, les méthodes hardcodées dans le framework pour le rendu graphique par exemple, utilisent les meilleurs algos connus à ce jour, donc à mons d'être un génie, pas moyen de faire mieux, même en ASM), XNA semble être le produit de rêve pour les développeurs de jeux indépendants (multi-plateformes).
 
Déjà 10 universités ont inclu XNA dans leur cursus de formation.
 
Bref, je pense que ce qu'on a pu dire jusqu'à présent sur C# incompatible avec jeu est en train de s'envoler.
En effet c'était vrai tant qu'on devait manuellement déclarer 25000 matrices de vertices en mémoire à chaque frame... En managed c'est pas top. Maintenant que c'est les libs de l'appli qui font s'en charger, on peut imaginer faire des moteurs 3D extrêment performants sans connaissances, là où le même niveau de connaissances en C++ ne permettent de faire qu'à peine mieu qu'en C# "classique".

Bah si : implémente la même chose en langage natif (C++ compilé par exemple), tu auras la même chose avec un chouillat de perfs en plus

c'est quoi le rapport entre IA et DX ?
Pour ce qui est du C#, yes, le C# est un peu plus lent que le C++ avec des pointeurs qui pointent sur des pointeurs qui pointent sur des pointeurs qui pointent sur... on sait pas trop où en fait, mais l'IA utilisant massivement des graphs de grande taille, et comme dit précédement, les méthodes de recherche et autres dans les graphs étant extrêment performantes dans le framework .NET, je ne suis pas si sûr que C# pêche énormément à ce niveau.
Ensuite, laisser le GC releaser les ressources mémoires au moment le plus oppurtun, c'est aussi éviter de vider de la mémoire alors qu'on a déjà le CPU overbooké par des traîtements complexes. Je ne suis pas certain que "tout gérer à la main" soit toujours un avantage aussi flagrant.

et tu connais tous les algos par coeur...
ps: et je ne vois pas comment tu peux faire mieux que ce qui est codé dans le framework... il est pas écrit en C# le framework hein...

C'est décidemment un topic très trollesque.
 
A votre avis, et à terme, le framework sera plus efficace sous windows ou linux ?

Sauf que le rendu ne fait pas tout. En fait dans un jeu bien écrit, le cpu et le gpu fonctionne en parallèle, et le rendu ne prend pas 90% du temps - idéalement le rendu ne devrait quasiment rien prendre, mais c'est bien sûr impossible. En pratique ça tourne autour de 50%.
 
Si par exemple le calcul des animations (position des bones, pas animations des vertices qui dans l'idéal se calcule sur gpu), et une partie de la gestion des collisions, peuvent être sortis dans des libs annexes, il reste quand même le moteur du jeu qui fait mine de rien beaucoup de choses.

L'IA ne fait pas que des recherches de pathfinding, loin de là!

Tout à fait! Et même cela évite de releaser pour réallouer un peu plus tard : un GC permet une grande réutilisation de petits blocs mémoire.

Suffit de recherche le papier en question

Une couche C#/natif a toujours un coût. De même que la couche C++/Lua que l'on utilise ici a un petit coût, pour un gain en confort de dév et de test/correction

 
on peut rien faire d'efficace sous linux. On ne construit pas un immeuble stable sur des sables mouvants....

Je dis pas le contraîre.
 
Mais justement, actuellement, parceque le C# est lourd pour tout ce qui est allocation mémoire et création d'objets, le rendu, qui ne demande pourtant rien (à la base, c'est juste copier des données dans une zonemémoire puis les envoyer au gpu) prenait actuellement du temps en C#, certainement beaucoup plus qu'en C++.
Sur ce point, C# pêchait énormément, puisque cette partie qui est censée être très rapide ne l'était pas.
Avec XNA, ça ne va plus être le cas.
C'est donc un gain de perfs énorme.
 
Ensuite, XNA, c'est pas seulement une surcouche de DX, c'est un ensemble de libs dédiées au jeu. Il devrait notamment y avoir des libs de recherche de chemin le plus court et autres, qui sont largement assi critiques que le rendu. Tant que l'appli n'est pas sortie, c'est pas la peine de faire des plans sur la comète.
 
Mais XNA est clairement, avec sa version "Express" destinée aux novices. Et un novice qui fait du C++, il va te faire un tri à bulles dans un array de 100000 lignes de pointeurs. Avec tous les artifices que tu veux, c'est plus lent qu'un "Sort()" bête et stupide sur un "List<myClass>".