Java7: Faszination File AIO ...

[GUI-Programmer]

Hier nochmal alles komplett in 4 Bilder ausgedrückt.

 

[tuxedo]

Wer's selbst testen will und ggf. nicht genug Speicher hat: Einfach die "count" Variable ein wenig runterschrauben...

Wieso schreib ich eigentlich dazu dass man den "count" ggf. runtersetzen soll um den Heap nicht zu fluten wenn's keiner liest?!?

Denn gnau das passiert bei dir... 10Mio Einträge scheinen bei dir nicht so ohne weiteres in den Speicher zu passen.. :autsch:

Manchmal hilft's wenn man 1 und 1 zusammen zählt.

--> RTFM :rtfm:

 

[tfa]

Hier nochmal alles komplett in 4 Bilder ausgedrückt.

Tut mir leid, Dropbox kann ich hier nicht aufrufen.

 

[tuxedo]

@tfa

Brauchst du auch nicht. Ist ein klassicher "OutOfMemory" Fehler. Hab mal exemplarisch eins der 4 Bilder angehängt.

 

[GUI-Programmer]

OK, der Fehler lag bei der Person vor der Tastatur!

Hab es nun hinbekommen mit 9 000 000 Einträgen (count). Aber mal was anderes:
1. Warum muss man nach jeden Durchlauf die HashMap.dat wieder löschen, da ansonsten diese Exception hier fliegt:

Creating map: 43ms
Adding key: 0
Adding key: 1000000
Adding key: 2000000
Adding key: 3000000
Adding key: 4000000
Adding key: 5000000
Adding key: 6000000
Adding key: 7000000
Adding key: 8000000
Filling map takes 10701ms
Start writing...
done writing.
File has size: 216000016
Writing takes 811 ms
Write-Speed: 266.3378742293465 mb/sec
Start reading + filling map...
map has size: 9000000
Exception in thread "Thread-4" java.nio.BufferUnderflowException
	at java.nio.Buffer.nextGetIndex(Unknown Source)
	at java.nio.HeapByteBuffer.getLong(Unknown Source)
	at Java7FileAioTest.readSet(Java7FileAioTest.java:244)
	at Java7FileAioTest.access$1(Java7FileAioTest.java:239)
	at Java7FileAioTest$2.completed(Java7FileAioTest.java:51)
	at Java7FileAioTest$2.completed(Java7FileAioTest.java:1)
	at sun.nio.ch.Invoker.invokeUnchecked(Unknown Source)
	at sun.nio.ch.Invoker.invokeUnchecked(Unknown Source)
	at sun.nio.ch.WindowsAsynchronousFileChannelImpl$ReadTask.completed(Unknown Source)
	at sun.nio.ch.Iocp$EventHandlerTask.run(Unknown Source)
	at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

2. Warum liegt bei mir die beste Schreibgeschwindigkeit um die 208 Mb/s bei etwa 7 000 000 Einträgen? Weniger und mehr Einträge geben eine schlechtere. Inwiefern hängt das mit den Cache zusammen?

3. Wow!!! Eine Schreibgeschwindigkeit von 208 Mb/s!!! CrystelDiskMark und normales Kopieren mit den Windows-Explorer erreichen in etwa 150 Mb/s!!!

 

[tuxedo]

1. Warum muss man nach jeden Durchlauf die HashMap.dat wieder löschen, da ansonsten diese Exception hier fliegt:

Wirf doch mal zur Abwechslung einen Blick in den Code...

Aber gut, weil ich so guter Dinge bin verrat ich's dir: Beim zweiten Start werden die Daten einfach angehängt, aber das programm geht davon aus dass dem nicht so ist. Ergo passt die Implementierung nicht mehr zur Datei. Deshalb der Fehler. Ich war bis dato einfach zu faul das zu ändern...

2. Warum liegt bei mir die beste Schreibgeschwindigkeit um die 208 Mb/s bei etwa 7 000 000 Einträgen? Weniger und mehr Einträge geben eine schlechtere. Inwiefern hängt das mit den Cache zusammen?

Kann ich dir nicht sagen. Hab Windows nicht implementiert. Linux übrigens auch nicht ;-)
Was hälst du davon wenn du versuchst es raus zu finden?

3. Wow!!! Eine Schreibgeschwindigkeit von 208 Mb/s!!! CrystelDiskMark und normales Kopieren mit den Windows-Explorer erreichen in etwa 150 Mb/s!!!

