Wie bringe ich Java dazu, meinen Multi-Core-Prozessor mit GZIPInputStream zu nutzen?

Question

Ich verwende einen GZIPInputStream in meinem Programm, und ich weiß, dass die Leistung verbessert werden würde, wenn ich Java mein Programm parallel ausführen lassen könnte.

Gibt es generell eine Befehlszeilenoption für die Standard-VM, die auf vielen Kernen läuft? Im Moment läuft sie nur auf einem.

Gracias.

bearbeiten

Ich verwende Java SE 6 Update 17 unter Windows XP.

Würde es helfen, den GZIPInputStream explizit in einen separaten Thread zu legen? Nein! Legen Sie den GZIPInputStream nicht auf einen separaten Thread! Keine Multithread-E/A!

Bearbeiten 2

Ich vermute, dass E/A der Engpass ist, da ich auf derselben Festplatte lese und schreibe...

Gibt es jedoch eine Möglichkeit, GZIPInputStream generell schneller zu machen? Oder einen Ersatz für GZIPInputStream, der parallel läuft?

Bearbeiten 3 Verwendeter Codeschnipsel:

GZIPInputStream gzip = new GZIPInputStream(new FileInputStream(INPUT_FILENAME));
DataInputStream in = new DataInputStream(new BufferedInputStream(gzip));

Answer 1

Komprimierung und Dekomprimierung mit gzip ist ein serieller Prozess. Um mehrere Threads zu verwenden, müssten Sie ein benutzerdefiniertes Programm erstellen, um die Eingabedatei in viele Streams aufzuteilen, und dann ein benutzerdefiniertes Programm, um sie zu dekomprimieren und wieder zusammenzufügen. so oder so wird IO ein Flaschenhals sein, WEIT vor der CPU-Auslastung.

Answer 2

Führen Sie mehrere VMs aus. Jede VM ist ein Prozess, und Sie sollten in der Lage sein, mindestens drei Prozesse pro Kern auszuführen, ohne Leistungseinbußen hinnehmen zu müssen. Natürlich muss Ihre Anwendung in der Lage sein, Multiprocessing zu nutzen, um davon zu profitieren. Es gibt kein Patentrezept, weshalb in der Presse immer wieder darüber gejammert wird, dass wir noch nicht wissen, wie wir Multicore-Maschinen nutzen können.

Es gibt jedoch viele Leute, die ihre Anwendungen in einen Master strukturiert haben, der einen Pool von Arbeitsprozessen verwaltet und Arbeitspakete an diese verteilt. Nicht alle Probleme lassen sich auf diese Weise lösen.

Answer 3

Ich denke, es ist ein Fehler, anzunehmen, dass Multithreading IO ist toujours böse. Um sicher zu sein, müssen Sie wahrscheinlich ein Profil für Ihren speziellen Fall erstellen, denn:

• Aktuelle Betriebssysteme verwenden den derzeit freien Speicher für den Cache, und Ihre Dateien befinden sich möglicherweise gar nicht auf der Festplatte, wenn Sie sie lesen.
• Neuere Festplatten wie SSD haben viel schnellere Zugriffszeiten, so dass ein Wechsel des Leseortes weniger problematisch ist.
• Die Frage ist zu allgemein, um davon auszugehen, dass wir von einer einzigen Festplatte lesen.

Möglicherweise müssen Sie Ihren Lesepuffer so abstimmen, dass er groß genug ist, um die Umschaltkosten zu reduzieren. Im Grenzfall kann man alle Dateien in den Speicher einlesen und dort parallel dekomprimieren - schneller und ohne Verluste beim IO-Multithreading. Etwas weniger Extremes könnte aber auch besser funktionieren.

Sie müssen auch nichts Besonderes tun, um mehrere verfügbare Kerne unter JRE zu verwenden. Verschiedene Threads verwenden normalerweise verschiedene Kerne, die vom Betriebssystem verwaltet werden.

Answer 4

Sie können den Standard nicht parallelisieren GZipInputStream ist es einfädig, aber Sie können Pipeline Dekomprimierung und Verarbeitung des dekomprimierten Streams in verschiedene Threads aufteilen, d.h. den GZipInputStream als Producer und das, was ihn verarbeitet, als Consumer einrichten und sie mit einer begrenzten blockierenden Warteschlange verbinden.