Java vs. C. Performance-Vergleich
-
*tust
Den Gefallen tu ich euch nicht.
-
Setze dich mal mit deiner Krankheit auseinander:
Die dissoziale Persönlichkeitsstörung ist durch ausgeprägte Diskrepanz zwischen Verhalten und geltenden sozialen Normen gekennzeichnet. Typische Merkmale sind
- Unfähigkeit, sich in andere hineinzuversetzen
- Unfähigkeit zur Verantwortungsübernahme, gleichzeitig eine klare Ablehnung und Missachtung sämtlicher sozialer Normen, Regeln und Verpflichtungen
- Unfähigkeit, längerfristige Beziehungen aufrechtzuerhalten, jedoch keine Probleme mit der Aufnahme frischer Beziehungen
- Geringe Frustrationstoleranz, Neigung zu aggressivem und gewalttätigem Verhalten
- Fehlendes Schuldbewusstsein
- Unfähigkeit, aus Erfahrungen zu lernen.
-
kalt
-
Steffo: Dem anderen eine psychische Erkrankung zu unterstellen, ist auch nicht nett. Das hast du doch gar nicht nötig
-
Aber es wäre schon mal interessant zu wissen, ob Pee nur ein Troll ist oder wirklich so dumm.
-
Steffo schrieb:
[steffo@localhost aufgabe2]$ time ./bubblesort 100000 a[0]=670 real 1m17.174s user 1m17.112s sys 0m0.026s [steffo@localhost aufgabe2]$ time java Bubblesort 100000 a[0]=-2147458265 real 1m47.629s user 1m47.539s sys 0m0.875sOk, das C++ Programm braucht also nur ~70% der Zeit des Javaprogramms. Das hört sich ungefähr nach dem an, was ich typischerweise annehmen würde. Aber so ein geringer Performanceunterschied ist natürlich nicht das, weswegen Java von einigen für langsam gehalten wird. Ich denke, wirkliche Unterschiede wird man sehen, wenn man stark objektorientierten Code schreibt. ...mit vielen kleinen Objekten, die man in C++ vielleicht auf den Stack legen würde. Wenn Du einen großen Unterschied zwischen den beiden Sprachen sehen willst, dann musst Du ein Programm schreiben, in dem derartiges zu finden ist.
-
Gregor schrieb:
Wenn Du einen großen Unterschied zwischen den beiden Sprachen sehen willst, dann musst Du ein Programm schreiben, in dem derartiges zu finden ist.
So ist es. Gregor und ich haben uns früher haufenweise solche Programme um die Ohren gehauen, die eine Schwäche der Implementierung der anderen Standardlib ausnutzten, und haben dann mit Faktor 3 und mehr behauptet, die andere Sprache sei prinzipiell ungeheuer langsam.
-
Gregor schrieb:
Ok, das C++ Programm braucht also nur ~70% der Zeit des Javaprogramms. Das hört sich ungefähr nach dem an, was ich typischerweise annehmen würde. Aber so ein geringer Performanceunterschied ist natürlich nicht das, weswegen Java von einigen für langsam gehalten wird. Ich denke, wirkliche Unterschiede wird man sehen, wenn man stark objektorientierten Code schreibt. ...mit vielen kleinen Objekten, die man in C++ vielleicht auf den Stack legen würde. Wenn Du einen großen Unterschied zwischen den beiden Sprachen sehen willst, dann musst Du ein Programm schreiben, in dem derartiges zu finden ist.
Ich bin wirklich kein Profi, aber soweit ich weiss, werden Javaprogramme hauptsächlich wegen Swing als langsam empfunden, weil dort alles selbst gezeichnet wird anstatt direkt vom OS.
Der nächst Punkt zum Stack (wie gesagt, bin kein Profi, aber unser Prof hat das so gesagt
) ist der, dass beim Stack Rücksprungsadressen gespeichert werden, d. h. BufferOverflows bei dem eine eigene Rücksprungsadresse mit eigenem Code untergejubelt wird, problemlose möglich sind. Beim Heap geht das nicht. Außerdem kann man seine eigenen Programme mit valgrind (was unser Prof. für die C/C++-Programmiung für unverzichtbar hält) nicht vollständig testen, da valgrind nur den Heap beobachtet.Liebe Grüße
Steffo
-
Steffo schrieb:
Ich bin wirklich kein Profi, aber soweit ich weiss, werden Javaprogramme hauptsächlich wegen Swing als langsam empfunden, weil dort alles selbst gezeichnet wird anstatt direkt vom OS.
Auch Javaprogramme, die nicht Swing benutzen, werden als langsam empfunden.
Der nächst Punkt zum Stack (wie gesagt, bin kein Profi, aber unser Prof hat das so gesagt
) ist der, dass beim Stack Rücksprungsadressen gespeichert werden, d. h. BufferOverflows bei dem eine eigene Rücksprungsadresse mit eigenem Code untergejubelt wird, problemlose möglich sind. Beim Heap geht das nicht.Was willst du damit sagen?
Außerdem kann man seine eigenen Programme mit valgrind (was unser Prof. für die C/C++-Programmiung für unverzichtbar hält) nicht vollständig testen, da valgrind nur den Heap beobachtet.
Auf dem Stack können prinzipbedingt keine Speicherlecks auftreten. Also braucht valgrind auch nicht den Stack zu beobachten.
-
Ich würde auch sagen, dass man in C und C++ noch ganz andere Möglichkeiten zur Strukturierung im Speicher hat, als in Java und Konsorten. Das dürfte noch am Ehesten große Performanceunterschiede zeigen, aber natürlich ist das mit so einfachen Tests nicht wirklich gut nachzuvollziehen. Eventuell könnte man mal Quicksort implementieren (nicht rekursiv natürlich), um dann zu gucken was der Stack von C/C++ so rausholen kann.
@Steffo Den Stack muss man nicht überwachen, weil alles automatisch passiert. Das ist ja das tolle und RAII nutzt das aus.
-
so ein grind, valgrind sucht doch nicht nur speicherlecks...
It also includes three experimental tools: a heap/stack/global array overrun detector,
-
Steffo schrieb:
Der nächst Punkt zum Stack (wie gesagt, bin kein Profi, aber unser Prof hat das so gesagt
) ist der, dass beim Stack Rücksprungsadressen gespeichert werden, d. h. BufferOverflows bei dem eine eigene Rücksprungsadresse mit eigenem Code untergejubelt wird, problemlose möglich sind. Beim Heap geht das nicht.Das Unterjubeln geht immer nur, wenn Programmierfehler ein Loch aufmachen.
Steffo schrieb:
Außerdem kann man seine eigenen Programme mit valgrind (was unser Prof. für die C/C++-Programmiung für unverzichtbar hält) nicht vollständig testen, da valgrind nur den Heap beobachtet.
Keine Ahnung, wie es mit C ist. Aber für C++ ist valgrind völlig unnötig.
Und der Stack ist SCHNELL! Allokierung aller lokaler Variablen geschieht in einem Takt. Einfach die Größe aller lokaler Variablen vom Stackpointer abziehen. Beim Heap braucht man so um die 100 Takte pro Objekt (Na, sind immernoch 40 Mio pro Sekunde, normalerweise rechnet man dann auf den Objekten hundertmalsolang, also egal.) (geht auch schneller, mit Allokatoren, die auf die Anwendung angepaßt werden).
-
Michael E. schrieb:
Auch Javaprogramme, die nicht Swing benutzen, werden als langsam empfunden.
Z. B.?
Der nächst Punkt zum Stack (wie gesagt, bin kein Profi, aber unser Prof hat das so gesagt
) ist der, dass beim Stack Rücksprungsadressen gespeichert werden, d. h. BufferOverflows bei dem eine eigene Rücksprungsadresse mit eigenem Code untergejubelt wird, problemlose möglich sind. Beim Heap geht das nicht.Was willst du damit sagen?
Ich habe die Sicherheit angesprochen. Es ist prinzipiell sicherer ein Array auf dem Heap anzulegen als auf dem Stack.
Außerdem kann man seine eigenen Programme mit valgrind (was unser Prof. für die C/C++-Programmiung für unverzichtbar hält) nicht vollständig testen, da valgrind nur den Heap beobachtet.
Auf dem Stack können prinzipbedingt keine Speicherlecks auftreten. Also braucht valgrind auch nicht den Stack zu beobachten.
Man kann aber problemlos den Speicherbereich auf dem Stack überschreiben und das wird valgrind nicht bemerken!
L. G.
Steffo
-
Steffo schrieb:
Ich habe die Sicherheit angesprochen. Es ist prinzipiell sicherer ein Array auf dem Heap anzulegen als auf dem Stack.
Ja, in C.
In C++ kann man ein std::array (Arraygrenzencheck im Debug-Code vorausgesetzt) nehmen und ist sicher.
-
Also ich kenne ja nicht viel Java-Software, aber das, was ich kenne, was ne UI hat, ist wegen der Langsamkeit fast nie benutzbar. Jetzt macht man in Java natürlich auch keine Anwendungsprogramme, weil es auch einfach sehr hässlich ist.
Man müsste Mal komplexe Serverframeworks vergleichen. Nur wird so was wiederum nicht in C++ programmiert. Aber wenn man zwei solche Umgebungen vergleichen würde, wären die Komplexitäten wohl zu hoch, als dass die Vergleiche vernünftig wären. Und da Java ja produktiv auch für Riesenprodukte eingesetzt werden kann, ist die Performance wohl zwangsläufig in Ordnung.
Und wenn Java nicht für irgendwelche Dinge zu langsam ist, dann ist es eben auch wieder egal, richtig? Mit Java kommt man nur eben nicht an die Systeminterna dran, man kann wahrscheinlich auch nicht die Grafikkarte programmieren (oder muss da was durchreichen, was dann zu viel Zeit kostet), oder? Ohne solche Spielereien verliert man viel Zeit.
-
Steffo schrieb:
Michael E. schrieb:
Auch Javaprogramme, die nicht Swing benutzen, werden als langsam empfunden.
Z. B.?
Man sollte den Spieß umdrehen und nach schnellen Javaprogrammen fragen
Javaprogrammierer, die ich getroffen habe, tendierten alle dazu, auch schon kleine Probleme totzudesignen. Dann hatte man auf einmal ein Dutzend Klassen, wo es eine Handvoll Funktionen auch getan hätten. Klar, dass das auf die Performance geht.
-
Zu der Sache mit dem stack overflow: Bei mir hat sich eclipse schon einige Male mit einer stack overflow exception verabschiedet, so gut scheint das in java also auch nicht gelöst zu sein
-
GorbGorb schrieb:
Zu der Sache mit dem stack overflow: Bei mir hat sich eclipse schon einige Male mit einer stack overflow exception verabschiedet, so gut scheint das in java also auch nicht gelöst zu sein
Das hat den Hintergrund, dass der Stack für gewisse Aufgaben tatsächlich unverzichtbar ist. Z. B. gerade im Bereich Compiler bzw. IDE, wo der Code auf Gültigkeit geprüft werden muss, arbeitet man mit Stackalgorithmen und da können sich natürlich Programmierfehler einschleichen. Aber Arrays werden in Java soweit ich weiss nicht im Stack, sondern im Heap angelegt.
Liebe Grüße
Steffo
-
Steffo schrieb:
Das hat den Hintergrund, dass der Stack für gewisse Aufgaben tatsächlich unverzichtbar ist. Z. B. gerade im Bereich Compiler bzw. IDE, wo der Code auf Gültigkeit geprüft werden muss, arbeitet man mit Stackalgorithmen
Damit ist aber nicht der Stack[TM] gemeint, über den wir hier reden.
-
Michael E. schrieb:
Damit ist aber nicht der Stack[TM] gemeint, über den wir hier reden.
OK, das stimmt. Peinlich.