Discussion:
Taktfrequenzen, Java und heise
(zu alt für eine Antwort)
Stefan Ram
2017-01-04 18:30:15 UTC
Permalink
(Hatte ich zuerst nach ger.ct gepostet. Dann fiel mir
ein, daß es eigentlich auch hierhin paßt. Also multipost.)

Ich kenne die Geschichte bisher so:

1995 - 2004 war die Zeit der "Kaffee-Sprachen" wie Java und C#,
die Effizienz für Produktivität eintauschten.
2004 hörten die Prozessoren auf, schneller zu werden
(im single thread, "The free lunch is over.").
Seitdem kommt es zur Rennaissance nativer Sprachen wie C++.
Projekte bei Microsoft werden wieder von C# auf C++ umgestellt.

Aber nun hat vor kurzen der heise-Verlag seine
"Programmiersprache des Jahres" vorgestellt: Java!

Eine der Begründungen dafür lautete: Java ist zwar
etwas langsamer, aber es profitiert davon, daß die
Prozessoren immer schneller werden. Hey!, so hat man
das /bis 2004/ immer gesagt. Leben die bei heise also
in der Vergangenheit?

PS: Obwohl, naja, Artikel nach de.comp.lang.java zu
posten ist ja auch etwas, das man so bis 2004 gemacht hat.
Lothar Kimmeringer
2017-01-04 19:11:47 UTC
Permalink
Post by Stefan Ram
Aber nun hat vor kurzen der heise-Verlag seine
"Programmiersprache des Jahres" vorgestellt: Java!
Eine der Begründungen dafür lautete: Java ist zwar
etwas langsamer, aber es profitiert davon, daß die
Prozessoren immer schneller werden. Hey!, so hat man
das /bis 2004/ immer gesagt. Leben die bei heise also
in der Vergangenheit?
Ein anderer Punkt ist, dass sich Java bzw. die Java Virtual
Machine immer weiter ausbreitet und an Stellen auftaucht, wo
man sie nicht erwarten wuerde, z.B. in Intel-CPUs beim Booten:
https://media.ccc.de/v/33c3-8314-bootstraping_a_slightly_more_secure_laptop


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Marcel Mueller
2017-01-04 21:38:02 UTC
Permalink
Post by Stefan Ram
(Hatte ich zuerst nach ger.ct gepostet. Dann fiel mir
ein, daß es eigentlich auch hierhin paßt. Also multipost.)
1995 - 2004 war die Zeit der "Kaffee-Sprachen" wie Java und C#,
die Effizienz für Produktivität eintauschten.
Damals hat vielleicht jeder darüber gesprochen, aber ernsthaft benutzt
wurde es kaum. Es war ja mal für Fat-Clients gedacht. Wer erinnert sich
noch? Die konzeptionellen Nachteile davon hängen Java hier und da immer
noch nach.
Post by Stefan Ram
2004 hörten die Prozessoren auf, schneller zu werden
(im single thread, "The free lunch is over.").
Das stimmt auch nicht wirklich. Die Taktfrequenz mag etwas stagniert
sein, aber IPC ist stetig gestiegen.
Post by Stefan Ram
Seitdem kommt es zur Rennaissance nativer Sprachen wie C++.
Projekte bei Microsoft werden wieder von C# auf C++ umgestellt.
Wahrscheinlich auf managed C++ ;-)

Aber hast Du fakten?
Post by Stefan Ram
Aber nun hat vor kurzen der heise-Verlag seine
"Programmiersprache des Jahres" vorgestellt: Java!
Naja, das ist immer eine Sache des Point of View. Wen man halt fragt.
Post by Stefan Ram
Eine der Begründungen dafür lautete: Java ist zwar
etwas langsamer, aber es profitiert davon, daß die
Prozessoren immer schneller werden. Hey!, so hat man
das /bis 2004/ immer gesagt. Leben die bei heise also
in der Vergangenheit?
Nein, die Geschwindigkeit einer Sprache macht vielleicht einen
konstanten Faktor Unterschied. Ein gescheiter Algorithmus holt einen
Exponenten.

