SolidWorks : Nouvelles spécifications techniques
Afin d’utiliser au maximum de sa puissance votre CAO 3D SolidWorks, une mise à jour des recommandations sur les spécifications techniques a été faite sur le site de SolidWorks. Certaines informations sont à prendre en compte et à ne pas négliger.
Les Versions de Microsoft Windows supportées par SolidWorks
Pour les différents OS, on notera principalement 2 choses. La première, c’est que Windows 7, en 32 et 64, seront supportés dès SolidWorks 2010 SP1.
La seconde chose à noter, c’est que SolidWorks 2010 est la dernière version qui supportera Microsoft Windows XP Professional.
Si vous avez cette OS, pensez qu’il faudra donc le changer lorsque vous migrerez sur SolidWorks 2011. Bien sûr, il reste encore du temps, mais vous pouvez d’ores et déjà planifier le budget.
Spécifications techniques des machines pour SolidWorks
Au niveau de la mémoire, SolidWorks préconise 2 Go de RAM. C’est le minimum.
Pour ceux qui gère de gros assemblages, une machine avec un processeur 64 bits et un OS 64 bits est fortement recommandé.
L’OS 32 bits ne gère pas plus de 2 Go, il est donc inutile d’ajouter de la mémoire si on utilise un OS 32bits.
Les configurations 64 bits gèrent la mémoire correctement, et là , SolidWorks préconise 6 Go de Ram minimum.
Pour la vidéo, prenez une carte OpenGL certifié par SolidWorks.
SolidWorks est compatible avec des processeurs Intel ou un AMD.
Pour plus d’informations techniques, notamment sur les cartes graphiques certifiées SolidWorks, je vous invite à suivre le lien sur les recommandations système SolidWorks.
Mots clés:harware, machines, PC, recommandations, SolidWorks, spécifications techniques+'&title='+encodeURIComponent(document.title)+'&overview='+encodeURIComponent(document.title)+'&urllanguage=fr&urlaffiliate=32003&encoding=UTF-8&urlpicture=http://www.viadeo.com/v_img5/shareit/viadeoflower.gif')
Et qu’en est il des processeurs multi-coeurs?
Ce n’est pas très logique de pousser les utilisateurs vers un OS 64 bits, sans utiliser la capacité maximum du processeur qui le fait tourner.
Bonjour Pascal,
Alors, en effet, SolidWorks seul ne sait pas gérer les bi-processeurs. Néanmoins, il y a 2 raisons pour passer en 64 bits.
La première est que si on utilise les outils de simulations de SolidWorks, là , le bi-processeur est géré et donc, ça réduit significativement les temps de calculs.
La seconde raison tient à la gestion de la mémoire. L’architecture windows 32bits a du mal à gérer plus de 1.6 Go de RAM et ne gère plus au dessus de 2Go, alors que sur l’architecture 64 bits, cette gestion de mémoire est correctement faite. Aussi, dans le cas de gros assemblages (par exemple), c’est une bonne raison pour passer en 64 bits.
Ceci dit, dans l’utilisation de SolidWorks, si on ne fait pas de simulations (calculs), et si on a pas besoin de plus de 2 Go de RAM, dans ce cas, en effet, autant rester en 32 bits.
Bonjour Ybo,
Je suis au courant de la limitation de mémoire de l’OS 32 bits.
Cependant, pour pouvoir travailler avec de gros assemblages, la mémoire ne suffit pas. Il faut aussi une bonne puissance de calcul (CPU et GPU).
Les évolutions technologiques sur les processeurs vont vers plus de coeurs. Il est rageant de voir qu’une partie seulement du processeur est utilisé alors que le calcul dure de longues minutes. Ajourd’hui sur un quad core 3 processeurs sont “au repos”, j’imagine la déception quand les 8 ou 16 coeurs seront abordables.
Je suis entièrement d’accord. D’ailleurs, il faut que l’ensemble des composants de la machine soit homogène, que ce soit le DD, la carte graphique, la RAM, le processeur ou même les bus.
Je ne peux actuellement dire si SolidWorks travaille sur la compatibilité multi-processeurs, mais je vais essayer d’aller à la “pêche aux informations”. Je ferai un feedback dès que je pourrai!
Alors d’après ce site internet :
http://www.javelin-tech.com/main/support/solidworks_2010_hardware_faq.htm
Solidworks serait ENFIN multithread dans sa version 2010, ce qui devrait permettre de gagner du temps à l’ouverture et à l’enregistrement des fichiers surtout.
Bonjour Matthieu,
Alors attention à ce qui est dit dans l’article que vous avez cité. SolidWorks 2010 est multi-processeurs, mais pas le moteur (solveur) paramétrique qui ne peut tirer avantage du multi-processeurs.
Bien sur, il y a du mieux, notamment à l’ouverture des documents qui utilisent bien le multi-processeurs. C’est donc un gain de temps certain à ce niveau là !
Un petit bémol donc, car on ne peut pas dire que l’article de Javelin technologies est faux, mais de là à dire que le multi-processeurs est complètement géré, non.
L’article joue sur les mots, il faut alors faire la différence entre SolidWorks et son moteur paramétrique…
Bonjour,
J’avais bien compris la chose comme ça, c’est pour ça que j’ai parlé de temps gagné à l’ouverture et à l’enregistrement des fichiers.
A dire vrai c’est l’ouverture et l’enregistrement des fichiers qui prennent le plus de temps pour l’utilisation que l’on fait de Solidworks dans ma boîte.
J’espère donc gagner un peu de temps (en espérant que l’architecture réseau ne ralentisse pas le tout …) et de voir (un peu …) de quoi sont capables nos bi-xéon quad core !
Nous avons réalisé des tests chez nous, avec des exemples clients. Nous avons ouvert des documents SolidWorks, asm, prt, drw avec SolidWorks 2009, puis, avec SolidWorks 2010 sur une machine bi-processeurs. Le test portait bien sur l’ouverture des documents seulement.
- Pour un cas, nous n’avons absolument rien gagné, et sans pouvoir expliqué pourquoi.
- Pour un cas, nous avons constaté un gain de temps de 70 %, sans pouvoir expliqué pourquoi non plus.
- Dans la majorité des cas, nous avons constaté un gain de temps variant entre 20 et 33%
Il semblerait donc qu’en effet, le gain de temps à l’ouverture est réel, aux alentours des 25% de gain en moyenne…
J’espère que ce sera le cas pour tout le monde, car nous n’avons pas trouvé une explication sur l’exemple ou nous n’avons rien gagné afin d’en tirer une analyse sérieuse.