L'OS 3.9 améliorerait-il notablement la vitesse du Lua ?

[mdr1]

Aucun intérêt de faire la mise à jour irréversible et qui enlèverait Ndless !
Même si l'accélération était vérifiée (probablement due à une surcadence), ça ne dépasserait pas ce que tu peux faire avec Nover.

[critor]

Si il y a une différence avec un timer de 0.01s, c'est qu'au moins l'une des deux calculatrices met plus de 0.01s pour effectuer l'action du timer.

Pas forcément, non : la différence peut parfaitement se trouver dans le temps de dessin (donc le on.paint), et non de calcul (on.timer).

J'incluais bien évidemment le temps de dessin en parlant de l' "action" du timer et non de son code.

[Adriweb]

Aucun intérêt de faire la mise à jour irréversible et qui enlèverait Ndless !

Ca dépend ce que tu veux faire avec ta Nspire - globalement j'utilise la mienne pour tester mes/des scripts Lua et faire des tutos vidéos, donc à vrai dire, je n'ai pas

Même si l'accélération était vérifiée (probablement due à une surcadence), ça ne dépasserait pas ce que tu peux faire avec Nover.

Probable, en effet - une bonne raison d'updater aurait été s'il y avait pas mal de changements en Lua, et qui auraient donc bien servi pour coder de nouveaux trucs - là, comme il y a vraiment pas grand chose de nouveau, autant rester en 3.6 effectivement avec Nover, ce qui aura le même effet.

Déjà, vous pensez que ce serait possible de baisser le timer jusqu'au millième ?

Non, le minimum est 0.01

J'ai compris que c'était possible sur hp prime non ?

Euh, possible, à part un Hello World j'ai rien fait d'autre, sur Prime

Sinon Adriweb, peut être que tu avais trop de classeurs ouverts sur l'une, et que l'autre tu venais de la reset.
Si ce n'est pas le cas, c'est vraiment prenant et je pense que je vais faire la mise à jour

J'ai effectivement beaucoup plus de classeurs (genre 50) dans la flash de celle qui est en 3.6 (contre 3-4 sur celle en 3.9), mais avant la vidéo, les 2 ont été reset.
Je doute que ça ait une influence, vraiment... mais je peux bien retester en foutant 50 .tns sur la 3.9

Après sur inspired LUA, j'ai vu platform.window:setBackgroundColor(color), tu l'as testé ? Ça ralentit ou pas ?

J'ai testé, oui, et non ça ne ralentit pas - au contraire, j'imagine/espère d'ailleurs qu'ils ont fait cela suffisamment intelligemment de leur côté pour que ce soit plus rapide que si on écrivait un setColorRGB suivi d'un fillRect.

Pourquoi ne pas reprendre le programme de fractale qui avait été utilisé pour voir la différence entre le Lua et le natif ? Sans on.timer bien entendu.

C'est une possibilité parmi d'autres pour essayer de voir où les différences de vitesses se trouvent.
Je vais tenter des trucs, mais si vous avez d'autres idées aussi, je suis preneur

J'incluais bien évidemment le temps de dessin en parlant de l' "action" du timer et non de son code.

Ok, mais ce n'est pas bon pour autant pour benchmarker correctement
En gros, il faudrait comparer proprement du calcul pur (sans dessin), dans un on.timer par exemple (ou non), et voir au bout de 30 secondes combien d'itérations ont été fait, ainsi que comparer la vitesse de dessin pur

[AnToX98]

Pour le background on peut mettre une image ou juste une couleur ?

[Adriweb]

Pour le background on peut mettre une image ou juste une couleur ?

Juste une couleur (un seul argument, donc 0xff0000 par exemple pour du rouge).

[Adriweb]

Bon, j'ai tenté quelque chose pour le fun (invalidate partiel), et j'ai été plus que surpris...
J'obtiens un script qui s'exécute plus rapidement sur la calculatrice que sur le logiciel !
Je ne sais pas si j'avais déjà vu ça...

Pour les sceptiques, oui, l'invalidate partiel fonctionne sur TINCS (on s'en rend vite compte si on mets des mauvaises coordonnées/dimensions)...

Quelques chiffres (temps pour effectuer 25 rebonds) :
Sur TINCS : 15.5 secondes avec invalidate complet et pareil pour invalidate partiel
Sur la calculatrice : 43.3 secondes avec invalidate complet, 14.56 secondes avec invalidate partiel

Code updaté :

Show/Hide spoilerAfficher/Masquer le spoiler

Code: Tout sélectionner

platform.apilevel = '2.4'     

-- Quick speed test with a bouncing square
-- Adriweb  -  tiplanet.org

local dirX, dirY = 1, 1
local x, y = 0, 0 -- will be overwritten
local hits = 0
local side = 20
local startTime, endTime = 0, 0
local running = false
local finished = false

function on.resize(w, h)
    if platform.window.setBackgroundColor then platform.window:setBackgroundColor(0x789ABC) end
    W, H = w, h
    x, y = .5*w, .5*h
end

function on.timer()
    x, y = x+2*dirX, y+2*dirY
    if x>=W-side or x<=0 then hits = hits + 1; dirX = -dirX end
    if y>=H-side or y<=0 then hits = hits + 1; dirY = -dirY end
    if hits == 25 then
        timer.stop(); running = false; finished = true
        endTime = timer.getMilliSecCounter()
        platform.window:invalidate()
    else
        platform.window:invalidate(x-2, y-21, side+4, side+23)
    end
end

function on.paint(gc)
    gc:fillRect(x, y, side, side)
    gc:drawString(hits, x, y-20, "top")
    if not running then gc:drawString( collectgarbage("count"), 5, 5, "top") end
    if finished then gc:drawString((endTime-startTime)/1000, 5, H-25, "top") end
end

function on.enterKey()
    if running then
        timer.stop()
    else
        startTime = timer.getMilliSecCounter()
        finished = false
        timer.start(0.01)
    end
    running = not running
end

function on.escapeKey()
    timer.stop()
    running = false; finished = false
    hits = 0
    dirX, dirY = 1, 1
    x, y = .5*W, .5*H
    collectgarbage()
    platform.window:invalidate()
end

Edit update : en 3.6 et en 3.9, avec invalidate partiel, les 2 calculatrices mettent exactement le même temps (14.56 secondes pour 25 rebonds)

[AnToX98]

Je n'ai pas compris. 43.3 secondes sur la calculatrice et 15 secondes sur le TNSS ? C'est le TNSS qui gagne non ?

[Adriweb]

Pour l'invalidate complet, bien sûr (et c'est "normal", le simulateur n'est pas limité). La où la calculatrice gagne, bizarrement, c'est avec un invalidate partiel.

[Lionel Debroux]

Vu que le temps est le même, le student software ne doit pas optimiser l'invalidate partiel, il doit bêtement tout redessiner. Et là, vu que c'est l'utilisateur qui demande un invalidate (plutôt que le système de fenêtres de l'OS qui ne fournirait peut-être pas assez d'infos pour éviter un redessin complet, par exemple, mais les OS modernes ont fait des progrès de ce point de vue-là), c'est la faute de TI.

[Adriweb]

Il y a vraisemblablement un soucis du côté de l'implémentation de TI vu le chronométrage en effet, mais l'invalidate partiel fonctionne sur TINCS dans le sens où si je foire mes coordonnées, je verrais des traces de "l'ancien" carré, par exemple. (jusqu'à ce que je bouge la souris sur l'écran (ou toute autre manière de forcer un invalidate complet)