sinon, un autre truc.

ce code-ci:

http://pastebin.com/uuBeHb46

s'exécute trois fois plus rapidement que celui-ci:

http://pastebin.com/AGqqutPG

alors que j'ai juste changé l'emplacement de --i, gagnant deux additions au passage. des avis? on sort du cadre de la réalité, là.

quel compilateur?

les boucles qui vont en arriere sont typiquement bien plus lente que les boucles qui vont de l'avant, ca a a voir avec la predictions d'access memoire. Tu dois certainement te taper differente forme de dependance de donnee bizarre.

c'est g++ version 4.4.1, avec les options -Wall -O2 -s. je m'étais trompé la dernière fois, ce n'était pas gcc.

• godrik Voir le profil de godrik

* Posté le 16 février 2012 à 22:52:38 Avertir un administrateur
* les boucles qui vont en arriere sont typiquement bien plus lente que les boucles qui vont de l'avant, ca a a voir avec la predictions d'access memoire. Tu dois certainement te taper differente forme de dependance de donnee bizarre.

on m'avait dit le contraire, c'était en rapport avec la comparaison qui sert de limite... !=0 serait plus rapide que <limite.

je vais essayer en inversant le sens des boucles.

c'est très légèrement plus lent en remettant les boucles dans l'ordre, en fait.

la comparaison a 0 est plus rapide en effet. mais travers les tableau dans l'ordre est plus simple pour les prefetcheurs.

De combien de temps on parle la ?

as tu essayer un autre compilateur?

1750 millisecondes pour blitter 120000 images, 5700 avec la deuxième portion de code.

avec g++ 4.4.1, je viens d'essayer avec la version 4.5.2 et ça supprime la lenteur, en fait... une mise à jour du compilateur s'impose.

j'ai pas tellement d'autres compilateurs sous la main... éventuellement celui de visual c++ 2010 mais je pensais m'en tenir à minGW, qui est simple à configurer et ne requiert pas tellement de DLL que personne n'a à l'exécution.

Je pensais a un vrai compilateur, genre le compilo d'intel
Il y a eu plein de gros changement dans gcc recement. Donc essaie de maintenir un compilo a jour. De memoire, le compilateur de microsoft est de bonne facture, pour faire des test, ca peut valoir le coup d'essayer. Sinon, je ne sais pas a quel point on peut lier un fichier object compiler avec visual studio et linker avec gcc, mais ca peut etre a envisager.

1. godrik Voir le profil de godrik
2. Posté le 16 février 2012 à 23:45:52 Avertir un administrateur
3. Je pensais a un vrai compilateur, genre le compilo d'intel

à vrai dire, je rêve de mettre la main dessus, mais il est payant, autant que je sache... sauf sous linux, avec un contrat d'utilisateur très restrictif. le problème, c'est que le projet que je fais est très dépendant de windows, actuellement.

et puis, j'ai un processeur de chez AMD. pas sûr que le gain de performances soit aussi évident que sur un processeur Intel.

les performances sont sensiblement les mêmes (très légèrement supérieures, on passe sous la barre des 1700) sous visual 2010, avec toutes les optimisations activées.

Je m'excuse de cette question conne mais g++ a-t-il un système de précompilation de header comme vs2010 ou l'on peut rassembler dans un fichier (stdafx.h) ce qui revient tout le temps?

Ça veut dire quoi "précompiler des headers" ? (surtout que hors templates + options de compilation de niveau 12, il n'y a rien à compiler dans un fichier header)

oui, g++ sait precompiler des headers:

$ g++ foo.h

genere un fichier foo.h.gch.

De memoire, ca sert a rien... Mais je suis peut etre en erreur.

On dirait que ça se fait de manière transparente en effet sur g++. En principe ça permet d'éviter de recompiler les headers qui ne changent jamais ou presque à chaque fois qu'une inclusion a lieu.

Mais je ne comprends pas trop le but. Les headers sont relativement petit. Ce n'est jamais mamoutesque un header file. Ou quand c'est gros, c'est parce qu'il contient du code template qui n'est probablement pas precompilable.

Aussi, que ce passe t'il quand on change des variables du precompilateurs? Le code est recompiler? Ou bien est ce que ca evite juste l'analyse syntaxique?

Salut ! J'ai une petite question, qui peut paraitre conne, mais je ne comprends pas... Pourquoi un octet = 256 ?

J'ai un gros problème de logique... on me dit :

Un chiffre binaire peut avoir deux états :

Ouvert ou fermé, 0 ou 1 en sommes.

Un octet contient 8 bits, je ne vois pourquoi on en arrive à 256 combinaisons possibles ?

Pourquoi le calcule 2*2*2*2*2*2*2*2 ?
Ça parait bête comme question, mais en gros dans ma tête je me représente un octet comme ça :

http://s4.noelshack.com/old/up/sans_titre-dbf1d0dc92.png

En gros j'en arrive à seulement 16 possibilités... je sais que j'ai une grosse erreur de logique, c'est pour ça que je préfère vous demander

http://s4.noelshack.com/1m/1/1/sanstitre-9938438e51.png je te le fais sur quatre bits sinon c'est trop long.

En fait, j'imagine bien que ça doit être ainsi mais je ne comprends pas pourquoi...

A la limite si tu as vraiment du mal à voir pourquoi tu peux simplement essayer différentes combinaison jusqu'à dépasser 16 et là tu verras bien pourquoi...