Java schneller als C++?!

java ist schön einfach und bequem und die implementierungszeit kurz - cpp ist mächtig. ob was wo warum um einen konstanten faktor von 0 bis c schneller ist interessiert echt überhaupt nicht - so lange es nicht um sehr zeitkritische probleme geht.

irgendwo meinte hier einer, dass es nicht frage der sprache, sondern der datenstruktur und des algos ist, um laufzeiten zu optimieren. dem schließe ich mich an.

unido schrieb:

irgendwo meinte hier einer, dass es nicht frage der sprache, sondern der datenstruktur und des algos ist, um laufzeiten zu optimieren. dem schließe ich mich an.

Naja, das hört sich zwar immer gut an, ist aber nur die halbe Wahrheit. Es sollte in allen Sprachen zur Selbstverständlichkeit eines Programmierers gehören, den besten Algorithmus und die beste Datenstruktur für eine gegebene Aufgabe zu nehmen, wenn es darauf ankommt. Wenn man das nicht hat, dann ist man als Programmierer daran schuld, dass das Programm nicht schnell genug ist und die Schuld liegt dann nicht bei der Sprache, in der man programmiert hat.

Allerdings kann die Sprache selbst auch ein Faktor sein, der zu Performanceproblemen führen kann. Wenn eine Sprache bestimmte Dinge nicht unterstützt, dann muss man im einfachsten Fall einen großen Mehraufwand betreiben, um entsprechendes zu programmieren oder es geht vielleicht sogar gar nicht. Wenn man diese Sache nun für die maximale Performance braucht, dann hat man ein größeres Problem, das schnell zu massiven Geschwindigkeitseinbußen führen kann.

Beispiel: Ich beschäftige mich etwas mit Bildverarbeitung. Da wird für den Wert eines Pixels oft ein "unsigned char" in C++ genommen, also ein 8 Bit Datentyp ohne Vorzeichen. Den gibt es aber in Java nicht. Man muss also drumherumarbeiten und ein short nehmen oder immer kompliziert umrechnen. Aber es ist noch viel schlimmer: Man nutzt nämlich auch andere Datentypen für die Werte von Pixeln. In C++ bietet es sich deshalb an, gewisse Algorithmen usw. als Templates zu schreiben. Java bietet aber keine Generics für primitive Datentypen. Man muss sich also wieder etwas einfallen lassen, nimmt beispielsweise eine Menge Redundanz in kauf oder weicht auf einen sogenannten Bottleneck Datentyp aus, für den dann die Algorithmen implementiert werden. Möglicherweise macht man auch eine Kombination aus beidem. Für so einen Bottleneck Datentypen nimmt man dann oft float oder ähnliches. Man hat also plötzlich Algorithmen für einen 4 Byte Fließkommadatentyp, obwohl das Gleiche für einen 8 Bit Ganzzahltyp auch gereicht hätte. Wenn man solche Probleme betrachtet, ist es kein Wunder, wenn das entsprechende Javaprogramm am Schluss um einen Faktor 10 oder größer langsamer als das C++ Programm ist und zusätzlich deutlich mehr Speicherplatz verbraucht. Und so ein Faktor 10 macht natürlich etwas aus. Den kann man nicht einfach mit einem "ist ja nur ein konstanter Faktor" wegwischen. Man muss da 3 Rechnergenerationen warten, bis das Javaprogramm so schnell läuft, wie das C++ Programm heute schon und das kann in vielen Bereichen natürlich als KO-Kriterium gegen Java gewertet werden.

Allerdings wird das gerade in der Bildverarbeitung ein spezielles Problem sein, welches sich bei vielen anderen Anwendungen nicht derart äußert. Du solltest diesen Beitrag also nicht nehmen, um Java generell für zu lahm zu erklären. Die Frage ist halt, was man braucht.

roan312

Ich kann eurer Diskusion zwar nicht ganz im Detail folgen, aber müsste man die Ausgabeanweisungen (printf() und so...) nicht nach dem Timer-Ende laufen lassen?
Das soll ja schließlich ein Mathematik "Benchmark" (wenn man es so nennen kann) sein.

roan312 schrieb:

Ich kann eurer Diskusion zwar nicht ganz im Detail folgen, aber müsste man die Ausgabeanweisungen (printf() und so...) nicht nach dem Timer-Ende laufen lassen?

Eigentlich schon, aber andererseits verbraucht das fast keine Zeit und ändert wohl nichts am Ergebnis, wenn der Benchmark selbst einige Sekunden andauert.

DEvent

Das selbe Problem hatte ich mal auch, als ich Bilder einlesen musste und die Daten alle in unsigned short waren, java aber keine unsigned kennt.
Gabts dafür eigentlich einen Grund?
Ich musste dann auch erst umrechnen, was ja wieder Rechenzeit kostet. Man sollte ja die Sprache immer nach dem Problem wählen und nicht die Sprache dem Problem anspassen. Da muss man halt auch eine neue Sprache lernen

