Quedal. Un algorithme en temps N peut aller bien plus vite qu'un algo en log N selon la gueule des données et surtout comment elles sont mises en cache. ==> On aura tout entendu sur le sdz.. Si et si, c'est l'algo le plus important dans le programme et non la vitess d'éxécution du langage qui vient poser des problème de ralentissement.
Outre le message de @AwpSoLeet au dessus, on peut ajouter que si ton langage n'autorise que des structures chaînées, tu peux implémenter aussi bien que tu veux, accéder à un structure chaînée, c'est pas cache friendly.
ractamard a écrit:
On dois pas avoir la même définition de heureux, (1) l'asm c'est bien plus compliqué et bordélique que le C++. (2) Je ne connais pas beaucoup de dev de jeu qui font de l'asm et même pour les indépendant genre open source ils font pas de l'asm alors qu'ils ont tout le temps qu'ils veulent. (3) L'asm tu le retrouve que dans le noyeau des moteurs graphiques et uniquement aux endroits critiques. Là encore, l'asm est choisié car il doit manipuler et calculé des tas de taritements.
(1) Sa sémantique est bien plus simple, et le bordélisme tient surtout du développeur. Il est juste ultra-minimaliste, donc il est long de développer avec.
(2) Voir présentation de la CPPCON 2014 sur le data-oriented design.
(3)
Ksass`Peuk a écrit:
C'est la balance coût de développement VS gain de performances qui répond à cette question. Certains dév de jeux côté moteurs seraient heureux de développer en assembleur si cela ne leur prenait pas trop de temps et ne ruinait pas le multi-plateforme.
Pour mettre mon grain de sel, je tiens à dire que le C est effectivement bien plus rapide que pas mal d'autres langages (en vitesse pure).
Après, il est évident que le choix des algos est également primordial. Mais à algo égal, le C a une bonne longueur d'avance.
Après, je tiens aussi à dire que l'optimisation de vitesse critique n'est pas valable dans tous les projets, et pas non plus dans toutes les zones.
Même si on programme un FPS nerveux, il y aura bien sûr beaucoup d'optimisations à faire au niveau des collisions, au niveau du rendu, mais par exemple l'affichage du menu, ou même par exemple la mise à jour des ennemis à l'écran n'est pas critique.
C'est à dire que si à chaque frame, tu as 5 ennemis à tout casser à mettre à jour, tu n'es pas à 3 multiplications près.
Il y a beaucoup de surcouches qui ne sont pas critiques au niveau, bien plus qu'on le croit. Pour celles la, si on va plus ou moins vite, ce n'est pas trop grave.
Typiquement, voila pourquoi certains éditeurs de jeux ont leur noyau en C++ (pour speeder à mort) mais sont scriptables par la suite avec une langage pas forcément de pointe, car on a moins de contrainte de temps par la suite.
Le problème qu'on a en disant que la vitesse importe peu pour la majorité des programmes c'est qu'au final tous les programmes sont 10 fois plus lents qu'ils ne devraient être et c'est pour ça que je dois attendre 15 secondes pour que LibreOffice se lance sur ma machine de guerre.
Nos machines sont de plus en plus puissantes mais on ne ressent aucune amélioration en terme de vitesse, justement parce que "comme les machines sont puissantes on peut utiliser tel langage qui est lent pour X raisons".
Le problème qu'on a en disant que la vitesse importe peu pour la majorité des programmes c'est qu'au final tous les programmes sont 10 fois plus lents qu'ils ne devraient être et c'est pour ça que je dois attendre 15 secondes pour que LibreOffice se lance sur ma machine de guerre.
Nos machines sont de plus en plus puissantes mais on ne ressent aucune amélioration en terme de vitesse, justement parce que "comme les machines sont puissantes on peut utiliser tel langage qui est lent pour X raisons".
Ah ça, je suis tout à fait d'accord avec toi. Personnellement je fulmine quand je vois que le moindre onglet dans Chrome me prend 100 Mo (au cas ou). Et je fulmine quand certains softs pourtant tout cons mettent du temps à se lancer.
Mais la, on rentre dans une autre problématique, celle de l'entreprise :
- soit tu fais un programme optimal et propre, et tu dois payer des ingénieurs un peu plus longtemps pour qu'ils le fassent.
- soit tu les payes un peu moins longtemps, et tu dis juste à tes clients qu'il leur faut un peu plus de RAM, et une belle machine.
Il y a deux avantages à faire cela :
- premièrement : ça te coûte moins cher à optimiser, car tu payes moins de temps les ingénieurs.
- deuxièmement (et c'est un non sens), psychologiquement, si tu vends un logiciel et que tu dis qu'il faut une super machine pour le faire tourner, le client se dit "c'est un logiciel de pointe" !
Si tu lui dis que ça peut tourner sur une machine d'il y a 10 ans, il se dira que le logiciel est daté comme un logiciel d'il y a 10 ans, que c'est un vieux machin. C'est totalement faux, mais c'est un ressenti commercial...
la vitesse des programmes dont il est capable. ==> Eu... tu ne verras pas la différence de temps entre deux programmes identiques mais codés dans différents langages la plupart du temps. C'est plus ton algo qui fera la différence.
- Edité par ractamard le 22 novembre 2015 à 21:31:36
Désolé de te contredire , mais la conception d'un language impose des limitations de vitesse aux programmes qu'il sera capable de produire. Si tu es dans le doute tu peux faire des essais en chronomettrant les temps d'execution. C'est vrai que sur un hello world ça ne se fait pas ressentir mais quand il s'agit de faire de millions de calculs par seconde la difference se fait bien ressentir entre langages de bas et de haut niveau.
Dans tes programmes as-tu déjà vu une seul fois une vrais différence de temps en fonction du langage ? Fais-tu des programmes qui demandent un grand nombre de calculs à la seconde ?
Et si désolé de te le dires, c'est l'implémentation de l'algo qui fais toute la différence. Si on suis ton résonnement avec tes benchmarks ont coderais les jeux en assembleurs et ce n'est plus le cas. Le java te produit des perfs tout à fait honorable. Le moteur Unity (C#) te fais un jeu 3d aisément sans lag..Mais tu dois être à 2 seconde près.
Edit: en plus tu me compares un langage Web avec du C.. tant que tu y es compare le a du batch et là tu pourras dire qu'il est beaucoup plus rapide
- Edité par ractamard le 22 novembre 2015 à 21:50:08
Sans lag? Tout le monde dis ça. Mais ça depend encore du matériel. Il est clair que si tu fabrique un obésiciel ultra lent et que tu prend un ordinateur suffisament rapide il aura la meme vitesse qu'un programme ultra rapide sur une machine ultra lente.
Autre exemple, les ingénieurs qui codent pour les programmes spatiales sont encadrés par un examinateur d'algo.. chaque programme fait est contrôlé par une personne qui regarde l'algo, il ne fait que sa toute la journée. Si l'algo prenait une place tellement petite dans un programme on ne s'amuserait pas à les payer pour rien.
Je suis d'accord pour l'importance de l'algo. Mais après l'avoir établi , le langage d'implementation est déterminant.
Tu me trouves l'endroit ou tu precises que tu ne parlais que des langages "pas web" ? (En admettant que ca ait un sens de dire ca, car non le PHP n'est pas un langage web, c'est tres utilise dans le web c'est tout). ==> le php ne peut être éxécuté que ur un serveur donc web globalement. "<acronym title="PHP: Hypertext Preprocessor">PHP</acronym> (officiellement, ce sigle est un acronyme récursif pour PHP Hypertext Preprocessor) est un langage de scripts généraliste et Open Source, spécialement conçu pour le développement d'applications web."
C'était vrai en 1995 tres cher . En 2015 le PHP est devenu plus cosmopolite , il peut etre utilisé dans des applications web , desktop , mobile etc ...
Si tu prends des langages assez proches, java, c# ou encore vb. Je connais pas leur rapidité d'éxécution mais est-ce que tous les gens venant sur le sdz ont réellement besoin des 2 secondes de traitements ? Car oui deux seconde pour un FPS c'est beaucoup mais pour un programme qui check une liste de données ? Bien sure que le choix du langage compte et qu'il est à prendre en compte mais pour moi l'algo est tout aussi important.
Si pour une raison où une autre tu te retrouve avec un monocoeur qui peine a executer KDE , tu comprendra pourquoi les gens qui maudissent le programmeurs qui ne se soucient pas de la vitesse d'execution ou de l'utilisation de la memoire le font. D'un autre côté , quand on est sur un core i5 on a l'impression que java est l'un langages les plus rapides qui soient , et qu'il n'y pas de grande difference avec le C ou l'asm.
Je ne vois pas l'intérêt de tes post LK13.. tu ne fais que redire les choses déjà dites.
Faut arrêter de croire que que le langage fait tout ! Certes il y est pour grand chose dans la vitesse d'exécution mais l'algo occupe également une part importante.
Si je prend tous les raisonnements, vous allez me dire que la SDL est lente ? Nan, c'est juste que vous vous en servez mal et que vos algos sont mal optimisés.
Je ne vois pas l'intérêt de tes post LK13.. tu ne fais que redire les choses déjà dites.
Faut arrêter de croire que que le langage fait tout ! Certes il y est pour grand chose dans la vitesse d'exécution mais l'algo occupe également une part importante.
Si je prend tous les raisonnements, vous allez me dire que la SDL est lente ? Nan, c'est juste que vous vous en servez mal et que vos algos sont mal optimisés.
Surtout evitons d'entrer dans du flamethrowing. Intel promet de fabriquer dans les années futures des processeurs ayant plus d'une centaine de coeurs. Avec l'avenement des processeurs moléculaires , la vitesse ne sera peut-être plus un soucis. Dans ce cas là le langage ne sera plus un soucis.Mais encore , viendra un nouveau langage , 10 fois plus lent et plus lourd ( mais d'autant plus simple que le java ) et le bond en terme de vitesse ne se ferra pas pleinement ressentir. Je propose que chacun garde son opinion là dessus . @ractamard
Surtout evitons d'entrer dans du flamethrowing. Intel promet de fabriquer dans les années futures des processeurs ayant plus d'une centaine de coeurs. Avec l'avenement des processeurs moléculaires , la vitesse ne sera peut-être plus un soucis. Dans ce cas là le langage ne sera plus un soucis.Mais encore , viendra un nouveau langage , 10 fois plus lent et plus lourd ( mais d'autant plus simple que le java ) et le bond en terme de vitesse ne se ferra pas pleinement ressentir. Je propose que chacun garde son opinion là dessus . @ractamard
Salut, je bosse sur des programmés de calcul sur les modèles cfao. Et j'ai remarqué que plus les processeurs sont puissants, plus les modèles et assemblages sont complexes et lourds. Et je ne peux jamais me reposer sur la puissance de mes nouvelles machines pour m'assurer, il faut toujours que j'optimise car les modèles en demandent toujours plus. Mais je sais que je suis dans une niche.
Faut arrêter de croire que que le langage fait tout ! Certes il y est pour grand chose dans la vitesse d'exécution mais l'algo occupe également une part importante.
c'est clair, j'aimerai pas être a la place du gars responsable de regler les problèmes de false sharing a coup de centaines de processeurs, ajouter de la puissance ne va pas automatiquement regler tous les problèmes, au contraire
Je pense , pour ma part que l'essentiel a été dit. Une autre conversation pourra etre crée si necessaire pour debattre de la question des processeurs et de leur vitesse et des performances des differents langages. Je sais pas pour vous , mais moi je pense que ça c'est un sujet résolu. Je m'excuse pour toute erreur , faute d'orthographe ou écart de comportement de ma part. Ne voyez rien de personnel dans mes posts , l'important est que nous soyons tous édifiés. Merci beaucoup à vous tous.
Le problème du rapport rapidité/puissance n'est pas nouveau. Et ne concerne pas que l'informatique.
Il y a quelques années, ont croyait qu'on allait réduire les consommations en carburant de nos véhicules, parce qu'avec les matériaux composites et des alliages de plus en plus légers et costauds, la masse globale des véhicules allait se trouver être réduite. En quelque sorte, c'est le cas, mais le poids des équipements est venu petit à petit combler le gain de masse en étant, lui, de plus en plus important, suffit de comparer la sellerie d'une voiture actuelle à celle d'une R16 pour s'en convaincre.
Pour nos chères machines, c'est pareille, ces lois ont d'ailleurs un nom, il s'agit des lois de Moore et de Wirth. L'une explique l'évolution "exponentielle" des capacités de calcule et l'autre l'augmentation de charge des tâches à effectuer et/ou de l'obésité, si bien qu'en 2015 le ressenti sur le démarrage de certains programmes (ou OS) est le même qu'en 1990 pour démarrer un Windows 3.11
Et j'ai envie de dire que oui, ça semble gênant à priori, mais tant mieux quand-même. Il est impensable d'avoir à réinventer la roue à chaque développement, et les sous/surcouches successives permettent cela. Perso, je suis un fana de jeux vidéos, et je ne crois pas me tromper de beaucoup en affirmant que depuis bien longtemps, le temps de développement d'un jeu n'a pas beaucoup évolué. Vous imaginez des gars sortir un jeu genre Arkham knight avec des moyens équivalents à ce qui était disponible pour Pac man ? Il leur faudrait 10 ou 15 ans au minimum si ce n'est pas 30. Ok, ptet qu'en faisant gaffe le jeu pourrait utiliser 5% de proc en moins et économiser 200 ou 300 Méga de ram mais quel intérêt s'il faut passer un an à optimiser ? Vous voyez les devs de jeux ressortir une version plus "light" 1 an après et qui couterait bien entendu plus cher (faut que les gars mangent pendant ce temps). Perso, pour un gain aussi pauvre, je ne suis pas acheteur...
Bien sûr les arguments d'efficacité/rapidité sont très certainement valables pour la NASA, l'ESA ou les applications critiques. Le grand public, c'est à dire nous pour une grande majorité, a accepté le fait qu'il faille gonfler les bécanes pour suivre l'évolution des applications.
Bref, oui le dernier jeu à la mode n'est pas plus rapide à charger que IK+ sur amiga, mais bon, je crois que ça vaut le coût d'attendre un peu...
Faut arrêter de croire que que le langage fait tout ! Certes il y est pour grand chose dans la vitesse d'exécution mais l'algo occupe également une part importante.
Je pense avoir déja lu ça quelque part. Pas toi ?
BA forcément je l'ai plusieurs fois dans la conversation..
je suis un fana de jeux vidéos, et je ne crois pas me tromper de beaucoup en affirmant que depuis bien longtemps, le temps de développement d'un jeu n'a pas beaucoup évolué. Vous imaginez des gars sortir un jeu genre Arkham knight avec des moyens équivalents à ce qui était disponible pour Pac man
D'accord, mais j'ai l'impression que c'est l'inverse qui s'est produit: c'est parce que nos machines ont (énormément) évolué, que tous ces jeux ont pu passer de packman à (mettons) bf3 [je ne suis pas gamer]
A+
Edgar;
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
pour moi le fait qu'il existe un flou vient du fait que la plupart des joueurs ne se rendent pas bien compte des mechanismes de programmation derrières les jeux, et n'ont donc absolument pas idée de la puissance necessaire a faire tourner leurs jeux.
J'ai tendance a penser que c'est le même phenomène qui cause tout les "MMORPG revolutionnaires" present dans la section projets de ce site
pour moi le fait qu'il existe un flou vient du fait que la plupart des joueurs ne se rendent pas bien compte des mechanismes de programmation derrières les jeux, et n'ont donc absolument pas idée de la puissance necessaire a faire tourner leurs jeux.
Je pense que ca vaut aussi pour la majorite des programmeurs malheureusement.
je suis un fana de jeux vidéos, et je ne crois pas me tromper de beaucoup en affirmant que depuis bien longtemps, le temps de développement d'un jeu n'a pas beaucoup évolué. Vous imaginez des gars sortir un jeu genre Arkham knight avec des moyens équivalents à ce qui était disponible pour Pac man
D'accord, mais j'ai l'impression que c'est l'inverse qui s'est produit: c'est parce que nos machines ont (énormément) évolué, que tous ces jeux ont pu passer de packman à (mettons) bf3 [je ne suis pas gamer]
A+
Edgar;
Oui et non, bien sûr la bécane doit être capable de fournir le rendu final, difficile d'affirmer le contraire, mais avant le rendu final il y a le développement. Et celui-ci n'est possible qu'avec des outils adaptés, je vois ça dans cet ordre, les bécane sont plus puissantes, permettant des outils plus poussés et plus simples d'utilisation (au prix de sous/surcouches obscures à n'en pas douter), de ce fait le résultat est de plus en plus spectaculaire à temps de développement équivalent.
Je ne crois pas me tromper en affirmant qu'un développement demande des ressources supérieures au rendu : J'ai 390Ko de fichiers .h et .c pour un exécutable de 146Ko... Autre exemple, quand je prépare les images de fond de mon jeu avec gimp, j'ai besoin de 18Mo de calques et autres (il faut ajouter la place pour l'exécution soft) avant de rendre mon jpeg de 400Ko. Et je mets 10 fois moins de temps qu'il n'en fallait pour faire un truc moins bien sur Amiga, parce que Gimp est 100+ fois supérieur en capacité et en fonctionnalité que ne l'étaient les softs pro (payants et chers) de l'époque.
Si tu prend ton PC actuel et que tu l'emmènes en 1986 avec ta De Lorean, je suis prêt à parier qu'il n'y aura pas grand monde pour développer un BF3 sans les softs de dev qui vont avec en moins de 10 ans malgré que la bécane sera capable de faire le rendu. Sommes-nous en mesure de dire si les rendus de 3DSMax (ou whatever) sont vraiment optimisés ? On n'en sait rien et on s'en fout en fait, on sait que ça passe.
Combien y a-t-il de programmeurs dans une équipe de dév ? Très peu j'en suis certain, les graphistes dessinent sur des softs pour, les modeleurs font leurs modèles sur des softs pour, les animateurs... vous avez compris.
Bien sûr si on veut faire un jeu en C, comme l'on fait la plupart d'entre nous, il est important d'avoir conscience du travail à fournir, si le gars veut faire son super RPG, il va en chier, maintenant, il peut utiliser RPG Maker et ne pas avoir à se prendre la tête sur les mécanismes. Il n'en sait rien si son binaire est optimisé ou pas, mais il a fait son jeu en 1 an au lieu de 5... Et ça fonctionne quand-même voire mieux parce que le soft en question a été éprouvé et débuggé.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Bonhomme !! | Jeu de plateforme : Prototype.
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Bonhomme !! | Jeu de plateforme : Prototype.