Reprise du message précédent :
ça avance encore.
J'ai terminé la phase de sélection du compromis.
Il ne me reste qu'à faire la routine de copie à proprement parlé qui sélectionnera la meilleure routine.
 
Je vais également inclure un test de performance pour comparer le memcpy de visual c avec ma routine.
Hélas je ne pourrait comparer avec celle de AMD, car elle ne supporte pas l'overlap inférieur à 8.
 
Le grand intérêt de ma routine c'est que chacun peu ajouter son code et le programme choisira toujours parmis le meilleur.
Actuellement, j'ai 152 tests pour chacune des 13 routines soit 3780 tests allant de 128 octets à 2Mo.
 
Au final, j'ai réussi à réduire le nombre de combinaisons à 928.

mais le gain de temps de tes routines ne risque pas d'être perdu par le temps pris pour le test de décision ?

C'est utilisable sous dev-cpp tes fonctions de la page d'avant, pour voir?

Bah c'est qqchose à faire à l'init ça, non ?
A moins que cela dépende du contexte ? données en cache , choses comme ça ?

A l'initialisation on prépare les 928 possibilités.
 
A l'appel des différentes fonctions memcpy (il y en a 5), on choisi la meilleure grâce à une table de pointage... Il faut environ 40 cycles pour y arriver. Mais on fait appel à la table de pointage uniquement si la taille est supérieure ou égale à 128 octets. C'est un moment de transition.
 
Etant donné que l'on ne peut pas savoir à l'avance s'il y a des données dans le cache, c'est la raison pour laquelle il y a 5 routines memcpy.
Mais ces fonctions font parties d'un très gros projet qui est en fait une machine virtuelle un peu comme java. Donc je saurais au final où se trouve les données et je pourrais réagir plus rapidement et plus efficacement.

dire que sous OS X les memcopy sont de base optimisés SIMD ^^ ...

Le problème c'est que selon le contexte, certaines routines se montrent plus rapides que d'autres : (AthlonXP Barton)
- Pour des transferts de moins de 384 octets, la FPU est plus rapide que le CPU, le MMX, SSE et autres SIMD.
- Pour des transferts allant jqà 32K, le code MMX et SSE est le plus rapide.
- Pour les blocs dans le cache L2, le code SSE pur est le plus rapide
- Pour des blocs dans la RAM, le code FPU est le plus rapide suivi de très près (2%) par le MMX/SSE.
 
Mais à chaque fois, j'ai écrit des variantes de code exploitant ou non le Hardware/Software/Middle Prefetching...
Et d'autres variantes avec des codes exploitants plus ou moins de registres, avec un code court ou long...
 
Le SIMD n'est pas toujours le plus rapide.
Le jour ou les CPU auront la fonction "rep movxx" implémentée en hard, ça va dépoter grave !
Cyrix l'avait déjà partiellement implémenté (sur le 6x86) pour "rep movsd" mais elle n'exploitait pas le bus sur 64 bits et travaillait sur 32 bits. Le débit était toujours la moitié du théorique.

ouais mais bon, MMX/SSE on peut pas vraiment appelé ca du SIMD ...
 

arrête de troller toi!

 
Arretes t'as deja fait du code propre et efficace sous MMX/SSE ?
En 10mn avec AltiVec au moins tu explose les perfs.

Nan, j'ai pas que ça à foutre!
Reste que là Altivec est hors sujet, je crois!

 
arf si on eut pu troller

