On Friday 30 August 2002 10:36, Marc SCHAEFER wrote: > PS: pour revenir � l'id�e de division enti�re et de modulo, il ne faut pas > oublier que beaucoup de processeurs ont une op�ration de division qui > fait les deux � la fois.
Et le r�sultat se trouve dans deux registres s�par�s ? > Je l'ai utilis� une fois pour gagner un > temps pr�cieux pour du RAID0 � multiple de 3 disques dans un > contr�leur hard, avec distribution par secteur (chunk_size = 1 > secteur). (la division pour conna�tre le num�ro physique du secteur, > le modulo pour conna�tre le num�ro du disque physique). (Ce qui suit n'est pas une r�ponse destin�e � Marc, mais une explication compl�metaire d'une technique souvent ignor�e mais tr�s pratique) Oui, tr�s pratique pour "packer" des valeurs dans un mot de N bits :-) Mais, en l'absence de preuves formelles, je pense que l'op�ration qui consiste � faire un d�calage de 8 bits (shift) devrait �tre traduite par une seule instruction CPU effectu�e en un seul cycle. Alors que la division est plus co�teuse; � moins que le compilateur d�tecte que la constant utilis�e est une puissance de deux et ne le transforme en �quivalent "shift". Certains CPU ont un instruction de division sur des entiers mais je doute que ce soit plus rapide qu'un "shift". Dans le cas qui nous int�resse, le modulo se r�sume � masquer les bits de poid fort. On peut donc �crire (pour deux valeurs de 16 bits � stoker dans un mot de 32 bits) unsigned int Source; ... Source = SectorNumber * 65536 + DiskNumber; /* (65536 == 2^16) */ ... DiskNumber = Source & (65536 -1 ); /* bits 0-15 */ SectorNumber = Source >> 16; /* bits 16-31 */ Mais cela est nettement moins lisible (sans doute plus lent) que : DiskNumber = Source % 65536; SectorNumber = Source / 65536; Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se d�sabonner aussi.
