Hallo, ich habe einen Computer mit einem I7-2600K CPU. Da ich öfters in LTSpice Simulationen laufen lasse, ist die CPU-Auslastung während die Simulation "berechnet wird" nie bei 100%. Obwohl die CPU Auslastung keine 100% erreicht, dauert die Simulation manchmal ziemlich lange (gerade wenn man einen kleinen Timestep wählt). Das ist doch nicht normal das die CPU Auslastung während des Simulationslaufes so gering ist, oder? mfg
:
Verschoben durch Moderator
max schrieb: > Das ist doch nicht normal das die CPU Auslastung während des > Simulationslaufes so gering ist, oder? Auf Mehrkernprozessoren ist es völlig normal, wenn trotz voller Auslastung eines Programms der Gesamtprozessor nur teilweise ausgelastet ist. Weil sequentiell arbeitende Software oftmals parallere Prozessorkerne nicht nutzt.
A. K. schrieb: > Auf Mehrkernprozessoren ist es völlig normal, wenn trotz voller > Auslastung eines Programms der Gesamtprozessor nur teilweise ausgelastet > ist. Weil sequentiell arbeitende Software oftmals parallere > Prozessorkerne nicht nutzt. mhm, dass ist aber blöd... Was bringen mir dann die neuesten und schnellsten CPU's wenn die Hälfte der Programme eh nicht schneller laufen kann...
max schrieb: > mhm, dass ist aber blöd... > Was bringen mir dann die neuesten und schnellsten CPU's wenn die Hälfte > der Programme eh nicht schneller laufen kann... du kann LTSpice mehrfach starten und verschiedene Simulationen gleichzeitig laufen lassen.
Du kannst während der Single-Core-100%-Simulation noch ruckelfrei surfen!
max schrieb: > mhm, dass ist aber blöd... Ja. Willkommen in der Realität von immer mehr Kernen. Das ist der moderne Ruder-8er ohne Steuermann. Einer rudert, sieben gucken zu. Und ab und zu wechseln sie vielleicht ab, um zu verschaufen. > Was bringen mir dann die neuesten und schnellsten CPU's wenn die Hälfte > der Programme eh nicht schneller laufen kann... Nichts. Weshalb es sein kann, dass man im gleichen Preissegment mit einem N-Kernprozessor besser dran ist als mit einem 2*n-Kerner, wenn schneller getaktet.
:
Bearbeitet durch User
Was mich interessieren würde: Welche im Handel erhältliche Hardware müsste man haben damit LTSpice maximal schnell simuliert?
max schrieb: > Was bringen mir dann die neuesten und schnellsten CPU's wenn die Hälfte > der Programme eh nicht schneller laufen kann... Der i7-2600K ist von 2012 - also bestimmt nicht die neuste CPU und schnellste CPU. i7-4790K kommt bis auf 4,4Ghz also schon mal 10% mehr und vermutlich ist er auch noch etwas effektiver damit wird es mindestens 20% schneller gehen.
max schrieb: > Hallo, > > ich habe einen Computer mit einem I7-2600K CPU. > > Da ich öfters in LTSpice Simulationen laufen lasse, ist die > CPU-Auslastung während die Simulation "berechnet wird" nie bei 100%. > Obwohl die CPU Auslastung keine 100% erreicht, dauert die Simulation > manchmal ziemlich lange (gerade wenn man einen kleinen Timestep wählt). > > Das ist doch nicht normal das die CPU Auslastung während des > Simulationslaufes so gering ist, oder? Nein, ist es nicht... Zumindest hier auf einem 6-Core-AMD geht die CPU-Last aller Cores während einer längeren Simulation auf 100%. LTspice unterstützt Multithreading/cores afair seit der ersten IV-Version von 2009. Ansonsten mal im Menü unter Tools -> Control Panel -> Spice nachsehen welcher Solver und wie viele Threads da eingestellt sind.
:
Bearbeitet durch User
Arc Net schrieb: > Ansonsten mal im Menü unter Tools -> Control Panel -> Spice nachsehen > welcher Solver und wie viele Threads da eingestellt sind. solver: normal threads: 8
max schrieb: > Arc Net schrieb: > >> Ansonsten mal im Menü unter Tools -> Control Panel -> Spice nachsehen >> welcher Solver und wie viele Threads da eingestellt sind. > > solver: normal > threads: 8 Und der Matrix-Compiler auf object-code? Dann sollte das eigentlich funktionieren
LTspice bestimmt vor Beginn der Simulation, nach im Programm festgelegten Kriterien z. B. Schaltungsgröße, die Anzahl der verwendeten "Cores". Leider kann man das nicht selbst vorgeben.
Arc Net schrieb: > Und der Matrix-Compiler auf object-code? Dann sollte das eigentlich > funktionieren Geeignetes Beispiel parat, um die Kernauslastung gut zu sehen?
NT schrieb: > Arc Net schrieb: >> Und der Matrix-Compiler auf object-code? Dann sollte das eigentlich >> funktionieren > > Geeignetes Beispiel parat, um die Kernauslastung gut zu sehen? Z.B. 3722-1.asc oder 3870.asc aus dem Examples-Ordner
Arc Net schrieb: > NT schrieb: >> Arc Net schrieb: >>> Und der Matrix-Compiler auf object-code? Dann sollte das eigentlich >>> funktionieren >> >> Geeignetes Beispiel parat, um die Kernauslastung gut zu sehen? > > Z.B. 3722-1.asc oder 3870.asc aus dem Examples-Ordner Oh ja. Gut zu sehen. Vielen Dank. ;)
schaffe mit dem 3722-1.asc nicht über 80% CPU auslastung....
Bei mir mit einer älteren Intel quadcore CPU sind bei Simulationen alle Kerne zu 100% ausgelastet - bei mittelgrossen Schaltungen. Bei kleineren habe ich noch nie drauf geachtet.
ok, habe jetzt 2-mal LTSpice offen und lasse die Simulationen gleichzeitig ablaufen, jetzt hab ich 100% CPU auslastung:
max schrieb: > schaffe mit dem 3722-1.asc nicht über 80% CPU auslastung.... Evtl. liegt das daran, dass die Festplatte die CPU beim Schreiben der Ergebnisdaten ausbremst, weil sie entweder zu langsam ist und/oder zu wenig Schreibpuffer (auf Festplatten- oder OS-Seite) vorhanden ist. Ich weiß nicht, wie die Angabe "98% Zeit mit max. Aktivität" in der Zeile "Datenträger" zu interpretieren ist, aber vielleicht ist das genau ein Indiz für obige Vermutung. Dass bei zwei simultan laufenden Simulationen die CPU-Auslastung 100% ist, kann daran liegen, dass sich die beiden Prozesse nach einer kurzen "Einschwingphase" so synchronisieren, dass immer, wenn der eine gerade Daten auf die Festplatte schreibt, der andere den nächsten Schwung an Daten berechnet.
Yalu X. schrieb: > "Einschwingphase" so synchronisieren, dass immer, wenn der eine gerade > Daten auf die Festplatte schreibt, der andere den nächsten Schwung an > Daten berechnet. Festplattenlast kannst du vergessen. Wenn die Software nicht völlig bekloppt ist, dann landet das in einem Puffer vom Betriebssystem und der wiederum etwas später per DMA auf der Platte. Verzögerung Null, Last nahezu Null. Um davon ernsthaft etwas mitzukriegen musst du schon gut in den Bereich 2-3stelliger MB/sec gehen, je nachdem ob HDD oder SSD. Das wird die Simulation kaum hergeben.
:
Bearbeitet durch User
Ich habe die Erfahrung gemacht, dass es auch vom OS abhängt. Zuerst meine Simulation unter WinXP laufen lassen. Beider Kerne voll ausgelastet, dauert es 1:27, bis die Simu durch ist. Dann PC rebootet, Linux geladen und LTSpice unter wine zum Laufen gebracht. Selbe asc-Datei läuft hier nur 1:03. Im Control Panel bei beiden überall "Reset to default", versaut mir unter Win irgendetwas die Show (Virenscanner?).
Yalu X. schrieb: > Evtl. liegt das daran, dass die Festplatte die CPU beim Schreiben der > Ergebnisdaten ausbremst, weil sie entweder zu langsam ist und/oder zu > wenig Schreibpuffer (auf Festplatten- oder OS-Seite) vorhanden ist. Gibt es da eine Idee, was man für Platten nehmen soll und wieviel die Platte an Zeit ausmacht, beim Simulieren? Ich stelle gerade einen PC zusammen: Beitrag "Konfiguration eines FPGA-PCs"
A. K. schrieb: > Festplattenlast kannst du vergessen. Wenn die Software nicht völlig > bekloppt ist, dann landet das in einem Puffer vom Betriebssystem und der > wiederum etwas später per DMA auf der Platte. Verzögerung Null, Last > nahezu Null. write() ist ein Syscall. Syscalls sind wegen Kontextwechsel nicht kostenlos, auch auf High-end CPUs. Die Simulation müsste intelligent genug sein die Daten MB-weise wegzuschaufeln, das ist aber eher nicht Erwartungswert.
Jim M. schrieb: > write() ist ein Syscall. Syscalls sind wegen Kontextwechsel nicht > kostenlos, Ein Syscall impliziert nicht zwangsläufig einen Kontextwechsel. > auch auf High-end CPUs. Auf Highend-CPUs kannst du aberhunderte von MB/s wegschaufeln, ohne dass die ins Schwitzen kommen.
:
Bearbeitet durch User
Hier gehts auch so wie man sichs vorstellt. Verstehe nicht warum das bei manchen hier nicht klappt. Mir fällt kein anderer Flaschenhals als die cpu ein, genug Daten damit die hdd bremst kommen hier bestimmt nicht zusammen..
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.