Hallo zusammen! Gibt es Anwendungsgebiete, bei denen Java nicht verwendet werden kann?

3 Antworten

Die anderen Antworten und Kommentare sind teilweise ganz gut, vor allem von rayha24.

Java ist z. B. für Treiber völlig ungeeignet, und auch für alle anderen Systeme, die Echtzeitanforderungen haben. Dadurch, dass man nie weiß, wie / wo / wann der GC anspringt und wieviel Zeit dieser verbrät, fallen schon mal eine ganze Reihe Low-Level-Anwendungen flach.

Java ist zwar - dank stetig verbessertem JIT-Compiler - verdammt schnell, aber wer ehrlich ist weiß, dass realistische Anwendungsszenarien eben nicht aus Qsort, dem Berechnen von Pi, usw. bestehen, und in solchen Fällen ist Java dann natürlich auch wesentlich langsamer als C++.

Und das ist auch ganz natürlich, und muss auch so sein, und wer etwas anderes behauptet, hat sich noch nie mit der Funktionsweise der Java VM, den JIT-Optimierungen, und auf der anderen Seite einem C++ Compiler beschäftigt.

Natürlich ist Java genial und für verdammt viele Aufgaben die beste Lösung, aber eben auch keine eierlegende Wollmilchsau.

Java ist dank JIT sehr performant! Aber C++ wird fast immer schneller sein! Ich schreibe "fast", weil es auch hier Ausnahmen gibt, in denen Java tatsächlich schneller ist. Genauso wie Python mit Pypy. Die machen den Kohl aber nicht fett, und C++ wird größtenteils die Nase vorn haben ... und zwar deutlich. :)

Trotzdem ist Geschwindigkeit nicht alles und der Entwicklungsprozess sollte auch beachtet werden. Java erhält hier - genauso wie C++ - sehr gute Unterstützung durch Tools, Bibliotheken und IDEs.

Alleine dank der C++-Templates hat sich zumindest das Performance-Thema im Bezug auf Java eigentlich schon erledigt. Dabei kann Java nämlich nicht mal ansatzweise mithalten.

Naja, um die Frage zu beantworten: Je mehr Low-Level, desto weniger ist Java geeignet. :)

Schönen Abend noch! :)

PS: Übrigens ist Java dank fehlendem W^X viel unsicherer, im Vergleich zu C++!

Alleine dank der C++-Templates hat sich zumindest das Performance-Thema im Bezug auf Java eigentlich schon erledigt. Dabei kann Java nämlich nicht mal ansatzweise mithalten.

In diesem Punkt irrst du. Im Gegenteil: Gerade was solche Bereiche angeht, kommt man vom reinen Low-Level-Programmieren weg. Je weiter man sich davon wegbewegt, desto stärker wird Java.

PS: Übrigens ist Java dank fehlendem W^X viel unsicherer, im Vergleich zu C++!

Deine Wertung unterschlägt dann aber böswillig viele andere Dinge, die C++ deutlich unsicherer machen. Beispielsweise fehlende Signaturen bei Bibliotheken, fehlenden Security-Manager...

0
@mepeisen

In diesem Punkt irrst du. Im Gegenteil: Gerade was solche Bereiche angeht, kommt man vom reinen Low-Level-Programmieren weg. Je weiter man sich davon wegbewegt, desto stärker wird Java.

Sorry, da habe ich ich wohl falsch ausgedrückt. Ich bezog mich eigentlich auf constexpr im Zusammenhang mit Templates. Die Konstanten, die dabei am Ende raus kommen, sind dann natürlich durch nichts zu toppen. :)

Deine Wertung unterschlägt dann aber böswillig viele andere Dinge, die C++ deutlich unsicherer machen. Beispielsweise fehlende Signaturen bei Bibliotheken, fehlenden Security-Manager...

OK, darüber kann man jetzt sehr lange Diskutieren, aber du hast vermutlich Recht, wenn du mir Einseitigkeit unterstellst. So etwas passiert halt manchmal. :)

0
@TeeTier

constexpr ist allerdings ein sehr spezieller Teilbereich und damit sind wir wieder bei der Frage, wie aussagekräftig exakt ein einzelner Punkt, den man sich rausgreift, für die Praxis ist.

Ich sage bei so etwas als Antwort gerne: Es gibt kein gut und schlecht, es gibt kein schneller und langsamer, es gibt ein "geeigneter" und ein "ungeeigneter". Und bei der Betrachtung kommt es nicht immer nur auf akademische Messungen an, sondern in der Praxis auch darauf, welches Know-How in einer Firma vorhanden ist usw.

1
@xub88

... und damit sind wir wieder bei der Frage, wie aussagekräftig exakt ein einzelner Punkt, den man sich rausgreift, für die Praxis ist.

Das ist aber EXAKT das, worum es hier geht! In der Frage ist explizit die Rede von Javas Nachteilen im Vergleich zu C++.

Es geht nicht darum OB und WANN sich WELCHE Optimierung lohnt, bzw. wann WAS angemessen ist, sondern einfach nur trocken um absolute Nachteile.

(siehe dazu meine längeren Kommententare weiter unten)

Es gibt kein gut und schlecht, es gibt kein schneller und langsamer, es gibt ein "geeigneter" und ein "ungeeigneter". Und bei der Betrachtung kommt es nicht immer nur auf akademische Messungen an, sondern in der Praxis auch darauf, welches Know-How in einer Firma vorhanden ist usw.

Das ist auch meine Meinung und ich stimme dir wieder mal zu! Ich glaube, wir reden irgendwie an einander vorbei. :)

Natürlich sollte man in einer Firma nicht mehrere Tage mit Pseudo-Optimierungen vergäuden, um am Ende bei +5% Effizienz gegenüber der Vorgängerversion zu liegen.

Und natürlich sind - je nach Aufgabe - andere Aspekte wesentlich wichtiger als Performance. Oftmals kann die Performance sogar komplett ignoriert werden, und es kommt einfach nur auf Geschwindigkeit an. Oder Wartbarkeit (damit einhergehend Sauberkeit, Doku, Testfähigkeit, usw.)

Aber um all diese Punkte ging es nicht in der ursprünglichen Frage, sondern explizit um Nachteile Javas.

Und absolut betrachtet liegt Javas Performance - da managed High-Level-Sprache mit GC in VM und anderem Objektdesign - bei numerischen Berechnungen eben hinter C++.

Ist das schlimm? Allermeistens Nein. Aber darum geht es nun mal in der Frage selbst, und dafür kann ich nichts.

Wie du in meinen erweiterten Kommentaren weiter unten lesen wirst: Java ist mit maximaler Optimierung (sowohl javac als auch VM) bei vielen Gleitpunktoperationen mit doppelter Genauigkeit (64 Bit Float == double) deutlich langsamer als C++ mit bewusst deaktivierten Optimierungen (-O0) und erweiterter Genauigkeit (128/80 Bit Float == long double).

In diesem Szenario ist bei Java das Ende der Fahnenstange erreicht, und mehr Optimierung geht nicht. GCC und Clang haben hingegen noch nicht mal mit Optimierungen angefangen, wohlgemerkt bei deutlich breiterem Datentyp.

