C'est vrai que c'est mieux de faire de l'asm inline ou pur asm, que des fonction intrinsics avec leur prolog, j'en suis pas fan.
Mais bon pour l'asm inline, j'ai un problème, c'est la lenteur de leur exécution, je sais pas pourquoi mais lorsque j'ai implémenté ma fonction rotate_matrix en inline, je suis descendu de -100 fps, bizarre :/
je sais pas si ça peut aidé, mais j'ai activé le parallélisme, enfin toutes les optimisations "possible" sur icl.
D'ailleurs je sais pas comment le compilateur peut paralléliser un programme oO
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 7 oct. 2014 à 09:40
Je n'utilise quasi jamais d'intrinsics pour calculs lourds.
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 5 oct. 2014 à 14:23
NON, on n'abandonne pas ni on ne tire de conclusions au 1er échec.
Insiste, je te promets qu'on peut mettre de 15 à 20 % dans la vue aux fonctions des compilos, tests faits avec celles de VS et ICC à chaque modif. Les fonctions intrinsèques à la FPU sont à classer au musée du siècle dernier, leur lenteur est affligeante.
C'est bon j'ai compris pourquoi intel n'appelle pas fsincos, dans optimization reference manual (intel doc), fsincos à 281 de latence alors que les instructions citée dans le code désassemblé, valent 2 à 6, par contre pour les antiques instruction: sub, and, cmp, j'ai pas vu.
ce code source de la fonction intrinsincs: sincos_ps_asm() ressemblant un peu au code decompilé:
Et il appel cette fonction a chaque appel de fonction sin() ou cos().
Etrange ..., sois il utilise une instruction non repertorié ou sois il le calcul manuellement .
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 3 oct. 2014 à 21:06
En open source, je n'ai jamais vu de fonctions trigo SIMD mais sait-on jamais... J'avoue ne pas être très doué pour les investigations sur le net.
Comme je fais dans les calculateurs, il est clair que j'ai mes biblis que je fais évoluer en suivant sortie des CPUs Intel. Pour l'instant elles sont au niveau SSE 4.2, je trouve que AVX2 n'apporte riien de significatif pour les calculs trigo.
UNE RUSE:
tu compiles un mini prog en C appelant sin(). En extraire le code sin() par décompilation ne devrait poser aucun probleme, idem pour les autres fonctions trigo. Fais en sorte de compiler avec ICC si possible car on peut lui indiquer le niveau SIMD voulu. Avec VS il faut placer "int __isa_available = 2;" avant les fonctions.
Cela fait, ne te restera qu'à virer les traitements d'erreur (errno et autres antiquites). Pour info, je retourne 0 quand expn du float est fullBits1 et basta.
7 oct. 2014 à 13:39
7 oct. 2014 à 12:41
7 oct. 2014 à 12:07
Comme ton sujet m'intéresse, on peut continuer par mail si tu veux.
monPseudoEnMinuscule AT outlook Point COM
Modifié par shaynox le 7/10/2014 à 10:29
Mais bon pour l'asm inline, j'ai un problème, c'est la lenteur de leur exécution, je sais pas pourquoi mais lorsque j'ai implémenté ma fonction rotate_matrix en inline, je suis descendu de -100 fps, bizarre :/
je sais pas si ça peut aidé, mais j'ai activé le parallélisme, enfin toutes les optimisations "possible" sur icl.
D'ailleurs je sais pas comment le compilateur peut paralléliser un programme oO
7 oct. 2014 à 09:40
Exemple prog de comparaison avec 2 boutons:
typedef struct _BNDT {
float (*pfunc) (float);
HWND hedT; // pour ticks resultants
HWND hlb; // listbox affichage resultats
} BNDT, *PBNDT;
dialogProc:
msgINITDIALOG:
...
bdt[0].hedT = GetDlgItem(hdlg, IDED_A);
bdt[1].hedT = GetDlgItem(hdlg, IDED_B);
bdt[0].hlb = GetDlgItem(hdlg, IDLB_A);
bdt[1].hlb = GetDlgItem(hdlg, IDLB_B);
bdt[0].pfunc = cosf;
bdt[1].pfunc = bnCosF;
return 1;
msgCOMMAND:
dwprm = (DWORD) wParam;
if(dwprm == IDCANCEL) goto dlgCLOSE;
if(dwprm < IDBT_A) goto zeroRET;
if(dwprm > IDBT_B) goto zeroRET;
tstACOSF(dwprm - IDBT_A);
return 0;
dlgCLOSE:
EndDialog(hdlg, 0);
return 0;
void tstCOSF(DWORD idx)
{
BYTE buf[56];
float flts[396], f;
UINT64 deb, fin;
int i;
PBNDT pdt = &bdt[idx];
SendMessage(pdt->hlb, LB_RESETCONTENT, 0, 0);
SendMessage(pdt->hlb, WM_SETREDRAW, 0, 0);
remplir396Flts(flts);
deb = __rdtsc();
for(i = 0; i < 396; i++) flts[i] = pdt->pfunc(flts[i]);
fin = __rdtsc();
fin -= deb;
*bnuqwtoa(fin, buf) = 0;
SetWindowText(pdt->hedT, buf);
// AFFICHAGE PERSO DANS LISBOX CORRESPONDANT AU BOUTON
buf[8] = 32;
for(i = 0; i < 396; i++) {
cDwToFullHex(*((DWORD*) &flts[i]), buf);
*bnFtoa(flts[i], buf + 9) = 0;
SendMessage(pdt->hlb, LB_ADDSTRING, 0, (LPARAM) buf);
}
SendMessage(pdt->hlb, WM_SETREDRAW, 1, 0);
SendMessage(pdt->hlb, LB_SETCURSEL, 0, 0);
}
7 oct. 2014 à 02:48
https://software.intel.com/en-us/forums/topic/530519?page=2#comment-1800623
Bon alors voilà, je sais plus quoi pensé :/
5 oct. 2014 à 21:16
5 oct. 2014 à 14:23
Insiste, je te promets qu'on peut mettre de 15 à 20 % dans la vue aux fonctions des compilos, tests faits avec celles de VS et ICC à chaque modif. Les fonctions intrinsèques à la FPU sont à classer au musée du siècle dernier, leur lenteur est affligeante.
5 oct. 2014 à 10:17
5 oct. 2014 à 10:04
Donc je garde la technologie FPU ^^.
Modifié par shaynox le 5/10/2014 à 07:28
ce code source de la fonction intrinsincs: sincos_ps_asm() ressemblant un peu au code decompilé:
code: https://github.com/mario007/renmas/blob/master/renmas3/asm/sincosps.py
Faut vraiment que je mette a jour sur les extensions ISA ^^
5 oct. 2014 à 05:30
Modifié par shaynox le 5/10/2014 à 05:43
( __libm_sse2_sincos) (grace a http://x64dbg.com trés bon débogueur )
J'ai envie de placer un no-comment, mais bon c'est made by intel donc je reste perplexe.
Modifié par shaynox le 5/10/2014 à 03:34
4 oct. 2014 à 17:58
Quand tu seras sans aucune dépendance alors le code sera dans l'exe par force.
4 oct. 2014 à 17:49
J'ai a peu prés les même option, j'utilise vs2013.
4 oct. 2014 à 10:02
Avec ICC, je compile fichier C ainsi depuis un build.bat :
@set optCL=/Gs9999999 /c /nologo /Ox /QxSSE4.2 /EHc /Qftz- /wd266 /Gy /WX- /MP /Qsafeseh- /W3 /GF /GS- /GR- /TC /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /Fo"%dirOUT%\"
@%dirINTL%icl.exe %optCL% %DirProj%%NAME%.c
3 oct. 2014 à 21:40
Merci
Modifié par shaynox le 3/10/2014 à 21:42
call __libm_sse2_sincos (intel compiler)
Et il appel cette fonction a chaque appel de fonction sin() ou cos().
Etrange ..., sois il utilise une instruction non repertorié ou sois il le calcul manuellement .
3 oct. 2014 à 21:06
Comme je fais dans les calculateurs, il est clair que j'ai mes biblis que je fais évoluer en suivant sortie des CPUs Intel. Pour l'instant elles sont au niveau SSE 4.2, je trouve que AVX2 n'apporte riien de significatif pour les calculs trigo.
UNE RUSE:
tu compiles un mini prog en C appelant sin(). En extraire le code sin() par décompilation ne devrait poser aucun probleme, idem pour les autres fonctions trigo. Fais en sorte de compiler avec ICC si possible car on peut lui indiquer le niveau SIMD voulu. Avec VS il faut placer "int __isa_available = 2;" avant les fonctions.
Cela fait, ne te restera qu'à virer les traitements d'erreur (errno et autres antiquites). Pour info, je retourne 0 quand expn du float est fullBits1 et basta.
Bon taf.
Modifié par shaynox le 3/10/2014 à 18:54
3 oct. 2014 à 18:12
ROUNDPS xmm0, xmm1/mem128, imm8
Arrondir, tronquer, ...
Tant que tu auras les calculs trigo en FPU, adieu vitesse.
Bonne continuation.
3 oct. 2014 à 16:47
3 oct. 2014 à 16:12