PureBasic

C'est quoi le problème de ce code ??!!! Je me prend un "Read Data error, no more data"
Ca doit être évident comme le nez au milieu du visage mais ???!!!

Si je met des data positives je n'ai pas d'erreur... Cependant si je ne me trompe pas, le type byte en purebasic accepte des valeurs entre -127 et +128 non ? C'est un bug ??
Ou plus probablement, je suis un benêt ...

Si tu utilises la version 4.30, le read prend maintenant un type. Tu dois donc écrire "read.b" au lieu de "read" tout court (qui est par défaut en .i).

Haaaa ... OK !!! Merci beaucoup !!

Effectivement je suis passé en 4.30.

Bon, donc je récapitule, je dois mettre le type de mes data (data.b) et définir le type de variable pour lire la donnée (dim autourX.b(8))
et en plus spécifier le format avec lequel je lis la donnée (read.b )

C'est pas un peu compliqué tout ça

Si tu as aussi peu de données, tu peux tout laisser en .i et ne pas t'embêter
En plus ce sera plus rapide

Il s'agit de valeurs pour tester autour d'une case avec un boucle type :

for i=1 to 8
if monde(x+autourX(i),y+autourY(i))...etc
next i

et éviter le fameux et laid:
for i=-1 to 1
for t=-1 to 1
if monde(x+t,y+i)... etc
next t
next i
Evidemment on aura reconnu les poids 10 des déplacement orthogonaux et 14 approximation de la racine de 2 pour les déplacement diagonaux...

En .i ce serai plus rapide ? Parceque le processe lit de toute façon en une fois un 32bts depuis la mémoire ?

Le .i est le type natif du microprocesseur. Pour un processeur 32 bits, le .i équivaut à un mot de 32 bits, qui est pour lui le type de données le plus rapide à traiter (même largeur que le bus, pas de masquage, etc.).
Ça va te sembler curieux, mais je ne suis pas sûr que ton "optimisation" soit meilleure que la double boucle. En général, une table permet effectivement de gagner en vitesse, surtout pour des effets de loupe (on où peut d'ailleurs combiner le x et le y pour accéder directement à la bonne donnée). Mais là, si c'est simplement pour accéder à 8 éléments d'un tableau... Bof. Mais je comprends ta logique.

bein oui, je n'accede qu'a 8 élements mais pour un nombre important de cases ....

Honnêtement mon "optimisation" je ne sais pas si ça en est une, mais quand je programmais sur de vieux proce, on faisait comme cela pour aller plus vite donc... Je garde cette habitude. Et puis je ne peux pas m'empêcher de penser qu'en assembleur ça fait quand même 2 boucles ce qui est toujours plus lent que une normalement...

Du reste c'est surement pour cela que je préfère spécifier un Byte plutôt qu'un Integer quand je n'en ai pas l'utilité, ce qui, comme tu l'as expliqué ne sert plus à rien

Boaf, c'est pas grave, ça me fait plaisir.

C'est un prog de pathfinding que je reprends et donc je ne voyais pas pourquoi ça ne re-fonctionnait plus

Oui, je te comprends, j'ai les mêmes réflexes, et j'ai dû en abandonner beaucoup. Sais-tu par exemple que bien souvent les flottants sont maintenant plus rapides que les entiers, et qu'il ne sert donc à rien de faire des conversions en espérant être plus rapide... C'est le genre de truc qui me rend fou
De même les anciennes optimisations à base de tables sont souvent plus lentes, et ce depuis l'apparition des mémoires caches. Quand les tables ne rentrent pas dedans, ça fait des "cache-hits" qui monopolisent le bus pour que le cache soit "rechargé" (par blocs) = gros ralentissements

Plus rapide que les entiers ??!! Bein non je ne savais pas ... je vais changer mon pseudo en "Hibernatus" arf

Au moins le coup du "cache hits" je le comprends mais là tu m'as cassé le moral.

J'ai appris les optimisations avec prog graphic en ass et c de M Abrash et bein je suis en train de me rendre compte que beaucoup de choses sont à oublier.

Pas grave, je fais ça pour me faire plaisir, je vais faire comme si de rien n'était... Je suis trop vieux

Bah, faut pas exagérer, il y a toujours des trucs à optimiser! Les p'tits jeunes croient dur comme fer qu'un compilateur fait un meilleur boulot que le code manuel! Tssss! Sans être un pro de l'optim, ça me fait bien marrer
Comme me disait mon pote toto, sans optim' t'en affiches 10, avec j'en affiche 100! Ces vieux réflexes nous poussent à donner le meilleur de nos bécanes; c'est écologique!

[aparté]
ça fait plus de 25 ans que je programme. J'ai appris à programmer à l'optimisation (sur des coucous à 1Mhz sur lesquels on calcule les cycles d'horloge) et j'ai toujours ce type de réflexe (dur de changer).
Flottant plus rapide que les entiers ? Sur le coup j'ai été étonné (vieux réflexe du co-pro qui n'existait pas) et comme il existe des instructions asm prédéfinies, donc ça doit être logique.

En fait, le simple fait de vouloir optimiser son code fait que l'on prend toujours autant de plaisir à programmer, de reprendre un code et de le refaire totalement. Ayant testé +sieurs langages, PureBasic reste l'un des rares permettant cette façon de programmer et c'est surtout pour cela que je l'adores (sans oublier FASM qui m'a réconcilié sur la programmation assembleur x86).

Désolé d'être rentré dans la discution
[/aparté]

flotans plus rapide que les entiers ? pourtant en cours d'architecture j'ai fait pas mal de bechmark sur les serveur de mon université ainsi que sur mes machines perso et les flotants son rarement favorisé.

Djes : tu aurrais de quoi expliquer un peu plus ? C'est vrai que ça me parraît surprenant, à la limite dans les derniers DSP et encore, mais ans un processeur pour ordinateur....

On a fait quelques tests, au hasard ici : http://www.purebasic.fr/english/viewtop ... torder=asc et là : http://www.purebasic.fr/english/viewtop ... torder=asc
Il y a tellement de configurations différentes qu'il est difficile d'adapter son code pour le rendre plus performant. D'après ce que j'ai pu constater, en moyenne, il est plus intéressant d'utiliser les flottants directement et les fonctions câblées (genre sin, tan, etc) que de travailler avec des entiers et faire des tables. C'est plus pérenne, plus précis, et aussi plus rapide dans la plupart des cas (car sur certaines configs, ce genre d'astuce est très lent).

C'est surtout une histoire d'os ? non ? l'alignement de la mémoire peut être.
En tout cas , sur linux , le .i explose les flottants , y a pas photo.