Ablabla C++

Petit topic style 'Zut' mais lié au C++. Si une idée vous passe par la tête ou que vous avez une question.
Que vous voulez juste parler d'une biblio/feature, bref pour des petits trucs liés au langage.

Donc je me posais une question toute bête. Dans le cas d'un héritage en 'diamond', ça existe des cas ou on y gagnerais a pas faire de l'héritage virtuel? Car en fait je trouve la syntaxe assez chiante (généralement faut rappeler a chaque fois les constructeurs des parents dans la liste d'initialisation, et souvent avec des 'doublons' au niveau des paramètres) et je me demandais donc, pourquoi par défaut l'héritage est pas virtuel? Y aurait un coût? Ça causerais des soucis de conception par la suite?

J'ai vu un passage sur l'héritage en diamant et l'héritage virtuel sur developpez.com (http://cpp.developpez.com/faq/cpp/?page=L-heritage#Qu-est-ce-que-l-heritage-virtuel-et-quelle-est-son-utilite), ça pourrait p'tet t'aider.

Sinon la SFML c'est vraiment génial, on a des fonctions pour un peu tout et n'importe quoi :p Du coup oni m'a conseillé de faire des metatextures, du coup y'a déjà quelqu'un qui a fait une algo optimisée et de préf' qui soit la même même si on rajoute des éléments? Ou si il faut en rajouter faut mieux juste faire une méthode "classique"?

L'héritage virtuel fonctionne de manière analogue aux méthodes virtuelles (vTable) : la classe fille, au lieu de contenir une instance de la classe mère, contient un pointeur vers son instance de la classe mère. C'est comme ça que les deux filles (et la petite-fille) partagent toutes trois la même instance. Mais de ce fait il faut passer par le pointeur à chaque cast le long de la lignée, ce qui coûte en performances. Première raison.

Deuxième raison : avec l'héritage virtuel, tu as donc une seule instance de la classe mère pour une instance de la petite-fille. Sans, tu en as deux (une pour chaque fille). C'est quand même une sacrée différence, qu'il serait un peu expéditif d'amputer avec un "toute façon avoir deux sous-objets mère cédébile çasérarien". Vu qu'on est pas en Java, les deux cohabitent, avec une préférence par défaut pour le plus simple et efficace.

Ah ok, je savais pas que ça avais un coût aussi violent.
Sinon sans aller jusqu’à amputer la fonction, j'ai du mal a imaginer un cas ou tu peux avoir besoin de 2 même instances de la classe mère.
Si un jour t'as un exemple concret sous la main pense a moi :b


Sinon soundii, update une metatexture, le seul réel coût que ça aurais c'est pour les transferts de texture vers le gpu.
Donc si tu dois vraiment faire beaucoup d'updates, le mieux est d'avoir une metatexture assignée a un FBO (équivalent surface GM), et de garder en mémoire ta structure de packing (perso j'utilise celle la http://www.blackpawn.com/texts/lightmaps/ qui est simple a implémenter et efficace).
Une structure du genre t'es pas obligé de la détruire/reconstruire a chaque update du coup ça peut être intéressant vu que t'as juste a dessiner ta nouvelle sous texture dans la metatexture.

Sinon avant de te prendre la tête tu peux tenter de refaire a chaque fois le packing côté cpu, et renvoyer toute l'image au gpu.
M'étonnerais que ça te cause des soucis de perf car je te vois mal faire cette operations plusieurs fois par frame.

Si t'as trop de mal avec le texture packing ma lib le fait, donc si t'as besoin je peut te filer le module en question un de ces jours (mais je doit modif quelques trucs car pour le moment mon packer est pas dans le bon module).

Je viens de découvrir un truc aujourd'hui.

Si je crée une classe A, avec deux méthodes dedans, une légère, et une lourde (genre une qui fait quelques octets et une qui fait 600ko).

I. Je fais un header et une fichier source, je compile ça en bibliothèque statique, puis je link ma classe a un projet.
Si j'utilise la classe A, même sans utiliser une de ses méthodes, l'exe générée pèsera dans les 600ko.

II. Je fais un header et deux fichiers source, et de même je compile en lib puis je link a un projet.
Si j'utilise la classe A sans utiliser de méthode, l'exe pèsera rien, de même si j'utilise uniquement la méthode légère.
Par contre si j'utilise la grosse méthode le binaire pèsera les 600ko.

Bref, je comprend mieux maintenant pourquoi certains 'extrémistes' disent qu'il faudrait créer un .cpp par fonction/méthode.

Du coup si vous écrivez une lib statique, et qu'une classe possède une ou plusieurs méthodes lourdes, il est conseillé de séparer chaque méthode dans un module séparé, ça permet de générer des binaires plus légers dans le cas ou l'utilisateur ne fera pas de call de chaque méthode.

Pour info, c'est dû au linker qui largue les fichiers objets dont aucun symbole n'est requis par les autres fichiers objets.

Le désavantage c'est que j'ai déjà eu le coup du linker qui largue un fichier objet contenant un objet statique qui devait faire des trucs dans son constructeur +_+

Pour désactiver ça avec g++ : -Wl,--whole-archive lesObjANePasLarguer -Wl,--no-whole-archive

Awé ça c'est ballot ahah

onilink_ a écrit:

Bref, je comprend mieux maintenant pourquoi certains 'extrémistes' disent qu'il faudrait créer un .cpp par fonction/méthode.

AhAH ! Cass-dédi à tous ceux qui disent que y'a trop de cpp dans mes projets \o/

Mass a écrit:

AhAH ! Cass-dédi à tous ceux qui disent que y'a trop de cpp dans mes projets \o/

Mais euh.... c'est juste super galère tous tes .cpp ...

Ça sent l'IDE pas user-friendly ça Mobi :p

Qt

D-z a écrit:

Ça sent l'IDE pas Mobi-friendly ça :p

Fixed.

Un benchmark que je viens de faire pour des gens sur /g/ qui débattaient de la rapidité des méthodes de swapping.

Code:

#include<stdio.h>
#include<stdlib.h>
#include<time.h>

void xorSwap(int *x,int *y)
{
   *x ^= *y;
   *y ^= *x;
   *x ^= *y;
}

void addSwap(int *x,int *y)
{
   *x = *x + *y;
   *y = *x - *y;
   *x = *x - *y;
}

void tempSwap(int *x,int *y)
{
   int temp = *x;
   *x = *y;
   *y = temp;
}

float chrono(void (*fun)(int*,int*),unsigned int swapNum)
{
   clock_t ticka;
   clock_t tickb;
   int x;
   int y;
   ticka = clock();
   for (int i=0;i<swapNum;i++) fun(&x,&y);
   tickb = clock();
   return (float) (tickb - ticka) / CLOCKS_PER_SEC;
}

int main(void)
{
   const unsigned int swapNum = 1000000000;
   puts("Let's make ebin swabs! :^)\n\n");
   
   // XOR
   puts("XOR swaps: ");
   printf("%f s for %d swaps\n",chrono(xorSwap,swapNum),swapNum);
   
   // Add
   puts("Add swaps: ");
   printf("%f s for %d swaps\n",chrono(addSwap,swapNum),swapNum);
   
   // Temporary variable
   puts("Temporary variable swaps: ");
   printf("%f s for %d swaps\n",chrono(tempSwap,swapNum),swapNum);
   
   puts("\nDad was guide inderesding. :^)\n");
   return 0;
}

Console a écrit:

Let's make ebin swabs! :^)


XOR swaps:
11.826000 s for 1000000000 swaps
Add swaps:
9.112000 s for 1000000000 swaps
Temporary variable swaps:
6.651000 s for 1000000000 swaps

Dad was guide inderesding. :^)

En fait c’est la méthode la plus stupide qui marche le mieux. J’ai rien compris aux explications par contre.

J'imagine que dans la majorité des cas, le compilo peut faire des optimisations en utilisant les registres, du coup forcément ça va plus vite.

Par contre faut faire gaffe avec les benchmark, d'une architecture a une autre ça donne pas forcément la même chose.
Du coup faut toujours préciser l'archi cible, le compilo et ses options.

Par exemple sur mon archi amd les opérations de multiplications sont bien plus coûteuses que les soustractions/additions, bah sur un intel récent les opérations de bases ont toutes le même coût...

Faut toujours prendre ça avec des pincettes du coup.

Code:

XOR swaps:
0.794000 s for 1000000000 swaps
Add swaps:
0.859000 s for 1000000000 swaps
Temporary variable swaps:
0.264000 s for 1000000000 swaps

MVSC 2013
x64, i5 4670K

onilink_ a écrit:

Par exemple sur mon archi amd les opérations de multiplications sont bien plus coûteuses que les soustractions/additions, bah sur un intel récent les opérations de bases ont toutes le même coût...

C’est pas censé être O(n) pour l’addition et O(n ln n 2^{3 log* n}) pour le produit (sauf si les ingénieurs de AMD sont encore à l’école primaire ) ?

Craki a écrit:

onilink_ a écrit:

Par exemple sur mon archi amd les opérations de multiplications sont bien plus coûteuses que les soustractions/additions, bah sur un intel récent les opérations de bases ont toutes le même coût...

C’est pas censé être O(n) pour l’addition et O(n ln n 2^{3 log* n}) pour le produit (sauf si les ingénieurs de AMD sont encore à l’école primaire ) ?

De ce qu'un prof nous avait dis en fait, c'est que les "algos" en portes logiques gravés sur les processeurs deviennent de plus en plus performants, et sur les archis récentes on tends vers une complexité constante quelque soit l’opération.... (pis on traite toujours le même nombre de bits généralement donc bon).

Et effectivement mon processeur a une dizaine d'années
Sur un processeur récent les tests montrent bien que la multiplication est de plus en plus légère...

Avi dans le sens où la multiplication est plus rapide sur l'intel que l'amd, et non l'inverse

Yep c'est ce que je voulais dire, j'ai un amd.

M'enfin, c'est les seul a avoir fait un octocore physique en attendant (sans hyper thread)...

Sans vouloir créer un débat, je trouve pas la différence énorme entre 4 ou 8 core, dans le sens ou y a pas spécialement beaucoup d'applis adaptées a tous les exploiter actuellement
Et quand une appli a besoin de gérer beaucoup de threads, elles fait les calculs sur le gpu

Mais l'avenir c'est le multithreading yep, ce sera vraiment fun quand on aura genre 64 cores huhuhu

oui je rappelais juste qu'un octocore existait, je suis sous intel perso
par contre pour le GPU on peut se trouver sur des impasses.
Deja, développer dessus n'est pas toujours facile. j'ai eu plusieurs probleme avec openCL qui me transformais mes vecteurs 3 en vecteurs 4 ou mes structures qui passait de 2 float4 et un float2 en 4 float4 tout ca parce que ca doit etre aligné dans la memoire graphique. ce qui faisait que tout mes tableau etait ordonée a la facon de la carte graphique et non au developpeur. A la fin, j'ai fait mes tableau en float tout court...
De plus, la precision est plus accru sur un CPU et on peut faire des calculs sur plus de 4-8 octets sur un CPU, entre autre grâce a la bibliotheque MPIR par exemple, chose pas (encore) possible sous GPU.

Ouai y a pas mal de contraintes supplémentaires sur le GPU, mais bon, généralement les applications qui ont besoin d'être hyper threadé sont bien assorties avec
J'ai rarement eu besoin (dans un jeu en tout cas) de faire de gros calculs coté cpu, qui étaient impossibles a passer coté gpu.

Tu parles d'un octocore mais c'est pour les serveurs, c'est pour ça que vous n'y voyez pas d'utilité :p En attendant, les VPS pas cher tournent sur ce type de core, parce que quand t'as 16 threads CPU tu peux plus facilement les découper entre plein de VPS. C'est une situation ou y'a énormément d'applications qui tournent en simultané et où un grand nombre de core est très pratique justement

Anéfé, vivement leur cpu 3d avec millemille cores alors

oué ! \o/

88 128 suffiront.
https://en.wikipedia.org/wiki/K_computer

Aucun rapport ^^

Ça me fait penser a https://resin.io/blog/what-would-you-do-with-a-120-raspberry-pi-cluster/
Genre les mecs ont fait un cluster de 120 rpi, mais ils savent pas quoi en faire huhu x)

