C/C++ Émulateur dofus 2.4x (CPP)

[Arth]

Coucou, grosse discutions ici, mais c'est intéressant et certain message m'ont interpellé. (Je vais pas parler de tous, sinon ça va être très long...)

Bon à savoir: on ne développe pas une application en C++ pour les perfs

Bah je suis désolé mais si... Tu peut lâcher une phrase comme ça ^^'. Mais je comprend ce que tu veut dire, on choisi pas ce langage pour que comme par magie cela soit plus performant. Et là je te rejoint, avoir un gros code performant en C++ c'est une tanné et c'est au détriment du temps de développement. Je pense que c'est ce que tu voulais dire ^^.
En ce qui concerne la mémoire, puisque vous en parlez, c'est pas magique encore une fois, le C++ peut utiliser bien moins de mémoire, mais il faudra la structurer correctement et c'est souvent plus dangereux car le c++ ne manipule pas la mémoire de manière sécurisé. C'est en partie de là qu'on tiens les perfs, moins de sécurité => accès plus rapide a la mémoire => code plus rapide. Ça tiens qu'au développeur de profiter au mieux de ça.

La simplicité et l'ingéniosité de la TPL (ainsi que de la programmation asynchrone en général), ainsi que le compilateur JIT permettront d'out-performances les bonobos qui développent en C++

La tu m’interpelle, je connais surement pas suffisamment C#, mais je voit mal comment un code C# (de qualité équivalent à un code C++) compilé JIT pourrait d'out-performer un code C++ compilé par un outil comme GCC avec les options d'optimisation active, et ça même en excluant le temps de compilation JIT. @DrBrook pourrais-tu m'expliquer ou me donnée des liens en rapport ?
En ce qui concerne la programmation asynchrone, on peut en faire en C++ très naturellement, et c'est très performant (forcement, comme dit plus haut ça nécessite des connaissance et c'est au détriment du temps de développement). Et comme tu as l'air de dire que l’asynchrone en C# c'est plus performant qu'en C++ (je résume un peu vite), j'aimerais savoir pourquoi ? comment c'est possible ? et tu as des liens ?

Mais j'ai aussi des questions par rapport à ton projet @w0dm4n :
J'ai regardé que très rapidement le code, et je constate que c'est développer pour du win pure (je parle de la partie socket surtout). Pourquoi ne pas utiliser une librairie moderne, multi-plateforme et asynchrone à la place ?
Comme par exemple Libuv en C ou Boost::asio en C++.

Je pense que ça serait dommage de faire du C++ et de ne pas pouvoir utiliser l’émulateur sur un serveur Linux par exemple. De plus les sockets asynchrone ça sera déterminant pour les perfs si c'est ce qui est recherché (et même dans le cas global pour un serveur).

