En attendant notre tour, quand on pourra râler sur nos (petits) enfants qui dansent sur leur qubits, alors que tout de même, l'algèbre de Bool c'était mieux avant …
Je me suis permis d'ajouter à ce bench l'implémentation que je proposais dans mon commentaire, pour mettre en évidence l'impact du choix de la structure de donnée sur les perfs :
On constate (pour les paramètres donnés) que l'intuition initiale du rédacteur sur la version branchless se retrouve dans ce cas. L'écart de performances de la version branchless "avec multiplication" par rapport au autres versions se réduit avec une structure contiguë en mémoire.
Merci pour cette (longue) lecture avec une analyse complète et intéressante.
Je reste curieux de la raison du choix du type la structure pour la matrice, un std::vector<std::vector<int>> plutôt qu'un std::vector<int> de dimension lignes*colonnes, peut-être était-ce un choix délibéré pour la simplicité d'accès aux lignes/colonnes. Ça reste acceptable vu la contraire initiale de la taille de matrice d'ordre 10×10. Cela dis, si on cherche les meilleures performance possible, ce point n'est probablement pas négligeable et ce std::vector<std::vector<int>> me jette quelques grains de sable dans les yeux, pour plusieurs raisons :
* std::vector est un conteneur qui stocke les données de façon contiguë dans une zone mémoire allouée dynamiquement. Grossièrement, la structure est composée de trois pointeurs : début/fin de la zone allouée, et première "case" libre (ça peut varier selon l'implémentation)
* std::vector<std::vector<int>> est donc une structure qui pointe sur une zone allouée dynamiquement, qui elle contient des std::vector<int> qui chacun d'entre eux pointent sur d'autres zones allouées dynamiquement
* Il y a déjà un impact à l'initialisation, puisqu'il faudra allouer autant de zones que les dimensions de la matrice le nécessite (mais c'est hors benchmark ici)
* Il n'y a aucune garantie que toutes ces "petites zones" soie allouée de façon contiguë (c'est plutôt improbable), donc on augmente le risque de cache-miss
* Je ne m'étends pas sur le surcoût d'utilisation de mémoire induit par la structure
Je serais curieux de comparer ces résultats à ceux exploitant une représentation de la matrice dans une seule zone continue (par ex avec un std::vector<int>). J'aurais bien voulu ajouter un comparatif à ce commentaire, mais je ne vais malheureusement pas avoir le loisir de m'amuser avec ce problème dans les prochain temps.
Pas tout à fait : les crochets ne sont pas interprétés par le shell, mais font partie de la syntaxe des expressions régulières de grep. En l'occurence, gre[p] correspond au mot 'grep', comme gre[py] correspond aux mots grep ou grey. Ici les crochets évitent simplement à l'expression régulière d'être matchée dans les commandes de la liste des processus, puisque l'expression régulière n'est plus capable de se 'matcher' elle-même.
Je m'habitue au dvorak depuis pas mal de temps, et j'ai plutôt adopté la version dvorak-us, principalement parce que les chiffres sont accessible directement (pas besoin de pavé numérique, pratique quand on en a pas sur un portable, ou quand le bras est trop lourd pour l'envoyer à l'autre bout du clavier ...), et aussi pour l'accès rapide au symboles très utilisé en programmation ( parenthèses & cie ). Pour les accents, une petite modification de layout pour avoir tout les accents en touche morte. Je vais peut être essayer le BÉPO, qui doit être bien plus sympa pour taper en français !
Sinon, quand tu posteras tes impressions avec ce mappage, tu pourrais faire une évaluation selon le contexte dans lequel tu l'utilise ?
Et pour ceux pour qui tout ça est du chinois, le Dvorak est un clavier ergonomique spécialement adapté à la langue.
Vous je sais pas, mais personnellement, je préfère utiliser mes dix doigts !
[^] # Re: et si c'était ... l'évolution ?
Posté par n6p7 . En réponse au journal Je fais partie d'une espèce menacée d'extinction. Évalué à 3.
En attendant notre tour, quand on pourra râler sur nos (petits) enfants qui dansent sur leur qubits, alors que tout de même, l'algèbre de Bool c'était mieux avant …
[^] # Re: Quitte à faire du branchless
Posté par n6p7 . En réponse au journal Exercices de programmation et benchmarks. Évalué à 1.
Je me suis permis d'ajouter à ce bench l'implémentation que je proposais dans mon commentaire, pour mettre en évidence l'impact du choix de la structure de donnée sur les perfs :
http://quick-bench.com/lSIBctcUoFcxRNSssMJTMy93Zfg
On constate (pour les paramètres donnés) que l'intuition initiale du rédacteur sur la version branchless se retrouve dans ce cas. L'écart de performances de la version branchless "avec multiplication" par rapport au autres versions se réduit avec une structure contiguë en mémoire.
# Impact de la structure
Posté par n6p7 . En réponse au journal Exercices de programmation et benchmarks. Évalué à 6.
Merci pour cette (longue) lecture avec une analyse complète et intéressante.
Je reste curieux de la raison du choix du type la structure pour la matrice, un
std::vector<std::vector<int>>plutôt qu'unstd::vector<int>de dimensionlignes*colonnes, peut-être était-ce un choix délibéré pour la simplicité d'accès aux lignes/colonnes. Ça reste acceptable vu la contraire initiale de la taille de matrice d'ordre 10×10. Cela dis, si on cherche les meilleures performance possible, ce point n'est probablement pas négligeable et cestd::vector<std::vector<int>>me jette quelques grains de sable dans les yeux, pour plusieurs raisons :*
std::vectorest un conteneur qui stocke les données de façon contiguë dans une zone mémoire allouée dynamiquement. Grossièrement, la structure est composée de trois pointeurs : début/fin de la zone allouée, et première "case" libre (ça peut varier selon l'implémentation)*
std::vector<std::vector<int>>est donc une structure qui pointe sur une zone allouée dynamiquement, qui elle contient desstd::vector<int>qui chacun d'entre eux pointent sur d'autres zones allouées dynamiquement* Il y a déjà un impact à l'initialisation, puisqu'il faudra allouer autant de zones que les dimensions de la matrice le nécessite (mais c'est hors benchmark ici)
* Il n'y a aucune garantie que toutes ces "petites zones" soie allouée de façon contiguë (c'est plutôt improbable), donc on augmente le risque de cache-miss
* Je ne m'étends pas sur le surcoût d'utilisation de mémoire induit par la structure
Je serais curieux de comparer ces résultats à ceux exploitant une représentation de la matrice dans une seule zone continue (par ex avec un
std::vector<int>). J'aurais bien voulu ajouter un comparatif à ce commentaire, mais je ne vais malheureusement pas avoir le loisir de m'amuser avec ce problème dans les prochain temps.# Sans aller jusqu'aux permissions
Posté par n6p7 . En réponse au journal Si tu frottes la lampe, tu peux demander ce que tu veux. Évalué à 8.
Pour une app de ce genre, le premier élément qui m'alerte est
4.4.2-v8L53-0.[^] # Re: exclure grep
Posté par n6p7 . En réponse au message Programmation script shell ksh unix. Évalué à 4.
# Dvorak vs Dvorak
Posté par n6p7 . En réponse au journal Dvorak : Josselin Mouette VS Bépo (1 / N). Évalué à 8.
Sinon, quand tu posteras tes impressions avec ce mappage, tu pourrais faire une évaluation selon le contexte dans lequel tu l'utilise ?
Vous je sais pas, mais personnellement, je préfère utiliser mes dix doigts !