|
| WD22 x64, grosse allocation de mémoire |
| Started by YFOLLET, Jan., 19 2017 1:49 PM - 10 replies |
| |
| | | |
|
| |
Registered member
8 messages |
|
Posted on January, 19 2017 - 1:49 PM |
Bonjour, existe t'il un paramètre pour allouer un tableau de plus de 2 Go de mémoire
genre gcAllowVeryLargeObjects sur VB.net
pour : gtabDistComCom est un tableau fixe [45000,45000] entier sans signe sur 2 octet |
| |
| |
| | | |
|
| | |
| |
Registered member
256 messages
Popularité : +29 (29 votes) |
|
Posted on January, 19 2017 - 2:50 PM |
Bonjour
WINDEV a bien un comportement équivalent à "gcAllowVeryLargeObjects de VB", mais pas sur les tableaux fixes.
Enlevez le "fixe" dans votre déclaration.
Il faut évidemment passer en 64 bits aussi.
Par curiosité, à quoi vous servent de telles structures de données ?
A part en manipulation d'image ou de vidéo, ça fait quand même un sacré paquet de données. |
| |
| |
| | | |
|
| | |
| |
Registered member
8 messages |
|
Posted on January, 19 2017 - 3:06 PM |
Merci de votre réponse
J'utilise un tableau de coefficient pour faire une accélération de calcul de sectorisation
ce tableau contient un distancier commune commune pour faire une évaluation du temps de déplacement par rapport au vol d'oiseau
mais windev semble pas très adéquate pour ce genre de tache
il est très lent , par exemple
POUR i = 1 A 37000
POUR j = 1 A 37000
gtabDistComCom[i,j]=5
FIN
FIN
plus de 15 minutes a réalise sur windev
7 secondes sur vb.net |
| |
| |
| | | |
|
| | |
| |
Posted on January, 19 2017 - 4:12 PM |
Bonjour,
Par curiosité, pourriez-vous faire un test en optimisant la boucle avec _A_ et nous donner le résultat. C'est étonnant une telle différence..
POUR i = 1 _A_ 37000
POUR j = 1 _A_ 37000 |
| |
| |
| | | |
|
| | |
| |
Registered member
8 messages |
|
Posted on January, 19 2017 - 4:47 PM |
ça prend exactement le même temps (j avais exagéré avec mes 15 min, c est plutot 5)
GLOBAL
gtabDistComCom est un tableau fixe [37000,37000] entier sans signe sur 1 octet // alocation de la mémoire en 1 fois
avec A ou _A_ ==> 5min05s
GLOBAL
gtabDistComCom est un tableau [37000,37000] entier sans signe sur 1 octet // allocation de la mémoire petit a petit
tableau non fixe ==> 5min04s
GLOBAL
gtabDistComCom est un tableau [37000,37000] réel
tableau non fixe de 10,2 Go ==> 5min15s
donc ça marche sans fixe, mais la gestion des tableaux en mémoire doit être horrible pour être aussi lente
on doit être très loin de l allocation d'un block mémoire puis un parcours simple par rapport a l'adresse de début + offset |
| |
| |
| | | |
|
| | |
| |
Posted on January, 19 2017 - 4:50 PM |
Bonjour,
A mon avis ça ne changera rien, la syntaxe _A_ permet juste de n'évaluer la
borne de fin qu'une seule fois. Or ici il n'y a rien à évaluer...
C'est surtout utile quand la borne de fin ressemble par exemple à
Table_Produit..occurence.
Frédéric.
"Michel" a écrit dans le message de groupe de discussion :
20170ddffee0c79eac0535a2ba5ce45e8dba@news.pcsoft.fr...
Bonjour,
Par curiosité, pourriez-vous faire un test en optimisant la boucle avec _A_
et nous donner le résultat. C'est étonnant une telle différence..
POUR i = 1 _A_ 37000
POUR j = 1 _A_ 37000 |
| |
| |
| | | |
|
| | |
| |
Posted on January, 19 2017 - 5:09 PM |
Merci d'avoir fait le test. J'avoue qu'un écart aussi important est difficile a justifier... |
| |
| |
| | | |
|
| | |
| |
Registered member
36 messages |
|
Posted on February, 17 2017 - 11:56 PM |
Probablement qu'on touche aux limites dans ce cas.
Effectivement, il n'y a pas de notions de type "VeryLargeObjects" en WD.
Ce serait intéressant de voir ce que le support en dit, vous pouvez leur faire remonter un mcro projet exemple ? |
| |
| |
| | | |
|
| | |
| |
Registered member
2,572 messages
Popularité : +222 (260 votes) |
|
Posted on February, 18 2017 - 10:49 AM |
Bonjour,
La vrai question à se poser est:
Est-il judicieux de stocker un tel nombre de donnée en mémoire ?
Ne peut-on pas trouver une autre méthode pour le stockage ? (bdd, fichier xml, texte, ...)
Moi perso, il me semble que la méthode est mauvaise. Tu imagines la quantité de RAM nécessaire rien que pour stocker tes valeurs ?
37 000 * 37 000 * 4 octets = 5 476 000 000 octets soit 5.5 Go. Je ne sais pas de combien de RAM sont équipés tes machines, mais ça va laisser peu de place pour le reste des applications.
--
Cordialement,
Philippe SAINT-BERTIN
Géode Informatique |
| |
| |
| | | |
|
| | |
| |
Posted on February, 21 2017 - 5:32 PM |
Salut, sans connaître la problématique il est difficile d'évaluer,
Un indice fait des million ou plus de calculs et pour chaque calcul accède a un coefficient
Choix 1 une requête même sur un disque m2x4 de quelques centaines de ms
Choix 2 un tableau mémoire accès un accès de quelques cycles cpu (ns)
Et
Résultat 1 : 10 jours de calcul
Résultat 2 : 1h de calcul
Alors tu choisi quoi? Économiser de la mémoire et attendre 10 jours? |
| |
| |
| | | |
|
| | |
| |
Registered member
2,572 messages
Popularité : +222 (260 votes) |
|
Posted on February, 21 2017 - 7:17 PM |
Bonsoir,
Perso dans ce cas précis, je change de langage tout simplement. Windev n'est pas fait pour faire des calculs mathématiques de cet ordre.
Par contre je suis etonné par les 7s de vb.net. en C# ca me prend 2ms pour 1boucle de 37000, soit 74 s pour le tout si je devais tout lancer. Cependant j'ai fait ca sur lon portable, ceci explique peut être cela.
--
Cordialement,
Philippe SAINT-BERTIN
Géode Informatique |
| |
| |
| | | |
|
| | | | |
| | |
|