Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.lang.java > #13086
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar
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