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


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

Re: Taktfrequenzen, Java und heise

From Marcel Mueller <news.5.maazl@spamgourmet.org>
Newsgroups de.comp.lang.java
Subject Re: Taktfrequenzen, Java und heise
Date 2017-01-18 22:55 +0100
Organization MB-NET.NET for Open-News-Network e.V.
Message-ID <o5oo88$iar$1@gwaiyur.mb-net.net> (permalink)
References <Java-20170104192730@ram.dialup.fu-berlin.de> <o4jpvq$i20$1@gwaiyur.mb-net.net> <MPG.32e0bfe36d57e0529896c3@news.aioe.org>

Show all headers | View raw


On 18.01.17 20.08, Wanja Gayk wrote:
> In article <o4jpvq$i20$1@gwaiyur.mb-net.net>, Marcel Mueller
> (news.5.maazl@spamgourmet.org) says...
>
>> 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.

>> 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.


> 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.


>> 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

Back to de.comp.lang.java | Previous | NextPrevious 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