Commentaires sur : SolidWorks : Nouvelles spécifications techniques

Par : Yves

Yves — Mon, 30 Nov 2009 16:36:52 +0000

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.

Par : Matthieu

Matthieu — Mon, 30 Nov 2009 16:24:42 +0000

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 !

Par : Yves

Yves — Mon, 30 Nov 2009 16:01:51 +0000

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…

Par : Matthieu

Matthieu — Mon, 30 Nov 2009 15:47:10 +0000

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.

Par : Ybo

Ybo — Tue, 22 Sep 2009 07:29:43 +0000

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!

Par : pascal

pascal — Tue, 22 Sep 2009 07:24:37 +0000

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.

Par : Ybo

Ybo — Fri, 18 Sep 2009 13:28:04 +0000

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.

Par : pascal

pascal — Fri, 18 Sep 2009 12:42:32 +0000

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.