Naja, allein Faktor 3-5 bedeutet dass du entweder einen Tag rechnen musst oder eine ganze Woche. Gerade bei neuen Machine Learning anwendungen macht es einen immensen Unterschied.
>> Für die meisten Dinge vernachlässigbar.
Ich weiß nicht ob's die meisten Dinge sind, aber für viele schon, da gebe ich dir recht.
>> c++ tut man sich doch nur dann an, wenn es wirklich nötig ist.
Modernes C++ muss man sich nicht mehr antun. Es ist eine schöne und bequeme Sprache. Schade, dass alle Leute den C++98 Standard im Kopf haben.
>> Viele Systemprogamme (schau mal Openstack an) sind heute in Python geschrieben, dass deutlich langsamer als Java ist.
Python ist nicht Python, da gibt es immense Performance-Unterschiede. Vieles bei diesen VM Sprachen ist auch nicht vergleichbar, da sie intern so wie NumPy auf C oder FORTRAN wechseln, sobald es performancekritisch wird. Java wechselt in JNI auf C bzw. C++. Dann sieht es so aus, als ob die Sprache nicht lahm ist. Die JVMs dieser Sprachen sind meist auch in C++ geschrieben. Wären sie in Java, dann kannst du da noch einen Faktor 5 davor multiplizieren.
Da gibt es aber auch Quellen, die was anderes aussagen.
Bei java muss man auch zwischen Server und Client Mode unterscheiden. Der JIT Compiler geht im Server Mode anderes vor. In der Regel braucht er länger um "warm" zu werden. Ist aber dafür dann schneller.
Ich spreche vom Quellcode, der Berechnungen ausführt. Dort bleibt 3-5 definitiv bestehen. Unabhängig vom Server oder Client.
Nicht berücksichtigt sind dieser Dinge:
- dass z.B. die Apache Machine Learning Bibliotheken teils nur mit Double anstatt sinnvollerweise mit Float arbeiten. Das allein ist schon Faktor 2. - Mittlerweile sind die AI Algorithmen so weit frisiert, dass sie auch gut mit Half Precision zurechtkommen. Damit haben wir Faktor 4. Java bietet noch kein natives Half Precision. Hier wird der Unterschied noch eine Ordnung höher sein. - Standardisierte Bibliotheken für GPGPU existieren auch nicht. Hier ist locker Faktor 100 drin.
Wenn wir von realen Benchmarks sprechen, dann müssen auch die oberen Dinge berücksichtigt werden.
Bei synthetischen Benchmarks unter gleichen Bedingungen ist mir auch kein Benchmark bekannt, der öffentlich von vielen Teilnehmen (nicht nur einer Person) getuned wurde, bei dem Java nicht um mindestens Faktor 3 gegenüber C absackt. Die Benchmarks einzelner Personen mit wenigen Beispielen sind nur Augenwischerei um sich eine Beruhigungspille zu verschreiben.
Wer es besser kann, sollte seinen Java Code hier einreichen:
https://benchmarksgame.alioth.debian.org/
Vielleicht irre ich mich ja und es geht doch schneller.
Der Quellcode macht erstmal gar nichts...nein der berechnet nichts. Synthetische Benchmarks? Dachte Du redest von realworld-performance. Und wieso redest Du jetzt ploetzlich von C und nicht mehr von C++
>> Der Unterschied zu c++ ist auch nicht so toll.
Naja, allein Faktor 3-5 bedeutet dass du entweder einen Tag rechnen musst oder eine ganze Woche. Gerade bei neuen Machine Learning anwendungen macht es einen immensen Unterschied.
>> Für die meisten Dinge vernachlässigbar.
Ich weiß nicht ob's die meisten Dinge sind, aber für viele schon, da gebe ich dir recht.
>> c++ tut man sich doch nur dann an, wenn es wirklich nötig ist.
Modernes C++ muss man sich nicht mehr antun. Es ist eine schöne und bequeme Sprache. Schade, dass alle Leute den C++98 Standard im Kopf haben.
>> Viele Systemprogamme (schau mal Openstack an) sind heute in Python geschrieben, dass deutlich langsamer als Java ist.
Python ist nicht Python, da gibt es immense Performance-Unterschiede. Vieles bei diesen VM Sprachen ist auch nicht vergleichbar, da sie intern so wie NumPy auf C oder FORTRAN wechseln, sobald es performancekritisch wird. Java wechselt in JNI auf C bzw. C++. Dann sieht es so aus, als ob die Sprache nicht lahm ist. Die JVMs dieser Sprachen sind meist auch in C++ geschrieben. Wären sie in Java, dann kannst du da noch einen Faktor 5 davor multiplizieren.
>>Naja, allein Faktor 3-5 bedeutet
Da gibt es aber auch Quellen, die was anderes aussagen.
Bei java muss man auch zwischen Server und Client Mode unterscheiden.
Der JIT Compiler geht im Server Mode anderes vor.
In der Regel braucht er länger um "warm" zu werden.
Ist aber dafür dann schneller.
Ich spreche vom Quellcode, der Berechnungen ausführt. Dort bleibt 3-5 definitiv bestehen. Unabhängig vom Server oder Client.
Nicht berücksichtigt sind dieser Dinge:
- dass z.B. die Apache Machine Learning Bibliotheken teils nur mit Double anstatt sinnvollerweise mit Float arbeiten. Das allein ist schon Faktor 2.
- Mittlerweile sind die AI Algorithmen so weit frisiert, dass sie auch gut mit Half Precision zurechtkommen. Damit haben wir Faktor 4. Java bietet noch kein natives Half Precision. Hier wird der Unterschied noch eine Ordnung höher sein. - Standardisierte Bibliotheken für GPGPU existieren auch nicht. Hier ist locker Faktor 100 drin.
Wenn wir von realen Benchmarks sprechen, dann müssen auch die oberen Dinge berücksichtigt werden.
Bei synthetischen Benchmarks unter gleichen Bedingungen ist mir auch kein Benchmark bekannt, der öffentlich von vielen Teilnehmen (nicht nur einer Person) getuned wurde, bei dem Java nicht um mindestens Faktor 3 gegenüber C absackt. Die Benchmarks einzelner Personen mit wenigen Beispielen sind nur Augenwischerei um sich eine Beruhigungspille zu verschreiben.
Wer es besser kann, sollte seinen Java Code hier einreichen:
https://benchmarksgame.alioth.debian.org/
Vielleicht irre ich mich ja und es geht doch schneller.
Der Quellcode macht erstmal gar nichts...nein der berechnet nichts.
Synthetische Benchmarks? Dachte Du redest von realworld-performance.
Und wieso redest Du jetzt ploetzlich von C und nicht mehr von C++