[Résolu] reel double precision sous GM8

Bonjour à tous,
je débute sur game maker 8
j'avais crée un algorithme pour un projet particulier : déplacement d'un cavalier seul sur un echiquier vide
le but lui faire chercher le chemin pour parcourir l'ensemble des 64 cases qu'une seule fois
en commençant par le coin inférieur gauche il faut que le programme exécute 27 millions de fois l'algorithme pour trouver la solution.

En C cela prends qu'une dizaine de secondes, en javascript presque 1 minute et en Qbasic presque 280 secondes
Hors sur game maker 45 minutes ??

On m'a affirmé que mon algorithme est une vraie usine à gaz donc,
je me suis mit sur une boucle calculant les décimales de PI

p = real("4.0");                          //declaration real double precision unknow
c = real("3.0");
for (i = 1; i < nbi; i += 1){         //j'ai tronque le code ou une saisie est demande pour nbi, puis transforme en réel
   p -= 4.0 / c;
   c += 2.0;
   p += 4.0 / c;
   c += 2.0;
}
show_message("secondes ecoulees : "+string(s)+"#piCalc = "+string(p)+"#coef = "+string(c));
//pi = 3.14 pas d'autres décimales affiches :/

Désolé pour mon pavé, j'ai besoin de savoir comment visualiser les décimales d'une division en double précision
par exemple : show_message("sin(60) = "+string(sinux));     //affiche : sin(60) = 0.87 au lieu de 0.866025
Mais aussi pourquoi les opérations sont si longues sous game maker ??
Car avec mon essai sous C : j'ai fais 999 900 000 itérations en moins de 15 secondes
et sous game maker => 1283 secondes pour le même nombre d’itérations
(pour info : 5 000 000 itérations en 18 secondes avec ce dernier !!)

scroller a écrit:

Hors sur game maker 45 minutes ??

Bienvenue dans le monde formidable de GM

Le C, C++, Basic: Compilé
Java: Machine virtuelle (la JVM) avec compilation JIT du bytecode
Javascript: Interprété, compilation JIT (just in time)
GM: Machine virtuelle avec interpretation du bytecode

Donc en gros, un langage compilé y aucune surcouche d’interprétation, vu que le code deviens natif (donc pleine puissance).

Une machine virtuelle JITed, y a qu'une surcouche d’interprétation, plutôt légère, elle va traduire un bytecode (semblant d'assembleur simplifié) en code machine. Ce qui fait de java un langage semi compilé, et plutôt rapide.

L'interprété JITed, qui lis le code a la volée et le transforme en code machine, la on a 2 surcouches d'un coup on peut dire, vu qu'il faut passer par un lexer (analyse et découpage des mots clés etc), un parseur (création d'un arbre de syntaxe abstraite / AST), puis qu'il faut convertir l'AST en code machine.

GM c'est une compilation script GML => Bytecode, mais ensuite il n'utilise plus du tout l’intérêt de la forme bytecode car c'est de l’interprétation simple. A aucun moment on passe par du code machine.
Bon après faut se dire que c'était encore pire avant, vu qu'il interprétait directement le GML
Mais ouai un petit coup de compilation JIT ça permettrait d'avoir de bien meilleurs perfs.
Le soucis c'est qu'une VM du genre pèse déjà bien plus lourd, est plus dure a porter si on utilise pas un JITer portable, puis c'est pas forcement simple a intégrer non plus...

Merci pour vos réponses,
je me doutais bien que le GML posait problème dés lors qu'on lui demande d’exécuter un grand nombre de boucles :/
Par contre, pour utiliser une variable type réel en double précision est-ce possible ?

scroller a écrit:

[...]
show_message("secondes ecoulees : "+string(s)+"#piCalc = "+string(p)+"#coef = "+string(c));
//pi = 3.14 pas d'autres décimales affiches :/

Désolé pour mon pavé, j'ai besoin de savoir comment visualiser les décimales d'une division en double précision
par exemple : show_message("sin(60) = "+string(sinux));     //affiche : sin(60) = 0.87 au lieu de 0.866025
[...]

Game Maker peut-il traiter des réels sans arrondir les valeurs ?

onilink_ a écrit:

Le C, C++, Basic: Compilé
Java: Machine virtuelle (la JVM) avec compilation JIT du bytecode
Javascript: Interprété, compilation JIT (just in time)
GM: Machine virtuelle avec interpretation du bytecode

Donc en gros, un langage compilé y aucune surcouche d’interprétation, vu que le code deviens natif (donc pleine puissance).

Une machine virtuelle JITed, y a qu'une surcouche d’interprétation, plutôt légère, elle va traduire un bytecode (semblant d'assembleur simplifié) en code machine. Ce qui fait de java un langage semi compilé, et plutôt rapide.

L'interprété JITed, qui lis le code a la volée et le transforme en code machine, la on a 2 surcouches d'un coup on peut dire, vu qu'il faut passer par un lexer (analyse et découpage des mots clés etc), un parseur (création d'un arbre de syntaxe abstraite / AST), puis qu'il faut convertir l'AST en code machine.

GM c'est une compilation script GML => Bytecode, mais ensuite il n'utilise plus du tout l’intérêt de la forme bytecode car c'est de l’interprétation simple. A aucun moment on passe par du code machine.
Bon après faut se dire que c'était encore pire avant, vu qu'il interprétait directement le GML
Mais ouai un petit coup de compilation JIT ça permettrait d'avoir de bien meilleurs perfs.
Le soucis c'est qu'une VM du genre pèse déjà bien plus lourd, est plus dure a porter si on utilise pas un JITer portable, puis c'est pas forcement simple a intégrer non plus...

Pour Java la JVM est pas vraiment légère puisque c'est elle qui fait la grande majorité des optimisations, pas le compilateur de bytecode.

Edit : De mémoire GM avant-Studio utilisait que des flottants double-précision et des string... Et je sais pas si ça dure avec GM:S mais c'est fort probable.

Faut aller dans le mode debug de souvenir pour voir plus de décimales. Les fonctions d'affichage standard et conversion en string arrondissent.
Au pire tu multiplie par 1000 avant de passer en string si tu veux des décimales en plus x)

Ok, merci j'ai pas pensé à ça je vais faire des testes.
Si tout est bon je mettrais le sujet en résolu
[edit]
Tout est bon, GM calcul bien les réels en double précision
effectivement c'est bien lors de la conversion en chaîne de caractère que la valeur est tronquée !!
Encore merci => problème entièrement résolu !!