Ja, ich weiß, es gibt wichtigere Punkte, die für Java sprechen. Aber darum ging es dem Fragensteller nun mal, und nicht um Javas Vorzüge. :)

Wenn du lustig bist, kannst du ja eine Frage bzgl. der Vorteile Javas stellen, und dann antworte ich dir mit den schicken Iterator-Interfaces, der Erweiterbarkeit auf andere JVM Sprachen wie Clojure, oder der super geilen LookAndFeel-Implementierung unter Swing. Und dann kommen wieder irgendwelche Leute, die mir die mir die Vorteile von C++ vorkauen, und am Ende diskutieren wir über VFTs, überladene Operatoren, R-Werte, Verschiebesemantik, und entfernen uns von deiner eigentlichen Frage, in der es ausschließlich um die Vorteile von Java ging.

So jetzt auch hier: Es geht NUR um Javas Nachteile im Vergleich zu C++! Nicht mehr, und nicht weniger!

Und mangelnde Hardwarenähe hat in jedem Fall - trotz JIT usw. - nun mal einen Einschnitt bei der Performance von niederen Operationen zu bedeuten. Frag deinen Profiler! :)

0
@xub88

PS: Danke für die Diskussion bis hier hin! Macht Spaß, aber missverstehe meine Beiträge bitte nicht als Java-Bashing oder unterstelle mir mangelnde Erfahrung.

Meine Arbeit sind Low-Level-Optimierungen auf diversen Systemen und ich weiß definitiv WIE Java, C++ usw. intern ticken. Disassembler und Maschinencode-Debugger sind meine täglichen Arbeitswerkzeuge. Ich schreibe nicht aus Spaß, dass Java langsamer ist. Das trifft nämlich fast immer dort zu, wo es auf Geschwindkigkeit ankommt!

Wie gesagt, du hast zwar mit (fast) allem Recht, was du hier schreibst, aber bitte nicht das Thema der eigentlichen Frage vergessen! :)

Schönen Tag noch! :)

0
@TeeTier

Das ist aber EXAKT das, worum es hier geht! In der Frage ist explizit die Rede von Javas Nachteilen im Vergleich zu C++.

Nein. In der Frage steht, ob es Anwendungsgebiete gibt, bei denen Java nicht verwendet werden kann. Und deine Antwort war sinngemäß: Ja, alles was mit Performance zu tun hat, denn C++ ist pauschal schneller.

Ich habe nichts anderes geschrieben als dass Java anders ist. Dass man bei Performance nicht Äpfel mit Birnen vergleichen darf. Ich habe nicht behauptet, dass Java pauschal schneller ist. Ich habe nicht behauptet, dass deine Erfahrungen Blödsinn sind. Du hast sie gemacht, hast dich aber nicht tiefer mit der eigentlichen Frage auseinandergesetzt,. was du nun an Erkenntnis aus deiner Erfahrung ziehst.

Das ist auch meine Meinung und ich stimme dir wieder mal zu! Ich glaube, wir reden irgendwie an einander vorbei. :)

Na dann :-) Sorry übrigens, dass ich kurzzeitig mit neuem User posten musste (xub88 bin ich). Irgendein Spassvogel in anderem Thema meinte, mich beleidigen zu wollen, editierte alles sofort weg und ich stand dumm da, weil ich mich auf den Spruch, dass er seine "dümmlichen Kommentare lassen solle" hinreißen lies. Merke: Die Admins sehen "dümmliche Kommentare" als Beleidigung an, die eine 24-h-Sperre zur Folge hat. Nun gut. Zurück zum Thema.

Aber um all diese Punkte ging es nicht in der ursprünglichen Frage, sondern explizit um Nachteile Javas.

Wie gesagt hat der TE nicht explizit nach Performance gefragt, sondern deutlich allgemeiner gefragt. Du hast dann das Thema auf die Performance reduziert. Und liegst dennoch damit völlig falsch, denn Performance ist, ich wiederhole mich, immer mehr als nur das pure Zählen von Instruktionen.

Und absolut betrachtet liegt Javas Performance - da managed High-Level-Sprache mit GC in VM und anderem Objektdesign - bei numerischen Berechnungen eben hinter C++.

Schau mal hier und staune Bauklötze:

http://readwrite.com/2011/06/06/cpp-go-java-scala-performance-benchmark

Ich traue denen zu, dass sie dort einen wirklich aussagekräftigen Code genommen haben. Und der Fairness halber müsste unoptimierter Debug-enabled C++ mit Java verglichen werden. Und damit wäre C++ langsamer als die Java 64bit VM, schneller als die 32bit VM. Fairness deswegen, weil (ich wiederhole mich) die C++-Compiler alleine schon von Haus aus extrem stark optimieren, was oft dem Ansatz von Java widerspricht, möglichst nah am Original-Code zu bleiben (auch damit das nachvollziehbar gedebuggt werden kann). Insofern ist unoptimierter (!) Java-Code gegenüber alleine schon vom Compiler stark optimiertem C++-Code einfach vom Ansatz her bereits im Nachteil.

Daraus abzuleiten, dass C++ per se schneller ist, würde bedeuten, dass du einen Ursain Bolt bei seinem Weltrekord mit einem Joji Kato bei seinem Weltrekord vergleichen. Der Joji ist halt schneller. Google mal nach den beiden, dann verstehst du, warum der Vergleich recht gut ist ;-)

0
@mepeisen

(xub88 bin ich)

Ich weiß, das merkt man am Ausdruck! :)

Schau mal hier und staune Bauklötze: ...

Sehr interessant. Aber sogar ich hätte Javas Performance besser eingeschätzt.

Im verlinkten Text steht folgendes:

A team at Google created a "simple and compact" benchmark that didn't take advantage of language-specific features.

Kein Programmierer würde in einem realistischen Szenario auf "language-specific features" verzichten, egal um welche Aufgabe es sich handelt. Immerhin steht weiter unten:

After benchmark tests were published within Google various employees took a stab at optimizing the code for specific languages.

Das hat die ganze Aktion dann doch noch gerettet. :)

C++ provides the best performance by far, but it requires the most extensive language-specific tuning.

Das ist genau das, was ich weiter unten geschrieben habe: Nichts für Anfänger. So ein "tuning" erfordert Erfahrung, und wenn man sich nicht absolut sicher ist, dann sollte man es sein lassen. Das gilt für alle Sprachen, nicht nur C++.

The algorithm was simplest to implement in Java, ...

Wie gesagt, meistens wird es genau DARAUF ankommen, anstatt auf Performance. Nicht immer, aber meistens! :)

Go offers concise notion and very fast compile time, but is still immature.

Wenn ich mich nicht irre, ist der Artikel von 2011, und inzwischen dürfte Go deutlich erwachsener geworden sein. In neueren Benchmarks steht Go wesentlich besser da.

Naja, zurück zu deinem Text:

Fairness deswegen, weil (ich wiederhole mich) die C++-Compiler alleine schon von Haus aus extrem stark optimieren, was oft dem Ansatz von Java widerspricht, möglichst nah am Original-Code zu bleiben (auch damit das nachvollziehbar gedebuggt werden kann).

