Est la multiplication et la division à l'aide d'opérateurs de décalage dans C vraiment le plus rapide?

Réponse courte: Pas probable.

Réponse longue:
Votre compilateur a un optimiseur qui sait se multiplient aussi vite que votre cible de l'architecture du processeur est capable. Votre meilleur pari est de dire au compilateur de votre intention clairement (c'est à dire i*2 plutôt que i << 1) et le laisser décider de ce que la manière la plus rapide de montage/code machine de la séquence. Il est même possible que le processeur lui-même a mis en œuvre les multiplier instruction comme une séquence de changements & ajoute dans microcode.

Ligne de fond-ne pas passer beaucoup de temps à se préoccuper de cela. Si vous voulez dire à la maj, maj. Si vous voulez dire à se multiplier, à se multiplier. Faire ce qui est sémantiquement plus clair--vos collègues vous en seront reconnaissantes. Ou, plus probablement, vous maudissent, plus tard, si vous faites le contraire.

En plus de toutes les autres bonnes réponses ici, permettez-moi de souligner une autre raison de ne pas utiliser la touche maj enfoncée lorsque vous signifie diviser ou multiplier. Je n'ai jamais vu une fois à quelqu'un de présenter un bug par l'oubli de la priorité relative de multiplication et d'addition. J'ai vu les bugs introduits lors de l'entretien les programmeurs ont oublié que le "multiplier" via une maj est logiquement une multiplication, mais pas syntaxiquement de la même priorité que la multiplication. x * 2 + z et x << 1 + z sont très différents!

Si vous travaillez sur numéros de puis utiliser des opérateurs arithmétiques comme + - * /%. Si vous travaillez sur des tableaux de bits, utilisez peu tourner les opérateurs comme & ^ | >> . Ne pas les mélanger; une expression qui est à la fois peu tripoter et de l'arithmétique est un bug en attente de se produire.

Est-il réellement plus rapide à utiliser-dire (i<<3)+(i<<1) à multiplier par 10 que l'utilisation de i*10 directement?

Il pourrait ou ne pourrait pas être sur votre ordinateur - si vous vous souciez, la mesure dans votre usage du monde réel.

Une étude de cas - à partir de 486 core i7

L'analyse comparative est très difficile de le faire de façon significative, mais nous pouvons regarder un peu les faits. De http://www.penguin.cz/~literakl/intel/s.html#SAL et http://www.penguin.cz/~literakl/intel/je.html#IMUL nous avons une idée de x86 cycles d'horloge nécessaires pour le décalage et la multiplication. Dis nous en tenir à "486" (la dernière de la liste), 32 bits des registres et immédiates, IMUL prend 13-42 cycles et IDIV 44. Chaque SAL prend 2, et en ajoutant 1, de sorte que même avec un peu de ceux-ensemble décalage superficiellement ressemble à un gagnant.

Ces jours-ci, avec le core i7:

