C'est quoi?

Est ce vrai que Java est le plus lent et C est le plus rapide?

Y'a t-il une grande différence entre les codes compilés JIT et les full-compiled (native) en terme de rapidité?

merci

le langage le plus rapide, c'est l'assembleur, mais il faut être un très bon programmeur pour faire plus rapide qu'un compilateur C

sinon, java n'est pas forcément le plus lent, mais il y a des langages plus rapides, oui

Java n'est pas LE plus lent, mais il est tout de même lent pour information JAVA n'est pas compiler alors que le C oui, (l'ordinateur doit compiler pendant l'aplication) c'est pour cela qu'on dit que JAVA est "lent".

Attention toute fois : le C est rapide a l'extrème condition que le programme est bien coder.

" JAVA n'est pas compiler "

Onche.
Java n'est certes pas le plus rapide mais personnellement j'irais pas le qualifier de langage lent. Testez Python et vous verrez ce que c'est, un langage lent.

J'ai vu plusieurs benchmark où Java était aussi rapide, voire plus, que du C ...
Après, je trouve inutile de parler en terme de vitesse, vu qu'il n'y a que de rares cas à ma connaissance qui nécessite de vraiment prendre en compte la vitesse (je parle de millisecondes là).
Un programme mal foutu sera lent, quel que soit le langage, et un programme bien foutu sera rapide, quel que soit le langage (relativement à ce qu'on lui demande de faire, ainsi que le "pourquoi il a été créé").

globalement bunyan a raison, ce qui est important ce n'est pas tant le langage que comment tu l'utilise qui compte. C et C++ son des langages de plus bas niveau que JAVA ou C#. Ils permettent donc des optimisation plus fine. Cependant, si tu ne sais pas pourquoi C ou C++ est plus rapide, tu ne sauras pas utilise efficacement ces fonctionnalite et le code sera globalement aussi rapide quelquesoit le langage utilise.

les programme en java sont generalement beaucoup plus lent que les programmes ecrit en C ou en C++ parcequ'ils sont ecrit par des boulets. Quand on ecrit les programmes convenablement, on peut arriver a des performances similaires. Si on veut vraiment se donner du mal et gratter les dernieres performances du systeme, on y arrivera en C et en C++ (mais difficilement) alors que ca va etre vraiment galere voire impossible en JAVA.

Oui il faut aussi savoir que JAVA vient aussi avec une armada d'API souvent très vite très complexes en architecture et qui "malgrè nous" font aussi ralentir le truc.

si tu veux du java rapide, il ne faut pas utiliser leurs outils a la con. Enfin tu fais la meme en C++, si tu veux vraiment tirer toutes les perf, tu fini par reimplementer std::vector et std::map.

(d'ailleurs c'est ce que je fais ces jours ci, et c'est super chiant)

"(d'ailleurs c'est ce que je fais ces jours ci, et c'est super chiant)"

comment fonctionne le std::map, grossièrement? je me suis toujours posé la question

"C'est quoi?

Est ce vrai que Java est le plus lent et C est le plus rapide?"

Pour des logiciels de type bureautique ou gestion, la performance ça ne compte pas trop et Java sera bien suffisant. Par contre, dès qu'on fait de la 3D temps réel, de la simulation, de l'embarqué, de l'optimisation de problèmes NP-difficiles, etc. alors ça peut encore être utile d'utiliser du C ou du C++.

C'est pour ça qu'il faut choisir son langage en fonction de ses besoins. C est globalement plus performant que Java (pas de JVM et pas de garbage collector pour C, et un meilleur contrôle), et ASM est encore plus performant que C (car on peut introduire des optimisations plus poussées), seulement si les langages de plus haut niveau sont un peu moins performants, c'est généralement parce qu'ils apportent un sucre syntaxique et des fonctionnalités qui permettent d'écrire plus rapidement des programmes plus sûrs.

Mais ca le coup des std::vector j'avoue avoir toujours eu un peu de mal a y croire en fait godrik.
Quand je regarde le code source je vois pas trop ou tu peux optimiser les fonctionnalites de base. Tu peux m'eclairer ?

vector est super generique, mais si tu connais ton application, tu peux faire ca mieux. Globalement c'est des histoires de ou et quand tu alloue ta memoire ou de combien tu alloue ta memoire.

Typiquement tu utilise push_back pour ajouter des donnees a la fin du vector, mais push_back a besoin de verifier la taille vector pour savoir si il faut etendre ou pas la memoire. En fonction de la ou tu es dans le code, tu peux deja savoir que le vector est assez grand et que donc il ne sert a rien de verifier ca.

vector fait de augmente la taille de la memoire exponentiellement. J'ai des vectors dont j'ai des estimations de la taille, si j'en ait plus de 30, je suis bon pour 15000. Et si j'en ait plus de 30000, je suis bon pour 5 million. Je pourrais laisser le vector grandir tout seul, mais tu peux eviter de payer des agrandissements inutile, c'est pas plus mal.

(j'ai du m'absenter)

Dnas les autres classiques, il y a "implementer insertion sort avec un tableau en O(n log n)". Si on garde un vecteur creux, on peut amortir les insertions/deletions et obtenir une meilleur complexite.

Quand on utilise vecteur c'est parceque l'on veut des donnees proche en memoire et a access aleatoire. Mais on a pas forcement besoin que la memoire soit contigue. Du coup, on peut utiliser une liste de tableau.

=> caelacanthe
Un std::map est implémenté avec un arbre rouge et noir(ou peut être un AVL), c'est un arbre binaire de recherche équilibré pour éviter d'avoir un arbre tout "squelettique", si les arbres ne te disent rien je t'invite à voir les articles wikipédia, c'est assez long à expliquer.

Pour en revenir sur la rapidité des langagues, je tiens a préciser, pour les langages compilés, une bonne partie des performances sont liées a la compilations. Par exemple, pour le C/C++, les performances peuvent grandement varier entre un programme compiler pour x86 générique (mode de compilation par défaut) et x86-64. Je jeu d'instruction de ce dernier est plus étendu et plus efficace dans certain cas.

De la même façon, si un programme Java s'adapte bien a la vectorisation il y a de grande chance qu'il soit plus rapide que son équivalent en C compilé en x86 générique.

Le cas de l'assembleur est plus particulier. Si vous ne connaissez pas tres bien le jeu d'instruction de votre cible, si vous ne savez pas ce qu'est un cycle de pénalité alors l'ASM sera pour vous moins rapide que du C.

Hum ok je vois, merci godrik.

J'en ai un autre qui m'est arrive aujourd'hui. J'ai une table de hashage que j'implemente avec boost::unordered_map. J'ajoute et je retire des element dans la table, mais globalement le nombre est a peu pres borne. boost::unordered_map se redimensionne tout seul pour ajuster le nombre de bucket. a chauqe ajout, il verifie la taille de la structure pour la redimensionner. Compte tenu que je sais a l'avance combien d'entre je vais avoir dans ma structure, le test de redimension ne sert a rien. Je vais probablement finir par reecrire la table de hash avec une taille fixe a la compilation. (ou en recuperer une qui vient d'ailleurs)

Premier point : faire un programme rapide en C est beaucoup plus facile que faire un programme rapide en Java car C est plus bas niveau que Java (manipulation des structures mémoires possible en C et très très fortement déconseillé, voir carrément interdite, en Java).

Deuxième point : Java transformé en bytecode puis interprété par la JVM. Or le processus d'interprétation est lent. Beaucoup plus lent que le processus de lecture de code binaire

Donc en général, on finit par dire : C est plus rapide que java, Java est lent etc

Mais il faut savoir une chose, c'est que les domaines d'application sont totalement différent. Tu verras pas beaucoup d'application orienté entreprise, web etc codé en C. Le C c'est devenu orienté recherche, application spécifique maintenant (traitement d'image, embarqué, réseau etc etc) où les manipulations basique de bas niveau, et la vitesse deviennent des critères.

Alors qu'en Java, on s'en fiche un peu de la vitesse...
Et ceux qui te dise le contraire, à savoir que tout est modulable et interchangeable (en général les fanboy C , me font doucement rire..

1. hyrulink2 Voir le profil de hyrulink2
2. Posté le 21 mai 2011 à 21:58:46 Avertir un administrateur
3. => caelacanthe

Un std::map est implémenté avec un arbre rouge et noir(ou peut être un AVL), c'est un arbre binaire de recherche équilibré pour éviter d'avoir un arbre tout "squelettique", si les arbres ne te disent rien je t'invite à voir les articles wikipédia, c'est assez long à expliquer.

oui, je crois que je vais aller faire un tour sur wikipedia... "arbre rouge et noir"?

merci pour les mots-clés

"Alors qu'en Java, on s'en fiche un peu de la vitesse...
Et ceux qui te dise le contraire, à savoir que tout est modulable et interchangeable (en général les fanboy C , me font doucement rire.."

c'est aussi parce que java, c'est un peu plus sécurisé que le C... l'utilisation d'un strcpy est si vite arrivée

@caelacanthe :"c'est aussi parce que java, c'est un peu plus sécurisé que le C... l'utilisation d'un strcpy est si vite arrivée "

Encore une fois, ca depend de ton cas d'utilisation, si tu sais de facon sur et certaine que les tailles sont correctes, il vaut mieux utiliser strcpy que strncpy qui necessite un test supplementaire.

@station__bis : "Alors qu'en Java, on s'en fiche un peu de la vitesse...
Et ceux qui te dise le contraire, à savoir que tout est modulable et interchangeable (en général les fanboy C , me font doucement rire.."

En terme de programabilite ils SONT equivalent. cf la notion de langage Turing complet. C n'est pas plus ou moins modulaire que java. Si tu penses qu'il l'est tu devrais ecrire plus de C...