Ob Java oder C# (spielt in einer ähnlichen Klasse), wenn man gescheit
programmiert, endet das immer genauso: die CPUs warten immer schneller
(also langweilen sich). Begrenzende Faktoren sind die Schnittstellen zu
den Systemen, bei denen man sich weniger Mühe gegeben hat. Klar, bekomme
ich mit C++ die CPU-Last von 7% auf 3% runter, aber wozu?

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.


Marcel
Wanja Gayk
2017-01-18 19:08:14 UTC
Permalink
Post by Marcel Mueller
Damals hat vielleicht jeder darüber gesprochen, aber ernsthaft benutzt
wurde es kaum. Es war ja mal für Fat-Clients gedacht. Wer erinnert sich
noch? Die konzeptionellen Nachteile davon hängen Java hier und da immer
noch nach.
Ich habe an einigen Fat-Clients in Java/Swing programiert. Ich fand das
jetzt nicht so unglaublich schlimm.
Welche meinst du konkret?
Post by Marcel Mueller
Nein, die Geschwindigkeit einer Sprache macht vielleicht einen
konstanten Faktor Unterschied. Ein gescheiter Algorithmus holt einen
Exponenten.
An der Stelle sehe ich durchaus mit Berechnungen auf der Grafikkarte
einen recht großen Faktor - und da ist man mit Java leider noch nicht
sehr gut versorgt. Aparapi (Projekt Sumatra) war ein schöner Anfang,
leider wohl eingeschlafen und der letzte Stand, den ich versuchen
konnte, war AMD-apezifisch und instabil.
Post by Marcel Mueller
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.

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]
Marcel Mueller
2017-01-18 21:55:20 UTC
Permalink
Post by Wanja Gayk
Post by Marcel Mueller
Damals hat vielleicht jeder darüber gesprochen, aber ernsthaft benutzt
wurde es kaum. Es war ja mal für Fat-Clients gedacht. Wer erinnert sich
noch? Die konzeptionellen Nachteile davon hängen Java hier und da immer
noch nach.
Ich habe an einigen Fat-Clients in Java/Swing programiert. Ich fand das
jetzt nicht so unglaublich schlimm.
Welche meinst du konkret?
Swing finde ich jetzt kein echtes Highlight, aber ein Problem würde ich
es definitiv auch nicht nennen. Es funktioniert.

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. Anders formuliert, wenn
man nicht die Speicherzuweisungen so beschränkt, dass nicht mehr als der
physikalisch vorhandene Speicher auf die JVMs verteilt wird, dann steht
die Kiste mit Swapping - keine Überbuchung. Das begrenzt natürlich die
maximale Größe einzelner Transaktionen. Selbst Perl, das eigentlich eher
Kinderkram ist, bekommt das besser auf die Kette. Das ist einfach nur
peinlich.
Beim ursprünglich avisierten Verwendungszweck wäre das alles kein reales
Problem.
Fairerweise sei angemerkt, dass man am GC mittlerweile herumgeschraubt
hat. Wobei ich jetzt nicht weiß, was das lizenzrechtlich bedeutet.
Post by Wanja Gayk
Post by Marcel Mueller
Nein, die Geschwindigkeit einer Sprache macht vielleicht einen
konstanten Faktor Unterschied. Ein gescheiter Algorithmus holt einen
Exponenten.
An der Stelle sehe ich durchaus mit Berechnungen auf der Grafikkarte
einen recht großen Faktor - und da ist man mit Java leider noch nicht
sehr gut versorgt.
Das hilft nur punktuell an den Stellen, wo es darum geht, stark
parallelisierbare, stupide Aufgaben durchzuführen. Und der Aufwand zur
Adaption an die GPU Architekturen ist immens. BTDT. Aber klar, bei
Number-Crunching hilft's.

