Bekannte in Java geschriebene Software?

Java-Forum Allgemeine Themen
101

[QUOTE=HBerger]Also ich weiss nicht ob ich eine andere Wahrnehmung habe …
Aber „guten“ sprich optimierten C/C++ Programmen fühlt man es an … Der unterschied wird geringer, aber trotzdem …
nimm mal eclipse und nen VS … klar schwer zu vergleichen, aber so kleinigkeiten wie menues öffnen, nen file auswahl dialog anzeigen … geht alles flotter.
Was natürlich nicht heissen muss, das VS generell schneller ist ^^ das kann man eh kaum vergleichen. Aber trotzdem fühlen sich java anwendungen generell „zäher“ an, find ich.

und eclipse ist noch nen positver fall von optimierten java …
[/QUOTE]

Ich arbeitete mal mit VS, und es fühlt sich wesentlich langsamer an als Eclipse. Auch wenn ich z.B. Firefox mit Eclipse vergleiche, die Dialoge und Menus öffnen sich bestimmt nicht schneller in Firefox.

Ich denke das ist eher psychologisch bedingt. In deinem Kopf denkt du immer: Java und Swing sind viel langsamer, native C++ Anwendungen sind schneller. Ich habe noch nie einen Unterschied in solchen minimalen Sachen wie Dialoge und Menüs gemerkt. Auch der Editor in Eclipse is genauso schnell wie in z.B. Kile (KDE/Qt Texteditor). Ich habe auch Graphen mit JFreeChart und andere Chart-Bibliotheken anzeigen lassen und die sind auch sehr flott.

Also Programmierer müsstest du wissen, dass a) Java Swing ist Hardware-Beschleunigt wie auch andere C++ Toolkits; b) 99,9999% der Zeit verbringt eine GUI Anwendung mit warten, warten auf User-Eingabe.

Du Vergleichst Äpfel mit Birnen. Wieso hast du nicht xerces-j benutzt?
Hier ist ein Benchmark einer Menge XML parser:
http://xmlbench.sourceforge.net/results/benchmark/
xerces-j und xerces-c sind fast gleich schnell.

[QUOTE=HBerger;70495]

Das Programm was die erzeugt ist uebrigens nen Java programm- frontend zu ner DB. der export dieser datei dauert im 20 min bereich.
früher hatten wir nur nen java parser … mussten den in nen c++ modul packen mittels jni um das laufen zu koennen …
das hat auch zig minuten gebraucht.

Ob solche mengen mit DOM zu parsen sinnvoll ist, ist ne andere frage, aber nur der „laufzeitunterschied“ ist schon gravierend

Ich mach hier Messdaten auswertung. Ich krieg datenstroeme von bis zu 20Mbit und muss die „online“ auswerten.
Dazu muss ich packete in signale zerlegen nach ner Vorschrift aus ner DB klar … und die Werte „validieren“.
bei bis zu 800k Packete/s …
Selbst ohne die Hw anbindung zu betrachten, die datenmengen kriegst in java nie hin … da fehlt einfach der direkte speicherzugriff. ich kann mir selbst unter c++ nicht erlauben, alles als object zu bauen.
Aber als HW Nahe programmierung wuerd ich das dann auch noch nicht bezeichnen …

Ciao …[/QUOTE]

Sicher dass du die Datenmenge nicht hinkriegst? Hast du es den versucht?
Java hat auch direkten Speicherzugriff: NIO.

Für Socket gibt es z.B.
Raining Sockets - High Performance IO in Java http://jniosocket.sourceforge.net/
High Performance Java Fast Sockets http://torusware.com/nevonproducts/jfs/

*** Edit ***

[QUOTE=HBerger;70557]Intressant …

