Discussion :

[guillaume07]

Salut,

j'ai un choix de langage à faire pour un projet, la performance en terme de vitesse d'éxécution est une contrainte du projet.

Quand est-il aujourd'hui de la différence de vitesse c# et ++ ?

merci

[Astraya]

Bonjour,
Tu pourras trouver un benchmarks sur cette page de plusieurs langages (C#, C++, Java) les tests sont réalisés sur plusieurs aspects de la programmation, int32, int64, exceptions, etc...

http://www.tommti-systems.de/go.html...enchmarks.html

[guillaume07]

merci, ça sera donc c++

[sevyc64]

La question a se poser est plutôt quelles sont les contraintes de vitesses qui te sont imposées.

Car si en comparant de façon brute les 2 langages, C# et C++, l'avantage va à C++, quelques soient leur performances respectives, un programme C++ mal écrit sera toujours plus lent qu'un programme C# optimisé.

De plus, il est possible que certaines choses ne soient faisable que d'un langage. A titre d'exemple je citerais la programmation "temps réels" sur laquelle j'ai travaillé, il y a quelques années et qui ne pouvais être faite qu'en langage natif, excluant de fait tout ce qui était managé (.Net, Java, ...)



Attention au lien donné, les tests datent de 2004 sur le framework 1.1, soit VS .Net 2003 et C#1. Depuis le framework a été considérablement amélioré, il est possible que ces tests ne soient plus pertinents.

D'ailleurs, si C++ arrive en tête les différences sont tout de même minimes avec C# (à part certains points, mais à noter que C# est plus rapide sur les I/O, donc s'il y a beaucoup de fichiers à écrire ou lire .....)

[guillaume07]

temps réel c'est quoi , c'est qui aille vite?

[sevyc64]

Oupss j'ai édité pendant que tu répondais.

Non, "Temps réels" n'a rien à voir avec une question de vitesse. C'est une notion de temps strict à respecter.

Par ma part, à l'époque, j'avais des calculs à effectuer toutes les 0.1ms +/-1%. Sachant que je tournais sous Windows NT 4.0 qui ne pouvais pas garantir sur le papier un temps de cycle inférieur à 50ms. Dans la réalité j'oscillais entre 25 et 34ms, à charge normale du système.

Pour mes devs j'avais été obligé de passer sur des librairies spéciales (RTX) qui venaient s'intercaler entre windows et le processeur/horloge et travaillaient directement sur celui-ci sans passer par Windows.
Ces librairies-là ne pouvaient être faite qu'en C natif (même pas du C++), l'interface quant à elle était faite en VB

[guillaume07]

ok mais donc si la contrainte de temps réel est de l'odre de la minute qu'est ce qui empêche de le faire en c#?

[sevyc64]

Tout dépend ce que tu as à faire, mais un cycle de l'ordre de la minute est un processus lent. Tous les langages (y compris C#) devraient arriver à tenir le coups sans trop de mal

[Astraya]

@sevyc64:
Effectivement , mes excuses je n'avais pas fait attention à la date de parution du benchmark. Sinon pour les fichiers je suis sceptique, tout dépend de la façon de coder c'est évident. Un test serais pas mal à faire d'ailleurs ^^. Il est possible de faire une copie brute sans aucun traitement en C++ donc vitesse optimum.

@guillaume07:
De l'ordre de la minute, je pense pas qu'on puisse dire que c'est temps réel ^^. Dans la notion de temps réel, c'est un façon de faire croire à l'utilisateur que ce qui se passe s'exécute dans un temps que l'on ne peut pas percevoir avec notre cerveau donc qui ce passe "instantanément". La minute on peut la percevoir

Edit: Un test peut être réalisé avec une formule qui est:
la somme du coût des tâches divisée par leurs temps d'échéance.
Si c'est inférieur à 1 c'est bon.

[sevyc64]

Dans la notion de temps réel, c'est un façon de faire croire à l'utilisateur que ce qui se passe s'exécute dans un temps que l'on ne peut pas percevoir avec notre cerveau donc qui ce passe "instantanément"

Non justement !!!

Cette notion là, que l'on pourrait dire "en temps réel", à laquelle tout le monde pense lorsqu'on parle de "Temps Réel", ne correspond en rien au véritable terme "Temps réel" utilisé en informatique et industrie.
Cette notion là, très à la mode, et pas uniquement en informatique a été propagé par des personnes qui ont cru en comprendre le sens sans même se poser la question de qu'elle était la réelle définition.


La véritable notion de temps réel est une contrainte de respect du temps. Elle n'a rien à voir avec une quelconque vitesse d'exécution.
On peut, très bien, être sur du temps réel avec des échelles de plusieurs heures.

Lire la définition de Wikipédia : http://fr.wikipedia.org/wiki/Syst%C3...emps_r%C3%A9el

[Astraya]

Ok, voila une notion que je n'avais pas compris entièrement.
Je te remercie.

[Arzar]

@sevyc64:
Effectivement , mes excuses je n'avais pas fait attention à la date de parution du benchmark. Sinon pour les fichiers je suis sceptique, tout dépend de la façon de coder c'est évident. Un test serais pas mal à faire d'ailleurs ^^.

Je te conseille de lire cette série d'article extrêmement instructive. Ou deux pointures de chez microsoft (Raymond Chen et Rico Mariani) s'amusent à coder un dictionnaire anglais-chinois, l'un en C++, l'autre en C#. L'appli est principalement limité par l'IO, car il faut charger le dictionnaire en mémoire depuis au fichier sur disque au démarrage. Résultat, les perfs de la version en C# défonce complètement celles de la version en C++, alors que ce sont quasiment des copies ligne à ligne.

Après de nombreuse passes d'optimisation, l'appli C++ fini par rattraper, puis légèrement dépasser l'appli C# en terme de performance, mais bon sang il en aura fallu des efforts (6 passes d'optimisation + du code de plus en plus long et de plus en plus illisible)

[JolyLoic]

C'est amusant, parce que j'avais fait un comparatif d'IO moi même il y a 3 ans environ entre C# et C++. La version de base en C# éclatait celle en C++, mais en faisant des changements mineurs j'avais réussi à retourner la tendance, sans pour autant faire du code trop illisible. J'ai aussi souvent entendu Matt Austern ,qui s'y connait un peu en IO dire que la lenteur des IO en C++ était principalement due à de mauvaises implémentations, et non pas à un problème intrinsèque. Mais il n'a pas développé assez pour que je puisse comprendre.