Y a-t-il possibilité de "débrider" Solidworks pour qu'il ait plus de 25% de processeur utilsé ?

Bonjour,

Nous recevons de nos clients de fichiers STEP relativement modestes (entre 100 et 400Mo, 200 à 500 pièces), mais Solidworks a beaucoup de mal à les ouvrir (SolidWorks 2017 SP05).

Quand je vais gratter du côté des ressources disponibles, je vois que Solidworks n'utilise que 25% du processeur principal, et 0% du processeur graphique ! Pareil pour la RAM, l'utilation globale n'utilise jamais plus de 75%.

C'est un peu frustrant d'avoir une machine correcte (Xeon E5 @ 3.1GHz, quadricore, 8Go RAM), mais d'avoir l'impression de ne pas l'utiliser pleinement et galérer au moindre fichier à ouvrir...

Si quelqu'un a une idée / suggestion pour essayer d'amélioirer la situation, je suis preneur !

 

Merci.

fait en sorte que tes fichiers soit des fichiers en parasolid

c'est le codage de base de SW

ca ira beaucoup plus vite et evitera les plantages

@+ ;-)

4 « J'aime »

voir aussi cela entre autre

https://www.generation-nt.com/allouer-ressources-systeme-applications-astuce-967111-1.html

@+

1 « J'aime »

Bonjour

Ce n'est vraisemblablement pas un problème de processeur pour une raison que j'ai expliqué plusieurs fois.

SW natif n'est  pas multitâches (n'est pas multithread) donc que tu est 1 ou 12 coeurs il va à la même vitesse. Seul simulation est multi-thread.

Tu peux regarder dans le gestionnaire de tâche de vingtdoze sur le coeur actif combien il en utilise de % (seulement sur un coeur).

Et encore selon la façon dont est écrit le programme de conversion c'est plus ou moins long car c'est programme sont loin d'être optimisé car la conversion n'est pas un truc trivial.

Par contre si tu as beaucoup de STEP à convertir cela vaut peut-être le coup de regarder les converter existants.

Cordialement

1 « J'aime »

Merci pour vos réponses.

C'est effectivement un peu dommage du coup... J'ai déjà passé Solidworks en priorité haute, voir même temps réel, mais ça n'améliore pas les choses.

Quand au format du fichier, quand ça vient des clients, on n'a pas toujours le choix !

 

merci encore !

J'ai effectué la priorisation via le lien de gt22 ( https://www.generation-nt.com/zoom-557231,967111-priorita-haute-priorite-haute-6.html ).

C'est normal que quand je clique sur "Priorité élevée" sur SolidWorks, il lance le gestionnaire d'installation ?

Oui pour SW seul la vitesse du proc est important pour la partie modélisation.

Il y a aussi la partie rendu qui est multi core.

1 « J'aime »

Ben vi !! Fuz3D c'est ce que j'ai dit d'une autre façon :-)

1 « J'aime »

Ba là c'est une autre façon de le dire XD

Bonjour

je poursuit un peu la discussion car je suis moyennement  voire pas d'accord avec la conclusion.

pierricklancien dit ceci """ J'ai déjà passé Solidworks en priorité haute, voir même temps réel, mais ça n'améliore pas les choses. """

Il ne faut pas oublier que tout est gérer par l'OS vingtdose

Nous avons vu que Solidworks ne fait pas de multithreading  mais l'OS  il est lui multitaches.

La solution consistant à déclarer SW comme prioritaire indique seulement à l'OS que si plusieurs programmes (monotaches) sont exécutés en même temps et bien il faut traiter celui-ci en priorité.

Ceci dit cette solution est ancienne c'est-à-dire avant l'arrivée des processeurs multi-coeurs. Avec les multi-coeurs c'est l'OS qui décident de façon dynamique quel coeur va exécuter tel ou tel programme. Donc on peut très bien exécuter un programme autre que SW qui utilise du multithread. Tout en exécutant un ou plusieurs programmes monotâche sans que cela altère notablement les programmes mono-tâche.

Revenons à solidworks , si vous exécuter un programme de conversion et qu'aucun autre programme significatif (non significatif c'est par ex regarder une page Web intranet ou extranet ou que vous fassiez de l'Excel ou autre programme peu gourmand en ressources pendant la conversion).

