et justement, je me demandais si on était sûr qu'il mettait les données utilisées en cache?

c'est les cas d'utilisation d'une surface de réception minuscule et de tableaux fragmentés qui m'interpelle, car un bloc mémoire de 768x512x4 octets ne rentre certainement pas dans les 2x1 mo de cache de l'athlon (d'après une ancienne conversation qui s'est tenue ici), mais la vitesse n'a jamais varié même avec l'utilisation de quantités de mémoire moins importante...

en tout cas, merci de tes avis.

"ben justement, j'ai essayé de copier ligne par ligne l'image source sur l'image de réception, grâce à memcpy, et... c'est quelque chose comme deux fois moins rapide "

Etrange, ca ne devrait pas l'etre, peut etre que c'est du a l'appel de fonction qui n'est peut etre pas inline.

"et justement, je me demandais si on était sûr qu'il mettait les données utilisées en cache?"

Oui. Pour ne pas passer par le cache, il faut le faire expres!

"un bloc mémoire de 768x512x4 octets ne rentre certainement pas dans les 2x1 mo de cache de l'athlon"
Oui, enfin, ca rentre quasiment:
512*768*4/1024/1024=1.50000000000000000000

Une question stupide: Pourquoi ne pas utiliser opengl?

" Pourquoi ne pas utiliser opengl? "

Excellente question.

"Une question stupide: Pourquoi ne pas utiliser opengl? "

pour que ça fonctionne même sur les machines qui ne gèrent pas correctement openGL. j'ai déja dû affronter ça, c'est galère

et en fait, ça offre d'autres avantages: par exemple, le moteur de rendu te refile un tableau de nombres à la fin du processus, et tu peux en faire ce que tu veux. le déverser dans une surface SDL pour l'afficher à l'écran, c'est ce que je fais, mais on peut aussi utiliser à peu près n'importe quelle librairie graphique, ou faire un rendu en ASCII sur la console, etc. et ça pourrait potentiellement être compatible multithread, si plusieurs threads s'occupent chacun d'une partie de l'écran.

Il y a des lib opengl software pour les machines qui n'ont pas de support materiel. Ca ne sera probablement pas significativement plus lent qu'un truc hard coder...

« -quel compilateur?
GCC, -s -O2 -Os. » -Os annule -O2, non ?

En effet, le man de gcc nous dit que :
« If you use multiple -O options, with or without level numbers, the last such option is the one that is effective. »