(à partir de http://software.intel.com/en-us/forums/showthread.php?t=61481)

Le temps de latence est 1 cycle pour un entier plus et 3 cycles pour un entier multiplication. Vous pouvez trouver des latences et des thoughput à l'Annexe C de la "Intel® 64 et IA-32 Optimisation des Architectures Manuel", qui est situé sur http://www.intel.com/products/processor/manuals/.

(de certains Intel blurb)

À l'aide de l'ESS, le Core i7 peut émission simultanée d'ajouter et multiplier les instructions, résultant en un taux maximal de 8 opérations à virgule flottante (le FLOP) par cycle d'horloge,

Qui vous donne une idée de la façon dont beaucoup choses ont. L'optimisation de trivia - comme le décalage de bits contre * - qui a été pris au sérieux, même dans les années 90 est juste aujourd'hui obsolète. De décalage de bits est encore plus rapide, mais pour les non-puissance de deux mul/div par le temps de vous faire tous vos déplacements et ajouter les résultats, il est encore plus lent. Alors, plus d'instructions signifie plus de défauts de cache, plus les problèmes potentiels dans le pipelining, plus d'utilisation de ces registres peut signifier plus de sauvegarde et restauration du contenu du registre à partir de la pile... ça devient vite trop compliqué de quantifier tous les impacts définitivement, mais ils sont essentiellement négatifs.

fonctionnalité dans le code source vs la mise en œuvre

Plus généralement, votre question est balisé le C et le C++. En tant que 3e génération langues, s'ils sont spécifiquement conçus pour cacher les détails de la sous-jacentes du PROCESSEUR à jeu d'instructions. Pour satisfaire leur langue les Normes, ils doivent soutenir la multiplication et le déplacement des opérations (et beaucoup d'autres) même si le matériel sous-jacent n'est pas. Dans de tels cas, ils doivent synthétiser le résultat requis à l'aide de beaucoup d'autres instructions. De même, ils doivent fournir le logiciel de soutien pour les opérations à virgule flottante si le CPU n'en a pas et il n'y a pas de FPU. Les Processeurs modernes supportent tous * et <<, donc cela peut sembler absurde théoriques et historiques, mais l'importance c'est que la liberté de choisir la mise en œuvre va dans les deux sens: même si le CPU a une instruction qui met en œuvre l'opération demandée dans le code source dans le cas général, le compilateur est libre de choisir quelque chose d'autre qu'il préfère parce que c'est mieux pour la spécifiques cas, le compilateur est confronté à.

Exemples (avec un hypothétique langage d'assemblage)

source           literal approach         optimised approach
#define N 0
int x;           .word x                xor registerA, registerA
x *= N;          move x -> registerA
                 move x -> registerB
                 A = B * immediate(0)
                 store registerA -> x
  ...............do something more with x...............

Instructions ou-exclusif (xor) n'ont aucun rapport avec le code source, mais xor-ing quoi que ce soit avec lui-même efface tous les bits, de sorte qu'il peut être utilisé pour définir quelque chose à 0. Le code Source qui implique des adresses de mémoire ne peut aboutir à être utilisé.

Ce genre de hacks ont été utilisés aussi longtemps que les ordinateurs ont été autour. Dans les premiers jours de 3GLs, pour sécuriser le développeur de l'absorption de la sortie du compilateur a dû satisfaire de l'existant hardcore de la main-optimisation de la langue de l'assembly dev. de la communauté que le code produit n'est pas plus lent, plus détaillé ou sinon pire. Les compilateurs ont rapidement adopté beaucoup d'optimisations - ils devenu un meilleur centralisée magasin de il de toute assemblée de la langue programmeur pourrait éventuellement être, mais il y a toujours la chance qu'ils manquent un précis d'optimisation qui se trouve être essentiel dans un cas particulier - les humains peuvent, parfois, de noix et de tâtonner pour quelque chose de mieux alors que les compilateurs il suffit de faire comme ils ont dit jusqu'à ce que quelqu'un se nourrit que de l'expérience en retour.

Donc, même si le décalage et l'ajout est encore plus rapide sur certains matériels, alors le compilateur de l'écrivain susceptibles d'avoir travaillé exactement quand il est à la fois bénéfiques et sans danger.

Maintenabilité

Si vos modifications sur le matériel, vous pouvez recompiler et il va chercher à le PROCESSEUR cible et de faire un autre choix, alors que vous avez peu de chances de jamais vouloir revoir votre "optimisations" ou à la liste qui compilation environnements doivent utiliser la multiplication et de la qui devrait passer. Pensez à tous les non-puissance de deux bits décalés "optimisations" écrite de 10 ans qui sont maintenant en train de ralentir le code qu'ils sont en mesure de l'exécution sur les processeurs modernes...!

Heureusement, de bons compilateurs comme GCC peut généralement remplacer une série de bitshifts et de l'arithmétique avec un direct de multiplication lorsque aucune optimisation est activée (c'est à dire ...main(...) { return (argc << 4) + (argc << 2) + argc; } -> imull $21, 8(%ebp), %eax) donc une recompilation peut aider, même sans en fixer le code, mais ce n'est pas garanti.

Étrange bitshifting d'application du code de la multiplication ou de la division est beaucoup moins expressif de ce que vous étiez sur le plan conceptuel essaie de l'atteindre, de sorte que les autres développeurs seront confus par ce, et un confus programmeur est plus susceptible d'introduire des bogues ou de supprimer quelque chose d'essentiel dans un effort pour restaurer semblant de santé mentale. Si vous ne le faites non évidente des choses quand ils sont vraiment, de façon tangible, bénéfique, et document bien (mais ne faites pas de document d'autres trucs qui sont de toute façon intuitive), tout le monde sera plus heureux.

Solutions générales rapport à des solutions partielles

Si vous avez quelques connaissances supplémentaires, tels que votre int ne sera véritablement en stockant les valeurs x, y et z, alors vous pourriez être en mesure de travailler des instructions de travail pour ces valeurs et vous obtenez votre résultat plus rapidement que lorsque le compilateur n'a pas cette idée et a besoin d'une mise en œuvre qui fonctionne pour tous les int valeurs. Par exemple, pensez à votre question:

De Multiplication et de division peut être réalisé en utilisant des bits les opérateurs...

Vous illustrer la multiplication, mais combien de division?

int x;
x >> 1;   //divide by 2?

Selon la Norme C++ 5.8:

-3 - La valeur de E1 >> E2 E1 décalés vers la droite E2 positions de bits. Si E1 est un type non signé ou si E1 a un type signé et un non négatif, la valeur du résultat est la partie entière du quotient de E1, divisée par la quantité 2 élevé à la puissance de l'E2. Si E1 a signé un type et une valeur négative, la valeur résultante de la mise en œuvre est définie.

Donc, votre de décalage de bits a une mise en œuvre définies résultat lorsque x est négatif: il ne peut pas travailler de la même façon sur des machines différentes. Mais, / fonctionne beaucoup plus prévisible. (Il ne peut pas être parfaitement cohérente, car les différentes machines peuvent avoir différentes représentations des nombres négatifs, et donc les différentes gammes, même quand il y a le même nombre de bits qui composent la représentation.)

Vous pouvez dire "je n'aime pas... que int est le stockage de l'âge de l'employé, il ne peut jamais être négatif". Si vous avez ce genre de perspicacité particulière, alors oui, votre >> sûr d'optimisation peut être passé par le compilateur, sauf si vous explicitement le faire dans votre code. Mais, c'est risqué et rarement utile car la plupart du temps vous n'aurez pas ce genre d'information, et d'autres programmeurs travaillant sur le même code ne saurez pas que vous avez pari de la maison à certaines des attentes des données vous serez manipulation... ce qui semble totalement sûr pour le changement pourrait se retourner contre à cause de votre "optimisation".

Est-il une sorte d'entrée qui ne peut pas être multiplié ou divisé de cette manière?

Oui... comme mentionné ci-dessus, les nombres négatifs ont définie par l'implémentation du comportement lors de l' "divisé" par décalage de bits.

Le déplacement est généralement beaucoup plus rapide que de multiplier au niveau de l'instruction mais vous pouvez très bien être en train de perdre votre temps à faire prématurée des optimisations. Le compilateur peut très bien réaliser ces optimisations au compile-time. Le faire vous-même permettra d'affecter la lisibilité et peut avoir aucun effet sur les performances. C'est probablement la peine de faire des choses comme ça si vous avez le profil trouvé ceci pour être un goulot d'étranglement.

En fait la division truc, connu comme "la magie de la division" peut effectivement générer d'énormes profits. Nouveau profil pour voir si c'est nécessaire. Mais si vous ne l'utilisez il y a des programmes utiles autour de vous pour vous aider à comprendre ce besoin d'instructions pour la même division de la sémantique. Voici un exemple : http://www.masm32.com/board/index.php?topic=12421.0

Un exemple que j'ai soulevé le cas des OP fil sur MASM32:

include ConstDiv.inc
...
mov eax,9999999
; divide eax by 100000
cdiv 100000
; edx = quotient

Générerait:

mov eax,9999999
mov edx,0A7C5AC47h
add eax,1
.if !CARRY?
    mul edx
.endif
shr edx,16

Il dépend entièrement sur le périphérique cible, la langue, objet, etc.

Pixel croquant dans un pilote de carte vidéo? Très probablement, oui!

.NET business application pour votre département? Absolument aucune raison même de le regarder.

Pour une haute performance de jeu pour un appareil mobile, il pourrait être utile dans la recherche, mais seulement après que plus facile optimisations ont été effectuées.

Autant que je sais que dans certaines machines de multiplication peuvent avoir besoin de jusqu'à 16 à 32 cycle de la machine. Donc Oui, selon le type de machine, bitshift opérateurs sont plus rapides que la multiplication ou la division.

Cependant, certaines machines ont leurs mathématiques processeur, qui contient des instructions pour la multiplication ou la division.

Dans le cas des entiers signés et décalage à droite vs division, il peut faire une différence. Pour les nombres négatifs, le changement des tours de tours vers l'infini négatif alors que les cycles de division vers zéro. Bien sûr, le compilateur va changer la division de quelque chose de moins cher, mais il sera généralement le changer pour quelque chose qui a le même comportement d'arrondissage de division, parce qu'il est incapable de prouver que la variable ne sera pas négatif ou il n'a tout simplement pas de soins.
Donc, si vous pouvez prouver qu'un certain nombre ne sera pas négatif, ou si vous n'aimez pas la façon de les arrondir, vous pouvez faire de l'optimisation d'une manière qui est plus susceptible de faire une différence.

Il y a des optimisations du compilateur ne peut pas le faire parce qu'ils ne fonctionnent que pour un ensemble réduit de données.

Ci-dessous, il est en c++ exemple de code qui peut faire plus rapide de la division de faire un 64bits "Multiplication par l'inverse". Le numérateur et le dénominateur doivent être en dessous d'un certain seuil. Notez qu'il doit être compilé en 64 bits instructions pour être effectivement plus rapide que la normale de la division.

#include <stdio.h>
#include <chrono>
static const unsigned s_bc = 32;
static const unsigned long long s_p = 1ULL << s_bc;
static const unsigned long long s_hp = s_p / 2;
static unsigned long long s_f;
static unsigned long long s_fr;
static void fastDivInitialize(const unsigned d)
{
s_f = s_p / d;
s_fr = s_f * (s_p - (s_f * d));
}
static unsigned fastDiv(const unsigned n)
{
return (s_f * n + ((s_fr * n + s_hp) >> s_bc)) >> s_bc;
}
static bool fastDivCheck(const unsigned n, const unsigned d)
{
//32 to 64 cycles latency on modern cpus
const unsigned expected = n / d;
//At least 10 cycles latency on modern cpus
const unsigned result = fastDiv(n);
if (result != expected)
{
printf("Failed for: %u/%u != %u\n", n, d, expected);
return false;
}
return true;
}
int main()
{
unsigned result = 0;
//Make sure to verify it works for your expected set of inputs
const unsigned MAX_N = 65535;
const unsigned MAX_D = 40000;
const double ONE_SECOND_COUNT = 1000000000.0;
auto t0 = std::chrono::steady_clock::now();
unsigned count = 0;
printf("Verifying...\n");
for (unsigned d = 1; d <= MAX_D; ++d)
{
fastDivInitialize(d);
for (unsigned n = 0; n <= MAX_N; ++n)
{
count += !fastDivCheck(n, d);
}
}
auto t1 = std::chrono::steady_clock::now();
printf("Errors: %u /%u (%.4fs)\n", count, MAX_D * (MAX_N + 1), (t1 - t0).count() / ONE_SECOND_COUNT);
t0 = t1;
for (unsigned d = 1; d <= MAX_D; ++d)
{
fastDivInitialize(d);
for (unsigned n = 0; n <= MAX_N; ++n)
{
result += fastDiv(n);
}
}
t1 = std::chrono::steady_clock::now();
printf("Fast division time: %.4fs\n", (t1 - t0).count() / ONE_SECOND_COUNT);
t0 = t1;
count = 0;
for (unsigned d = 1; d <= MAX_D; ++d)
{
for (unsigned n = 0; n <= MAX_N; ++n)
{
result += n / d;
}
}
t1 = std::chrono::steady_clock::now();
printf("Normal division time: %.4fs\n", (t1 - t0).count() / ONE_SECOND_COUNT);
getchar();
return result;
}