Performance avec la STL - Page 1

Bonjour,
Je développe actuellement une librairie 3d pour la gp2x avec quelques personnes.
J'aurais besoin d'un avis sur un point clé concernant la gestion des objets. En fait, nous hésitons à utiliser la stl pour le stockage des faces des objets (utilisation de l'object list ou vector). Cela nous permettrait d'avoir une gestion efficace des listes d'objets (avec des méthodes de tri performantes). D'un autre côté, la stl est écrite pour une architecture de type PC et malgré sa portabilité, des doutes subsistent concernant les performances sur une architecture embarquée disposant de moins de mémoires.
Lors de l'ajout dans un vector par exemple, il me semble que la STL peut faire une allocation de place assez importante en une fois. Cela pourrait dégrader les performances.

J'attends vos avis. Merci :-)

Je pourrais pas t'aider mais je te souhaite bonne chance

a mon avis, je penses que sur GP2x il faudrait des lib 3d mais avec le minimum sindical car la GP2x c'est pas une bomb en 3D

L'utilisation de la STL entraîne l'utilisation du C++.
Malgré tout ce qu'on peut dire, un programme en C++ sera plus lent qu'un programme en C, a algorithmes égaux.
Et pour de l'embarqué, le C est vraiment plus adapté. Bien sûr que le C++ permet une facilité de programmation et une grande modularité dans ses programmes, mais cela reste au détriement de la vitesse, élément primordial en embarqué.

Yod4z :
a mon avis, je penses que sur GP2x il faudrait des lib 3d mais avec le minimum sindical car la GP2x c'est pas une bomb en 3D

Quand on voit le projet de WipeOut like sur GP32 (qui est loin d'être dispo et jouable mais on croise les doigts ) y a pas de raison que la GP2X ne puisse pas avoir une lib puissante et des jeux peut être pas aussi bon que sur PSP (y a pas photo), mais au moins comme sur DS non? après il faut une bête de programmeur motivé pour avoir ces jeux, c'est sure ^^

j ai vu un debut d emulateur play one sur gp32,pourkoi pas sur gp2x alors?

C'était un fake...

Par contre celui qui tourne déja sur GP2X non ^^

essaye de contacter l'auteur de Yeti3D :
http://www.angelsoftware.org/index.php?Projet---gp32
il me semble que c'est codé par ThunderZ. Tu peux lui adresser un mp ou un mail. Je suis sûr qu'il te répondra.

en espérant que ça t'aide

Pékélé :
essaye de contacter l'auteur de Yeti3D :
http://www.angelsoftware.org/index.php?Projet---gp32
il me semble que c'est codé par ThunderZ. Tu peux lui adresser un mp ou un mail. Je suis sûr qu'il te répondra.

en espérant que ça t'aide

en fait thunder à codé l' adaptation sur gp32

Gatchan :
L'utilisation de la STL entraîne l'utilisation du C++.
Malgré tout ce qu'on peut dire, un programme en C++ sera plus lent qu'un programme en C, a algorithmes égaux.
Et pour de l'embarqué, le C est vraiment plus adapté. Bien sûr que le C++ permet une facilité de programmation et une grande modularité dans ses programmes, mais cela reste au détriement de la vitesse, élément primordial en embarqué.

Est ce que tu as des liens qui parlent de cela ?
On est encore au début du projet et ces choix nous semblent primordials, donc on veut pouvoir être sûr de nous.

Merci :-)

tori :
C'était un fake...

je confirme que ce n'est pas un fake
je connais un des membres qui fait le portage pocket pc de l'emulateur FPSE du nom pour la version ppc : FPSECE
et l'auteur de la version pc avait fait un portage sur gp32 avec l'emulateur geepee32 pour les screenshots
malheureusement il n'a pas voulu faire de release publique ce qui est dommage car ça aurait pu etre sympa de tester la play sur sa gepette !

en fait thunder à codé l' adaptation sur gp32

ok, je ne me rappelais plus. Je pense qu'il pourraît être d'une grande aide quand même
Et comme il passe de temps en temps...

Je n'y connais rien en 3D alors je ne peux pas t'aider. As-tu regardé comment le moteur de quake fonctionnait ? est-ce qu'il gère les objets de la même façon ?

Yod4z :
a mon avis, je penses que sur GP2x il faudrait des lib 3d mais avec le minimum sindical car la GP2x c'est pas une bomb en 3D

Elle peut le devenir... Regarde la gba, il y a des démos bluffante de 3D donc pourquoi cela ne serait pas possible sur gp2x? Elle a quand même deux processeurs puissant!
Pour le c++ j'ai toujours trouvé ça plus lent par rapport à un programme en C... Mais peut être que mes test étaient pourris

des demos et un jeu y a des direrence enorme sur amiga y a eut pas mal de demo bluffante mais apres niveau jeux en 3d ca ete plutot desert

J'ai besoin de preuves et donc de doc à l'appui pour montrer que le C est plus rapide que le C++ à algorithme égal. Savez vous ou je peux trouver ca ?

Merci

bamoo :
J'ai besoin de preuves et donc de doc à l'appui pour montrer que le C est plus rapide que le C++ à algorithme égal. Savez vous ou je peux trouver ca ?

Merci

Tu risques pas d'en trouver puisque c'est faux!!

Gallenza, toujours aussi extrème
Après recherche, voici ce que j'ai trouvé :
http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance.htm
http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance2.htm
Deux pages montrant les éventuelles "surcharges pondérales" suite à l'utilisation du C++.

Je reprend ce que je disais, mais je le corrige : a algorithmes égaux, un code C++ sera au mieux aussi rapide que le C. tout simplement car les compilateurs C++ supportent le C. D'un autre côté, à quoi bon utiliser le C++ si cela peut être fait en C?
Clairement, le C++ et le C ne doivent pas être utilisés dans les mêmes cas. Le C++ est parfait si on a tout prévu en modèle objet.
Et il est possible d'avoir un programme rapide si il est bien programmé (voir ce lien : http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1430.pdf ).

Mais malgré tout je préfère le C. Et je pense que pour de l'embarqué, et si on a pas en tête la réutilisation du code, il est très bien adapté (petite taille de l'executable, facilité d'accès au bas niveau, etc...). Surtout, cela limiterai moins l'accès aux programmeurs : une lib C peut être utilisée en C++, l'inverse n'est pas toujours vrai...
Enfin, au final, tout dépend du programmeur. Un bon programme en C++ sera plus rapide qu'u programme C mal écrit, et vice verça.
A vous de mettre au plat vos besoins, voir si l'apport de l'objet facilitera le développement, et surtout, voir ce que vous voulez obtenir : une librairie rapide mais plus 'monolithique', ou une librairie un peu plus lente, un peu plus grosse, mais plus modulaire.

Oui, il y a plein de débats là-dessus. Mon avis n'est pas celui des radicaux, à savoir du tout objet en C++ ou du C pur. Je pense sérieusement qu'on peut tirer avantage d'un "code batard". L'utilisation de certaines caractéristiques du C++ comme :
- les classes sont très pratiques pour la maintenabilité du code et ne ralentissent pas l'exécution du code à condition de prendre quelques mesures (mettre le constructeur et le destructeur en inline dans certains cas et éviter l'appel de ces 2 méthodes à de trop nombreuses reprises, dans une boucle par exemple).
A la limite, il est possible d'utiliser les structures en C, mais je ne vois pas trop l'intérêt.
- On peut aussi utiliser la pile pour déclarer des variables au milieu du code ou dans notre boucle for par exemple.
- La surcharge des opérateurs est très pratique. Pouvoir faire v1+v2 sachant que v1 et v2 sont des vecteurs ou des matrices améliore grandement la lisibilité !
- Il y a aussi les commentaires facon C++ bien que la plupart des compilateurs C les acceptent.

