Is het mogelijk om Solidworks te "ontfermen" zodat er meer dan 25% van de CPU wordt gebruikt?

Hallo

We krijgen relatief kleine STEP-bestanden van onze klanten (tussen de 100 en 400MB, 200 tot 500 onderdelen), maar Solidworks heeft veel moeite om deze te openen (SolidWorks 2017 SP05).

Als ik de beschikbare bronnen ga schrappen, zie ik dat Solidworks slechts 25% van de hoofdprocessor gebruikt en 0% van de grafische processor! Hetzelfde geldt voor RAM, het totale gebruik gebruikt nooit meer dan 75%.

Het is een beetje frustrerend om een fatsoenlijke machine te hebben (Xeon E5 @ 3,1 GHz, quad-core, 8 GB RAM), maar om het gevoel te hebben dat je hem niet volledig gebruikt en worstelt met het minste bestand om te openen...

Als iemand een idee/suggestie heeft om te proberen de situatie te verbeteren, ben ik er helemaal voor!

 

Bedankt.

Maak uw bestanden parasolide

dit is de basiscodering van SW

Het zal veel sneller gaan en crashes voorkomen

@+ ;-)

4 likes

Zie ook dit o.a.

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

@+

1 like

Hallo

Het is waarschijnlijk geen processorprobleem om een reden die ik meerdere keren heb uitgelegd.

Native SW is  geen multitasking (is niet multithreaded), dus of je nu 1 of 12 cores bent, het gaat op dezelfde snelheid. Alleen de simulatie is multi-threaded.

U kunt in de taskmanager met twintig dozers op de actieve kern kijken hoeveel % deze gebruikt (slechts op één kern).

En nogmaals, afhankelijk van hoe het conversieprogramma is geschreven, is het min of meer lang omdat het verre van geoptimaliseerd is, omdat conversie geen triviaal iets is.

Aan de andere kant, als je veel STEP moet converteren, kan het de moeite waard zijn om naar de bestaande converters te kijken.

Vriendelijke groeten

1 like

Dank u voor uw antwoorden.

Dan is het inderdaad een beetje jammer... Ik heb Solidworks al overgeschakeld naar hoge prioriteit, of zelfs realtime, maar het verbetert de zaken niet.

Wat betreft het bestandsformaat, als het van de klanten komt, hebben we niet altijd een keuze!

 

Nogmaals bedankt!

Ik heb de prioritering gedaan via de gt22 link ( https://www.generation-nt.com/zoom-557231,967111-priorita-haute-priorite-haute-6.html ).

Is het normaal dat wanneer ik op "Hoge prioriteit" klik op SolidWorks, het installatiebeheer wordt gestart?

Ja, voor SW is alleen de snelheid van de proc belangrijk voor het modelleringsgedeelte.

Er is ook het renderinggedeelte dat multi-core is.

1 like

Nou vi!! Fuz3D, dat is wat ik op een andere manier zei :-)

1 like

Nou, dat is een andere manier om het te zeggen XD

Hallo

Ik zet de discussie een beetje voort omdat ik het matig  of niet eens ben met de conclusie.

pierricklancien zegt dit """ Ik heb Solidworks al overgeschakeld naar hoge prioriteit, of zelfs realtime, maar het verbetert de zaken niet. """

We mogen niet vergeten dat alles wordt beheerd door de OS twentydose

We hebben gezien dat Solidworks niet multithread, maar het besturingssysteem  is multitasking .

De oplossing om SW als prioriteit te verklaren, vertelt het besturingssysteem alleen dat als er meerdere programma's (singletasking) tegelijkertijd worden uitgevoerd, dit als prioriteit moet worden behandeld.

Dat gezegd hebbende, deze oplossing is oud, d.w.z. vóór de komst van multi-coreprocessors. Bij multicores is het het besturingssysteem dat dynamisch beslist welke core welk programma zal uitvoeren. Je kunt dus heel goed een ander programma dan SW draaien dat gebruik maakt van multithreading. Tijdens het uitvoeren van een of meer single-tasking programma's zonder de single-tasking programma's significant te wijzigen.

Laten we teruggaan naar solidworks, als u een conversieprogramma uitvoert en geen ander belangrijk programma (niet-significant is bijvoorbeeld het kijken naar een intranet- of extranetwebpagina of het uitvoeren van Excel of een ander resourcebesparend programma tijdens de conversie).