Der Maschinencode aus meinem Beispiel weiter unten mit den Vektorwolken enthält an sehr vielen Stellen folgendes:

mov eax,edx
mov edx,eax ; <= ???

Das hat GCC mit -O0 (deaktivierten Optimierungen) erzeugt. Optimierungslevel 0 erzeugt sehr oft sehr merkwürdigen (im Sinne von "falschem" oder "sinnlosen") Code. Das obige Beispiel frisst zwar nur einen einzigen sinnlosen Takt, und dürfte von der CPU-internen Optimierung sogar rausgefiltert werden, aber irgendwie fragt man sich, was sich GCC dabei gedacht haben mag. :)

Trotzdem ist dieser Mist immer noch schneller als Java ... also in meinem Beispiel ... Tendenz ... nicht verallgemeinern ... klar? :)

Also dann, wie ganz unten schon geschrieben, vielen Dank für die Diskussion, deine Ansichten, deine "Penetranz" und auch den Benchmark-Link!

Ich wünsche noch einen schönen Tag! :)

0

Ja und Nein. Ich spreche mal von (reinem) Java, also ohne Hilfestellungen über DLLs/SOs u.ä..

Zunächst einmal kann Java dann nicht verwendet werden, wenn man sehr hardwarenah programmieren will oder muss. Das liegt schlichtweg daran, dass Java eine allgemein gehaltene Sprache ist und dass die Standard-Bibliothek solcherlei Sachen wie beispielsweise direktes Programmieren der Grafik-Hardware nicht zulässt.

Alles, was sehr Betriebssystem-nah oder Computer-nah ist, kann ebenfalls nicht mit Java programmiert werden. Der gemeine Computer heutzutage basiert nicht darauf, bereits zur Bootzeit Java zu kennen und ausführen zu können. Also kann man da auch nicht wirklich Java nutzen. Es gibt aber Ausnahmen. Spezielle Prozessoren, die Java kennen und ausführen und rein in Java geschriebene Betriebssysteme.

Ansonsten gibt es eigentlich kein Anwendungsgebiet, das mittlerweile nicht durch Java umsetzbar wäre. Solange genug Ressourcen und eine Java VM zur Verfügung steht.

Es gibt einige sehr spezielle Anwendungsfälle, in denen es auch sehr spezialisierte Programmiersprachen gibt (Meist in Zusammenhang auch mit höherer Mathematik). Da hat Java dann kein Platz, obwohl es nicht unmöglich wäre.

Java wäre z.B. auch in Thema Datenbanken mit Abfragen etc. ineffizient (also anstatt von SQL)

0
@TUrabbIT

Das zu vergleichen ist unmöglich. SQL ist eine deklarative Programmiersprache. Java eine imperative. Zwei grundlegend verschiedene Konzepte. 

Wenn man es vergleichen könnte und würde man mit Java die Algorithmen nachbilden, die in der deklarativen SQL durch das DBMS zur Verfügung gestellt werden und intern abgehandelt werden und unterstellen wir, dass dieses "Java DBMS" dann auch den Javacode genauso wie SQL Queries optimiert, dann wäre Java in der Hinsicht genau so effizient wie SQL, weil die Effizienz von SQL-Abfragen eben nicht durch SQL sondern durch das Datenbanksystem gewährleistet wird.

1
@TUrabbIT

Wie tente1 schon schreibt, vergleichst du mit deinem Satz Äpfel mit Birnen. Davon abgesehen verweise ich aber mal auf SQLite oder Hibernate und Co. Es gibt rein in Java geschriebene Datenbank-Engines, die SQL sprechen...

1

High Performance Applications :) Die Börse verwendet sicherlich kein Java für Ihre Zahlen.

Du würdest dich wundern, was ein guter Entwickler an Performance aus Java herausholen kann. Performance ist mittlerweile kein echtes Argument mehr.

0

Bei sowas schon & bei der Entwicklung von z.B. Steuergeräten für Autos auch. Java wird nie an die Performance von unmanaged Sprachen wie C, C++ usw rankommen.

0
@Reyha24

Glaube mir mal, ich weiß, wovon ich rede. Wir schreiben beispielsweise Banken-Software. Über 100tsd Endanwender (Bankmitarbeiter) neben was weiß ich wie vielen im eBanking, hunderte Banken und Millionen Transaktionen pro Sekunde sind da eher die Regel. Und ja, in nahezu allen Bereichen wird Java eingesetzt. Und ja, Java kann da problemlos mithalten.

Java ist einfach anders, muss anders optimiert werden und Java muss anders betrachtet werden.

1

Tehe, guter Witz - ich habe mal von einer Firma gehört, die ein Börsenprogramm in Java geschrieben hat. Dieses Programm hat es auf 1 Million (echte) Transaktionen pro Sekunde gebracht. Das wurde ermöglicht, in dem ein Prozessorkern immer voll ausgelastet war und nie auf Daten warten musste. Die anderen Kerne mussten mehr oder weniger oft auf Daten warten, deswegen waren die nicht voll ausgelastet.

Ich kann mich leider nicht mehr an den Namen der Software oder Firma erinnern und eine kurze Suche hat mich auch nicht.

Für diese Art der Problemlösung muss man zumindest einen gewissen Grad an Wissen über die Rechnerarchitektur haben. Das wiederrum ignoriert einen Vorteil von Java - Plattformunabhängigkeit (mehr oder weniger).

0

Java wird sogar häufig für Performance relevante Anwendungen verwendet, da Java durch vm Ausführung codeoptimietung zur Laufzeit unterstützt. Das heißt die vm ersetzt ganze codeteile durch hoch performanten code und kann diesen sogar just in time hart kompilieren. Das ist in C und cpp nicht möglich, da der Code nach der kompilierung unveränderlich ist und so nicht zur Laufzeit optimiert wird. Damit kommt die Geschwindigkeit von javacode manchmal sogar über die von C++ und C Code.... rehya24, vielleicht erstmal n bisschen lesen und Vorträge darüber anhören bevor man Argumente von vor 10 Jahren bringt.

1

JavaTheHutt: Und wo sieht man jetzt, dass Java so performant ist wie C oder C++? tente1: Der JIT-Compiler kann zwar zu Laufzeit optimieren, was auch super ist, aber er kann nicht alles optimieren, weil sein Zeitfenster begrenzt ist. Und wenn der Java Code dadurch schneller sein sollte, als der unmanaged Code, dann wurde der unmanaged Code einfach nicht gut optimiert. Das hat weniger was mit der Sprache zutun als mit dem Optimizing-Prozess. Die Anspielungen kannst du dir übrigens sparen. Bringen keinen weiter.

2
@Reyha24

JIT Compiler müssen ja auch nicht alles optimieren sondern nur die Teile, die am meisten laufen und das geht problemlos ohne große Einbußen. Bereits zum Zeitpunkt des Classloadings werden schon große Teile wegoptimiert. Nichtsdesto trotz solltest du, bevor du solche Argumente bringst, lesen. Einige Hochschulen haben dazu ganz nette Dokumente geschrieben. Die sind sogar schon einige Jahre alt. Alle kommen zu dem Schluss, dass in den aller meisten Belangen Java C++ nichts nachsteht. Und meine Anspielungen lasse ich nicht, denn was du sagst ist schlicht nicht mehr zeitgemäß.

