Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.java > #13087

Re: Taktfrequenzen, Java und heise

Show all headers | View raw

In article <o5oo88$iar$1@gwaiyur.mb-net.net>, Marcel Mueller 
(news.5.maazl@spamgourmet.org) says...

> Die Probleme liegen z.B. bei der Speicherverwaltung. Java nutzt den zur 
> Verfügung gestellten Speicher aus. Wenn er nicht mehr reicht oder die 
> JVM Langeweile hat, wird aufgeräumt.
> Was sich theoretisch gut anhört, ist in der Praxis bei Servern manchmal 
> ein echtes Problem. Wenn nämlich mehrere JVMs auf einer Maschine laufen 
> und auch unter Feuer stehen, dann zieht jede JVM über kurz oder lange 
> den maximal zur Verfügung stehenden Speicher.

Erm. Nein.
Das kommt stark auf dein Programm an. 
oder um es ander zu sagen: Wenn das bei dir der Fall ist, dann hast du 
wahrscheinlich das Problem, dass deine Objekte zu lange leben, sodass 
die VM mit dem Aufräumen nicht mehr hinterher kommt, weil es zu viel in 
der Old Generation herum fuhrwerken muss. Will heißen: Alles, was eine 
Transaktion ausmacht, sollte wenn möglich mit einer minor collection 
verschwinden.

> Das begrenzt natürlich die 
> maximale Größe einzelner Transaktionen. 

Ich würde eher sagen: Die Dauer die die Transaktionsdaten im Speicher 
vorgehalten werden können.

> Fairerweise sei angemerkt, dass man am GC mittlerweile herumgeschraubt 
> hat. Wobei ich jetzt nicht weiß, was das lizenzrechtlich bedeutet.

Nichts, es sei denn, du möchtest eine Kommerzielle JVM, die JRockit oder 
Zing benutzen.
 
> Aber nichts für ungut: wer ernsthaft das letzte Quäntchen Performance 
> braucht und Java nutzt, hat den Schuss noch nicht gehört.

> >> Eine andere Seite der Realität ist allerdings, dass mir immer wieder
> >> erstaunlich ineffiziente Lösungen begegnen. Dabei geht es meist weniger
> >> um die einzelnen Code-Zeilen als um das ganze Datenmodell oder den
> >> Umgang mit redundanten DB-Zugriffen. Aber (schnelleres) Blech ist halt
> >> nun einmal billiger als Menschen.
> >
> > Seit ich mir Präsentationen von Leuten, wie Martin Thompson und Kirk
> > Pepperdine reinziehe, habe ich auch das Gefühl, dass auch davor noch
> > recht viel Luft nach oben ist.
> 
> ?
> 
> -v

Nunja, einfach mal auf Youtube nach diesen Namen suchen. 

Martin Thompson ist z.B. bekannt dafür, viel mit Low Latency Anwendungen 
zu tun zu haben, beispielsweise war er für LMAX Stock Exchange im 
Hochfrequenzhandel für die Software tätig und die können wirklich keine 
Millisekunde verschenken.

Die Sache ist, dass man für Low Latency Java-Anwendungen eben nicht ganz 
so naiv programmieren kann, wie man es üblicherweise tut, bzw. kann man 
mit Java extrem schnell werden, man muss aber einige Sachen beachten. Da 
wäre das "False Sharing" (zwei Daten werden von untershiedlichen Threads 
parallel bearbeitet, liegen aber in einem Objekt gebündelt in einer 
Cachline - das bedeutet Caches müssen abgeglichen werden und das kann 
mal schnell die Performance um eine Größenordnung velangsamen). 
Da wären Zugriffsmuster auf Daten zu beachten, um vom Prefetch des 
Speichercontrollers zu profitiere, etc.
Größe von Daten tun ihr übriges: Binäre Protokolle statt JSON, XML. 
Multiple Daten in Longs, etc. da wird viel getan, damit möglichst viele 
Daten in eine Cachline passen, die zusammen gehören.
Man kann mit Java extrem schnell sein, aber das sieht dann nicht 
unbedingt mehr aus, wie das Feld-Wald-und-Wiesen-Java.

https://mechanical-sympathy.blogspot.de
(Die Artikel von 2011 bis 2012 (inkl) sind ggf. interessant)

https://www.youtube.com/watch?v=C70MLXX-ztU
https://www.youtube.com/watch?v=rKMTsJxYK30
https://www.youtube.com/watch?v=KrWxle6U10M

Kirk Pepperdine hat einige Präsentationen, in denen er zeigt, wie er 
Performance-Problemen auf den Grund geht und das erschreckende daran 
erscheint, dass er zu dem Schluss kommt:  Erst, wenn du siehst, dass 
weder das System, noch thread Contention, noch der Garbage-Collector 
dich bremst überleg dir, ob dein Algorithmus richtig ist.
Das ist schon ein starkes Statement und warum das richtig ist, erklärt 
sich letztendlich durch die enorm unterschiedlichen konstanten Faktoren 
beim Zugriff auf Ressourcen.

hier z.B:
https://www.youtube.com/watch?v=-XI9kJGCHtM

Man schaut ein paar von den Präsentationen an und fragt sich 
willkürlich, wo man selbst etwas in die Richtung optimieren kann.

Gruß,
-Wanja-

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

Back to de.comp.lang.java | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Taktfrequenzen, Java und heise Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-01-04 22:38 +0100
  Re: Taktfrequenzen, Java und heise Wanja Gayk <brixomatic@yahoo.com> - 2017-01-18 20:08 +0100
    Re: Taktfrequenzen, Java und heise Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-01-18 22:55 +0100
      Re: Taktfrequenzen, Java und heise Wanja Gayk <brixomatic@yahoo.com> - 2017-01-30 17:53 +0100
        Re: Taktfrequenzen, Java und heise Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-01-30 21:00 +0100
          Re: Taktfrequenzen, Java und heise Bernd Waterkamp <Bernd-Waterkamp@web.de> - 2017-01-30 22:12 +0100

csiph-web