VBA, VBS, finalement j'ai pas à me plaindre, y'en a qui sont plus mal lotis que moi.
VBA, VBS, finalement j'ai pas à me plaindre, y'en a qui sont plus mal lotis que moi.
Mais yasko t'es pas gentil: tu l'as tout cassé mon Troll.
Et puis le jour où tu me verras faire du vba/vbs, faudra me casser les jambes. C'est PowerShell ou rien pour l'administration.
On n'oublie pas comme ça 10 ans sur.... SCO Openserver (rire sardonique)...
Bon, on revient au topic de base ? Ca donne quoi si tu passes sur 16K au lieu de 1 ?
There are only 10 types of people in the world: Those who understand binary, and those who don't.
Je ne vois pas pourquoi ça changerait le nombre de transactions / seconde... Mon problème n'est vraiment pas un problème de débit (après tout on parle d'un débit nécessaire de l'ordre de 200 Mo/sec, je n'ose même pas imaginer que ce soit un souci sur un i7), mais bien d'être sûr que le producteur n'est pas trop ralenti.
Mais vu que j'y capte rien, ça ne veut rien dire
PS - Et de toute évidence si je passe à 16 ko sur mon exemple idiot ça demanderait 80 Go/s, et là je doute
Je fais peut etre du vba, mais moi, j'ai le vague souvenir de cours où on montrait que le context switching c'était le mal, qu'il fallait trouver la bonne balance entre la quantité de donnée à analyser par passe et la latence voulue: que plus tu augmentais le buffer avant de le traiter, plus tu augmentais la latence, mais que du coup plus il était grand, plus son rendement était meilleur.
Et que vu que tu balances 200Mo/sec, un buffer de 16K, ca ne représente que 0.000078 s de latence grosso modo.
Enfin, moi, ce que j'en dis, hein....
There are only 10 types of people in the world: Those who understand binary, and those who don't.
Relis bien ce que j'ai écrit : je me fous de la latence ; même si celle-ci atteignait une seconde, je m'en ficherais
En revanche clairement, je vais devoir faire un peu de tuning sur la taille des buffers synchronisés entre les threads, mais ça ne pourra se faire que sur la vraie appli, pas sur le code alacon que j'ai écrit.
There are only 10 types of people in the world: Those who understand binary, and those who don't.
Si tu t'en fous de la latence, alors tu peux mettre des gros buffers sans problème. Au pire tu pollues un peu de cache L3...
Pourquoi? À la louche, si on considère que la latence d'une transaction est constante et que ton code ne fait rien d'autre que des transactions, 6M transactions/s te donne 170ns d'overhead par transaction (temps que va passer ton simu à attendre le consommateur et à jouer avec des volatiles partagés).En revanche clairement, je vais devoir faire un peu de tuning sur la taille des buffers synchronisés entre les threads, mais ça ne pourra se faire que sur la vraie appli, pas sur le code alacon que j'ai écrit.
Si tu as 200Mo/s à faire passer, et n la taille d'un paquet, tu as 200M/n transactions à faire passer par seconde.
Avec des paquets de 34 octets ça te fait 100% d'overhead, avec des paquets de 16K tu as un overhead de 0,2%.
Ça veut dire que ça pourrait scaler idéalement jusqu'à 80 Go/s, donc que tu as de la marge
Je ne prends plus de café à cette heure-ci, sinon je vais devoir trouver quelqu'un sur qui frapper, et comme je suis en vacances, ça pourrait me causer des problèmes de couple
J'ai mis le double buffer dans le vrai code. La synchro se fait avec des volatiles. Le boulot fait sur les buffers est un bête dump binaire (cf. Write (2)), soit dans le thread pour le MT, soit dans le main pour le non-MT.
- pour 10k entrées de 16-bit; avantage mesurable pour le MT (~5%)
- pour 100k entrées; à peu près pareil
- au-delà; avantage à peine mesurable pour le non-MT (dans le bruit je dirais).
Holà s'pas du boulot, sinon j'aurais fait ça à la dure avec des centaines de Go de data... Ou pas vu que notre filer est tout le temps saturé...
En fait, j'ai transformé un truc que je faisais pour m'éclater à la maison, en un truc utile pour le boulot. L'est pas belle la vie ?