2
@tente1

@tente1: Ich muss Rayha24 leider Recht geben.

Unter Linux habe ich vor einer Weile eine sehr sehr kleine Software in C geschrieben, die ptrace() aus "sys/ptrace.h" missbraucht, um zur Laufzeit die ausgeführten Instruktionen eines anderen Programms oder Prozesses zu zählen.

Ich habe dabei einige Standard-Operationen sowohl in C++ als auch in Java, Python, PHP, usw. gemessen. (Konstruktion und Destruktion, Schleifen, Algorithmen der jeweiligen Standardbibliothek, usw.)

Dadurch dass tatsächlich einzelne Maschinencode Instruktionen gezählt wurden (auch nach mehreren Durchläufen, um JIT eine Chance zu geben), konnte man exakt sehen, welche Operationen in welchen Sprachen wieviele Prozessor-Befehle verbrauchten.

Lange Rede kurzer Sinn: C++ war mit Abstand am schnellsten, danach kam Java, dicht gefolgt von Python und der Bummelletzte war PHP. :)

Dieses Experiment habe ich im letzten Winter gemacht, dürfte also relativ aktuell sein.

Zum Schluss noch eine kleine Bitte: Könntest du mir mal ein oder vielleicht sogar zwei Quellen zu den von dir genannten Uni-Papers nennen? Denn meiner Erfahrung nach beziehen sich solche Tests generell auf unrealistische Umgebungen (wie ich in meiner Antwort schon erwähnt habe: Qsort, Pi, etc.).

Vielen Dank schon mal im Voraus, und allen Mitlesern noch einen schönen Abend! :)

1
@TeeTier

 Ich muss Rayha24 leider Recht geben.

Allerdings nur aufgrund mangelhafter Erfahrung. Einen speziellen Algorithmus zu zählen ist schlichtweg albern. Mit solchen Mechanismen bekommst du einen Benchmark hin, der Java unperformant zeigt,. Genauso bekommst du einen Benchmark hin, der Java performant zeigt. Was ist nun richtig? Beides.

In der Praxis kommt es nicht drauf an, dass die Anzahl an Instruktionen gezählt wird. Warum? Software ist heutzutage hoch komplex. Durch Modularisierung und vieles mehr ist Software so weit gebaut, dass sie eben nicht mehr aus beispielsweise einer simplen For-Schleife besteht, deren Performance man misst. So ein Benchmark ist in der Praxis komplett unbrauchbar.

Tatsächlich gibt es nur selten bis nie eine Situation, in denen ein Performance-Problem auf Java selbst oder auf C/C++ selbst zurückzuführen ist. Performance-Probleme sind, wie tente und JavaTheHut andeuten, eine Frage der Optimierung und der optimalen Ausnutzung von System-Ressourcen. Was nützt dir beispielsweise ein hoch-performanter C/C++-Codeblock, wenn es direkt danach mangels Skalierbarkeit einen Flaschenhals beim Datenbankzugriff gibt, weil beispielsweise eine Bibliothek genutzt wird, die nicht Multithread-fähig ist?

Was nützt dir hochperformanter Java Code, wenn eine Bibliothek genutzt wird, die ständig zwischen nativem Code und Java hin- und herspringt (und ja, da ist Java extrem langsam, was in der Natur der Sache liegt)?

Wieso PHP vergleichen, was erst seit kurzem den Weg weg von einer reinen Interpreter-Sprache nimmt?

Hast du bei deinen Benchmarks die VM optimiert? Debugging-Code ausgeschaltet? Den Garbage-Collector auf zweiten Prozessor gelegt?

Es gibt so vieles, was man am Verhalten einer Java-VM optimieren kann und was dann bereits einen sprunghaften Anstieg der Performance bedeutet. Im Endeffekt gibt es immer Speziallösungen, in denen mal der C/C++-Code schneller ist und mal auch der Java-Code um ein vielfaches schneller. Das in Summe sagt gar nichts darüber aus, was nun insgesamt besser ist.

0
@mepeisen

@teetier Die meisten Paper dazu gibts nicht frei verfügbar. Ne BA vonna HS Neubrandenburg gibts dazu frei. Aber wenns dich interessiert, dann schau mal an einer/deiner Hochschulbibliothek vorbei und schau ob du deren Paperdatenbank nutzen darfst. Über Google scholar findet man dazu ne ganze Menge. Drauf zu greifen kann ich allerdings auch nur über die Hochschule.


1
@mepeisen

Erst mal sorry wegen der Verspäteten Antwort! :)

Einen speziellen Algorithmus zu zählen ist schlichtweg albern. Mit solchen Mechanismen bekommst du einen Benchmark hin, der Java unperformant zeigt,. Genauso bekommst du einen Benchmark hin, der Java performant zeigt. Was ist nun richtig? Beides.

Ich habe keinen "speziellen" Algorithmus gezählt, sondern die absoluten Basis-Standardaktionen, die in jedem Programm vorkommen, und einige Standardalgorithmen, die in jeder Standardbibliothek vorhanden sind. Wenn Java zum Alloziieren von Objektspeicher knapp 200 Instruktionen braucht, und C++ nur 40, dann gibt es daran nichts zu rütteln.

Meine Software hat im RAM alle Befehle aufgezeichnet, die zwischen einer Start- und einer End-Sequenz von weiteren Befehlen lagen. (An diese Sequenzen bin ich vorher mit Hilfe eines Debuggers gelangt, aber das nur am Rande.)

Somit konnte ich im Nachhinein den ausgeführten Programmcode Instruktion für Instruktion disassemblieren, und auch beobachten, wie der JIT-Compiler optimiert (Pipelinging z. B.).

Ich bin mir zwar sicher, dass - wie du sagst - man jeden Benchmark so hinbiegen kann, dass die favorisierte Sprache vorne liegt, aber im vorliegenden Falle war Java in keinem einzigen Punkt schneller als C++. Ich habe mich - wie gesagt - nur auf Basisoperationen beschränkt. (Auch Array Operationen, dazu weiter unten mehr.)

In der Praxis kommt es nicht drauf an, dass die Anzahl an Instruktionen gezählt wird. Warum? Software ist heutzutage hoch komplex. Durch Modularisierung und vieles mehr ist Software so weit gebaut, dass sie eben nicht mehr aus beispielsweise einer simplen For-Schleife besteht, deren Performance man misst. So ein Benchmark ist in der Praxis komplett unbrauchbar.

Wie gesagt, mir ging es um gundlegendste Funktionen ... der Zugriff einer HashMap<int, int> ist z. B. bei Java um den Faktor 5 langsamer, als bei C++. Dabei spielt es keine Rolle, in welchem konkreten Algorithmus diese HashMap angewendet wird.