De beste manier om te bewijzen wat ik uitleg , is door de conversie zelf uit te voeren (zonder dat er een ander programma wordt uitgevoerd) en je zult zien dat je conversieprogramma waarschijnlijk minder dan 25% van de verwerkingscapaciteit van een enkele kern gebruikt.

Dus als er maar één programma wordt uitgevoerd, hoeft het geen prioriteit te krijgen. Als het ombouwprogramma niet efficiënt is, zal uw 2CV nooit een veranda zijn.

Het is om deze reeks redenen, plus de redenen die ik eerder heb gegeven, dat Pierricklancien geen verschil ziet, zelfs niet na het aanwijzen van SW als een prioriteit.

CQFD  

 

4 likes

Hallo

in dit geval is het SW dat de CPU-belasting beperkt, niet Windows.
Prioriteit of niet, alleen programma om te werken of niet, SW is niet in staat om meer dan 1 CPU-kern te gebruiken.

met een 4-core CPU is het logisch om te beperken tot 25% CPU-gebruik, wat eigenlijk 1 core is die op 100% draait (en de andere op 0%)


De hypothetische (en een beetje) oplossing zou zijn om tegelijkertijd 4 SW-sessies te starten (dit zullen 4 verschillende taken voor Windows zijn), en om het openen/converteren van 4 STEP-bestanden (1 in elke SW-sessie) tegelijkertijd te starten.
 

In dit geval, als Windows zijn werk goed doet, kan elk van de kernen tot 100% worden geladen.

Het is de kosten van het testen waard

PS: ook in dit geval moet er geen enkele in "prioriteit" worden geplaatst, want nogmaals, het is SW die zich beperkt tot 1 kern, niet Windows.

PPS: het is duidelijk dat de photoview360-module alle cores gebruikt, en tot 100%, gedurende de gehele duur van het renderingproces.

PPPS: er zal worden geconcludeerd dat:

Voor openheid/berekening/ontwerp is het de werkfrequentie van de processor die de grootste impact heeft op de prestaties

Voor renderingberekeningen is het het aantal cores dat de meeste impact heeft op de prestaties

de meeste SW-gebruikers gebruiken photoview360 niet, dus multi-core is (vandaag) bijna nutteloos op een machine die uitsluitend met SW wordt gebruikt

3 likes

Hallo beginneling

1°) U vergeet te zeggen dat de simulatiemodule alle kernen gebruikt voor de geringste simulatie omdat deze rekenmodule parallelle berekeningen uitvoert.

2°) als je meerdere SW-opdrachten opent , krijg je een foutmelding omdat je geen logging hebt, noch automatische back-up. Je moet de mogelijke impact op het resultaat zien (ik heb het nog nooit geprobeerd).

Ik weet dat als je twee of meer opdrachten niet opent, de opdrachten uiteindelijk op elkaar gaan trappen omdat ze dezelfde bestanden gebruiken en tijdens interacties en tijdelijke updates. Dit veroorzaakt een crash omdat SW het geheugen zeer slecht beheert.

3°) Beweren dat SW geen gebruik maakt van de mogelijkheden van de multicore is onjuist. De modules voor het laden van onderdelen zijn  in parallelle berekening, wat interessant is voor grote assemblages. Er zijn andere acties (SW-programma's) die af en toe gebruik maken van parallel computing.

Het display maakt gebruik van multi-core. Ik heb een 3D-muis en als ik de ASM langzaam of vooral heel snel de assemblage uitvoer, dan gebruikt hij 3 cores op 100% of meer dan 3 cores.

Je moet ook kijken naar het geheugenbeheer, dat niet hetzelfde is, afhankelijk van de programma's en de geladen SW-bestanden.
Heel belangrijk ook  schijfinteracties, want dit speelt ook een rol aangezien SW veel aan geheugenwisseling doet en vooral aan schijfwisseling en dit geldt nog meer voor conversieprogramma's (die veel tussenresultaten opslaan).
Laatste punt, de frequentie van de processors varieert afhankelijk van de rekenbelasting en zoals gezegd het geheugengebruik.

Aan de andere kant is het voor de GPU doodstil.

Het is dus beter om voorzichtig te zijn bij het trekken van conclusies (zie uw PP en PPPS) die overhaast of zelfs onnauwkeurig kunnen lijken. Het zou nodig zijn om de gedetailleerde bank door Solidworks te kunnen laten maken om een zo gedetailleerd mogelijk oordeel te hebben.

Vriendelijke groeten

 

1 like