Wir haben ein „Project“ das „scheitert“ grad an der performance.
Das heisst unsere SW liefert Signal-Werte interpretiert (double) oder ints und nen Zeitstempel(8 byte) so 8-12k pro sec.
die bekommen das per JNI injiziert (die laufen in einer von unserem Prozess aufgezogenen JVM)
die versuchen die werte zu nehmen, simple vergleiche zu machen <>== gegen Werte aus ner DB und schreiben die ergebnisse in ne konsole und log.
Die Fehler die sie finden sind gering, also IO ist ueberhaupt nicht das Problem …
nur kommen sie trotzdem mit der Input-Datenmenge nicht klar …
laut deren aussage kann java keine 8k/s Instanzen pro Sek instanziieren, und damit scheitert die sache schon an der Übergabe per JNI …
Vielleicht ist es auch JNI selber, keine Ahnung …
Ciao …[/QUOTE]

Schon mal versucht einen Profiler einzusetzen?
Auch andere Strategien einzusetzen, 1000de von Instanzen zu erzeugen ist nicht wirklich das optimale.

*** Edit ***

[QUOTE=CCMike;70561]Rein am instanzieren wirds wohl nicht liegen:

Damit schaff ich 300 millionen instanzierungen im ersten durchlauf und 390 wenn die vm warmgelaufen ist.

Aber ja, sobald man beginnt was zu berechnen/überprüfen geht die zahl schnell runter.[/QUOTE]

Du musst auch bedenken, dass die Instanzen wieder von dem GC aufgeräumt werden müssen.
Besser ist das Flyweight Pattern.

102

[QUOTE=devent]
Also Programmierer müsstest du wissen, dass a) Java Swing ist Hardware-Beschleunigt wie auch andere C++ Toolkits
.[/QUOTE]

Da Eclipse nicht auf Swing basiert ist das Argument etwas merkwürdig.

Eclipse ist auf jedenfall langsamer als eine Delphi, .NET, Qt oder was auch immer Anwendung. Man muss nur mal zwischen mehreren Perspectives wechseln, das läuft alles andere als flüssig.

103

300 millionen instanzierungen im ersten durchlauf und 390 wenn die vm warmgelaufen ist

Boah, so gut optimiert die msvc runtime ned ^^ im release schaff ich keine 100mille news/s. und debug brauchen wir nicht reden :slight_smile:
Vielleicht hasst auch die dickere Maschine :slight_smile:

Aber generell.
Da sitzen mehrere leute mir „jahrelanger Erfahrung“ in Java dran, und die meinen es geht nicht.
Ich selbst kenn mich mit Java ned so aus…
Ich kann mir aber vorstellen, dass man da auch ne Menge „optimieren“ /tricksen kann … besonders wenn man die Allokierungen „verhindert“, oder dem GC bissi auf die Sprünge hilft … oder oder, keine Ahnung.
Nur ist das dann noch Java ? Die Philosophie ist doch, everything is an Object, und destroy later, sometimes …

Ciao …

*** Edit ***

@ CCMike
Ahh sehs grad, in dem Beispielcode allokierst du threaded :slight_smile: ?
Ich hab nur die c++ ST methode getestet :slight_smile:

dein Code auf meiner maschine(4 cpus ohne HT) gehen grad mal
159.342.468 max mit der Standard Java VM.
Das sollte aber auch in ST mehr als ausreichend sein …

muss also an was anderem liegen …

Reine Arithmetische operationen solltens auch ned sein, da sollte die JVM ebenfalls so schnell sein wie c++
Double sollte Java auch kennnen …
Keine Ahnung wie schnell Java bei bitmanipulation ist …
wie „schnell“ koennt Ihr aus nem Array von 32 Byte z.b. die Bits von posi 11 - 19 extrahieren und als unsigend int64 ablegen ?

Ansonsten koennt nur noch JNI die Schwachstelle sein …
@devent

Schon mal versucht einen Profiler einzusetzen?

Ich arbeite nicht mit Java produktiv. Ich schau es mir grad an, aber wegen themen die nicht so viel mit performance zu tun haben.
Profiler ? sowas gibts auch ? :slight_smile:

Auch andere Strategien einzusetzen, 1000de von Instanzen zu erzeugen ist nicht wirklich das optimale.

Japp, unter c++ vermeide ich news wie die Pest, wenns um performance geht.

Flyweight Pattern

Sowas gibts auch unter java?
Glaub ich muss noch viel lernen …

Ciao …

*** Edit ***

Ich arbeitete mal mit VS, und es fühlt sich wesentlich langsamer an als Eclipse.

Bei Visual Studio musst aufpassen auch mit dem Betriebssystem. M$ will ja auch neue Versionen verscherbeln, da muss es auch nen Grund zu liefern :slight_smile:
So verwendet VS die WFC (Windows Foundation Classes).
In Ihrer jeweiligen Version schaffen sie es die Befehe direkt an die WInapi abzusetzen, wenn die OS version stimmt, bzw drüber ist. Ansonsten „emulieren“ sie irgendwas. und das ist echt „lahm“.
Also brauchst fuer die entsprechende VS Version auch die entsprechende OS version, sonst fühlt es sich an wie Kaugummi ^^
vs 2005 - windows XP
VS 2010 - windows 7
Vs 2012 - windows 8
…

Ich hatte vs2010 auf XP, das war echt keine Freude ^^
selbe machnine nu mit win7 Firmenclient, echt flüssig dagegen !

hab auch 2012 drauf - ne Katastrophe hier.
Zu hause aufn Ultrabook mit weniger cpu (i3) weniger ram (4GB) aber windows 8 echt flüssig.

So kann man auch neue OS versionen an den Mann bringen :slight_smile:

Ciao …

104

In Java gibts keine unsigned Integer. Wenn man mehr als signed int64 (long) braucht, dann muss man auf BigInteger ausweichen, was extrem langsam wird.

105

[QUOTE=deetee]Da Eclipse nicht auf Swing basiert ist das Argument etwas merkwürdig.

Eclipse ist auf jedenfall langsamer als eine Delphi, .NET, Qt oder was auch immer Anwendung. Man muss nur mal zwischen mehreren Perspectives wechseln, das läuft alles andere als flüssig.[/QUOTE]

Wieviel RAM hast du der Eclipse JVM zugewiesen?
Ich sehe nämlich oft dass nur die Standardeinstellung benutzt wird, obwohl der Computer viel mehr RAM hat. In der eclipse.ini kann man das einstellen, wenn man mehr RAM zuweist, dann läuft Eclipse auch wesentlich flotter. Native Programme haben so eine Einstellung nicht, die können soviel RAM verbrauchen wie sie wollen. Aber da Java unter einer virtuellen Maschine ausgeführt wird, kann dies zu Problemen führen.

eclipse.ini:
-Xms1024m
-Xmx4048m

*** Edit ***

BigInteger ist nicht auf Schnelligkeit optimiert.
Vllt. ist Java GMP die bessere Wahl: https://bitbucket.org/dfdeshom/gmp-java/overview

106

Vllt. ist Java GMP die bessere Wahl: https://bitbucket.org/dfdeshom/gmp-java/overview

Wenn ich für nen datentyp soweiso ne Brücke zu ner anderen runtime(JNI → c) brauche, dann kann ich doch echt gleich den performancekritischen Code in der runtime (c) schreiben, und nur die ergebnisse / Statistic ans „langsamere“ subsytem liefern.
Da wären wir quasi wieder fast am Anfang :smiley:

„Theorethisch“ gäng es auch mit 32bit Integers, aber mit mehr Aufwand …
Theorethisch und laut Standard kann ich Signale > 32 bit haben, praktisch hab ich aber noch keines gesehen zumindest nicht bei uns.
Was ich aber definitiv habe, sind 32 bit signale, aber einmal signed codiert und einmal unsigned. d.h. ich muesst fuer die Berechnung grundsätzlich 2 Wege bauen.
Das konnte man sich mit int64 sparen

Ciao …

107

