Reprise du message précédent :
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>".

Arf, le vieux troll...
Pour info, comparaison de quelques temps de compilation sous Win et Linux d'un même projet :

http://www.gamesfromwithin.com/art [...] 00092.html
http://www.gamesfromwithin.com/art [...] 00100.html
 
Bien sûr tout le monde ne compile pas, mais c'est une opération assez lourde et donc un bon indicateur de performances assez complet (cpu + mémoire + disque).

Ok en effet.
Une chose très importante en Direct3D (mais qui est apparemment conservée dans XNA si c'est simplement une surcouche) est le coût des appels à la méthode de rendu d'un objet (DrawPrimitive/DrawIndexedPrimitive) : chaque appel fait passer du ring3 (applications) au ring0 (kernel) du mode protégé, et c'est ce qui ralentit énormément tout moteur 3D Direct3D.
 
Si XNA pouvait squizer cela, les jeux écrits en C# auraient pû être bien plus rapides que leurs homologues C++. Dommage ce n'est pas le cas

D'abors, si tu continues à être désagréable, tu vas te retrouver obligé de participer à ce topic, et le refaire tout en C++ pour me montrer que c'est mieu
http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0

 
Euh oui, mais windows boot beaucoup plus vite !

Il plante aussi beaucoup plus vite

quand une fusée se crash ça va aussi plus vite qu'un vélo qui se crash

1) Chez toi peut-être
2) Tu boot combien de fois par minutes ? Ha pardon, j'avais oublié que Windows plentait tout le temps (réponse du berger à la bergère inside).

je me méfis des comparos linux/windows dans la mesure où la plupart du temps les gens qui utilisent des stations de travail, utilisent des linux uniquement en mode console, et donc c'est nomale que si le linux en question ne gere pas un explorateur ou un environnement genre kde ben que toute les perf soient consacrées aux taches consoles...
 
EDIT: idem pour la stabilité souvent les utilisateurs de linux sont justement qu'utilisateur, une fois le systeme paramétré ils n'y touchent plus. apres si on fait du emacs + make et gcc ben c'est normale que ça plante jamais... ma copine elle xp depuis des années elle fait que du photoshop k!tv et firefox, ben ça plante jamais hein  

n'importe quoi

Non merci, je n'aime pas les mmorpg. Je ne touche qu'au fps et rts dans mes projets persos (et à tous les autres genres au taf ) :

Ca n'empêche pas que le moteur 3D reste en grande partie pareil (faut juste qu'il s'adapte à de plus grands espaces, ce qui n'est pas forcément le plus simple à faire à priori)
En plus, tu prends FoM par exemple, c'est ni plus ni moins qu'un QuakeLike avec 1000 personnes connectées : c'est un FPS avec une gestion commerciale en plus...

Les besoins sont très différents : dans un mmo, le calcul des animations prends beaucoup plus de temps et devient critique, alors que l'éclairage, les collisions etc... passent carrément en arrière voire aux oubliettes.

 
On ne peut pas comparer 2 compilos completement differents (g++ / VC++). VC++ initialise la memoire lors d allocations (je ne suis plus sur qu il le fasse en mode release mais en mode debug tu as 0xCDCDCDCD si je me trompe pas des que tu alloues de la memoire).

D'un autre côté, avoir un cube capable de marcher sur un sol accidenté et buter contre les mur, c'est déjà pas mal pour moi

En mode debug seulement ! Et tu peux faire de même avec g++ (ce que je fais en utilisant le fameux mmgr de Paul Neetle ou avec le GC).
En release, les deux compilos fonctionnent bien sûr de manières similaires.

oki autant pour moi merci de l info. Mais j aurais pensé que c est deux compilo etaient differents. J ai jamais testé avec des programmes basiques (multi archi) utilisant uniquement des libs standards.
donc j etais pas trop sur d autant que mes projs ne finissent jamais en mode release sous VC++.

On est vendredi aujourd'hui ?

je pense que comparer des softs windows/linux, c'est pas aussi évident :
- déjà, de par la sructure de leurs noyaux, ces deux OS offrent des performances très différentes selon les traîtements demandés. Linux préfère le multi-processus au multi-thread. Windows, c'est l'inverse. c'est un exemple basique, mais qui résume bien la différence.
=> Ainsi, une appli particulière, portée d'une plateforme à l'autre sans optimisation particulière, offrira toujours des performances nettement différentes d'une plateforme à l'autre, sans que cela ne signifie quoi que ce soit.
 