À ta place, je n'utiliserais pas -Os qui n'apporte concrètement rien (la place, ce n'est pas vraiment un problème de nos jours) et je laisserais uniquement -O2 pour gagner en perf.

"« If you use multiple -O options, with or without level numbers, the last such option is the one that is effective. » "

intéressant, je croyais que ça ne comptait que pour -O1 -O2 -O3. je ferai le test, merci

1. godrik Voir le profil de godrik
2. Posté le 10 février 2012 à 03:02:18 Avertir un administrateur
3. Il y a des lib opengl software pour les machines qui n'ont pas de support materiel. Ca ne sera probablement pas significativement plus lent qu'un truc hard coder...

des librairies spécialisées dans le rendu software? sur les machines privées de support hardware pour openGL, la moindre application en SFML ramait comme pas permis.

et de toute manière, c'est un projet pour lequel j'essaye d'éviter de multiplier les librairies externes. il utilise à peu près uniquement SDL et SDL_image, et encore, avec ce que je fais, ça sera juste pour le chargement des PNG et l'affichage visuel dans une fenêtre.

je rève d'un programme qui pourrait se résumer entièrement à du code source, et pas quelques fichiers sources et plein de librairies dont la moitié sont périmées.

Monsieur caelacanthe ne veut rien faire comme tout le monde, il est beaucoup trop bon pour ça.

1. Pocolo Voir le profil de Pocolo
2. Posté le 10 février 2012 à 16:02:48 Avertir un administrateur
3. Monsieur caelacanthe ne veut rien faire comme tout le monde, il est beaucoup trop bon pour ça.

tu rages que moi > toi, c'est clair désormais.

Tu souffres du syndrome du mec qui veut tout faire "à la main" car il pense que ça sera forcément plus rapide alors que tu vois bien que non.

c'est plus le syndrome du mec qui veut tout faire à la main parce que ça l'éclate.

et puis, excuse-moi, mais 60000 sprites affichés par seconde, ça enterre littéralement SDL, surtout que ces sprites-là sont des surfaces en profondeur 32 bits.

« ça enterre littéralement SDL » prouve-le sérieusement avant de lancer de telles affirmations. Parce que si au final tu fais comme les pro-SFML qui comparent sur une fonctionnalité que la SDL n'a pas, l'affirmation n'a absolument aucune valeur.

"# Chris_27 Voir le profil de Chris_27

1. Posté le 10 février 2012 à 19:42:15 Avertir un administrateur
2. « ça enterre littéralement SDL » prouve-le sérieusement avant de lancer de telles affirmations. "

je sais, il faudrait d'abord que je le finisse. je suppose qu'introduire des trucs supplémentaires fera forcément baisser les performances.

mais c'est justement cette histoire de fonctionnalité que j'ai/n'ai pas qui devrait faire la différence. c'est vraiment de la base dont je vais me contenter, couleur de transparence, quelques niveaux d'alpha uniforme, et c'est tout. le tout probablement réparti sur plusieurs unités de calcul. ça semble bien parti, à vrai dire.

Repartir des sprites de 128x128 en faisant du calcul parallele ca va etre cotton. Tu as plus vite fait de partitionner ton image de sortie, de pousser les images d'entree dans une liste et de rendre a la fin par partie de l'ecran (et c'est ce qu'opengl devrait faire...)

"Tu as plus vite fait de partitionner ton image de sortie, de pousser les images d'entree dans une liste et de rendre a la fin par partie de l'ecran (et c'est ce qu'opengl devrait faire...) "

c'est ce que je pensais faire, un peu... je sépare chaque partie de l'écran, j'affiche les sprites dans la partie de l'écran avec laquelle ils sont en intersection (un sprite pourrait être dessiné sur plusieurs parties de l'écran, de fait) et je délègue un thread par partie d'écran. à la fin, je recolle les parties d'écran sur l'image finale que j'envoie à la fenêtre SDL.

ça a l'air assez compartimenté pour ne pas s'embéter avec des mutex et de l'accès concurrenciel, en plus, mais c'est pas comme si j'avais fait beaucoup de multithread...

mais je ne tiens pas à utiliser openGL, pour l'instant. le résultat final n'est pas la seule chose que je vise... si je commence à utiliser openGL, je vais remettre la main dans ce paquet de fonctions compliquées et démesurées pour ce que je fais, et programmer cesserait d'être amusant.

"à la fin, je recolle les parties d'écran sur l'image finale que j'envoie à la fenêtre SDL."
pas la peind de decouper. Tout le monde ecrit sur la memoire en meme temps. Si tu n'as pas ed chance, tu peux avoir un peu de false sharing, mais c'est tres peut probable et si tu fais ta decoupe aligner sur les lignes de caches ca ne posera pas probleme de toute facon.

Ce qui est important c'est de faire ton calcul parallele en un seul bloc
si tu fais "pour chaque sprite, faire en parallel, copier le sprite" ca ne va pas fonctionner.
Il faut faire "pour chaque bout de l'image d'arrive en parallele, pour chaque sprite, copier le sprite."

"Il faut faire "pour chaque bout de l'image d'arrive en parallele, pour chaque sprite, copier le sprite." "

exact, je pensais procéder de la manière suivante... j'ai une liste de sprites à dessiner. tous les threads parcourent la liste, et chaque thread a sa partie d'écran associée; si un sprite recoupe sa partie d'écran, il le dessine. le thread s'interrompt après avoir parcouru toute la liste, et j'attends simplement que tous les threads aient fini pour afficher l'image finale. tu dis que tout ça peut se faire sur la même surface? c'est encore mieux, je pensais utiliser des surfaces temporaires (correspondant aux parties de l'écran), et les coller dans la surface finale à la fin.

Ce n'est pas un soucis qu'ils ecrivent sur la meme surface, il n'y aura pas de condition de course. En fonction de l'architecture sur laquelle tu tournes, c'est probablement ce qui fonctionnera le mieux.

je suis face à un cas plutôt intriguant...

http://pastebin.com/SjHn4xVi

voici le destructeur des surfaces virtuelles:

~ISRV2VirtualSurface()
{
for(unsigned int i=0;i<1<<m_iPOTDimY;++i)
{
free(m_tbPixels[i]);
}
free(m_tbPixels);
}

le programme s'exécute de manière sensiblement plus lente si je:

-supprime ce destructeur
-remplace i<1<<m_iPOTDimY par i<128
-remplace i<1<<m_iPOTDimY par i<m_iOfficialDimY (qui représente la dimention réelle de la surface, pas une puissance de 2 immédiatement supérieure)
-précalcule 1<<m_iPOTDimY

une idée de pourquoi ça fait exactement le contraire du résultat attendu? surtout qu'il n'est appelé qu'une fois par seconde, seulement après l'application des 60000 images.

128 représente la dimention des images utilisées pour ce benchmark, bien entendu.