[QUOTE=devent]Wieviel RAM hast du der Eclipse JVM zugewiesen?
Ich sehe nämlich oft dass nur die Standardeinstellung benutzt wird, obwohl der Computer viel mehr RAM hat. In der eclipse.ini kann man das einstellen, wenn man mehr RAM zuweist, dann läuft Eclipse auch wesentlich flotter. Native Programme haben so eine Einstellung nicht, die können soviel RAM verbrauchen wie sie wollen. Aber da Java unter einer virtuellen Maschine ausgeführt wird, kann dies zu Problemen führen.

eclipse.ini:
-Xms1024m
-Xmx4048m
[/QUOTE]

Ich hatte bisher -Xms1024m -Xmx2048m eingestellt. Da ich noch mit 1-2 virtuellen Maschinen lokal arbeite kann ich Eclispe leider nicht alles geben. Aber meiner Erfahrung nach ändert das auch kaum was an der GUI Performance, und darum geht es ja hier hauptsächlich. Eclipse verarbeitet mit mehr RAM die ganzen Arbeiten wie Build Workspace, Build Index o.ä. schneller, aber ein Wechsel der Perspective oder andere GUI Prozesse laufen nur bedingt flüssiger durch mehr RAM. Ein wenig aber schon, das stimmt, nur kommt es nicht an die Performance von non-Java Anwendungen ran. Ich fühle immer einen Unterschied. Allerdings muss man da schon unterscheiden, zwischen echten Java GUI Problemen und allgemeinen Problemen durch zu wenig Speicher. Bei zu wenig speicher verhält sich jede Anwendung besonders in der GUI langsam!

108

Sollte aber SWT nicht schneller sein als Swing(im Allgemeinen, ist ja groesstebteils nativ)…
Gut Swing eigentlich auch, aber ihr wisst was ich meine ;D

109

[QUOTE=groggy]Sollte aber SWT nicht schneller sein als Swing(im Allgemeinen, ist ja groesstebteils nativ)…
Gut Swing eigentlich auch, aber ihr wisst was ich meine ;D[/QUOTE]
Seit Jahren ist beides in etwa gleichschnell, da auch Swing seit Jahren OpenGL beschleunigung einsetzt.

110

Wie gesagt, man kann es ja an fast allen standard Java Implementationen beobachten …
Ich vermute auch nicht, das es das reine zeichnen auf der Gui bzw bei nativ Frameworks das absetzen der API Calls die ursache ist.

Sondern ich denk das es die Eventqueue ist.
Selbst wenn man die in C programmiert, braeuchte man einsprungpunkte zurueck nach Java (JNI oder aehnliches).
Wenn ich schaue was die Qt treibt um die Queues nicht bremsen zu lassen …
Wenn ich meine GUI Programme Profile, iss schon erstaunlich wie wild nen GUI programm in der loop umherspringen kann … ^^

Aber gewissheit koennen da nur proflier liefern …

Ciao …

111

Prominentes Beispiel ist auch eine Software im Teichenbeschleuniger in Bern:

112

[QUOTE=L-ectron-X]Prominentes Beispiel ist auch eine Software im Teichenbeschleuniger in Bern:
[/QUOTE]

A in Genf

B prominent? Bekannt?? Bei wem denn?

113

Ups. Haste Recht. In Genf.
Naja weniger bekannt, aber prominent auf alle Fälle. Ich fand die Erwähnung schon wert, dass dort in Java programmierte Software eingesetzt wird.

114

Interessanterweise auch der CUDA Visual Profiler: https://developer.nvidia.com/nvidia-visual-profiler

Ist eine Eclipse RCP Anwendung.

115

Fiel nicht mal was in Java programmiertes vom Himmel? :slight_smile:

116

Java zur Quantenteilchen-Urknall-Forschung auf nVidia-GPUs … wie weit es diese Sprache doch mitlerweile gebracht hat wenn man sich mal überlegt wofür sie eigentlich gedacht war.

Und natürlich : Minecraft … *scnr