Comparaison de deux byte

Bonjour,

je souhaiterai comparer 2 byte de la façon la PLUS RAPIDE possible !

Le souci en java, c'est que nous n'avons pas des "unsigned", donc les byte sont codés sur [-128, 127].
Lorsque je veux comparer, je ne peux donc pas faire Math.max((int)b1, (int)b2), car la valeur 255 en int est négative en byte :mur:

Donc quelle est la façon la plus rapide de comparer deux byte ?

J'ai ces deux possibilités, mais j'espère qu'il y a plus rapide car je dois vraiment aller au plus vite :
- Math.max(b1 & 0xFF , b2 & 0xFF)
- Math.max(0<=b1?b1:256f+b1, 0<=b2?b2:256+b2)

EDIT : pas compris qu'il s'agissait d'une comparaison bit à bit...
J'excluerai donc le bit du signe par un mask ...

Citation:

---

Envoyé par Nemek

J'exclurai donc le bit du signe par un mask ...

---

C'est-à-dire ?

Citation:

---

Envoyé par ToTo13

J'ai ces deux possibilités, mais j'espère qu'il y a plus rapide car je dois vraiment aller au plus vite :
- Math.max(b1 & 0xFF , b2 & 0xFF)

---

À mon humble avis c'est déjà très rapide.
Pour faire encore plus rapide, il faudrait manipuler des int au lieu de bytes depuis le début (en s'assurant lors de la création des données, qu'ils ne sortent pas du range 0 <= int < 256).
Possible aussi que ça le fasse avec des short, pour économiser de la mémoire

Citation:

---

Envoyé par thelvin

À mon humble avis c'est déjà très rapide.
Pour faire encore plus rapide, il faudrait manipuler des int au lieu de bytes depuis le début (en s'assurant lors de la création des données, qu'ils ne sortent pas du range 0 <= int < 256).
Possible aussi que ça le fasse avec des short, pour économiser de la mémoire

---

Ben justement, c'est l'appliquer à comparaison en pixel d'un BufferedImage. Lorsque je travaille sur des images en niveaux de gris [0,255], c'est forcément des byte derrière.
Certaines images couleurs sont codées sur des int, mais d'autres le sont encore sur des byte.

D'où mon souci pour comparer AU PLUS VITE des byte. Je ne souhaite pas du "très rapide", mais LE PLUS rapide. Car c'est pour avoir des performances très particulière sur un algo.

a mon avis, le bit de signe est a prendre en consideration, mais comme un bit significatif et non un bit de signe.

Pour faire de la comparaison bit a bit, rien de tel que l'assembleur (java n'a pas ete fait pour ca il me semble...) donc la solution pour que ton calcul soit le plus rapide possible serait de passer par du jni. Mais ton temps d'acces au calcul (travercer la conche jni / c / asm) risque de ne pas te faire gagner enormement au final. A moins de regrouper des series de comparaison.

en fonction du nombre de comparaisons a faire tu peu aussi passer par des int (qui permettent la valeur 256). ta comparaisson sera rapide, mais le passage prendra du temps. tout depend des comparaisons que tu fait sur une variable.

Code:

---

1 2 3 4 5 6 7 8

//renvoi la valeur (integer) d'un byte, non signe int bv(byte b){ int out = b; if(b<0) out=out+256; return out; }

---

enfin en fonction des cas, tu peu traiter lemsb (bit de signe) puis le reste, si le msb suffi a determiner qui est le plus grand ca ira vite, sinon non...

Edit : dans le cas des images, en fonction de tes contraintes (multiplatforme?)ca peut etre interessant de passer par du jni. Et d'y mettre toute la procedure critique.

Je me suis demandé un moment si une méthode qui fasse la séparation des cas en fonction du signe n'irait pas plus vite, mais après quelques tests la solution avec "& 0xFF" est la plus rapide.

j'ai fait quelques tests pour comparrer les methodes... voici mes premiers resultats. Le bute est pas de donner une valeur temporelle mais etablire un ordre de grandeur du travail necessaire pour la comparaison, et ce avec differentes methodes. Ici je comparre deux tableau de 1200*1600. Soit 1920000 comparaisons. Les temps sont donné par comparaison (t/1920000)
Les premiers resultats sont obtenu lors de le premiere execution du code (donc sans jit ou presque). Les second resultats sont obtenu avec jit (probablement, peut on en etre sur en java?). le tout avec une jvm 64b.

- la valeur base correspond au temp de referance (appel, boucle... pas de comparaison )

- la valeur byte correspond a la meme boucle avec la comparaison

Code:

---

result = Math.max(bt1[i] & 0xFF , bt2[i] & 0xFF);

---

- la valeur int correspond a la meme boucle avec la comparaison

Code:

---

result = Math.max(it1[i],it2[i]);

---

- la valeur cint correspond a la meme boucle avec la comparaison

Code:

---

1 2 3 4 5

if(it1[i]<it2[i]) result =it2[i]; else result =it1[i];

---

Note : la convertion de la table byte vers int,n'est pas pris en compte dans les resultats.

base 0.4643557291666667ns
byte 1.9922109375ns
int 1.480859375ns
cint 1.3644703125ns

apres un passage ...

base 0.0155984375ns
byte 0.12138854166666667ns
int 0.030397395833333334ns
cint 0.037596354166666665ns

En principe, une extension suivie d'un bitwise-AND devrait être plus rapide qu'un compare suivi de jne suivi d'extension suivi d'addition, sur n'importe quel processeur.

Donc la méthode b1 & 0xFF devrait être la plus rapide partout.
En principe.

dès que vous faites: b & 0xFF, vous faites une promotion de votre byte en int, car 0xFF c'est un int en java! CA ne devrais pas être catastrophique car la promotion se fera via les registres de toutes façons plus gros que 8 bits ;)

Pour savoir comment se comporte votre test avec JIT, il faut faire tourner votre test en boucle, indiquer chaque résultat de mesure et observer la stabilisation (en général une dixaine de runs est suffisant)

alternative à tenter:

Code:

---

1 2	//a < b? a<0?a>b:a<b; // la logique est inversée pour les nombres <0

---

Bonjour,

j'ai fait des tests et c'est bien en utilisant 0xFF que j'obtiens les meilleurs performances.

Merci !

accesoirement, pour avoir une bonne idée des perfs, un coup d'oeil au code généré (language machine java) pourrait etre utile :p

Euh il s'agissait pas d'une comparaison bit à bit :question:

Citation:

---

Envoyé par tchize_

alternative à tenter:

Code:

---

1 2	//a < b? a<0?a>b:a<b; // la logique est inversée pour les nombres <0

---

---

Ça ne fonctionne pas, car il faut aussi tenir compte du fait que b peut être négatif.
Si a est positif et b négatif, b est dans ce cas plus grand que a ...

ha ben oui, avais écrit à la va vite :p Du coup l'expression risque vite de devenir illisible :D