Aber nichts für ungut: wer ernsthaft das letzte Quäntchen Performance
braucht und Java nutzt, hat den Schuss noch nicht gehört.
Post by Wanja Gayk
Aparapi (Projekt Sumatra) war ein schöner Anfang,
leider wohl eingeschlafen und der letzte Stand, den ich versuchen
konnte, war AMD-apezifisch und instabil.
Vergiss Java, wenn Du auf GPUs rechnen willst. OpenCL wäre ein Ansatz.
Aber wenn Du wirklich Bumms haben willst, ist GPU Assembler angesagt,
selbstverständlich plattformabhängig. Und am Ende ist es oft weniger der
optimale Algorithmus als vielmehr Speicherlayout, Cache-Effizienzen oder
ähnliches was über den Durchsatz entscheidet. Und das ist so oder so
plattformabhängig.
Post by Wanja Gayk
Post by Marcel Mueller
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


Marcel
Wanja Gayk
2017-01-30 16:53:04 UTC
Permalink
Post by Marcel Mueller
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.
Post by Marcel Mueller
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.
Post by Marcel Mueller
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.
Post by Marcel Mueller
Aber nichts für ungut: wer ernsthaft das letzte Quäntchen Performance
braucht und Java nutzt, hat den Schuss noch nicht gehört.
Post by Wanja Gayk
Post by Marcel Mueller
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)





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:


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]
Marcel Mueller
2017-01-30 20:00:54 UTC
Permalink
Post by Wanja Gayk
Post by Marcel Mueller
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.
Ajo, man kann natürlich jedes Programm optimieren und dabei auch oft
einen Faktor 10 holen. Voraussetzung man hat beliebig viel Geld und
beliebig viel Zeit. In den anderen Fällen findet man sich in der echten
Welt wieder.

Das eigentliche Problem in Java ist konzeptioneller Natur. Dre GC-Thread
läuft auf niedriger Prio solange der Speicher nicht knapp wird. Wenn man
nun Anwendungen hat, die die Kiste wirklich unter Feuer halten,
schaukeln sich so alle VMs über kurz oder lange auf Xmx hoch. Erst wenn
es wieder Langeweile gibt, ruckelt sich das wieder ein.
Und freier Speicher in der JVM heißt auch noch lange nicht freier
Speicher im OS. Das kommt immer auf die JVM an, wie, wann und ob der
freie Speicher zurück zum OS findet.
Post by Wanja Gayk
Post by Marcel Mueller
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.
Nein, das ist nicht das Problem. Wenn ich bei obigem Szenario Swappen
vermeiden will, darf ich den Speicher mit den VMs nicht überbuchen. Das
macht den eigentlichen Unterschied. Heißt 7 VMs => Maximale
Transaktionsgröße ~= Speichergröße/7.

Wir hatten da vor einigen Jahren massive Probleme mit einem
Integrationssystem. Eine einzige große Message => Boom!
Mittlerweile wurde sowohl auf der Java-Seite als auch beim Blech
nachgerüstet, so dass das kein operatives Problem mehr ist.
Post by Wanja Gayk
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.
Ach der Unsinn. Ja, das ist heißes Zeug. Wird Zeit, dass endlich eine
Transaktionssteuer kommt, die solch einen volkswirtschaftlichen Unsinn
eindämmt.
Post by Wanja Gayk
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.
Ja, "new" vermeiden.
Post by Wanja Gayk
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).
Das betrifft restlos alle Sprachen.
Post by Wanja Gayk
Da wären Zugriffsmuster auf Daten zu beachten, um vom Prefetch des
Speichercontrollers zu profitiere, etc.
Dito. Mit Java hat man aber so gut wie keinen direkten Einfluss auf das
Memory-Layout. Das geht in Grenzen in .NET und ordentlich in C/C++.
Post by Wanja Gayk
Größe von Daten tun ihr übriges: Binäre Protokolle statt JSON, XML.
Ist halt auch mehr Aufwand beim Debuggen.
Post by Wanja Gayk
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.
:-)
Ja, die Vorfaktoren werden manchmal etwas zu sehr ignoriert.
Da wird schon bei der Ausbildung genau diese Dummheit gelehrt.

