Windows und mehrere CPU-Kerne

wern001

Admiral
Registriert
Mai 2017
Beiträge
8.789
Wieso unterstützen Windows-Funktionen so schlecht mehrere Kerne?
z.B
Miniatur-Vorschau erstellen läuft nur auf einem Kern. Wenn Windows meint den einen Ordner mit ca 2000 Bilder (a 25 MB pro Bild) neu zu erstellen dauert das wieder ewig. 1 CPU-Kern auf 90-95
Druckerspooler läuft auch nur auf einem CPU-Kern. So eine 400-600 MB Spooldatei (Fotoausdruck für A0) auf einer SSD zu erstellen dauert gefühlt eine Ewigkeit während nur 1 CPU-Kern auf max läuft
 
  • Gefällt mir
Reaktionen: Foxel
Die Frage ist nicht warum nutzt Windows nur einen Kern ...

sondern eigentlich kann man diese Aufgaben überhaupt parallelisieren ...

Druckerspool wird wohl einfach nicht gehen liegt einfach an der Sache das eine Aufgabe nicht unendlich zerkleinert werden kann. Da ja nur ein Auftrag erstellt wird.

Genauso wie mit der Vorschau du erstellst ja nur eine Tump Datei ... ergo muss man sich Fragen können mehrere Kerne auf die gleiche Datei schreiben ... wohl nicht.
 
  • Gefällt mir
Reaktionen: dominic.e, conf_t und Flomek
Hast du eine sehr alte CPU, die nur 1 Kern hat, oder ist im Windows Taskmanager die Grafik noch auf "Gesamtauslastung" eingestellt ? Rechtsklick aufs Diagram und "logische CPUs" auswählen.

Ansonsten das übliche ; Windows is...halt Windows, ob man Win10 128 Kerne/1024Gb Ram und eine Festplatte mit 20Gb/sec zur verfügung stellt, anfangen kann es damit nicht wirklich viel, bzw immer nur soviel wie gut die einzelnen Funktionen/Programme/Spiele programmiert sind und in der Lage sind Befehlsketten zu verteilen.
 
gerade das erstellen der thumbs ist wunderbar parallelisierbar. natürlich rechnen nicht mehrere prozesse an einem bild rum, dafür könnte man aber mehrere bilder gleichzeitig bearbeiten.

die eigentliche frage ist aber müßig, microsoft wird hier nicht mitlesen :)
 
xxMuahdibxx schrieb:
ergo muss man sich Fragen können mehrere Kerne auf die gleiche Datei schreiben ... wohl nicht.

So einfach ist das aber auch nicht. Das ganze besteht aus einlesen der Dateien, generieren der Thumbnails, sowie schreiben des Caches. Alle Abchnitte lassen sich parallel abarbeiten, das Einlesen an sich ist nicht wirklich parallelisierbar, da limitiert i.d.R. der Datenträger und sequentielles Lesen ist sowieso am schnellsten, das Generieren lässt sich dagegen sowohl durch die einzelnen Bilder, als auch - zumindest bei einigen Codecs - pro Bild parallelisieren.

Die Frage ist was für 90% Auslastung das sind auf dem Kern, ist das wirkliche Arbeit, oder einfach nur I/O-Wait (warten auf Daten).
 
das erstellen der Miniaturansichten wäre doch optimal zum parallelisieren? Mehrere Dateien gleichzeit einlesen
Das schreiben in eine Datei wird doch wohl die wenigste Zeit in Inanspruch nehmen. Auch das lesen der Dateien ist bei weitem nicht am Limit des Netzwerks. es werden nur ca 25 mb/sek gelesen. Das Raid5 schaft auf dem Server ca 450-500 MB/sek
 
Ich würde für so Aufgaben mal IrfanView o.ä. ausprobieren. Batchjobs werden von Drittanbietern gerne besser erledigt, als von Windows "intern".
 
Das IrfanView Thumbnails läuft auch nur auf einem CPU-Kern.
Ich arbeite halt viel mit Bilder (Illustrator, Photoshop, Gimp...) und diese Miniaturansichten im Explorer sind halt eine feine Sache. Wenn Windows nicht der Meinung ist alle Miniaturansichten zu löschen und neu zu erstellen.
 
Zuletzt bearbeitet:
Zum gleichzeitigen Einlesen von mehreren Bildern/Verzeichnissen müsste der Prozess aber auch zwischen HDDs und SSDs unterscheiden. Bei einer HDD sind mehrere gleichzeitige Zugriffe ja eher kontraproduktiv und verlangsamen den Gesamtprozess. Ich denke aber auch einfach, dass ein Betriebssystem viele seiner Systemprozesse nicht auf Mehrkernbetrieb optimiert. Pro Prozess ein Thread = Ein Kern wird beschäftigt. Da ein Betriebssystem ja ständig viele Systemprozesse am Laufen hat, ergibt sich durch die vielen gleichzeitigen Threads ja schon eine Verteilung auf die Kerne, nur dauern diese Prozesse halt oft nur Millisekunden, dass man die Auslastung in der Statistik nicht sieht..
 
