none
capacite memoire du stack RRS feed

  • Question

  • Bonjour,

    Je voudrais savoir quelle est la capacité mémoire du stack (location des donnees type value.
    Cette capacité, peut-elle etre modifiée (augmentée par exemple et comment) ?
    Dépend-t'elle de la config du PC ?
    Ces infos me sont précieuses pour savoir si je peux mettre des matrices 5*20000 (dans une struct) en type value et non dans le heap (pb de vitesse).

    Merci pour votre réponse.

    Fred

    lundi 17 mars 2008 13:39

Réponses

  • Merci "Papy Normand",
    Votre explication m'a beaucoup aidé...
    Théoriquement, je me sens beaucoup plus à l'aise avec C# car j'avais déjà écrit ce programme en DELPHI.
    Donc pas de prob avec les pointeurs.
    Comme je l'avais écrit auparavant, j'ai voulu aller vers Visual C# parce que DELPHI, comme C++, ont des jours bien comptés (à mon avis). Je pensais aussi qu'avec Visual C# je gagnerai en vitesse d'exécution.

    Bien cordialement,

    Fred
    dimanche 23 mars 2008 11:30

Toutes les réponses

  • Bonjour,

    Lorsque vous créez un thread en .Net 2.0, vous pouvez spécifier la taille de la stack :

     

    http://msdn2.microsoft.com/en-us/library/5cykbwz4.aspx

     

    Guillaume
    lundi 17 mars 2008 14:24
  • Merci pour votre réponse mais comme je ne m'y connais pas bien en threads, je voudrais m'en passer et donc connaitre la capacité du stack alloué au démarrage, sinon s'il faut ajouter des options de compilation ou d'execution avec une allocation mémoire pour ce stack.
    Merci pour vos réponses,

    Fred
    lundi 17 mars 2008 14:39
  • Ces options de compilations existent en C++

    http://msdn2.microsoft.com/en-us/library/8cxs58a6(VS.80).aspx

    mais pas en C# semble t il.

    Par contre il est conseillé d'utiliser editbin qui permet de tailler la stack selon son bon vouloir:

    editbin.exe /STACK

     

    Un lien avec l'utilisation de la commande ainsi qu'un petit exemple permettant de l'essayer:

    http://www.thescripts.com/forum/thread229335.html

     

    mardi 18 mars 2008 12:36
  • Merci pour votre réponse.
    Dans mon cas, il vaudrait peut-etre mieux d'utiliser des pointeurs (en unsafe) sur un tableau de heap qui a été épinglé (FIXED)
    Etes-vous d'accord avec mon idée ?

    Merci,

    Fred
    mardi 18 mars 2008 17:15
  • Je n'ai pas de réponse sur ma dernière affirmation (tableau épinglé dans le Heap et travailler en unsafe).

    Merci pour réponse,

    Fred
    jeudi 20 mars 2008 13:28
  • Bonjour,

     

    Ta proposition semble valable comme le montre cette présentation sur les fixed buffer (http://msdn2.microsoft.com/en-us/library/zycewsya(VS.80).aspx) néanmoins je ne suis pas sur que j'infligerai ça au C#

    J'avoue que ces mécanismes sont pour moi plus en rapport avec le C++ et que vouloir appliquer ce comportement au C# n'est peut être pas la meilleure chose.

    Personnellement soit je travaillerai avec des collections (genre hashtable pour optimiser les accès aux données) soit je ferai ce code directement en C++ mais sans la vision précise du projet je suis peut être complètement à côté de la plaque.

     

    En tout cas bon courage car ça s'annonce chaud

    vendredi 21 mars 2008 08:01
  • Merci pour ta réponse.

    C'est un programme de dynamique avec au plus 200 degrés de liberté et pour chacun 30000 valeurs mais que je pourrais scinder en 3 (sauvegarder dans fichiers temporaires).
    Pour l'entrée des éléments par l'utilisateur et les sorties des résultats, C# me paraît judicieux  et très convivial.
    Il n'y a qu'une soubroutine qui "dure" longtemps (calculs mathématiques matriciels simples) mais qui n'est pas très longue à programmer et qui va remplir le maudit tableau. Pendant ce calcul, il n'y a pas d'intervention de l'user.
    Voilà, penses-tu que je doive écrire cette partie en C++
    ou est-ce jouable en C# unsafe?

    Merci pour ton aide,

    Fred

    PS j'avais déjà écrit ce programme en DELPHI, mais je voulais passer à un  environnement plus moderne  et qui offrait plus de possibilités et contrôles.
    vendredi 21 mars 2008 08:27
  • Bonjour,

     

    Le problème de C++ est double :

    - c'est le langage qui permet d'utiliser un certain nombre de fonctionnalités de Windows telles que les API ou même les classes WMI ( quoique dans ce dernier cas PowerShell ou un programme écrit en VC# sont tout aussi pratiques )

     

    - j'ai eu l'occasion de discuter avec des gens au stand MSDN aux TechDays de Paris. Ils ont fait la moue sur l'avenir de C++ pour le prochain Visual Studio ( C++ existerait encore mais les nouveautés pour VB et VC# risquent de ne pas être ajouté au C++ , c'est généralement un signe de mort plus ou moins programmée). D"autant plus que j'ai répondu récemment à un questionnaire de l'équipe MSDN visant à connaître l'opinon sur une sorte de "fusion" entre VB et VC#.

     

    De toute façon, pour le moment, il est parfaitement possible d'avoir un project comprenant des sources VB,VC# ou C++.

    La génération de l'executable se passe bien ( elle semble allongée en version 2008 quand il y a un source C++ ).

     

    Si vous vous sentez plus à l'aise en C++, faîes votre subroutine de traitement matriciel en C++, je pense que son temps d'exécution sera plus court qu"en VC# ou VB, si vous pouvez gagner 1 ou 2 minutes sur un traitement de 10 minutes, je pense que l'utilisateur ne dira jamais non. Par contre, comme vous travaillerez en non-managé, il faudra bien faire attention aux risques de plantage dû souvent à une mauvaise utilisation des pointeurs

     

    Il y a 30 ans j'ai écrit une centaine de programmes de traitement matriciel en Fortran ou en APL. Je me souviens des sueurs froides que j'ai ressenti en voulant deboger un prog de 1000 lignes en APL  ( résolution de systèmes d'équations avec 7 variables ). Bonne chance.

     

    Bonne journée

     

    samedi 22 mars 2008 17:59
  • Merci "Papy Normand",
    Votre explication m'a beaucoup aidé...
    Théoriquement, je me sens beaucoup plus à l'aise avec C# car j'avais déjà écrit ce programme en DELPHI.
    Donc pas de prob avec les pointeurs.
    Comme je l'avais écrit auparavant, j'ai voulu aller vers Visual C# parce que DELPHI, comme C++, ont des jours bien comptés (à mon avis). Je pensais aussi qu'avec Visual C# je gagnerai en vitesse d'exécution.

    Bien cordialement,

    Fred
    dimanche 23 mars 2008 11:30