Du kannst auch Äpfel mit Birnen vergleichen: "Wow, Äpfel sind viel runder als Birnen."

Mein Test schreibt 1Mio Einträge á 12bytes pro Schreibaktion. macht rund 1,2MB Blockgröße. Evtl. benutzt Windows und dein Benchmark eine andere Blockgröße?
Und wie hier schon erwähnt wurde: Je mehr man kopiert (insgesamt) desto eher stößt man an die Grenze des Caches. Hat man die Grenze erreicht, bricht die Geschwindigkeit ein. Mit 9Mio Einträgen in der Map bist du bei nur 108MB. Hier wurde aber von Cache-Grenzen bei 300MB berichtet... Womit wir wieder beim Thema Äpfel und Birnen wären..

Und um's nochmal klarzustellen:

Dieser Test sollte nur zeigen dass Java überhaupt solch einen "hohen" Durchsatz (mit Hilfe von AIO) schafft. Das ist kein Festplattenbenchmark oder ähnliches....

- Alex

 

[GUI-Programmer]

Beim zweiten Start werden die Daten einfach angehängt, aber das programm geht davon aus dass dem nicht so ist.

Also einfach vorher das FileSystem überprüfen ob die Datei bereits existerst und wenn ja, dann löschen. Oder gibts einen besseren Vorschlag, sodass die Datei nicht gelöscht und erstellt werden muss?

Mein Test schreibt 1Mio Einträge á 12bytes pro Schreibaktion. macht rund 1,2MB Blockgröße. Evtl. benutzt Windows und dein Benchmark eine andere Blockgröße?

OK, dann weiß ich bescheid. Werd das ganze mal nochmals auf ganz unterschiedlichen Systemen testen:
- 5 Jahre alter PC mit Windows XP
- Ubuntu 11.10 in meiner VirtualBox
- Netbook Asus Eee PC R105 mit Intel Atom, 2Gb RAM und Windows 7 Starter
Melde dann irgwann das Ergebnis.

 

[tuxedo]

Und was will uns das Ergebnis dann sagen? Dass es auf furchtbar langsamen/alten Maschinen langsamer geht und auf super schnellen ggf. schneller? Das wissen wir mittlerweile.

Interessant wird's erst, wenn du bei gleichen Vorrauseetzungen und Parametrisierung mit einer anderen Implementierung auf der gleichen Maschine mehr hin bekommst wie mit AIO...

 

[GUI-Programmer]

Und was will uns das Ergebnis dann sagen? Dass es auf furchtbar langsamen/alten Maschinen langsamer geht und auf super schnellen ggf. schneller? Das wissen wir mittlerweile.

Interessant wird's erst, wenn du bei gleichen Vorrauseetzungen und Parametrisierung mit einer anderen Implementierung auf der gleichen Maschine mehr hin bekommst wie mit AIO...

OK, du hast ja eigentlich Recht. Das mit den unterschiedlichen Systemen ist wahrscheinlich nur für mich interessant. Und *mehr hin bekommen* werde ich wahrscheinlich vorerst nicht, aber interessant wärs schon.

 

[Reality]

Gibt es eigentlich irgendwelche Tutorials bzgl. CompletionHandler, Future, Semaphore, ByteBuffer?

Danke im Voraus.
Reality

 

[tuxedo]

CompletionHandler sind AFAIK neu seit Java7. Für den Rest gibt's tonnenweise Doku im Netz, da schon seit Java5 (oder früher?) verfügbar. Schau ma besten mal in die Java Insel...
Wie CompletionHandler funktionieren zeigt ja mein Sample. Mir fällt jetzt spontan auch nicht ein was es dazu noch mehr zu erklären gäbe (was nicht schon im JavaDoc steht)?! Ist ja nicht wirklich "kompliziert", man muss nur anders denken... Von Java Seite wirft man das ganze nur einmal an und übergibt einen CompletionHandler. Der wird dann von <irgendwo aus der JVM> gerufen wenn die losgetretene Aktion fertig ist. Der Trick ist, mit einem CompletionHandler die nächste Aktion auszulösen und erneut einen CompletionHandler zu übergeben. Damit geht das Spiel von vorne los. Und das eben so lang, bis man entscheidet "so, genug jetzt, keine weitere Aktion und somit auch kein CompletionHandler mehr".

- Alex