Mot-clé - assembleur

Fil des billets - Fil des commentaires

02 sept. 2013

Racine d'un entier 64 bits non signé en C

Ce billet est un peu spécial, dans le sens ou je me contente de poster un morceau de code sans beaucoup de commentaires. J'ai écrit ce code récemment pour résoudre un problème un peu agaçant : calculer une racine carrée sur un nombre entier 64 bits.

Pour ceux qui se disent que le problème est simple (appeler la fonction sqrt() de la librairie C ou std::sqlt() de la librairie standard C++), je répond "oui, presque". Parce qu'un nombre non signé de 64 bits ne peut étre représenté correctement sur un double de 64 bits (sqrt() utilise le co-processeur arithmétique de votre x86). On peut utiliser un long double - mais dans ce cas, les performances sont désastreuses (parce que votre processeur n'a pas de registre générique travaillant en 80 bits).

Tout ça pour dire que la fonction ci-dessous peut aussi vous être utile (même si elle n'est pas parfaite : elle dépends principalement de la réponse à une devinette : quelle est la valeur de la racine carrée que je cherche ? Plus je sais répondre précisément à cette devinette, plus l'exécution est rapide).

Lire la suite...

25 fév. 2013

Programmation concurrente : le modèle de mémoire C++11

thread.jpg

Dans l'article précédent, on a pris contact avec ce qu'est la programmation concurrente, et comment elle était (grosso-modo) mise en oeuvre dans les systèmes d'exploitation récent. On a aussi parlé de primitives de synchronisation et de tout un tas de petites choses qui sont autant de concepts importants, nécessaires à une bonne compréhension du problème. Et dans ce cadre, la relation avec le standard C++11 a été mis de coté de manière explicite.

Cet article revient sur le C++11, mais d'une façon détournée : on va parler du modèle de mémoire mis en place par le standard.

Lire la suite...

05 janv. 2013

Micro-optimisations : booléens contre ensemble de drapeaux

Il y a quelque temps, un utilisateur de mon blog (alpha_one_x86) a proposé quelques sujets qui avait pour lui un intérêt. Certains sujets traitant de micro-optimisations - et étant moi même intéressé par ce type d'optimisation - j'ai décide de consacrer un premier billet à quelques petites explications touchant non pas au comment, mais au pourquoi.

Si vous avez des questions liées à ce type de sujet (ou si vous souhaitez que je discute d'autres micro-optimisations), n'ayez pas peur de me le faire savoir en postant un commentaire ici ou là (voir en me contactant).

Je vais quand même insister sur un point précis : je parle ici de micro-optimisation, c'est à dire d'optimisations dont l'impact sur les performances est très souvent négligeable. Il arrive de temps en temps qu'une telle optimisation offre un réel avantage, mais ces cas sont rares. Avant de mettre en pratique un des cas présenté ci-dessous, il convient de mesurer l'impact sur votre code et de peser le pour et le contre, notamment en terme de rapport gain/maintenance et gain/temps de développement.

Ne venez pas dire que je ne vous ai pas prévenu :)

Lire la suite...