Tatsächlich gibt es nur selten bis nie eine Situation, in denen ein Performance-Problem auf Java selbst oder auf C/C++ selbst zurückzuführen ist. Performance-Probleme sind, wie tente und JavaTheHut andeuten, eine Frage der Optimierung und der optimalen Ausnutzung von System-Ressourcen. Was nützt dir beispielsweise ein hoch-performanter C/C++-Codeblock, wenn es direkt danach mangels Skalierbarkeit einen Flaschenhals beim Datenbankzugriff gibt, weil beispielsweise eine Bibliothek genutzt wird, die nicht Multithread-fähig ist?

In dem Punkt gebe ich dir uneingeschränkt Recht! Das sehe ich auch so. Ich hoffe, es kam nicht so rüber, als ob ich dabei anderer Meinung bin.

Nochmal zur Verdeutlichung: Ich denke zwar, dass C++ meistens schneller als Java ist, aber ich denke ebenfalls, dass es fast nie darauf ankommt, da andere Punkte bei der Entwicklung und im Betrieb wesentlich mehr Priorität genießen sollten.

Wieso PHP vergleichen, was erst seit kurzem den Weg weg von einer reinen Interpreter-Sprache nimmt?

Weil PHP vermutlich die beliebteste Web-Skript-Sprache ist, und ich einfach nur mal interessehalber wissen wollte, wie sie sich sich im Verhältnis zu den anderen schlägt. Das tut jetzt hier aber nichts zur Sache, und dieses Experiment galt rein meinem persönlichen Interesse.

Hast du bei deinen Benchmarks die VM optimiert? Debugging-Code ausgeschaltet? Den Garbage-Collector auf zweiten Prozessor gelegt?

Ja, ich habe realistische Standard-Optimierungen durchgeführt, die auch in den meisten Produktivumgebungen vorzufinden sein sollten. Obwohl die Testklassen nur sehr klein waren, habe ich den Startspeicher massiv erhöht, natürlich ohne Debugging und den GC hatte ich sowohl aktiviert, als auch komplett deaktiviert, wobei ich sagen muss, dass selbst ein aktivierter GC mir nicht in meine Testbereiche gepfuscht hat, da die wohl einfach zu klein waren. Konnte bei ein paar hundert Instruktionen keinen Unterschied zwisch ein- und ausgeschaltetem GC feststellen ... ist ja auch logisch, dafür müsste das Programm dann wohl wesentlich länger durchlaufen.

Es gibt so vieles, was man am Verhalten einer Java-VM optimieren kann und was dann bereits einen sprunghaften Anstieg der Performance bedeutet. Im Endeffekt gibt es immer Speziallösungen, ...

Mir ging es nicht um hochoptimierte Speziallösungen, sondern um alltägliche Situationen, wie sie vermutlich in 99% aller Umgebungen anzutreffen sind. Wenn wir da jetzt beim verbleibenden 1% höchstoptimierte Java-Umgebungen mit liederlich hingepfuschtem C++ vergleichen, bringt uns das nicht weiter. Natürlich ist Java auch mal schneller als C++ ... oft sogar ... aber auf das Verhältnis kommt es an!

Das in Summe sagt gar nichts darüber aus, was nun insgesamt besser ist.

"Besser" ist undefiniert und keine Aussage. Hier ging es auch nicht um "besser", sondern ausschließlich um die Performance. Und es ging auch nicht darum, ob diese Performance in irgend einer Form wichtig oder lohnenswert ist.

Ein Verhältnis  55:45 ist statistisches Rauschen. Aber 95:5? :)

0
@TeeTier

PS: Platz hat nicht mehr gereicht ... noch eine Sache zu Array-Operationen.

Als Test habe ich versucht PCM-Audio innerhalb von verschiedenen Formaten zu konvertieren (stereo, 24bit signed => 8bit unsigned). Diese Aufgabe ist so einfach, dass der Quelltext bei C++ und Java nur minimalst unterschiedlich war. Der eigentliche Algorithmus war identisch. Allein mit -O1 war C++ dabei deutlich schneller, als Java (+ VM) mit nur allen möglichen Optimierungen.

Aber egal ... das war nur ein Experiment und ich erhebe da keinen Anspruch auf Korrektheit. :)

0
@TeeTier

@TeeTier: Hast du dazu vielleicht was veröffentlicht? Könnte was für die Allgemeinheit sinnvolles sein.

0
@TeeTier

Wenn Java zum Alloziieren von Objektspeicher knapp 200 Instruktionen braucht, und C++ nur 40, dann gibt es daran nichts zu rütteln

Nutze mal beispielsweise eine intelligente Garbage-Collection Bibliothek in C++ und schaue dann, was daraus wird.

Ein Java-Objekt zu allokieren ist inhaltlich einfach etwas anderes als es in C++ zu allokieren. Alleine schon, weil eine Standard-C++-Klasse nicht virtual ist und damit nicht an der Vererbung teilnimmt, eine Java-Klasse aber automatisch immer. Dann wiederum hat eine Java-Klasse immer einen Standard-Konstruktor. Hat dein C++-Compiler die Anweisung einen Standard-Konstruktor zu erzeugen? Das, was auf den ersten Blick gleich aussieht, ist schlichtweg nicht gleich...

sondern die absoluten Basis-Standardaktionen, die in jedem Programm vorkommen, und einige Standardalgorithmen, die in jeder Standardbibliothek vorhanden sind

Nehmen wir mal das Beispiel "Datei öffnen". Das ist in Java bereits von der Architektur her wegen dem Security-Manager etwas völlig anderes als in C++. Wenn du meinst, dass Java langsamer ist, weil es auch mehr tut, weil gleich aussehender C++-Code oftmals "direkter" ist, dann hast du in vielen Fällen mit der Standard-Bibliothek auch durchaus Recht. Deswegen ist Java aber per se nicht langsamer. Es macht Dinge anders und wenn du einen gleichrangigen C++-Code untersuchen wolltest, müsstest du auch die Features, wie einen Security-Manager o.ä., überhaupt erst mal dazu bauen.

Auch Array Operationen, dazu weiter unten mehr

Und auch hier bietet Java einige zusätzliche Features, die du in C++ nicht von Haus aus hast. Beispielsweise Range-Check.

Wie gesagt, mir ging es um gundlegendste Funktionen ... der Zugriff einer HashMap<int, int> ist z. B. bei Java um den Faktor 5 langsamer, als bei C++. Dabei spielt es keine Rolle, in welchem konkreten Algorithmus diese HashMap angewendet wird.

Hast du das mal mit Strings verifiziert? Wie sieht es mit der ConcurrentHashMap aus? Die HashMap ist im übrigen gerade nicht für primitives ausgelegt. Das muss man auch mal bedenken, wenn man etwas vergleicht. Sonst vergleicht man Äpfel mit Birnen.

Mir ging es nicht um hochoptimierte Speziallösungen, sondern um alltägliche Situationen

Du widersprichst dir selbst. Du nutzt hochoptimierten C++-Code und vergleichst ihn mit einem Mehr an Java-Code, ohne dich damit auseinanderzusetzen, was dieses Mehr bedeutet.

Ich kann unter DOS auch mittels INT 10h direkte Bildschirmausgabe machen und werde immer um ein Vielfaches schneller sein, was mir die Standard-Bibliothek von C++ jemals bieten wird. Ich werde immer nur einen Bruchteil der Instruktionen nutzen, weil ich nicht den Umweg über irgendwelche Streams und File-Handles gehe. Mein C-Code ist dann einfach hochspezialisiert im Vergleich zum C++-Code. Und doch ist es so etwas primitives, wie ein Hello-World.