onilink_ a écrit:

Craki a écrit:

onilink_ a écrit:

Par exemple sur mon archi amd les opérations de multiplications sont bien plus coûteuses que les soustractions/additions, bah sur un intel récent les opérations de bases ont toutes le même coût...

C’est pas censé être O(n) pour l’addition et O(n ln n 2^{3 log* n}) pour le produit (sauf si les ingénieurs de AMD sont encore à l’école primaire ) ?

De ce qu'un prof nous avait dis en fait, c'est que les "algos" en portes logiques gravés sur les processeurs deviennent de plus en plus performants, et sur les archis récentes on tends vers une complexité constante quelque soit l’opération.... (pis on traite toujours le même nombre de bits généralement donc bon).

Et effectivement mon processeur a une dizaine d'années
Sur un processeur récent les tests montrent bien que la multiplication est de plus en plus légère...

En fait c'est vrai, mais en même temps c'est un peu plus compliqué que ça. Ce qui change surtout, c'est par exemple la façon avec laquelle ton processeur va "scheduler" ses opération. Par exemple, de plus en plus on va utiliser des pipelines complexes (en fait de ce côté là c'est vrai que récemment plus ça va moins c'est vrai parce qu'on veut limiter aussi la dissipation de chaleur/consommation en puissance), de l'exécution "out of order", etc. afin de mitiger les effets de l'exécution effectivement plus longue de la multiplication.

Pour ce qui est de la vitesse du swap ça dépend de plusieurs facteurs:
1. Du compilateur: La plupart des compilateurs aujourd'hui reconnaissent le "naive swap" et vont l'optimiser selon les besoins. Si vous voulez avoir vraiment l'heure juste vous devriez faire vos test avec de l'assembleur.
2. Du CPU: De toute évidence, chaque architecture est différentes et a des durées d'opérations différentes. En plus de gérer leurs pipelines différemment.
3. Du code autour: Celui là est plus subtile, mais dans les cas où il y a des branchements par exemple (boucles ou if) ton CPU va plus ou moins émettre des hypothèses statistiques dépendamment du résultat des derniers branchements avant de tester la condition et tu vas perdre des cycles si l'hypothèse est fausse.