- ensuite, les technologies windows sont pour la plupart proprio et protégées. rares sont donc les implémentations des libs windows sous linux. par contre, l'inverse est vrai. ainsi, on se retrouve avec firefox qui ramme à mort sous windows, alors qu'il est léger sous linux, car sous windows les libs utilisées sont de simples transcriptions de celles de linux, sans utiliser les éléments du kernel. comparativement, IE est bien plus léger que FF sous Windows, ce qui résume bien la différence d'architecture logicielle.
=> ainsi, une application transcrite d'un OS vers l'autre, même si elle comprends des optimisations spécifiques, reste biaisée tant qu'elle n'est pas complètement réécrite de façon à utiliser aussi des libs dédiées.
 
- en fait, les seuls logiciels qui pourraient effectivement être comparés de façon "objective" sont ceux qui sont écrit dans des langages de haut niveau, comme le Java et le C#, et comportant des optimisations spécifiques à l'os cible.
=> malheureusement, ces optimisations s'accompagnes aussi de modifications de l'algorythme (passer de multi-process à multi-thread, c'est pas seulement de la réécriture, c'est aussi toute la conception qui est à revoir), du coup on est limité par des applications simple qui, par définition, ne peuvent pas être représentatives.
 
il est admis que windows est plus lent que linux. cependant, je ne pense pas qu'un seul bench soit réellement valable pour argumenter dans tel ou tel sens.

Mon moteur 3D est la preuve du contraire

Au lancement seulement, car il est intégré à l'explorer donc en grande partie chargée au démarrage de Windows. En utilisation non.
 

N'imp.

 
pas franchement non, c'est l'inverse. La différence est d'ailleurs assez monstrueuse sur certains site

linux préfère aussi le multi-threading au multi-process ? depuis quand ?
 
quand je dis "léger", c'est sa taille et son occupation mémoire, pas ses performances.
 
ensuite, vive la légende de ceux qu'on tout compris à l'info... iexplore.exe intégré en partie dans explorer.exe... biensur. alors pourquoi je peux shooter explorer.exe de la mémoire et continuer à utiliser iexplore.exe sans aucun problème ?
 
ils utilisent nombre de libs communes, directement accessibles dans le kernel, tout comme word par exemple; tu t'es jamais demandé pkoi open office met deux plombes à démarrer, alors que les applis office mettent moins d'une seconde ?

pas fini de dire des bétises hein   et je te signale que les probleme de conso memoires apparaissent autant sous linux que sur windows

parceque FF ça demande pas trois plombes à démarrer sous Windows par hasard ?
j'ai le temps de lancer tous les softs de la suite office 2003 en moins de temps... faut pas pousser non plus. sous linux, moz démarre immédiatement, car toutes les libs graphiques utlisées notamment sont déjà en mémoire, comme c'est le cas quand tu lance word sous windows. y'a pas de libs xforms ou autre natives sous windows, moz doit s'emmerder à les démarrer avec lui sous windows...
 
et si moz utilise en effet les libs intégrées de windows, dis-moi pkoi sous vista son aspect reste austère alors que toutes les autres applis que j'ai pu tester se mettent aux couleurs de vista ? (tronche des boutons, progressbar, etc.)

si, et la reponse est tres, c'est parce que c'est de la merde... meme les linuxiens n'utilisent pas open office alors    

 
Peut-être que s'il était écrit en c#....

et après, c'est moi qui troll    

bon ok j'arrête

Arjuna je veux bien te croire quand tu me dis que ton FF met 3 plombes à s'ouvrir, mais je ne pense pas que ce soit le cas chez tout le monde perso j'utilise aussi linux et FF s'ouvre aussi vite sous linux que sous windows...

Tout pareil.
Quand au coup des optimisations spéciales Linux...

 
spa un troll. Linux est une merde, incapable d'avoir la moindre API stable, et qui change chaque fois qu'un développeur-étudiant-communiste fait un commit dans le CVS.
 
Si vous voulez que je défonse linux, attendez ce soir, là, j'essaye de bosser