Bref, si vous avez des contres arguments n'hésitez pas car nous n'avons pas encore fait notre choix !!!

Merci :-)

gallenza
:

bamoo :
J'ai besoin de preuves et donc de doc à l'appui pour montrer que le C est plus rapide que le C++ à algorithme égal. Savez vous ou je peux trouver ca ?

Merci

Tu risques pas d'en trouver puisque c'est faux!!

Comme déjà dit, ce n'est pas faux. Le C++ est au mieux aussi rapide que le C, principalement à cause de la surcouche objet. Après, ça dépend bien sûr des compilos utilisés, je ne dis pas qu'un très mauvais compilo C ne fera pas du code plus lent qu'un très bon compilo C++.
L'intérêt du C++ par rapport au C n'est pas d'être plus rapide en exécution, mais plus rapide en temps de développement. Mais tu ne peux pas attendre d'un langage de plus haut niveau qu'il soit plus rapide q'un langage plus proche du processeur.

Effectivement, tout code C étant du C++, le C++ peut forcément être aussi rapide que du C.
J'avais donc raison.
Maintenant c'est clair que le C est un langage qui n'offre aucune fonctionnalité, et qui est le langage dela prog système.
Par déformation on peut tout programmer en C, mais je ne pense pas que pour le programmeur ce soit cool.