Wieso braucht ihr unsigned bei Farbwerten? Farben behandelt man doch praktisch als Bitmuster, also z.B. 0xFFFFFF00 für deckendes Gelb. Solche Bitmuster lassen sich mit unsigned shifts (<<< und >>>) leicht erzeugen. Der Unterschied zwischen signed und unsigned Typen besteht doch mehr oder weniger nur daraus, dass die Operatoren '<' und '>' anders arbeiten. Rechenoperationen verhalten sich gleich und erzeugen die selben Bitmuster.
So richtig nötig sind unsigned Typen wirklich nicht. Ob man sie deswegen gleich weglassen muss, darüber kann man natürlich streiten.

Gregor@Home schrieb:

... Und so ein Faktor 10 macht natürlich etwas aus. Den kann man nicht einfach mit einem "ist ja nur ein konstanter Faktor" wegwischen. Man muss da 3 Rechnergenerationen warten, bis das Javaprogramm so schnell läuft, wie das C++ Programm heute schon und das kann in vielen Bereichen natürlich als KO-Kriterium gegen Java gewertet werden. ...

Dann sind wir uns beide anscheinend einig, dass bei deinem problem java nicht die erste wahl ist. dein faktor von 10 untermauert die berechtigung des "ko-kriteriums".

Gregor@Home schrieb:

... Allerdings wird das gerade in der Bildverarbeitung ein spezielles Problem sein, welches sich bei vielen anderen Anwendungen nicht derart äußert. Du solltest diesen Beitrag also nicht nehmen, um Java generell für zu lahm zu erklären. Die Frage ist halt, was man braucht.

tue ich überhaupt nicht. um ehrlich zu sein, ich liebe java. die frage ist nur, wann die sprache sinnvoll ist. schwarz-weiß malerei und das zwanghafte favorisieren von etwas a' la "oh linux ist ja sooo toll und windows ja sooo schlecht. und java sooo schlecht und c++ sooo toll" gehen mir nur einfach auf die nerven. ebenso, dass es anscheinend noch genug leute gibt, die es kaum fassen können, dass java bei vielen sachen sehr sehr nah an native ausführungsperformance rankommt. habt ihr denn noch nie etwa rosa schweinchen durch die lüfte fliegen sehen?

Optimizer schrieb:

Wieso braucht ihr unsigned bei Farbwerten?

Ich beziehe mich nicht auf Farbwerte. Das bezog sich jetzt auf Grauwert-Bilder und vor allem Grauwert-Volumen (CT-Aufnahmen usw.).

Optimizer schrieb:

Farben behandelt man doch praktisch als Bitmuster, also z.B. 0xFFFFFF00 für deckendes Gelb. Solche Bitmuster lassen sich mit unsigned shifts (<<< und >>>) leicht erzeugen.

Ja, so sehen Farbbilder aus, die du irgendwo darstellst. Damit arbeitet man aber meistens nicht, wenn man Bildverarbeitung betreibt. Der erste Schritt ist da meistens eine Konvertierung zu einem Bild mit nur einem Kanal. Oder man behandelt die Farbkanäle zumindest separat.

Optimizer schrieb:

Der Unterschied zwischen signed und unsigned Typen besteht doch mehr oder weniger nur daraus, dass die Operatoren '<' und '>' anders arbeiten. Rechenoperationen verhalten sich gleich und erzeugen die selben Bitmuster.

Nun braucht man aber < und > an allen möglichen Stellen. So ein Mist. Das fängt ja schon an, wenn man irgendwelche Schwellenwerte einführt und die kommen nun wirklich häufig vor. Oft braucht man den Wert des Pixels auch als Index für ein Array, wenn man zum Beispiel ein Histogramm erstellen will. Und es gibt natürlich noch tausend andere Gründe, warum man dort unsigned Werte braucht. Man kann natürlich auf einen größeren Datentyp ausweichen und so nicht auf unsigned angewiesen sein, aber ideal ist das, wie gesagt nicht.

@Gregor,

ich bin softwareentwickler im Bereich industrielle Bildverarbeitung. Das Basisprogramm, welches wir verwenden (mit Source), hat ein Frontend welchen in VB 6 geschrieben ist. Das Backend ist in C++. Das Frontend wird jetzt in den nächsten Monaten von VB nach Java portiert. Das Frontend arbeitet aber auch viel mit den Grauwerten und benutzt den VB Datentyp Long. Ich denk mal, wenn sie nach java portieren werden sie auch einfach einen größeren Datentypen nehmen

bv-mensch schrieb:

@Gregor,

ich bin softwareentwickler im Bereich industrielle Bildverarbeitung. Das Basisprogramm, welches wir verwenden (mit Source), hat ein Frontend welchen in VB 6 geschrieben ist. Das Backend ist in C++. Das Frontend wird jetzt in den nächsten Monaten von VB nach Java portiert. Das Frontend arbeitet aber auch viel mit den Grauwerten und benutzt den VB Datentyp Long. Ich denk mal, wenn sie nach java portieren werden sie auch einfach einen größeren Datentypen nehmen

Das "Frontend" ist ja nicht gerade der Teil, der die Leistung benötigt. Insofern sehe ich da kein Problem bezüglich des Einsatzes von Java.