Das einlesen ist doch gar kein Problem dafür sind die Datenraten der Datenträger einfach zu gering... die Frage ist wie wird die Datei erstellt und gespeichert/zwischengespeichert.

Auch ein RAID bringt da nicht viel beim Speed ( wenn er aus HDD´s besteht ) ... da ja die Bilder eher kleine Datein sind ist die zugriffszeit am wichtigsten.
 
Eine weitere Sache (so aus Unternehmenssicht):
Die Frage ist doch auch, in welchem Verhältnis der Aufwand für eine solche Anpassung zum entstehenden Nutzen steht.
Das muss sich auch rechnen.
Auch unter der Berücksichtigung, wie viele der gesamten Anwender von der Änderung auf welche Art betroffen sind.
 
puri schrieb:
. Ich denke aber auch einfach, dass ein Betriebssystem viele seiner Systemprozesse nicht auf Mehrkernbetrieb optimiert. Pro Prozess ein Thread = Ein Kern wird beschäftigt. ..

Also bei mir laufen lt. Taskmanager 134 Prozesse auf 1738 Threads. Das System an sich läuft auf 143 Threads, der Explorer nutzt 88 usw. Kannst davon ausgehen dass die bei MS wissen was sie tun.
 
  • Gefällt mir
Reaktionen: hroessler und Aduasen
1. Bilder einlesen ist nicht CPU-abhängig sondern Datenträger-abhängig.
Festplatten liefern unter 180 MByte/Sek. SSDs liefern ca. 500 MByte/Sek. M.2 max. 4 GByte/Sek.
Selbst ein Kern sollte die Bilder von HDD und Sata-SSDs problemlos alleine schaffen.

2. Druckerspooler: Das langsamste am gesamten Prozess ist der Drucker selbst.
Hochkomplexe Bilder (PS, PDF etc.) brauchen eher RAM als Rechenpower um die Daten aufzuarbeiten.
Bei GDI-Druckern (Tintenpisser) werden dann die Rohdaten (große Mengen) übertragen.
Da ist dann eher USB2.0 bzw. 100MBit-Lan das Nadelöhr.
 
  • Gefällt mir
Reaktionen: areiland
Auf lokaler SSD einen Ordner in Vollbild mit .cr2 von Detailansicht auf Große Symbole umstellen dauert hier ziemlich exakt 6 Sekunden bis alle 128 sichtbaren Bilder mit insgesamt 2,4GB konvertiert sind. Macht ~400MB/s.
 
Ich hab hier mal eben den Test gemacht:

Zwei Ordner mit verschiedenen Medieninhalten jeweils auf zwei Rechnern geöffnet.
Alles liegt auf der jeweiligen System-SATA-SSD des Rechners (Samsung Evo 850).

Rechner 1: Ryzen 1600, 16 GB RAM, SSD: Evo 850 2,5" SATA, Windows 10 + Windows Explorer
Rechner 2: Core i5 6200U, 8 GB RAM, SSD: Evo 850 M.2 SATA OEM, Kubuntu 18.04 + KDE Dolphin

Ordner 1 mit ca 700 JPG-Bildern, gesamt etwa 400 MB.
Ordner 2 mit ca 1100 MP4/H264-Videos, gesamt ca 92 GB.

Ergebnis:
Das eigentlich weit schwächere Notebook ist deim Aufbau der Miniaturansichten bei beiden Ordnern schneller. CPU-Auslastung kurz bei 80-100% auf allen 4 Threads und fertig. Währenddessen dümpelt der Windows-Rechner bei insgesamt 12% Auslastung (quasi 1,5 genuzte Kerne) dahin und braucht gefühlt doppelt so lange bis die Miniaturansichten angezeigt werden.

Fazit:
Windows schleppt Altlasten aus mehreren Jahrzehnten mit sich herum. Als es noch keine SSDs gab, limitierte bei solchen Tasks die langsame Festplatte oder eine Single Core CPU. Seitdem hat sich MS einfach nicht die Mühe gemacht, den Explorer multithreaded zu machen.


Wär doch mal interessant, wenn CB sich des Themas annehmen würde und mit 2x gleicher Hardware und professionellen Messmethoden die Geschwindigkeit von solchen Alltagsaufgaben zwischen Windows und Linux vergleichen würde.
 
CastorTransport schrieb:
Ich würde für so Aufgaben mal IrfanView o.ä. ausprobieren.

Ich Linux :)
Da klappt Multicore bei den Thumbs :daumen:

masterw schrieb:
Windows schleppt Altlasten aus mehreren Jahrzehnten mit sich herum. Als es noch keine SSDs gab, limitierte bei solchen Tasks die langsame Festplatte oder eine Single Core CPU. Seitdem hat sich MS einfach nicht die Mühe gemacht, den Explorer multithreaded zu machen.

0x8100 schrieb:
die eigentliche frage ist aber müßig, microsoft wird hier nicht mitlesen :)

Und da sind die wohl passenderen Antworten ;)
 
  • Gefällt mir
Reaktionen: masterw
Das wird ihm aber wenig helfen wenn er von seiner NAS bei kleineren Dateien nur 25MB/s bekommt und auch Windows lokal, selbst von HDD, zigfach schneller wäre.
 
Zurück
Oben