Du vergleichst Äpfel mit Birnen. Du machst 5 Experimente, bei denen du nicht hinterfragst, wieso du auf ein Ergebnis kommst und aus diesen 5 Experimenten leitest du den Wahlspruch ab "Java ist immer langsamer als C++". So etwas funktioniert in der Praxis aber nicht.

0
@tente1

@tente1: Ich mache sehr oft diese Art von Experimenten, und ehrlich gesagt denke ich mir auch immer, dass es vielleicht interessant für Dritte wäre. Ich habe zwar noch nichts dazu veröffentlicht, aber vielleicht mache ich einfach mal einen Blog draus. :)

0
@xub88

Ich will hier jetzt den Rahmen dieser Diskussion nicht weiter sprengen, und verzichte diesmal auf Zitate deiner Aussagen, aber im Großen und Ganzen geht es hier NICHT um den Vergleich zwischen Java und C++!

Es geht um den Performance-Unterschied zwischen Java und C++! Das ist ein sehr großer und wichtiger Unterschied, und die ursprüngliche Frage zielte genau darauf ab: In welchen Punkten ist Java C++ unterlegen?

Man kann jede Sprache / Bibliothek / Funktionalität absichtlich verlangsamen; das ist keine Kunst! Ich kann bei C++ SecurityManager ähnliche Features einbauchen, GC benutzen, Container-Zugriffe über c.at(i) anstatt c[i] machen, und komme damit der Java Funktionalität nahe.

Die Frage ist nur, warum sollte ich so etwas tun? Es sind zwar schicke Features, die in vielen (je nach Szenario auch den meisten!) Fällen einfach nicht benötigt werden. Mit einem Wort: überflüssig.

Jedes der von dir genannten Features kann man bei C++ nachrüsten, und in vielen Fällen einfach auf defensive Programmierung und Grundfunktionen der STL zurück greifen. Dann ist man (fast immer) gleich auf mit Java.

ABER: Andersrum ist das nicht möglich. Ich kann bei Java keinen Array-Zugriff ohne Bereichsprüfung machen, wenn ich GC bewusst deaktiviere, muss ich mein komplettes Programm umschreiben, und auch wenn ich den SecurityManager nicht benötige, gibt es bei entsprechenden Funktionen IMMER mindestens noch eine sinnlose Überprüfung auf "null".

Fakt ist: Man kann JEDE Sprache beliebig langsam machen, indem man sie mit Features aufbläht, die nur in einem Bruchteil der Fälle benötigt werden. Man kann aber KEINE Sprache schneller machen, da man nicht benötigte - aber hartkodierte - Funktionen nicht einfach "abschalten" kann. (Anmerkung A: mit "Sprache" meine ich auch die entsprechende Laufzeitumgebung / Anmerkung B: Auch wenn JIT hier viel raus holen kann, gilt das trotzdem nur für einen Bruchteil!)

Beispiel gerade erst von Gestern: Ich habe für eine wissenschaftliche Einrichtung die Rotation einer Wolke aus Vektoren implementieren sollen. Bei denen basiert übrigens alles auf Java, aber das nur nebenbei.

Die Rotation von einer Wolke mit mehreren zich Millionen Vektoren hat in Java ~1,95 Sekunden beansprucht. Wohlgemerkt NACH allen Optimierungen an der VM. Wir haben auch mehrere VMs getestet, aber - nicht wirklich überraschend - war die Oracle VM am performantesten.

Dann habe ich den Code in C++ übersetzt und per JNI von Java aus aufgerufen: 0,89 Sekunden. Immerhin mehr als doppelt so schnell.

Aber halt! Für besagte Vektoren wurde eine double-Genauigkeit überhaupt nicht benötigt, und float sollte ausreichen: Leider gibt es in Java kein Math.sin(float), sondern nur Math.sin(double), und der Einsatz einer Drittbibliothek fällt sowieso weg, weil der Aufruf über JNI alleine schon Äonen verbrät.

Man kommt also nicht drum herum, direkt auf den Daten direkt in C++ zu arbeiten. Gesagt, getan: C++ Version in Template-Version umgebaut, und Benchmarks mit float, double und long double durchgeführt. Dabei gleich noch die Compilerflags -ffast-math und -march=native übergeben, umd SIMD wie AVX zu erzwingen ... Egebnis:

float: 0,58 sek / double: 0,85 sek / long double: 0,90 sek

Fazit: C++ war für die vorliegende Aufgabe die beste Lösung, da es in Java leider nicht möglich ist, den Anforderungen entsprechend einfache Genauigkeit bei Gleitkommaoperationen zu erzwingen. Aber selbst wenn wir bei C++ "long double", also erweiterte Genauigkeit, verwenden (was für uns einen absoluten Overkill an Genauigkeit darstellt), so sind wir immer noch mehr als doppelt so schnell wie die beste Java-Version!

Für unsere Anforderung hatten wir also einen Performancegewinn von mehr als +230%, wobei der eigentliche Aufwand für die Optimierung (umschreiben in C++ für JNI) inklusive Tests bei ca. einer viertel Stunde lag. Da kann keiner behaupten, dass sich so etwas nicht lohnt!

Ich muss dazu sagen, dass der Code primär für Java entwickelt und auch dafür optimiert wurde. Die nachträgliche Übersetzung wurde ohne größere C++ Optimierungen einfach nur plump übersetzt und die besagten Compilerflags angegeben.

Ich möchte noch erwähnen, dass wir spaßenshalber sowohl bei Clang++ als auch bei G++ die Optimierungen bewusst komplett deaktiviert hatten und keinerlei optimierende Flags angaben. Trotzdem lagen beide sogar mit "long double" bei ca. 1,8 sekunden, was noch mal knapp VOR Java MIT Optimierungen liegt! Mit normalem double (64 bit float) lagen wir ebenfalls mit komplett deaktiverten Optimierungen bei etwas über 1,0 sek, was fast doppelt so schnell ist, wie Java.

Fazit: Für numerische Berechnungen ist Java wirklich ungeeignet ABER ich stimme zu, dass die Performance in vielen Fällen nicht mal ansatzweise die Primäranforderung ist. Aber da es dem Fragensteller GENAU um diesen Punkt ging, beziehe ich mich jetzt mal darauf.

In vielen Fällen wird Java sowieso nur als API-Kleber benutzt, und dabei spielt die Effizienz sowieso fast gar keine Rolle.

0
@TeeTier

Noch eine Bemerkung: Von vielen anderen Programmiersprachen entwickle ich seit 1997 in Java (früher noch mit JBuilder von Borland) und seit 1999 in C++.

Als guter Programmierer sollte man GENAU wissen, WANN man WELCHES Werkzeug einzusetzen hat. Auf Teufel komm raus an Java / C++ / wasauchimmer fest zu halten ist einfach nur unprofessionell.

