Optimisation des ruptures du pipeline - Page 3

je viens de tomber la dessus (a propos de l'ARMv7 Cortex A9 (utilise dans entre autres les PlayStation-Vita et i-trucs/tablettes)
dans le genre "effets de bords sournois" c'est pas mal

Since the Branch Target Address Cache (BTAC) is based on 16-byte sizes and only allows 2 branches per line, if any code has more than 2 branches within 16-bytes of code, then it is likely to flush the instruction pipeline.

Oh ben ça va encore, ça n'impacte que les perfs, je connais des bugs hardware bien plus méchants que ça

sur les PIC, par exemple

heureusement qu'il n'y en a pas sur la psvita

?
quel genre de bug HW?

tiens ca me rappelle des instructions deconseillees sur certaines consoles parcequ'elles sont "unreliable"

c'est pas toujours au niveau des instructions, le core est quasi identique sur toute cette famille de microcontroleurs (des 8 bits, c'est plutot fait pour piloter des mécanismes, style device usb et al ), c'est plutot sur des périphériques qui suivent pas les specs ou qui marchent carrément mal (style une uart qui envoie pas le bit de start, une pin qui suce du courant 3x plus que ce que dit la datasheet, etc enfin j'invente)

sur celui que je comptais utiliser là, ils nous disent, dans certains cas rares, l'instruction au vecteur de reset n'est pas exécutée. Sachant qu'en général c'est un GOTO MAIN , et que c'est la seule instruction à cet endroit, après y'a le vecteur d'interruption, alors ils nous conseillent de mettre un NOP devant, comme ça si il passe à l'as tant pis, et le goto qui suit sera toujours exécuté
là heureusement y'a un workaround, mais des fois tu l'as carrément dans l'os

exemple pour ce PIC 18F1320 http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010265

y'a l'errata : http://ww1.microchip.com/downloads/en/DeviceDoc/80244d.pdf (erratas différents pour les différentes versions du silicon bien sûr , ah tiens là si, y'a l'instruction DAW qui foire, et l'UART qui fait mal l'autobaud )

ils ont vraiment pas l'air de connaitre les outils de gestion de conf, les tests automatisés de validation et les outils de suivis de bugs.

que veux tu, on peut pas mettre un chip dans svn, que du soft

pas grand chose a voir mais jsuis tombe la dessus hier et ca m'a bien fait marrer
http://www.shervinemami.info/NEON_RotateBGRX.swf

le mec ecrit un tuto d'optim, et apres sur son site fait des bench et dit que son code qui rox est trop trop rapide et tout...
alors qu'il passe a cote d'un truc simplissime qui lui permettrait de virer 8 instructions dans son rotate SIMD qui en fait 12
meme notre graphiste qui scripte l'a vu

faut connaitre le jeu d'instructions disponible déja

j'ai l'impression que le mec a passé plus de temps à faire son swf que son algo

bah nan meme pas besoin...

il loade chaque ligne de la matrice 4x4 dans un vecteur 128 bits

ensuite il fait:

transpose(q0, q1, q2, q3) (4 instructions)
mirror(q0, q1, q2, q3) (8 instructions)

pour rotate la matrice.

transpose + mirror horizontal, c'est pareil que mirror vertical + transpose.

y a juste a faire:

transpose(q3, q2, q1, q0)


.......

et voilà, maintenant t'es obligé de faire un swf pour lui expliquer

pour revenir aux optimisations, quand tu tombes sur ton cas a=b, b=a pondu par l'optimisation, tu remplaces ça par #asm #endasm ?

Pas dit que ça suffise, il a déjà posté un exemple magnifique où VC++ avait désoptimisé du code ASM fait à la main

vince> bah le probleme des blocs asm {} comme ca, c'est que ca interagit mal avec le code autour.

non mais la en gros le truc dans videz votre presse papier ou il stockait le registre sur la stack pour le reloader juste apres, c'etait genere par ce code la:

		SIMD::Float4	d =	lerp4(wwww, lerp4(vvvv, lerp4(uuuu, noise->m_Gradients[aa + 0],
									    noise->m_Gradients[ba + 0]),
								lerp4(uuuu, noise->m_Gradients[ab + 0],
									    noise->m_Gradients[bb + 0])),
						    lerp4(vvvv, lerp4(uuuu, noise->m_Gradients[aa + 1],
									    noise->m_Gradients[ba + 1]),
								lerp4(uuuu, noise->m_Gradients[ab + 1],
									    noise->m_Gradients[bb + 1])));

en le changeant en ca:

		SIMD::Float4	gaa0(noise->m_Gradients[aa + 0]);
		SIMD::Float4	gaa1(noise->m_Gradients[aa + 1]);
		SIMD::Float4	gba0(noise->m_Gradients[ba + 0]);
		SIMD::Float4	gba1(noise->m_Gradients[ba + 1]);

		SIMD::Float4	gaa0gba0 = lerp4(uuuu, gaa0, gba0);
		SIMD::Float4	gaa1gba1 = lerp4(uuuu, gaa1, gba1);

		SIMD::Float4	gab0(noise->m_Gradients[ab + 0]);
		SIMD::Float4	gab1(noise->m_Gradients[ab + 1]);
		SIMD::Float4	gbb0(noise->m_Gradients[bb + 0]);
		SIMD::Float4	gbb1(noise->m_Gradients[bb + 1]);

		SIMD::Float4	gab0gbb0 = lerp4(uuuu, gab0, gbb0);
		SIMD::Float4	gab1gbb1 = lerp4(uuuu, gab1, gbb1);

		SIMD::Float4	d =	lerp4(wwww, lerp4(vvvv, gaa0gba0, gab0gbb0),
						    lerp4(vvvv, gaa1gba1, gab1gbb1));

il est moins perdu, et ya plus le pbl (bon yen a d'autres, mais ils etaient quand meme la dans la version d'avant aussi )

le truc relou avec les blocs asm aussi, c'est que la ca builde sur PC/32 bits SSE, PC/64 bits SSE, Playstation3/PPU, Playstation3/SPU, Xbox360/Xenon, PsVita/ARM-NEON, et tablettes WinRT/ARM-NEON...
pour implementer ca a la main en ASM pour chacune de ces plateformes, ca serait inmaintenable, surtout qu'il y plusieurs centaines d'endroits comme ca :/

c'est des soucis avec le code qui génère les expressions, donc en lui mâchant le travail ça passe mieux, hmm?

j'ai déja vu ça aussi.

sur ma plate forme on a un PRNG avec une formule un peu velue, pour la générer le compilo utilise un max de tmp, alors qu'en décomposant les opérations, ça passe parfaitement avec juste 2 variables locales ^^


./70 en effet c'est ridicule

squalyl > c'est du PIC ?

J'ai fait une routine de CRC32 dessus, et c'est pareil, le code ASM fait main était ~3.5x plus rapide que ce que générait le compilo C.

ouep, pic18.

on a un crc16 aussi, je suis pas allé voir les détails, mais pour un autre projet perso qui utilisait le même crc, je l'ai codé en asm et c'était pas la mort.
mais je pense que c'est pas trop dégueu parce qu'il est codé en termes d'une suite d'opération A = A op truc, le pic s'en sort pas trop mal.