Et je me demandais aussi, pourquoi utiliser CAMP pour "émuler" de la réflexion ? Je n'ai pas regarder pourquoi tu utilisait cela et j'ai pas trop idée de l'utilité pour le projet, mais tu ne pense pas qu'utiliser de tel outil serait justement problématique pour les perf (dans l’éventualité que c'est ce que tu cherches).

 

[Itsame]

Should've used the boost library instead of using CAMP and SqlApi++.

 

[scalexm]

Bah je suis désolé mais si... Tu peut lâcher une phrase comme ça ^^'.

Bah non. En 2017, on dit pas "je veux écrire un programme performant, donc je vais l'écrire en C++". On peut en effet dire "j'ai besoin d'écrire un programme de pilotage automatique d'avion où chaque cycle d'horloge compte, je vais l'écrire en C++". Ou encore "Je dois gagner ce concours de solveur SAT le plus performant, je vais l'écrire en C++". Mais tu vois bien que quand on dit ça, c'est qu'on a des contraintes extrêmement particulières. Dans 99% des cas, vouloir rendre quelque chose plus performant n'est pas un bon argument pour utiliser du C++.

La tu m’interpelle, je connais surement pas suffisamment C#, mais je voit mal comment un code C# (de qualité équivalent à un code C++) compilé JIT pourrait d'out-performer un code C++ compilé par un outil comme GCC avec les options d'optimisation active, et ça même en excluant le temps de compilation JIT

cf mon exemple moins abstrait de std::string du C++ vs char* du C. Ensuite tu peux très bien imaginer que plus tu montes en abstraction, plus tu vas subir des comparaisons de ce genre.

c'est souvent plus dangereux car le c++ ne manipule pas la mémoire de manière sécurisé. C'est en partie de là qu'on tiens les perfs, moins de sécurité => accès plus rapide a la mémoire => code plus rapide

On peut manipuler de la mémoire de façon 100% safe en C++ sans aucune perte de performances...

Et je me demandais aussi, pourquoi utiliser CAMP pour "émuler" de la réflexion ? Je n'ai pas regarder pourquoi tu utilisait cela et j'ai pas trop idée de l'utilité pour le projet, mais tu ne pense pas qu'utiliser de tel outil serait justement problématique pour les perf

Je ne sais pas non plus pourquoi il l'utilise, mais d'après ce que je lis CAMP c'est presque uniquement de la méta-programmation exécutée lors de la compilation donc absolument 0 impact sur les perfs à l'exécution.

Vous voyez, vous parlez de performances blabla, mais vous n'avez pas vraiment d'idée de ce qui rend un programme performant ou pas.

@Wodman: excellente initiative en tout cas pour l'open sourcing

 

[Arth]

Mais tu vois bien que quand on dit ça, c'est qu'on a des contraintes extrêmement particulières. Dans 99% des cas, vouloir rendre quelque chose plus performant n'est pas un bon argument pour utiliser du C++

Mais ... Tu sais bien qu'avoir besoin de perf c'est déjà une contraire particulière, en 2017, et c'est donc pourquoi on choisi le C++ dans ce genre cas. Donc je suis toujours pas d'accord avec toi.

cf mon exemple moins abstrait de std::string du C++ vs char* du C. Ensuite tu peux très bien imaginer que plus tu montes en abstraction, plus tu vas subir des comparaisons de ce genre.

Effectivement, le C ne présente que très peu de possibilité d'abstraction. Et le C++, face au C écrit de manière classique, permet d'avoir de meilleur perf pour de grosse application grâce à cette abstraction. Mais... Tu réponds absolument pas à ma question.
Si tu veut je peux reformuler la question: En quoi l'abstraction du C# permet d'avoir de meilleur perf que le C++ (qui permet lui même de l'abstraction) ?
Et je m’intéresse en particulier à l’exécution synchrone.

On peut manipuler de la mémoire de façon 100% safe en C++ sans aucune perte de performances...

Ouais, et j'ai pas dit le contraire... J'ai dit que nativement, en C++, il n'y a pas de mécanisme pour sécuriser la mémoire (à part le typage fort à la limite qui est evalué à la compilation ou les protections anti stack-smashing qui sont activable ou non). Et donc, face à des languages qui embarque des sécurités au runtime, le C++ gagne en perf (toujours à condition de par faire n'importe quoi, puisque c'est mon postulat de base "faire un code C++ correct demande du travail').
Du coup j'aimerais voir, où dans mon message, j'ai écrit qu'en C++ on ne pouvais pas écrire un code safe ?

CAMP c'est presque uniquement de la méta-programmation exécutée lors de la compilation donc absolument 0 impact sur les perfs à l'exécution.

Je ne connais pas non plus CAMP, mais effectivement il ne semble l'utiliser que pour construire des class abstraites. Par contre le 0 impact ça dépend de la librairie.

Vous voyez, vous parlez de performances blabla, mais vous n'avez pas vraiment d'idée de ce qui rend un programme performant ou pas.

Je voit pas en quel honneur tu te permet de jugé mes qualités à connaitre ou non ce qui permet de la perf. Donc je vais te demander de baisser d'un ton.

 

[w0dm4n]

Coucou, grosse discutions ici, mais c'est intéressant et certain message m'ont interpellé. (Je vais pas parler de tous, sinon ça va être très long...)


Bah je suis désolé mais si... Tu peut lâcher une phrase comme ça ^^'. Mais je comprend ce que tu veut dire, on choisi pas ce langage pour que comme par magie cela soit plus performant. Et là je te rejoint, avoir un gros code performant en C++ c'est une tanné et c'est au détriment du temps de développement. Je pense que c'est ce que tu voulais dire ^^.
En ce qui concerne la mémoire, puisque vous en parlez, c'est pas magique encore une fois, le C++ peut utiliser bien moins de mémoire, mais il faudra la structurer correctement et c'est souvent plus dangereux car le c++ ne manipule pas la mémoire de manière sécurisé. C'est en partie de là qu'on tiens les perfs, moins de sécurité => accès plus rapide a la mémoire => code plus rapide. Ça tiens qu'au développeur de profiter au mieux de ça.


La tu m’interpelle, je connais surement pas suffisamment C#, mais je voit mal comment un code C# (de qualité équivalent à un code C++) compilé JIT pourrait d'out-performer un code C++ compilé par un outil comme GCC avec les options d'optimisation active, et ça même en excluant le temps de compilation JIT. @DrBrook pourrais-tu m'expliquer ou me donnée des liens en rapport ?
En ce qui concerne la programmation asynchrone, on peut en faire en C++ très naturellement, et c'est très performant (forcement, comme dit plus haut ça nécessite des connaissance et c'est au détriment du temps de développement). Et comme tu as l'air de dire que l’asynchrone en C# c'est plus performant qu'en C++ (je résume un peu vite), j'aimerais savoir pourquoi ? comment c'est possible ? et tu as des liens ?

