Non capisco la differenza di fps (ds_grid)

[DeathSeller1]

Ciao ragazzi. Ho una domanda un po' strana.

Sto sempre lavorando su generazione procedurale e ho confrontato due script che all'apparenza dovrebbero avere la stessa velocità di esecuzione, ma in realtà uno "gira" a 9000fps (38000k di memoria usata), l'altro a 5000fps (18000k).

Codice: Seleziona tutto

// Il primo viene chiamato in questo modo
global.worldElevationSeed = sDS(global.worldElevation,255,50);
while(ds_grid_get_max(global.worldElevation, 0, 0, global.worldSize, global.worldSize) < 250) ||
     (ds_grid_get_min(global.worldElevation, 0, 0, global.worldSize, global.worldSize) > 5){
    global.worldElevationSeed = sDS(global.worldElevation,255,50);
// E restituisce string(random_get_seed());

Codice: Seleziona tutto

Il secondo viene chiamato in questo modo
sDS(global.worldElevation,global.worldSize +1,global.worldSize +1,elevationDispersion,elevationRoughness);
// E non restituisce niente: setta i valori di una griglia all'interno dello script (ds_grid_set(grid,i,j,value));

Gli script fanno la stessa identica cosa e, a parte le ovvie modifiche per far creare la ds_grid o per ritornare la stringa, sono identici.
Giusto per curiosità, qualcuno sa dove si trova questa grossa differenza?

[Jak]

Fatico un pò a capire come vengono usati questi script, a guardarli sembrano cose completamente diverse.
I motivi comunque possono essere molteplici, per esperienza ti assicuro che con game maker l'apparenza inganna e solo benchmark intensivi ti fanno capire la natura delle cose.
Game maker è ben diverso da un linguaggio compilato dal quale puoi aspettarti relazioni teoriche tra gli script, ci sono decine di fattori micoscopici che influiscono enormemente sul risultato finale per via di determinati sistemi di controllo di errori ed altro. Ce ne sarebbe da parlare per mesi a riguardo.
In genere la cosa migliore da fare è usare meno script possibile e fidarsi il più possibile delle funzioni integrate di GM che son generalmente più veloci della stessa cosa fatta a mano.
Altro consiglio che ti dò è quello di usare le grid solo se hai necessità di estrema flessibilità o comodità o calcoli su aree dove gli script integrati sono molto veloci, altrimenti usa gli array bidimensionali che sono MOLTO più veloci in lettura e scrittura.

[DeathSeller1]

Ciao jak e grazie per la risposta. I due pezzetti qua sopra richiamano lo stesso script (diamond square) che genera un terreno proceduralmente. Il più veloce dei due crea e riempie una grid che viene poi eliminata (quella con seed alla fine) dopo che lo script ha ritornato tutti i dati alla grid principale.
Il secondo script invece riempie direttamente la grid principale da dentro sè stesso e non ritorna niente.

In via teorica, se proprio mi devo aspettare differenze di prestazioni, direi che dovrebbe essere il secondo ad andare più veloce. Invece proprio no.

Il problema delle array per così tanti dati è che non possono essere smemorizzate come le strutture di dati che, una volta che non servono più vengono distrutte liberando memoria.

Comunque appena ho un po' di tempo provo a fare dei bench con 2 progetti nuovi. Così, giusto per curiosità.

[Jak]

Certo che puoi invece! Basta fare "array=0" e trasformarlo da array a variabile, in questo modo il garbage collector di GM penserà al resto ed eliminerà l'array.
Chiaramente è più rischioso perchè se ti porti l'array in giro nel programma questo rimarrà in memoria anzichè dare errore e ti risulterà più difficile il debug.
Conta comunque che calcoli su aree quindi ds_grid_get_max() e ds_grid_get_min() sono velocissimi quindi potrebbe comunque essere conveniente.
Per quanto riguarda le differenze di prestazioni gli script sDS() non sono uguali a giudicare dal numero di parametri e quindi suppongo che abbiano anche prestazioni diverse, è possibile che sia quello script a rallentare e l'utilizzo delle ds_grid abbia un'impatto di prestazioni impercettibile rispetto a sDS().
Nel primo caso inoltre vedo un OR e non un AND, non conosco sDS() come è fatto ma mi viene da pensare che hai un'ottima percentuale di probabilità di uscire dal loop subito oppure dopo appean un ciclo.
Il risultato è fare comunque una unica passata esattamente come il secondo script MA con uno script con meno argomenti, quindi suppongo più veloce.