En fait le processeur à tellement de mécanisme pour accélérer les transferts qu'en rusant on peut encore améliorer les débits :  
Exemple avec un transfert de 512Ko vers 512Ko (1Mo au total) et un cache de 512Ko, il existe une astuce pour augmenter le débit de 50%.  
Le MMX/SSE est particulièrement pratique en traîtement SIMD comme le ARGB (je m'en sers et les gains obtenus sont ahurissants x8 à x16 !)...
Mais en mode copie, on ne se sert que des fonctions de chargement, d'écrire normale/d'écriture directe (en RAM) et de prefetching. C'est pas vraiment du SIMD. Je suis bien d'accord.

 
en >>SSE2<< o_O paske en MMX les vecteurs ne fournissent que du x4 max.

ouais, c'est bien cool tout ça, mais t'as fait ton trasnfert à la vitesse de l'éclair, mais t'as souillé ton cache pour de bon

Taz> C'est tout à fait vrai. C'est pour cela que j'insiste sur le fait qu'il ne faut pas une mais plusieurs routines bien dédiées à certains types de copies.
Joel F> Non non, je t'assure, j'ai des résultats surprenants. Avant pour ces calculs, ils étaient fait en 32 bits via la FPU (pour un point en 8bits) car le CPU (ALU) n'était pas assez rapide. En MMX avec le MULADD ou le MUL ultra-rapide, le gain de temps est énorme. Et surtout le traîtement se fait en 4x16 bits ce qui est suffisant.
 
Premier résultat du test :
Sur un logiciel complet mais n'exploitant pas des copies très importantes (moins de 4Ko), je n'ai pas de gain comparé à la routine memcpy. Donc 0%. Il faut aussi souligner que la moitié des copies ont un overlap et doivent se faire en backward.
En cherchant bien, j'ai compris pourquoi (je m'en doutais déjà). Au-delà de 1Ko (selon le CPU), il est interressant de choisir la meilleure routine, mais en dessous, cela n'apporte rien, voire cela ralenti plus qu'autre chose.
Dans le programme de test, plus de la moitié des copies font moins de 256 octets. Et avec cette taille, je perds de la vitesse, mais je la retrappe sur les tailles supérieures à 1Ko.
 
Donc c'est pour l'instant un demi-échec, puisque j'ai déjà la solution. Reste à la développer.
La solution avec un CALL reste d'actualité uniquement sur les grosses copies (>1Ko). Pour le reste, la routine de copie se chargera de tout.
 
Il reste également un point interressant, c'est de déterminer cette barrière. Ainsi, on peut encore gratter des cycles tout en étant le plus efficace quelque soit le processeur.

 
oui mais chez moi 4x16 bits ca donne un Speedup theorique de x4
et je pense que ce que tu as mesuré c'eait plus les disparités d'UC que le gain SIMD

J'ai mesuré la vitesse globale de ma routine avant (FPU) et après (MMX).

est-ce que tu as une idée précise de ce qui faudrait connaître en terme de données contextuelle pour décider de la méthode la plus efficace à choisir?

Oui :
- A-t-on le droit de salir le cache L1/L2 ?
- Les données sources sont dans le L1, le L2 ou en RAM ?
- Les données cibles doivent-elles être dans le cache L1/L2 ou en RAM ?
- Overlap ?
- Alignement Source et Cible ?
 
Salir le cache L1/L2 :
Quand on veut copier des données sachant qu'elles se trouvent en RAM, il est interressant de salir le cache en préchargeant les lignes. Cela accèlère la copie x1,5 à x3.
 
Après analyse du source de memcpy de visual C.
Je pense que je vais laisser tomber la gestion de l'overlap et du mode backward-copy.  Dans bien des cas, l'overlap et le backward-copy c'est pour les petites données. Dans ces cas là, le memcpy est très bien conçu (même si on peut toujours faire mieux).
 
Donc je vais me concentrer plus sur l'alignement et le forward-copy. Pour limiter les tests et les combinaisons.

on peut donc imaginer que dynamiquement, l'os (voir même directement le cpu si c'est cablé) décide de la meilleur méthode à prendre

fais un bench avec un truc genre qsort je te dis, pour évaluer l'impact sur le cache. y a que ça de vrai.

Quel beau rêve.
C'est ce que je suis en train de réaliser puisque je travaille sur une machine virtuelle. Donc je saurais où se trouve les données et quel est la meilleure méthode à appliquer, où se trouve les données. J'en suis même arriver à faire de l'exécution-préemptive.

mais tu les choisis comment tes données contextuelles? empiriquement?
tu fais du rebouclage ou alors tu code tes règles de manière figée?

Taz> Oui, mais pour moi, le meilleur bench n'est pas un test dans un qsort ou une autre routine, le meilleur bench se fait pour les appli que je développe.
 