Mais j'ai aussi des questions par rapport à ton projet @w0dm4n :
J'ai regardé que très rapidement le code, et je constate que c'est développer pour du win pure (je parle de la partie socket surtout). Pourquoi ne pas utiliser une librairie moderne, multi-plateforme et asynchrone à la place ?
Comme par exemple Libuv en C ou Boost::asio en C++.

Je pense que ça serait dommage de faire du C++ et de ne pas pouvoir utiliser l’émulateur sur un serveur Linux par exemple. De plus les sockets asynchrone ça sera déterminant pour les perfs si c'est ce qui est recherché (et même dans le cas global pour un serveur).

Et je me demandais aussi, pourquoi utiliser CAMP pour "émuler" de la réflexion ? Je n'ai pas regarder pourquoi tu utilisait cela et j'ai pas trop idée de l'utilité pour le projet, mais tu ne pense pas qu'utiliser de tel outil serait justement problématique pour les perf (dans l’éventualité que c'est ce que tu cherches).

Oui effectivement pour les sockets il faudrait que je passe sur une autre lib plus tard pour passer sur linux, j'ai juste start avec ça mais c'est pas très long de toute façon a modifier.
Pour CAMP il me sert a créer des records de table de base de donnée et tout chargé automatiquement, pareil pour la save, je link le camp::UserObject au player, je l'update et a la save il se met à jour automatiquement. Et pour les perfs ça ne change pas grand chose en réalité.

 

[Nelimee]

Si tu veut je peux reformuler la question: En quoi l'abstraction du C# permet d'avoir de meilleur perf que le C++ (qui permet lui même de l'abstraction) ?
Et je m’intéresse en particulier à l’exécution synchrone.

Ça m'intéresse aussi. Je ne connais pas le C#, mais j'aimerai bien avoir des arguments sur ce point, j'ai du mal à voir comment un programme interprété (à moitié interprété pour le C# si j'ai bien compris) peut être plus performant qu'un langage compilé ET "minimaliste" (dans le sens où le code compilé ne fait rien de plus que ce que l'utilisateur demande explicitement, pas comme par exemple l'Ada et le boundary-checking au runtime) comme le C ou le C++.
Si t'as des benchmarks sous la main, c'est le top ! Sinon, une simple explication suffira

 

[Arth]

@w0dm4n
D'accord merci pour ta réponse, j'avais plus ou moins imaginé cela pour la sauvegarde en lisant la présentation du projet mais je me demandais si il y avais d'autre utilisation de CAMP plus au cœur de l’émulateur. C'est certain que si il ne s'agit que de la partie sauvegarde, c'est surement pas très impactant.
Et merci du partage en open-source ! Super projet .

@Nelimee le C# n'est pas un langage interprété en soit, comme le dit @DrBrook, il y a un système de compilation JIT, juste avant l’exécution, des parties du bytecode sont remplacé par de du code machineet et il subit de petit optimisation en même temps. Et c'est pourquoi il peut arriver à au moins l’égaler en performance. Par contre, pour comprendre comment il peut le dépasser, je me pose les mêmes questions que toi.
De plus la compilation JIT ne permet pas, à ma connaissance, des d'optimisations aussi complexe que ce que peut faire un GCC avec les options d'opti.

 

[scalexm]

@Arth
Oui la nécessité d'avoir des performances peut être un argument et j'ai d'ailleurs insisté sur ce point dans tous mes messages, mais c'est un cas absolument extrême. Dans 99% des cas ou bien on n'aura pas besoin de ce gain théorique de performances, ou bien on ne l'observera carrément pas. Donc l'argument de dire "je vais écrire un émulateur en C++ pour battre tous les autres en termes de perfs" est TOTALEMENT fallacieux, c'est ce que je dis depuis le début. Et souvent en 2017 même quand on cherche des grosses performances on ne se tournera pas forcément vers du C++ car on peut faire le même taff plus facilement avec plein d'autres langages.

Je sais pas précisément ce qu'a voulu dire DrBrook (je suis pas l'auteur de son message), mais ce qu'il faut retenir c'est qu'il faut pas du tout s'étonner de la possibilité qu'un programme C# outperform un programme C++, même bien écrit. Le C# est bien meilleur pour l'abstraction que le C++ et prendre de la hauteur permettra toujours d'écrire un code d'une meilleure façon qu'on ne l'aurait fait à plus bas niveau. L'exemple std::string VS char* est vraiment révélateur.