Le meilleur moyen de prouver ce que j'explique  c'est de lancer tout seul la conversion (sans aucun autre programme en cours d'exécution) et vous verrez que votre programme de conversion utilise vraisemblablement en pointe moins de 25% de la capacité de traitement d'un seul coeur.

Donc si un seul programme s'exécute il n'a pas besoin d'être prioritaire. Si le programme de conversion n'est pas performant et bien votre 2CV ne serra jamais une Porche.

C'est pour cet ensemble de raison plus celles que j'ai donné précédemment qui fait que pierricklancien ne voit pas de différence même après avoir désigné SW comme Prioritaire.

CQFD  

 

4 « J'aime »

Bonjour

en l'occurence, c'est bien SW qui limite la charge processeur, pas windows.
Prioritaire ou pas, seul programme à fonctionner ou pas, SW n'est pas capable d'utiliser plus d'1 coeur du CPU.

avec un CPU à 4 coeurs, il est logique de plafonner à 25% d'utilisation du CPU, soit en fait 1 seul coeur qui fonctionne à 100% (et les autres à 0%)


La solution hypothétique (et un peu batarde) serait de lancer simultanément 4 sessions de SW (ce seront 4 tâches différentes pour windows), et de lancer l'ouverture/conversion de 4 fichiers STEP (1 dans chaque session SW) simultanément.
 

Dans ce cas là, si windows fait bien son job, chacun des coeurs pourra être chargé à 100%.

ça vaut le cout de tester

PS : aucun ne devras être placé en "prioritaire" dans ce cas de figure non plus, puisqu'encore une fois, c'est SW qui limite à 1 seul coeur, pas windows.

PPS: il est clair que le module photoview360 utilise bien tous les coeurs, et jusqu'à 100%, durant toute la durée du traitement du rendu.

PPPS : on en concluera que :

pour de l'ouverture/calcul/conception, c'est la fréquence de fonctionnement du processeur qui impacte le plus les performances

Pour du calcul de rendu, c'est le nombre de coeurs qui impacte le plus les performances

la plupart des utilisateurs de SW n'utilisant pas photoview360, le multicoeur est (aujourd'hui) quasiment innutile sur une machine utilisée exclusivement avec SW

3 « J'aime »

Bonjour Le Novice

1°) Vous oubliez de dire que le module simulation utilise tous les coeurs pour la moindre simulation car ce module de calcul fait du calcul parallèle.

2°) si vous ouvrez plusieurs cession de SW vous aurez un message d'erreur car vous n'aurez pas de journalisation, ni de sauvegarde automatique. Il faut voir les incidences éventuelles sur le résultat (je n'ai jamais essayé).

Je sais que si l'on n'ouvre deux cessions ou plus les cessions finissent par se marcher dessus car ils utilisent les mêmes fichiers et lors des interactions et des MAJ temporaires. Cela fait planter car SW gère très mal  la mémoire.

3°) Dire que SW n'utilise pas les possibilités du multicoeur est inexacte. Les modules de chargement des pièces est  en calcul parallèle, ce qui est intéressant pour les gros assemblages. Il y a d'autres actions (bout de programmes SW) qui utilise ponctuellement le calcul parallèle.

L'affichage utilise le multicoeur. J'ai une souris 3D et bien si je fais tourner lentement l'ASM ou surtout très rapidement l'assemblage et bien cela utilise 3 coeurs à 100% ou plus de 3coeurs.

Il faut aussi regarder la gestion de la mémoire qui n'est pas la même selon les programmes et les fichiers SW chargés.
Très important aussi  les interactions disques car cela joue aussi puisque SW fait pas mal de swapping mémoire et surtout swapping disque et cela est encore plus vrai pour les programmes de conversion (qui stocke beaucoup de résultats intermédiaires).
Dernier point la fréquence du processeurs varie selon la charge de Calcul et comme dit l'utilisation mémoire.

Par contre pour la GPU c'est le calme plat.

Donc il vaut mieux être prudent lorsque l'on fait des conclusions (cf votre PP et PPPS) qui pourront paraître hâtives voir inexactes. Il faudrait pouvoir disposer du bench détaillé fait par Solidworks pour avoir un avis le plus circonstancié possible.

Cordialement

 

1 « J'aime »