moktar1er> Toujours de façon contextuelle quand il s'agit du processeur virtuel et de façon figée quand c'est le code qui décide (appel d'une routine fixe).
De toute façon, le processeur virtuel à le droit de modifer les appels aux fonctions pour choisir la plus rapide suite à des stats d'exécution.

euh, je chipote, mais pour une copie avec overlap, c'est memmove, pas memcpy...

memcpy gère également l'overlap. Regarde le source.

oui, mais ça c'est pour les blaireaux. dans des vrais implémentations, on fourbe pour gagner un test

Taz> C'est sûr mais un test de gagné et la routine qui n'est plus conforme, c'est pas top.
Mieux vaut développer des routines avec des noms différents et bien explicites.

« The definition of certain C library routines such as memcpy contain the words: If copying takes place between objects that overlap, the behavior is undefined. »
 
et tu peux également te mettre profonds le reste de la section 7.1. Et revoir le prototype de memcpy

Lis bien cela... Microsoft est en contradiction avec le C ansi et lui-même :
 
Issu de la MSDN sur memcpy

 
Issu maintenant du source de memcpy.asm de visual c

 
Et maintenant, le plus marrant : (issu du source également memcpy.asm)

 
D'après les textes, la fonction est compliante avec la norme C ANSI. Mais d'après le code, profond oui il est ! puisque memcpy et memmove se partage le même code !!!

Microsoft, c'est quand même pas une référence dans le développement. Et puis taz a raison, historiquement, le memcpy sur des zones se recouvrant a un comportement indéfini. Tout au mieux, on produit un code qui ne sera pas portable en considérant qu'on peut utiliser indifféremment memmove ou memcpy parce que dans un runtime précis, il n'y a pas de différence. Vous me direz, c'est toujours bon pour l'hégémonie de microsoft. Surtout si l'on remarque que le memcpy de la glibc ne gère pas les zones se recouvrant...

je dirais surtout qu'on a inventé un mot clef spécialement pour

DocMaboul + Taz> Tout à fait !
 
Le problème c'est que de nombreux programmeurs Windows utilisent systématiquement memcpy, même s'il y a overlap.
Alors que memmove est là pour ça.

tu crois que j'ai une quelconque estime pour ces personnes ? restrict powa

Taz> C'est quand même eux qui font 99% des logiciels. Même sans respect, faut bien admettre qu'ils ne connaissent pas les rêgles et qu'il faut s'adapter.
 
C'est ce genre de programmeurs qui tuent la profession.

99% ?

 
Moi je suggère de suivre la norme Ansi et de séparer les deux. S'il y a deux fonctions, c'est bien pour une question de performances. Les programmeurs Windows qui ne font pas la différence ne font sans doute pas attention non plus aux écrasements mémoire qui pullulent dans leur code. De toute façon, ce n'est pas eux qui utiliseraient une librairie comme la tienne. Et ceux qui y sont intéressés, par contre, je suis sûr qu'ils font la différence entre memcpy et memmove.
Bref, ceux qui écrivent proprement, ce serait à eux de modifier leur code ?

Nuance, ceux qui programment sous Windows oublient de tester la création d'objets, oublient de les détruire (c'est pire !) croient qu'on fait un sizeof pour mesurer la longueur d'une chaîne, ne savent pas caster correctement, ont du mal avec les pointeurs, l'héritage, les threads... et programment en MFC (là, c'est vraiment pire !)
Quand je vois tout les progs que j'ai dû corriger et les erreurs commisent... Y a de quoi devenir fou. Ils pensent souvent que le métier de prog est un métier qui rapporte du fric et c'est pour cela qu'il le font ! Or c'est faux. C'est un métier comme un autre sauf qu'il faut se prendre la tête tous les jours, travailler sur des projets qui durent des mois ou des années...
 
Trêve. Je m'égare.
 
En fait, je fourni des fonctions "performantes" pour les sections critiques : manipulation d'objets lourds ou répétitifs... Dans le projet sur lequel je travaille, les appli construites doivent tourner aussi bien sur des machines à 400MHz que sur les monstres d'aujourd'hui.
 
Up> Les progs doivent tourner dans les écoles. C'est pas là où l'on trouve du matos performant !

Hum, je programme sous windows, et j'ose me permettre de préciser que je ne crois pas qu'on fait un sizeof pour mesurer la longueur d'une chaine, que je n'ai pas de mal avec les pointeurs, et je n'utilise pas le MFC. à part ça, étant donné que je n'ai jamais eu de cours de programmation et que j'ai appris par moi même, j'avoue que mes connaissances sont assez anarchiques et que je ne connais pas toutes les subtilités de l'héritage et que je n'ai qu'une vague notion de ce que sont les threads. En ce qui concerne les cast, je ne sais pas si je les fais correctement ou pas. Bref, je programme sûrement mal, mais ça n'a rien à voir avec le fait que je le fais sous windows : c'est juste que j'ai appris en vrac, j'aurais pu le faire avec un autre OS... Donc merci de ne pas traiter de con ceux qui programment sous windows, ils ne le sont pas tous (et je ne parle même pas forcément pour moi).

en tout cas, je pense pas que memcpy soit le point chaud d'une appli pédagogique.