J'ai sans doute mal interprété ton message à propos de la mémoire, mais disons qu'en général justement le genre d'argument qui reviennent tout le temps en faveur des performances du C++ c'est l'implication "pas de sécurité => accès plus rapide à la mémoire", comme si on ne pouvait pas avoir d'accès optimal à la mémoire en rajoutant des sécurités (mais du coup j'imagine que ce n'est pas ce que tu as voulu dire).

Et pour CAMP tu dis "ça dépend de la librairie" (déjà on dit bibliothèque mais bon), sauf que je viens justement de te dire que c'est presque uniquement du template meta-programming donc oui, ça dépend de la bibliothèque, et en l'occurence c'est 0 runtime overhead.

 

[scalexm]

Bon maintenant pour compléter vite fait mon argument, à la question: pour tout programme en C#, existe-t-il un programme en C++ faisant la même chose avec de meilleures performances? La réponse est probablement oui.
Les questions qui suivent naturellement sont: ce programme (dont la correction doit être la même que celle en C# rappelons le) est-il accessible à la pensée d'un être humain? Est-ce qu'écrire ce programme coûtera moins cher qu'acheter une machine plus performante? Et surtout, est-ce que ça en vaut la peine? Les réponses varient selon le type et la taille du programme, mais la réponse à la toute dernière question est extrêmement souvent: non.

 

[w0dm4n]

Bon maintenant pour compléter vite fait mon argument, à la question: pour tout programme en C#, existe-t-il un programme en C++ faisant la même chose avec de meilleures performances? La réponse est probablement oui.
Les questions qui suivent naturellement sont: ce programme (dont la correction doit être la même que celle en C# rappelons le) est-il accessible à la pensée d'un être humain? Est-ce qu'écrire ce programme coûtera moins cher qu'acheter une machine plus performante? Et surtout, est-ce que ça en vaut la peine? Les réponses varient selon le type et la taille du programme, mais la réponse à la toute dernière question est extrêmement souvent: non.

On a compris que tu voulais avoir le dernier mot, t'en fait pas

 

[Telokis]

On a compris, tout le monde ici possède une très grosse b*te. Maintenant vous pouvez la ranger parce-qu'on s'en fout complet.
C'est naïf de penser que le C++ n'est pas un choix quand on veut des perfs et puis c'est tout.
Puis s'il a envie de faire du C++ il le fait parce-qu'il se fout de votre avis.

Sinon, je suis très content de voir un projet en C++, c'est mon langage de prédilection donc ça fait plaisir !
Je vais me permettre de te suggérer CMake pour te garantir un portage vers Linux sans trop de douleur !

 

[Nameless]

La tu m’interpelle, je connais surement pas suffisamment C#, mais je voit mal comment un code C# (de qualité équivalent à un code C++) compilé JIT pourrait d'out-performer un code C++ compilé par un outil comme GCC avec les options d'optimisation active, et ça même en excluant le temps de compilation JIT. @DrBrook pourrais-tu m'expliquer ou me donnée des liens en rapport ?
En ce qui concerne la programmation asynchrone, on peut en faire en C++ très naturellement, et c'est très performant (forcement, comme dit plus haut ça nécessite des connaissance et c'est au détriment du temps de développement). Et comme tu as l'air de dire que l’asynchrone en C# c'est plus performant qu'en C++ (je résume un peu vite), j'aimerais savoir pourquoi ? comment c'est possible ? et tu as des liens ?

JIT: optimisation locale, peut profiter des optimisations comme les instructions sur le processeur
c++: optimisation globale et locale impossible

Pourquoi impossible ? C'est simple, le c++ c'est directement du langage machine alors que le c# est d'abord transcrit en IL puis en langage machine. Lors du transfert en langage machine l'IL sera opti et profitera de toutes les optimisations locales possible (mémoire du proco, cache etc).

Pour l'async, il a pas dit que c'était plus performant en C#, mais que c'était plus productif. (notamment via await et la TPL)

Et pour finir, le c++ sera plus rapide que le c#, à condition d'être un ingé avec 10 ans de background c++

En gros il le sera pas ici, continuez a chercher qui a la plus grosse, et laissez les vrais développeurs (ceux qui s'intéressent au fond des choses) travailler.

 

[w0dm4n]

On a compris, tout le monde ici possède une très grosse b*te. Maintenant vous pouvez la ranger parce-qu'on s'en fout complet.
C'est naïf de penser que le C++ n'est pas un choix quand on veut des perfs et puis c'est tout.
Puis s'il a envie de faire du C++ il le fait parce-qu'il se fout de votre avis.

Sinon, je suis très content de voir un projet en C++, c'est mon langage de prédilection donc ça fait plaisir !
Je vais me permettre de te suggérer CMake pour te garantir un portage vers Linux sans trop de douleur !

Oui c'est une bonne idée CMake d'ailleurs si tu veux le build pour linux et faire une pull request ça serait cool

 

[Telokis]

Oui c'est une bonne idée CMake d'ailleurs si tu veux le build pour linux et faire une pull request ça serait cool

Allez, je vais essayer de prendre le temps de faire ça ! =D

 

[Arth]

Bon, j'avais commencé à écrire un message construit à @scalexm pour expliquer ce que j'avais pu lire à droite à gauche, mais entre temps il y a eu une avalanche de message, parfois prétentieux et pas pertinent (pas tous).
Je trouve dommage que personne ne puisse répondre à la question que ce pose @Nelimee et moi, je m'attendais à une ou 2 références expliquant en détail et avec de vrais arguments. Mais ce n'est pas le cas. Je trouve dommage que personne n'ait de réponses constructives, et j'ai donc fait des recherches par moi-même. Je ne détaillerais pas trop, car le débat semble clos pour beaucoup.

1. La plupart des personnes et des tests disent/montrent que les 2 sont plus ou moins équivalent pour des programmes contenant le même code (un code souvent naïf), parfois l'un gagne parfois l'autre gagne. Cela dépend du matériel. Et de même pour des codes optis avec une large préférence pour le C++.
2. parfois le C# out-performe le C++, la raison est généralement de code contre optimaux en C++, et les bons articles explique pourquoi le code C++ est mal écrit.

Pour le point 1, il montre bien que ce que dit @Nameless est faux, le C# n'est pas plus capable que le C++ de faire des optis local.
De plus il y a pas de code assembleur issus du C++ fonctionnant sur tous type de CPU, c'est les CPUs qui utilisent des Instructions Set identique pour simplifier la portabilité... donc les optimisations local dut au choix des instructions n'est pas un argument car le C++ fait donc la même chose (je soupçonne quand même la phrase d'être mal tourné car dans le cas contraire elle montrerait une forte méconnaissance du sujet. Si j'ai mal compris, autant pour moi).
Si il s'agit de dire qu'il a une meilleur organisation de la mémoire, qui peut être spécifique au système (utilisation des mémoires caches plus proche du CPU). Les résultats montrent bien que c'est pas toujours une réussite, et le C++ fait de même.

Pour l'async, il a pas dit que c'était plus performant en C#, mais que c'était plus productif. (notamment via await et la TPL)

bah ... Non il a dit :

La simplicité et l'ingéniosité de la TPL (ainsi que de la programmation asynchrone en général), ainsi que le compilateur JIT permettront d'out-performances les bonobos qui développent en C++

Vous noterez l'insulte gratuite au passage.
Et @Nameless, tu ne réponds quand même pas la question, tu dit être un vrai dev, explique nous, on te demande.


Maintenant je vais essayer d'exprimer ce que je pense par rapport au message de @scalexm, qui propose une réponse par la thèorie.
Je suis d'accord pour dire que l'abstraction permet de résoudre les problèmes facilement, mais elle ne permet pas toujours de prendre le chemin le plus court (parfois elle le peut !). Et les structures abstraites permetent d'embarquer des optimisations, comme avec std::string.

Du coup je me sens obliger de te donner l'exemple, toujours en C VS c++, du printf et du std::cout.
Le printf est simple et bien optimisé.
Le std::cout est complexe car abstrait. (mais il permet plus de choses et il est quand même bien foutu)
Ce qui à pour effet d'avoir un std::cout beaucoup plus lent qu'un printf. Il en est de même pour tous les opérateurs de flux en C++ face au fonctions simple de manipulation de fichier en C.
Et c'est le genre d'erreur simple qui peut rendre un code C++ plus lent face à du C# si l'on fait une transcription direct de l'un à l'autre.

Je sait pas ce que tu en pense, mais pour ma part je trouve le sujet tres complexe et je ne peux pas me resoudre à dire: abstraction = perf.

Du coup, non il ne faut pas forcement un ingé avec 10ans de background ce genre de choses... Il le faudra pour concevoir un système qui utilise au mieux la machine et là on ne parle même plus de c# car on est de loin plus optimal.

De plus, je tiens à demander des excuses auprès de @w0dm4n qui trouve son poste concernant son projet pollué, j'imaginais que le débat serait intéressant. Mais peu semble prêt à cela.

 

[Nameless]

Tu veux que je t'explique comment un vrai dev développe Arth ? Parce qu'avant de parler de performance, on parle de test unitaire, de méthode, d'algorithmique, de convention, de clarté et propreté du code, d'abstraction, de dépendance, de cache, de pool...

 

[Telokis]

Mais sérieux allez pourrir un autre thread, c'est pas possible, ça !
Vous créez votre propre sujet, vous le nommez de façon appropriée (genre "Pourquoi est-ce que la longueur de mon C++ est bien supérieure à la vôtre") et vous arrêtez de polluer ce thread avec vos conneries.
@Arth, tu essayes d'avoir un véritable débat mais tu n'es pas au bon endroit pour ça. Y'a qu'à voir la réponse de @Nameless. Si tu veux une discussion il va falloir parler avec des gens qui savent discuter sinon tu ne vas jamais avancer et ce thread va continuer à être pollué pour que dalle.
@Nameless Je te connais pas mais tu transpires tellement la prétention que j'ai pas envie de te connaître plus que ça. Va raconter à quel point tu es beau, grand et fort dans un thread "autosuçage", stp.

 

[Itsame]

Instead of saying he's doing it wrong, why not make a better server in C++ and show him how it's done? I also don't like the CAMP library if I'm being honest.

Edit: Could you explain what the "SWF" folder should contain?

 

[w0dm4n]

Tu veux que je t'explique comment un vrai dev développe Arth ? Parce qu'avant de parler de performance, on parle de test unitaire, de méthode, d'algorithmique, de convention, de clarté et propreté du code, d'abstraction, de dépendance, de cache, de pool...

Tu m'as bien l'air d'être un vrai dev toi, un grand je dirais même qui fait des caches de l'abstraction et tout ^^ tu dois certainement être ceo d'une boîte multi millionnaire

Bon, j'avais commencé à écrire un message construit à @scalexm pour expliquer ce que j'avais pu lire à droite à gauche, mais entre temps il y a eu une avalanche de message, parfois prétentieux et pas pertinent (pas tous).
Je trouve dommage que personne ne puisse répondre à la question que ce pose @Nelimee et moi, je m'attendais à une ou 2 références expliquant en détail et avec de vrais arguments. Mais ce n'est pas le cas. Je trouve dommage que personne n'ait de réponses constructives, et j'ai donc fait des recherches par moi-même. Je ne détaillerais pas trop, car le débat semble clos pour beaucoup.

1. La plupart des personnes et des tests disent/montrent que les 2 sont plus ou moins équivalent pour des programmes contenant le même code (un code souvent naïf), parfois l'un gagne parfois l'autre gagne. Cela dépend du matériel. Et de même pour des codes optis avec une large préférence pour le C++.
2. parfois le C# out-performe le C++, la raison est généralement de code contre optimaux en C++, et les bons articles explique pourquoi le code C++ est mal écrit.

Pour le point 1, il montre bien que ce que dit @Nameless est faux, le C# n'est pas plus capable que le C++ de faire des optis local.
De plus il y a pas de code assembleur issus du C++ fonctionnant sur tous type de CPU, c'est les CPUs qui utilisent des Instructions Set identique pour simplifier la portabilité... donc les optimisations local dut au choix des instructions n'est pas un argument car le C++ fait donc la même chose (je soupçonne quand même la phrase d'être mal tourné car dans le cas contraire elle montrerait une forte méconnaissance du sujet. Si j'ai mal compris, autant pour moi).
Si il s'agit de dire qu'il a une meilleur organisation de la mémoire, qui peut être spécifique au système (utilisation des mémoires caches plus proche du CPU). Les résultats montrent bien que c'est pas toujours une réussite, et le C++ fait de même.



bah ... Non il a dit :

Vous noterez l'insulte gratuite au passage.
Et @Nameless, tu ne réponds quand même pas la question, tu dit être un vrai dev, explique nous, on te demande.


Maintenant je vais essayer d'exprimer ce que je pense par rapport au message de @scalexm, qui propose une réponse par la thèorie.
Je suis d'accord pour dire que l'abstraction permet de résoudre les problèmes facilement, mais elle ne permet pas toujours de prendre le chemin le plus court (parfois elle le peut !). Et les structures abstraites permetent d'embarquer des optimisations, comme avec std::string.

Du coup je me sens obliger de te donner l'exemple, toujours en C VS c++, du printf et du std::cout.
Le printf est simple et bien optimisé.
Le std::cout est complexe car abstrait. (mais il permet plus de choses et il est quand même bien foutu)
Ce qui à pour effet d'avoir un std::cout beaucoup plus lent qu'un printf. Il en est de même pour tous les opérateurs de flux en C++ face au fonctions simple de manipulation de fichier en C.
Et c'est le genre d'erreur simple qui peut rendre un code C++ plus lent face à du C# si l'on fait une transcription direct de l'un à l'autre.

Je sait pas ce que tu en pense, mais pour ma part je trouve le sujet tres complexe et je ne peux pas me resoudre à dire: abstraction = perf.

Du coup, non il ne faut pas forcement un ingé avec 10ans de background ce genre de choses... Il le faudra pour concevoir un système qui utilise au mieux la machine et là on ne parle même plus de c# car on est de loin plus optimal.

De plus, je tiens à demander des excuses auprès de @w0dm4n qui trouve son poste concernant son projet pollué, j'imaginais que le débat serait intéressant. Mais peu semble prêt à cela.

Y'a pas besoin d'excuse c'est pas grave t'inquiète ^^ voir des pseudos codeur craché sur un langage de "bonobo" alors qu'ils savent certainement pas pour la plupart comment fonctionne un pointeur ou une allocation mémoire c'est rigolo

Instead of saying he's doing it wrong, why not make a better server in C++ and show him how it's done? I also don't like the CAMP library if I'm being honest.

Edit: Could you explain what the "SWF" folder should contain?

You know about people who criticizes, they cant do anything specially if you ask them to do c/c++
The content of the SWF folder is on the repository (ive just added it) it's AuthPatch.swf used to bypass auth encryption

 

[Nameless]

Je n étais pas en train de critiquer le c++, j'exposais juste de simple faits et ma pique sur les vrais développeurs était pour ceux qui se lancent dans ce genre de débat sans importance. La programmation regroupe tous les langages, il n'existe pas de "solution ultime".
C'est ce que j'essayais de dire à travers mon message, loin de moi l'idée de m'en prendre à d'autres développeurs ou de me lancer dans une "guerre des langages" !
(tu as d'ailleurs tout mon soutien pour ton projet)

Et pour répondre à ton "attaque", effectivement je suis ce genre de développeur Ceux qui ont accès a mon travail pourront te le confirmer.