CPU Auslastung während Simulation LTSpice

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.

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.

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.

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.

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

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.

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.

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..