Ich liebe Java, achte seine Eleganz, das schöne API Design und die tollen Entwickler-Tools! Aber Java schleppt prinzipbedingt aufgrund eines völlig anderen Konzeptes als C++, eben verdammt viel Ballast mit sich, der meistens überhaupt nicht benötigt wird. In performance-kritischen Fällen - wider besseren Wissens - trotzdem auf Java zu setzen, zeugt von mangelnder Erfahrung.

Bei der Verwendung als besagter API-Kleber ist es völlig wurscht, ob man Java, C++ oder eine Skriptsprache wählt, und beim obigen Beispiel mit dem Börsenprogramm (welches mehr als eine Millionen Transaktionen pro Sekunde durchführt) ist Java logischerweise auch gut geeignet, da in den meisten Fällen vermutlich sowieso auf Datenpakete von der NIC gewartet wird.

Will man allerdings wirklich effizient mathematische Berechnungen durchführen, die über Integeradditionen hinaus gehen, nimmt man doch kein Java!

Und wenn - wie oben erwähnt - eine Firma dies dennoch tut, und eine Mathebibliothek in Java schreibt, weil Firmenintern kein C++ler zur Verfügung steht, dann spricht das nicht FÜR Java, sondern GEGEN das Management der Firma. In so einem Falle hat man gefälligst qualifizierte Leute einzustellen.

Managed Code und Unmanaged Code, IL oder Maschinencode, statisch oder dynamisch Typisiert ... all diese Punkte haben Vor- UND Nachteile. Man muss sich auf das Konzept seiner Entwicklung einlassen und weise abwägen, ob für partielle Aufgaben nicht evtl. etwas anderes besser geeignet ist.

Aus diesem Grunde erwarte ich auch von Entwicklern, die etwas auf sich halten, dass diese mehr als 10 Programmiersprachen fließend beherrschen. Wer nur eine Hand voll kann, ist einfach viel zu eingeschränkt in seiner Sichtweise, als dass er sich ein vollständiges Bild machen kann.

Übrigens hat ein Kollege kurz in Erwägung gezogen, das obige Beispiel mit der Vektorwolkenrotation in Assembler zu schreiben, da FSIN ja offensichtlich schneller als Aufrufe einer externen Mathelib sind. Ich hätte dem normalerweise sogar zugestimmt, da bei so trivialen Problemen der Entwicklungsaufwand in Assembler auch nicht den in C++ übersteigen dürfte, allerdings ist die FSIN-Instruktion tatsächlich viel viel langsamer, als ein von IBM entwickelter Algorithmus, der sich in den gängigen Standardbibliotheken wieder findet. Von daher konnten wir von vornherein auf Assembler verzichten.

Und so ein umfangreiches Wissen sollte man von einem Entwickler erwarten dürfen, der sich anschickt, Algorithmen zu implementieren. Mit Verlaub - aber ich glaube das ist nichts für den durchschnittlichen Java-Programmierer.

Also als Antwort auf die eigentliche Frage des Fragenstellers: Java ist nicht für Low-Level aufgaben geeignet, da - verglichen mit C++ - ineffizient ... und da nützt auch alles Schönrechnen nichts, denn am Ende steht der Profiler, und den kann man nicht mit Worten, sondern nur mit Code überzeugen.

Allerdings ist natürlich zu beachten WIE HOCH der Performance-Gewinn ist, und ob sich der Mehraufwand an Entwicklung lohnt. Aber da C++ keine schwarze Magie ist, und auch nicht wirklich sehr viel komplizierter als Java, hält sich der Zusatzaufwand meistens in akzeptablen Grenzen. (siehe oben: 15 Minuten für eine Gesamtsteigerung auf über 330% => absolut akzeptabel)

Aber darum ging es - ich wiederhole mich - in der Frage überhaupt nicht, sondern nur um Punkte, in denen Java unterlegen ist. Und das ist (absolut Betrachtet) die mangelnde Hardwarenähe und die damit einhergehenden Performanceeinschränkungen.

Ginge es in der Frage darum, wofür Java perfekt geeignet ist, würden mir ebenso viele Punkte einfallen.

Schönen Abend noch an alle Mitleser! :)

0
@TeeTier

Die Frage ist nur, warum sollte ich so etwas tun?

Ich habe nicht gesagt, dass du das tun sollst. Die ursprüngliche Frage des TE war, ob es Anwendungsgebiete gibt, für die man Java nicht nutzen kann. Punkt aus. Mehr hat er nicht gefragt.

Du kommst nun wieder mit einem ganz konkreten sehr spezialisierten Beispiel an und willst daraus wieder dieselbe allgemeingültige Formel ableiten. Das Problem ist doch, wenn nun einer deine allgemeingültige Formel (Java ist immer langsamer als C++) nimmt und auf seinen Anwendungsfall überträgt, der mit deinem nichts mehr zu tun hat, rennt er womöglich gegen eine Wand.

Das Ein-Mal-Eins der Performance ist, dass Benchmarks in hochkomplexen Systemen fast nie einen Sinn ergeben, denn sie versuchen in einer Zahl etwas zu verallgemeinern, was nicht zu verallgemeinern ist. Man kann Benchmarks auf einen einzelnen Algorithmus machen. Auf eine einzelne Aktion. Man kann mehrere machen und kann dann vielleicht eine Tendenz ableiten. Dann kann man überlegen, wieso die Tendenz ersichtlich ist und kann dann sagen "Java hat zusätzliche Features, die für mich fragwürdig sind, daher ist für mich in eigen Fällen C++ immer schneller." Dann überlässt man dem Leser die Entscheidung, ob er Java ebenfalls für aufgebläht hält. Aber man hat dem Leser das Handwerkszeug an die Hand gegeben, deinen persönlichen Benchmark, deine persönliche Erfahrung richtig einzuordnen.

Warum bin ich so penetrant? Ich bin durchaus Spezialist, was Anwendungs- und Datenbankperformance angeht. Schon oft habe ich durch teils primitive Maßnahmen Code derart optimiert, dass man die CPU-Last auf einen Bruchteil denken konnte o.ä. (wirklich auf Stellen nach dem Komma). In der Praxis der Anwendungsentwicklung ist mir selten ein Beispiel untergekommen, wo nicht die eigentliche Performance tatsächlich an der Programmiersprache hängen blieb. Tatsächlich waren es immer die Algorithmen, in denen ein Wurm war. Tatsächlich waren es unglückliche parallele Zustände uvm.

Deine Rotation der Wolken ist ganz hübsch. Klar, da geht es um Massendaten, die verrechnet werden sollen. Da hast du einen Algorithmus, der Millionenfach dasselbe tut und dann betrachtest du das Ergebnis "2,54 Sekunden" vs. "2,12 Sekunden". Schön und hübsch. Wie oft in der Praxis spürst du nun den erreichten Performance-Unterschied? Das ist eine wichtige Frage. Nicht um dein Tuning als unnötig abzustempeln, ich kenne deinen Anwendungsfall nicht. Sondern um mal zu fragen, was Performance ist. Performance ist nicht einfach nur eine nackte Zahl. Wenn dein Anwendungsfall vorsieht, dass die Wolke einmal pro Stunde berechnet wird, was machen dann diese paar Zehntel Sekunden Tuning für einen Unterschied?