Bei Skalierbarkeit zählt der Algorithmus, bei Geschwindigkeit nicht
unbedingt.
Post by Wanja Gayk
Man schaut ein paar von den Präsentationen an und fragt sich
willkürlich, wo man selbst etwas in die Richtung optimieren kann.
Schnelle Programme schreiben liegt mir im Blut. Selten, dass mir solche
Faux-Pas passieren. Aber ich komme halt auch noch aus der Zeit, wo man
DB-Kernel auch mal in Assembler geschrieben hat. Damit ging dann auch in
den 80-ern schon search as you type.

Die Ideen von damals taugen zuweilen noch heute. Habe erst kürzlich
einen In-Memory Kern für eine Anwendung geschrieben - allerdings in
.NET, aber das verhält sich in vielen Bereichen ähnlich.
Es gibt zwei Anwendungen mit zumindest ähnlichem Datenmodell und
ähnlicher User- und Transaktionszahl. Unsere läuft auf einer Hasenkiste
mit 2 CPUs bei 5% Last, die des externen Anbieters auf 16 CPUs, die auch
durchaus öfters unter Vollast stehen. Das Ding ist halt klassisch WAMP/LAMP.

Den Haupteffekt hat nicht einmal das InMemory selbst gebracht -
Datenbank-Caches bringen auch eine Menge -, sondern die Deduplication.
Das wiegt auch den zusätzlichen Aufwand dafür dicke auf.
Alle In-Memory Objekte sind immutable - damit ist false sharing raus.
Die Objekte selbst sind Multitons, also pro Primärschlüssel kann immer
nur ein Objekt gleichzeitig im Speicher stehen. Das gilt auch für alle
parallelen Useranfragen. Data Races sind bei Immutable ja kein Problem.
Und last but not least werden redundante Subobjekte dedupliziert, allen
voran Strings. Also anstelle von Wertidentität tritt Referenzidentität.
Dadurch sinkt der Memory Footprint erheblich (ca. Faktor 5) und mit ihm
steigt natürlich die Effizienz der Memory Caches. Des weiteren skaliert
die Sache sogar weniger als linear. Sowohl bei mehr Usern als auch bei
mehr Daten im RAM steigt die Wahrscheinlichkeit für Redundanzen, die der
Deduplikation zum Opfer fallen, weiter an.

Was noch etwas gebracht hat, ist der Einsatz der strukturierten
Wertetypen in .NET. Der Nutzen ist dabei noch nicht einmal unbedingt nur
die Laufzeit, sondern eher die Code-Qualität, Fehlerabhängigkeit und
Wartbarkeit. So können einfache Wertetypen erheblich mehr Typsicherheit
bringen. Ein Primärschlüssel mag technisch gesehen ein String sein, aber
wenn man es mit einem struct Ref<Entität> Typ kapselt, der zur Laufzeit
(also nach dem JIT) keinen zusätzlichen Code erzeugt, wird die Sache
typsicher.
In Java gibt es dazu leider kein Pendant. Da muss man sich zwischen dem
Elementaren Typ mit Performance und der Wrapper-Klasse mit Code
Sicherheit entscheiden.

Das einzige was bei all diesen Techniken wirklich ein Anachronismus ist,
ist SQL bzw. RDBMS.


Marcel
Bernd Waterkamp
2017-01-30 21:12:02 UTC
Permalink
Post by Marcel Mueller
Und freier Speicher in der JVM heißt auch noch lange nicht freier
Speicher im OS. Das kommt immer auf die JVM an, wie, wann und ob der
freie Speicher zurück zum OS findet.
Richtig. Wobei der Default für das Kriterium um Speicher wieder herzugeben
(MaxHeapFreeRatio) mit 70 Prozent halt auch ziemlich hoch angesetzt ist. Zu
heftig sollte man den aber auch nicht senken, weil das wieder andere
Probleme verursacht.

Grüße,
Bernd

Lesen Sie weiter auf narkive:
Loading...