(qu'est-ce qu'il ne faut pas lire parfois quand même ...)

mouarf, c'est clair, y'a defois, on se demande si les personnes qui postent savent de quoi ils parlent

gallenza :
Effectivement, tout code C étant du C++, le C++ peut forcément être aussi rapide que du C.
J'avais donc raison.
Maintenant c'est clair que le C est un langage qui n'offre aucune fonctionnalité, et qui est le langage dela prog système.
Par déformation on peut tout programmer en C, mais je ne pense pas que pour le programmeur ce soit cool.

C'est pas pour te faire chier mais le C n'est aucunement le "langage dela prog système", Le C tout comme le C++ est un langage évolué. Si tu veux du langage de prog systéme vat plutot chercher l'assembleur. L'assembleur te permet de faire totatlement tout ce que tu veux bien plus rapidement que n'importe qu'elle autre langage, par contre accroche toit bien pour lire un programme long et compliqua en assembleur, autre inconvénéient l'assembleur 8086, n'est pas le même que celui des ARM ni celui des proc mac. Chaque famille de proc a son assembleur.

Au fait contrairement a ce que tu dit "tout code C étant du C++", je pense perso que c'est le contraire le C++ étant une évolution du C et pas le contraire.

LAF ! ! ... !

LAF :
C'est pas pour te faire chier mais le C n'est aucunement le "langage dela prog système", Le C tout comme le C est un langage évolué.

Ca dépend de ce qu'il entendait par "programmation système", mais historiquement, et dans les faits, les systèmes d'exploitations sont quasiment tous écrits en C, à part d'inévitables et peu nombreuses couches très bas niveau en assembeleur

LAF :
L'assembleur te permet de faire totatlement tout ce que tu veux bien plus rapidement que n'importe qu'elle autre langage

Ca, c'est la théorie, mais les processeurs modernes deviennent tellement compliqués, que dans la majorité des cas du code produit par un compilo C aura de bonne chances c'être plus performant que celui fait par un homme (multi-coeurs, pipelines, cache, etc).

LAF :
Au fait contrairement a ce que tu dit "tout code C étant du C ", je pense perso que c'est le contraire le C étant une évolution du C et pas le contraire.

Je pense que c'est ce qu'il voulait dire sans l'avoir bien exprimé

Yop les choupschoups

Bon ba vous prenez pas la tete avec les langagues, y'a quand meme les algos avant tout en 3D et la facon dont vous codez et architecturé votre code.
Mon optiminion personnel est qu'il est plus facil je trouve pour des consoles portables de travailler et d'optimiser un code C pur car la plus par du temp la generation C++ diffèrent pas mal.

Dans mon cas personnel, je code en C car du coup je maitrise mieux mon code.

Yeti et Yeti Pro sont ecrit en full C.

Voily voilou

LAF
:

gallenza :
Effectivement, tout code C étant du C++, le C++ peut forcément être aussi rapide que du C.
J'avais donc raison.
Maintenant c'est clair que le C est un langage qui n'offre aucune fonctionnalité, et qui est le langage dela prog système.
Par déformation on peut tout programmer en C, mais je ne pense pas que pour le programmeur ce soit cool.

C'est pas pour te faire chier mais le C n'est aucunement le "langage dela prog système", Le C tout comme le C++ est un langage évolué. Si tu veux du langage de prog systéme vat plutot chercher l'assembleur. L'assembleur te permet de faire totatlement tout ce que tu veux bien plus rapidement que n'importe qu'elle autre langage, par contre accroche toit bien pour lire un programme long et compliqua en assembleur, autre inconvénéient l'assembleur 8086, n'est pas le même que celui des ARM ni celui des proc mac. Chaque famille de proc a son assembleur.

Au fait contrairement a ce que tu dit "tout code C étant du C++", je pense perso que c'est le contraire le C++ étant une évolution du C et pas le contraire.

LAF ! ! ... !

Désolé de te contrer sur tout, mais si tu avais fait un tour dans les codes sources des noyaux des OS (www.kernel.org pour le noyau Linux) tu te rendrais compte assez facilement de ton erreur.
Et fait marcher tes neurones, le C++ étant un sur-ensemble du C, tout code C est bien du C++, alors que l'invese n'est pas vrai (ex: tu peux déclarer une strucure en C++, mais pas une classe en C).
Sans rancune.

LOL !! Là tu me fait rire !
Le C++ est bassé sur le C et pas le contraire.
Tu me parle du code sources des OS mais c'est pas le nec plus ultra, si tu veux faire de la programation hard c'est pas du C ou du C++ qu'il te faut mais du ASM !
Vat donc programmer un pic en C ou en C++....
Tu peux y arriver mais tu vat bouffer 1mo de mémoire juste pour faire un programme de chenillard (allumer des led les une après les autre genre K2000), alors qu'en ASM il prendra 100o.

Par contre je suis d'accord que dès que tu veux faire un programme compliqué sans avoir de préocupation de vitesse et de taille le C et le C++ sont bien mieux et surtout bien plus lissible.

LAF ! ! persite et signe !

LAF :
Tu me parle du code sources des OS mais c'est pas le nec plus ultra, si tu veux faire de la programation hard c'est pas du C ou du C++ qu'il te faut mais du ASM !

Programmant tous les jours pour de l'embarqué, je peux te dire que tu te mets le doigt dans l'oeil très très profond
La seule fois où on utilise de l'asm, c'est quand le compilo n'est pas assez puissant pour optimiser au maximum le matériel (ex: fonctions de traitement du signal spécifiques à un DSP) ou quand le langage atteint ses limites (fonction de changement de tâches d'un OS, avec changement des registres et manipulation de la pile, etc). Ou pour faire le kake démo-codeur. Mais c'est pas très très pratiqué dans l'industrie ça. Quand on arrive à devoir optimiser en taille ou en vitesse au point de passer à l'asm, c'est que soit on est désespéré, soit que le système a mal été dimensionné.

LAF :
Vat donc programmer un pic en C ou en C++ ....

Sans problème (pour le C)

LAF :
Tu peux y arriver mais tu vat bouffer 1mo de mémoire juste pour faire un programme de chenillard (allumer des led les une après les autre genre K2000), alors qu'en ASM il prendra 100o.

Faux, pour le C du moins. Autant la runtime C++ peut être grosse, autant le C prend peu de place et est parfaitement adapté à de la programmation proche du matériel, et embarquée.

LAF :
LAF ! ! persite et signe !

LAF !! qui a probablement beaucoup d'expérience en la matière ?

Ce que tu dit ne contredit en rien ce que je dit, tu reconis même que quand tu veux faire mieux tu laisse le C pour passer a l'assembleur.
APrès je reconnais que travailler en assembleur faut en vouloir, et bien préparer ton travail et ton code sources, sinon pratiquement imposible de t'y retrouver.
Quand au C avec ces routines intégrérnt il ne pourrat jamais battre un programme assembleur pour de petit programme.

LAF ! ! ... !