Wenn dein Anwendungsfall aber vorsieht, dass du eine Million Wolken einmal pro Sekunde berechnen willst, nun, dann verweise ich darauf, dass deine Technologie falsch gewählt ist. Dann verweise ich auf Quanten-Computer, die das in Bruchteilen von Sekunden berechnet bekommen. Dann sind wir womöglich auch nicht mehr im Bereich von C++ :-)

1
@mepeisen

Man kann mehrere machen und kann dann vielleicht eine Tendenz ableiten.

Eigentlich wollte ich auf nichts anderes als eine "deutliche Tendenz in Richtung C++" hinaus. Dass meine Aussagen natürlich nicht allgemeingültig sind, ist klar. :)

Warum bin ich so penetrant?

Ich empfinde dich überhaupt nicht als penetrant. Das, was du sagst stimmt ja in der Sache! Aber das nur am Rande. :)

Ich bin durchaus Spezialist, was Anwendungs- und Datenbankperformance angeht.

Datenbanken sind nicht mein Hauptgebiet, aber ich konnte mal einen SQL-Cluster bestehend aus fast 30 unter Last ächzenden Maschinen auf einen einzigen Rechner "schrumpen", der noch verdammt Spielraum nach oben hatte. Dir ist Ähnliches vielleicht auch schon mal widerfahren, wenn du auf dem Gebiet Tätig bist. :)

Ich will damit nur sagen: Bevor man sich über die Performance-Unterschiede von Java und C++ Gedanken macht, sollte man sowohl Java, als auch C++ erst mal grundlegend beherrschen. Die auf 30 Rechner verteilte DB war eine Katastrophe, bei der ich am Verstand des Designers gezweifelt habe. Das gleiche trifft man fast immer an, wenn jemand - ohne ausreichende Erfahrung - versucht Code (in welcher Spache auch immer) zu optimieren.

In der Praxis der Anwendungsentwicklung ist mir selten ein Beispiel untergekommen, wo nicht die eigentliche Performance tatsächlich an der Programmiersprache hängen blieb.

Ja, das kann ich auch so unterschreiben! Allerdings gibt es wirklich hin und wieder Fälle, wo es genau so ist. Wenn auch - wie du schreibst - sehr selten. :)

Wie oft in der Praxis spürst du nun den erreichten Performance-Unterschied?

Es werden vier mal täglich (d. h. ca. alle 6 Stunden) gesammelte Daten auf relativ Leistungsstarken mobilen Computern an Orten berechnet, an denen man keinen Zugriff auf einen vernünftigen Cluster oder ein Netzwerk hat. Die Software dafür (Visualisierung, Statistik, etc.) ist in Java geschrieben, und es werden immer so lange und so viele Berechnungen durchgeführt, wie in das 6-Stunden Zeitfenster passen. Je mehr Daten berechnet werden können, desto genauer (exponentiell) ist das Endergebnis.

Vor diesem Hintergrund hatte eine Performance-Steigerung absolute Priorität. Es macht einen entscheidenden Unterschied, ob man nur n oder mehr als 3*n Berechnungen in der selben Zeit durchführen kann.

Aber du hast natürlich völlig Recht, wenn du jetzt sagst, dass das kein alltäglicher Anwendungsfall ist. :)

Wenn dein Anwendungsfall vorsieht, dass die Wolke einmal pro Stunde berechnet wird, was machen dann diese paar Zehntel Sekunden Tuning für einen Unterschied?

Keinen. :)

Und in so einem Falle würde ich mich auch nicht damit beschäftigen.

Dann verweise ich auf Quanten-Computer, die das in Bruchteilen von Sekunden berechnet bekommen.

OK, ich guck mir dann gleich mal die gängigen Preisvergleichsseiten an, und suche nach "mobilen Quantencomputern für den Außeneinsatz unter widrigen Bedingungen". Hoffentlich gibt es da etwas in der Preisklasse von gängigen Ultrabooks. Aber man bekommt ja bestimmt Rabatt, wenn man gleich 50 Stück bestellt. :)

Dann sind wir womöglich auch nicht mehr im Bereich von C++ :-)

Das sind wir schon lange nicht mehr. :)

Also dann, vielen Dank bis hier hin, und viel Erfolg mit deiner Arbeit!

Schönen Tag noch an dich und alle anderen Mitleser! :)

0

Eine bereichernde Diskussion in meinem noch andauernden Studium der Informatik. Vielen Dank dafür.

1

Anwendungsgebiete mit 433 MHz? Wo verwendet man 433 MHz als Frequenz?

...zur Frage

Verbindung von Netzwerken, wer kann mir den Sinn von folgenden Geräten erklären (siehe unten)?

Also ich schreib bald Abitur in meiner Fachrichtung (IT) und weiß die Funktion folgender Geräte noch nicht, das muss ich aber drauf haben:

Repeater, Hub, Switch, Bridge, Netzwerkkarte, Router, Gateway, Proxy

Also was ein Router ist weiß ich das ist wie zu Hause der dich ans Internet verbindet. Ein Switch weiß ich auch was das ist, ein Switch erweitert nur die Ports am Router mehr nicht, zb wenn der Router nur 4 Eingänge für LAN Kabel hat dann kann man sich eine Switch mit 20 Eingängen kaufen und halt mehr Geräte anschließen. Eine netzwerkkarte weiß ich auch was das ist die dient ja zum senden der Netzwerkdaten etc aber was ist der Rest?

Was ist ein repeater? Welchen Zweck hat er? Was ist eine Bridge, Gateway, Hub, USW? Bei mir zu Hause gibt’s keine Bridge, keinen hub, keine Gateway und wir haben dennoch Internet also was ist der Sinn dieser Geräte?

Mit freundlichen Grüßen

...zur Frage

Ich habe bei uns die Salbe "Zeel" gefunden, wofür ist die?

Ich habe eine Salbe gefunden mit der Aufschrift "Zeel". Die Packungsbeilage habe ich hier noch liegen, aber aus ihr geht nicht hervor, wofür diese Salbe verwendet wird (Anwendungsgebiete etc.).

Benutzt einer von euch diese Salbe und kann mir sagen, was man damit machen kann?^^

...zur Frage

Wofür wird C++ verwendet?

Hallo!

Ich bin Student und lerne C# und auch Java. Nun gibt es noch C++ und ich frage mich, wie sich diese "alte" und umständliche (im Vergleich zu C# und Java) Programmiersprache noch heute halten kann.

Wofür wird denn C++ verwendet? Was sind die Vorteile?

...zur Frage

Verwendung der Assemblersprache

Wofür kann ich Assembly Language verwenden?

Ein bekannter hat mir erklärt, dass es eine andere 'Schreibweise' von Maschinencode ist. Ausserdem habe ich gelesen, dass man Assembler auch für das Entwickeln von Betriebssystemen verwendet.

Was sind andere die Anwendungsgebiete dieser Sprache?

...zur Frage

Tabellen mit Java programmierern?

Wie kann ich mit java eine tabelle erstellen in die werte eingetragen werden ? und mit denen dann gerechnet wird ?

...zur Frage

Was möchtest Du wissen?