fait gaffe, je vois un peu de mousse derrière tes épaules
 
sinon, pour le coup de FF, euh... à moins que ça aient empiré sous Linux (ou amélioré sous Windows) la dernière fois que j'ai utilisé FF sur un linux, c'était bien plus rapide que sous win. maintenant, j'ai pas fait de tests récents... a l'époque en tout cas, FF utilisait XForms ou Mozaic ou je ne sais quoi, qui sont déjà chargés par la GUI de Linux. Sous Win, il fait pareil, mais avec des versions "portées" de ces mêmes libs. Non pas qu'elles ne soient pas performantes, elles doivent être chargées avec Moz alors qu'elles n'ont pas besoin de le faire quand on est sous Linux.
D'ailleurs, je vais parler plutôt de mozilla en effet, car mes tests datent de l'époque où FF n'existait pas, il n'y avait que mozilla (époque de la sortie de NS7 quoi, quand on avait un bon grs truc "launcher" dans la barre d'icône, qui tentait de faire semblant d'accélérer l'unise à gaz que c'était au démarrage. Sous Linux, c'était infiniment plus rapide à démarrer à cette époque. je pens(ais) que ça n'a(vait) pas changé...

Parce que la norme Posix a beaucoup évolué ces 15 dernières années ?

 
renseigne toi sur c_type_b qui disparait par surprise, sur les changement d'ABI de gcc, sur les changements de comportement des API du noiyau, sur ce genre de conneries, tu verras ce qu'es une blague dans l'informatique.  
 
Va faire lire ça à n'importe quel responsable produit, ça devrait bien le faire rire :  
http://lxr.linux.no/source/Documen [...] nsense.txt

c'est pas des optimisations "spéciales linux" pas plus que "spéciales windows". mais quand je vois un module PHP sous Windows qui tourne avec IIS à condition d'avoir un émulateur de CGI et un interpréteur de perl installé pour faire une tambouille infâme en mémoire, oui, je confirme que le module à l'origine, écrit pour apache sous nux est certainement très performant sous nux, n'est pas du tout envisageable en production sous windows, car on utilise 25 artifices tous aussi consommateurs pour les faire tourner sous windows.
 
ensuite, Oracle, jusqu'à la version 8.0.5 a toujours été écrit pour Unix, puis, pas un coup de conditions de compilation, était recompilé pour Windows, sans une seule modification.
 
depuis la version 8i (8.1.x) Oracle maintient deux versions du code, une pour Unix (et plus récemment Linux) et une pour Windows. Comme par enchantement alors que sous Unix la version 8i était plus lourde que la 8.0, sous Windows elle a été une véritable bouffée d'oxygène, Oracle est subittement devenu performant sur plateforme Microsoft.
on a le même exemple avec Apache, qui subittement (avec je ne sais plus quelle version, ça date de 3 ou 4 ans) est passé d'une code multi-processus, que Linux accepte sans problème, à un code multi-thread. D'un seul coup, idem, l'appli est devenue ultra performante sous Windows, alors que la version précédente était une merde infâme comparée à IIS 4.0 qui pourtant n'est à la base pas une flèche.
 
c'est pas des exemples que j'invente. de par mon métier, j'y ai été confronté directement.

Ha oui, mais ça n'a rien à voir ; faut savoir de quoi on parle mon p'tit monsieur

Seulement si tu as déjà une application les utilisant de lancées. Sinon NON!
Par contre j'ai déjà constaté que les accès disques sous Linux sont plus performants (réarrangement sur le cpu de l'ordre des requêtes de lecture pour diminuer les déplacements des têtes de lectures par exemple ; ce que font d'ailleurs les disques scsi en hard).

parceque FF c'est pas Mozilla sans la partie messagerie par hasard ?
moi dans FF, quand je fait "about", j'ai marqué en gros "mozilla"

 
non, justement. C'est le même moteur de rendu, le même moteur interne (xul, XPCom, et tout), mais l'IHM a été refaite.

Excuse-moi, mais je n'utilise pas les api kernels que ce soit sous Windows ou Linux (sauf quand je touches aux modules pour ajouter du support hardware), j'utilise des api faites pour écrire des applications. Quant aux abi pour exécuter du code d'autres Os, bof m'en tape complètement.