Fragen: JAVA (Geschwindigkeit), D()
-
Hier ist ein interessanter Artikel
http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.htmlThe center of the star is Java's average performance, and the branches shoot out to the individual benchmarks. The resulting shape says something about Java. On the X axis (slowness), we see that the performance is impressive, often brushing near the "wall of best performance" of C on the left. But on a few occasions the performance breaks down and the star shoots to the right. On the Y axis (code size), the star spreads across the chart, twice brushing near the top. Also the center of the star is slightly above the centroid of the background cloud. In other words, Java is not a particularly concise language, and in fact it is sometime depressingly convoluted, but its performance is excellent except when it's not.
-
Danke für die Antworten! Das zu Java:
Ich frage weil ich es irgendwie nicht verstehen kann, diese Langsamkeit ( die Ja zweifellos in der Vergangenheit vorhanden war ) kann doch hächstens im Zehntel - Hundertstel Sekunden Bereich sein? Denn Tausendstel und noch kleiner wäre garnicht mehr bemerkbar. Ich glaube mich würde diese Verzögerung nicht stören, deshalb wundere ich mich wieso alle sich so beschweren... nungut, ich werde es mir demnöchst mal Anschauen.Zu dem Speicher: Ich habe mich zuerst nciht getraut, wollte nichts kaputt machen ^^ Jetzt mal Ausprobiert bei 99'999 durchläufen mit jeweils einem Array mit 99'999 Feldern, kommt eine Fehlermeldung in der Konsole, ich benutze code:BLOCKS
Nurnoch zu D will ich noch ein par eurer Meinungen hören...
In meinem Obigen Link auf Seite 4 schrieb Skalli am 15.05.09
[...]
Einfach toll, leider kaum verbreitet, ich hoffe die Sprache findet viel mehr Anklang. Vereint die Vorteile von C#, C, C++, Java etc... Anschauen lohnt sich gewiss!
[...]
Und anhand seinem Ganzen Beitrag kommt es mir vor das er kein unerfahrener in dem thema ist.Wegen diesem Beitrag frage ich nun, nach D, und bitte euch eure meinungen über D zu schreiben, aber nciht nur : is gut/schlecht, sondern bitte mit einer kleinen Begründung.
mfG
-
im Zehntel - Hundertstel Sekunden Bereich
Bei Feld- Wald- und Wiesenprogrammen spielt es auch keine Rolle.
Anders sieht es aus wenn zB größere Datenmengen verhackstückt werden oder zB
die Routine mit dem "Hundertstel" einige Millionen mal aufgerufen wird.Ich habe Programme die schon mal eine Woche laufen können, da spielt das
dann schon eine Rolle (und ob es dann von einer garbage collection gekillt
wird).
-
under_cover schrieb:
kam mir eine Frage in den Sinn die ich schon lange habe:
1.Ist Java wirklich SO LAHM, dass es jeder 2. der über Java redet erwähnt ? Ich hatte noch keine Erfahrung mit Java, vielleicht guck ich es mir in Bälde an, wollte aber schon mal fragen...Am ehesten kriegst Du diesbezüglich quantitative Aussagen, wenn Du Dir Benchmarks ansiehst. Zum Beispiel den da:
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all&box=1
So. Da sieht Java durchaus recht fix aus. Aber natürlich haben derartige Mikrobenchmarks nur eine sehr begrenzte Aussagekraft. Die Frage ist jetzt, warum Java trotzdem als lahm wahrgenommen wird. Es gibt diesbezüglich mehrere Gründe:
1. Java war früher wesentlich langsamer. In der Anfangszeit ist Java wirklich nur interpretiert worden. In der Tabelle, die Du auf der Benchmark-Seite sieht, ist die damalige Geschwindigkeit mit dem Eintrag "Java 6 -Xint" vergleichbar. Heute sind wir von der Geschwindigkeit beim Eintrag "Java 6 -server". Du bist heute also locker um einenFaktor 7 schneller.
2. Bestimmte Dinge sind in Java in der Tat weiterhin recht langsam. Es ist auch heute noch möglich, äquivalente Programme in C++ und Java zu schreiben, die in Java vielleicht um einen Faktor 5 langsamer sind. Umgekehrt ist das sicherlich auch möglich, aber wesentlich schwerer. Man muss in Java durchaus darauf achten, an einigen Programmstellen etwas anders zu programmieren, um nicht in eine Performancefalle zu geraten.
3. Es gibt eine ganze Menge grafische Javaprogramme, die sehr schlecht und langsam reagieren. Das liegt dann meistens nicht daran, dass es nicht besser gehen würde, sondern eher daran, dass es dem Programmierer egal war. Man kann es sich bezüglich diesem Aspekt in Java leicht machen und schnell Code produzieren, der diese Schwachstellen aufweist, oder man muss etwas mehr nachdenken, um ein Programm mit besseren Eigenschaften zu realisieren. Der Punkt ist hier, dass Java durch die Struktur seiner Standardbibliothek die Programmierung von den langsameren Programmen fördert. Hinzu kommt, dass es jede Menge Programmierer gibt, denen diesbezüglich einfach Know-How fehlt. Java ist wesentlich leichter als C++ zu lernen. Und das heißt auch, dass es jede Menge Leute ohne wirklichen Einblick gibt, die Javaprogramme schreiben.
4. Java ist praktisch eine "General Purpose Mainstream Sprache". Das heißt, dass sie in fast allen Anwendungsgebieten eingesetzt werden kann. Und somit macht sie Sprachen wie C+ auch auf breiter Front Konkurrenz. Das wird von den Liebhabern dieser Sprachen aber natürlich nicht gerne gesehen und deshalb werden Gründe gesammelt, warum Java für etwas nicht eingesetzt werden sollte. In der Anfangszeit von Java war das einfach. Java war damals wesentlich langsamer und entsprechend war ein "Java ist dafür eh viel zu lahm" ein generelles Totschlagargument gewesen. Es war sogar generell DAS Argument gegen Java. Mit der Zeit ist Java wesentlich schneller geworden, aber das Argument wurde beibehalten. Aus welchem Grund auch immer. Sei es nun bewusst oder unbewusst: Die Leute suchen immer noch nach Gründen gegen Java und das alte Argument wird da gerne unreflektiert übernommen. Sei es, weil Leute unwissend sind und das irgendwo mal im Netz gelesen haben, oder sei es, weil Leute wissen, dass ihr Gegenüber unwissend ist und sich deshalb dieses alten, aber in der Zwischenzeit entkräfteten Arguments bedienen. Ich will damit nicht sagen, dass es heutzutage keine Gründe mehr gibt, Java für eine bestimmte Aufgabe nicht zu verwenden, aber dieses generelle Totschlagargument ist inzwischen eigentlich stark entkräftet. Man müsste sich jetzt stärker mit den Anwendungsspezifischen Vor- und Nachteilen von Java auseinandersetzen, um diesbezüglich eine sinnvolle Aussage treffen zu können.
So. Natürlich gibt es auch noch diverse weitere Gründe. Die Quintessenz bleibt aber, dass es heutzutage durchaus möglich ist, schnelle Javaprogramme zu schreiben. Aber dafür muss man unter Umständen einiges an Mühe investieren, um bestimmten Schwachstellen von Java auszuweichen. Die Frage ist, ob der Performancegewinn die Mühe wert ist.
-
Gregor schrieb:
Es ist auch heute noch möglich, äquivalente Programme in C++ und Java zu schreiben, die in Java vielleicht um einen Faktor 5 langsamer sind. Umgekehrt ist das sicherlich auch möglich, aber wesentlich schwerer.
dazu müßtest du eine konkrete und durch den programmierer nicht behebbare deutliche performance-schwäche von c++ finden. ich bezweifle, daß es die gibt.
-
volkard schrieb:
Gregor schrieb:
Es ist auch heute noch möglich, äquivalente Programme in C++ und Java zu schreiben, die in Java vielleicht um einen Faktor 5 langsamer sind. Umgekehrt ist das sicherlich auch möglich, aber wesentlich schwerer.
dazu müßtest du eine konkrete und durch den programmierer nicht behebbare deutliche performance-schwäche von c++ finden. ich bezweifle, daß es die gibt.
Kleine Speicherbereiche auf dem Heap anfordern
-
under_cover schrieb:
3. Die Programmiersprache D, sollte ich mir sie hin und wieder mal Angucken (damit meine ich mal einige meiner C++ sachen in D umzuschreiben, um mich vertraut zu machen), weil es irgendwann den Platz von C++ einnehmen sollte, oder wäre das Zeitverschwendung da D noch ne Weile Entwickelt werden muss bes es C++ überholt?
D ist erstmal ein ganz großer Hype. Von "C++ überholen" kann nicht im Ansatz die Rede sein. Es mangelt an Tools etc. Der Hype ist wohl auch schon vorbei: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Kurz:
hustbaer schrieb:
ad 3: vergiss D
-
Kleine Speicherbereiche auf dem Heap anfordern
siehe "small object allocator" , zum beispiel in "modern c++ design" von alexandrescu.
-
Danke euch allen für die Antworten jetzt bin ich wieder um ein Stück klüger
Und dann werde ich D wohl vergessen und mich eben ganz Auf C++ konzentrieren, und wie gesagt vielleicht gucke ich mir mal Hello World in Java an...Aufwiederlesen
-
volkard schrieb:
Kleine Speicherbereiche auf dem Heap anfordern
siehe "small object allocator" , zum beispiel in "modern c++ design" von alexandrescu.
natürlich kann man sich nen workaround bauen, aber standardmäßig ist es nicht gerade schnell.
-
lern lesen.
-
volkard schrieb:
... eine konkrete und durch den programmierer nicht behebbare deutliche performance-schwäche von c++ finden. ich bezweifle, daß es die gibt.
exceptions und downcasts waren in C++ auch nicht so die raketen, wenn ich mich nicht täusche.
-
Gut, wenn nicht behebbar nicht verwenden bedeutet, dann schon
-
Schnellgeschwindigkeit schrieb:
volkard schrieb:
Kleine Speicherbereiche auf dem Heap anfordern
siehe "small object allocator" , zum beispiel in "modern c++ design" von alexandrescu.
natürlich kann man sich nen workaround bauen, aber standardmäßig ist es nicht gerade schnell.
Das ist eine optimierung, kein work around. Du ersetzt einen algorithmus durch einen besseren. bei java musst du work-arounds einbauen z.b. garnicht allokieren zur laufzeit (ueblich auf vielen handy/smartphones) oder eigene free/alloc listen, weil du garnicht optimieren kannst und bei den einfachsten dingen ploetzlich einen furtchbar langen GC einspringen siehst.... oder im schlimmsten fall garnichts davno weisst.
z.b. vorletzter eintrag auf seite 1.
http://www.anddev.org/fastest_sprite_rendering-t3208.html schrieb:
The next thing i've noted that FPS were down every 5-6 seconds. I've checked console view and guess what? It was garbage collector. Removing this string helped to DOUBLE the fps and even more. Top FPS now are 50. average ~40.
-
rapso schrieb:
Schnellgeschwindigkeit schrieb:
volkard schrieb:
Kleine Speicherbereiche auf dem Heap anfordern
siehe "small object allocator" , zum beispiel in "modern c++ design" von alexandrescu.
natürlich kann man sich nen workaround bauen, aber standardmäßig ist es nicht gerade schnell.
Das ist eine optimierung, kein work around. Du ersetzt einen algorithmus durch einen besseren. bei java musst du work-arounds einbauen z.b. garnicht allokieren zur laufzeit (ueblich auf vielen handy/smartphones) oder eigene free/alloc listen, weil du garnicht optimieren kannst und bei den einfachsten dingen ploetzlich einen furtchbar langen GC einspringen siehst.... oder im schlimmsten fall garnichts davno weisst.
Das ist eine optimierung, kein work around.
:p
-
under_cover schrieb:
1.Ist Java wirklich SO LAHM, dass es jeder 2. der über Java redet erwähnt?
Ja, ist es. Jedes größere GUI Programm ist in Relation zu einem nativ Compilierten GUI Programm ziemlich lahm. Bei GUI-losen Programmen fällt es nicht so sehr ins Gewicht, da gibt es den größten Ärger wenn der GC herumzickt. Wenn man in die GC Falle gefallen ist, dann hat man einen ziemlichen Ärger am Hals.
-
~john schrieb:
under_cover schrieb:
1.Ist Java wirklich SO LAHM, dass es jeder 2. der über Java redet erwähnt?
Ja, ist es. Jedes größere GUI Programm ist in Relation zu einem nativ Compilierten GUI Programm ziemlich lahm. Bei GUI-losen Programmen fällt es nicht so sehr ins Gewicht, da gibt es den größten Ärger wenn der GC herumzickt. Wenn man in die GC Falle gefallen ist, dann hat man einen ziemlichen Ärger am Hals.
Die Lahmheit der GUIs liegt an den GUI Frameworks.
Zu behaupten Java ist langsam, bloss weil die GUI Frameworks langsam sind, ist wohl ein schlechter Scherz.
Dasselbe trifft im Übrigen auf C# und die "Forms" Klassen des .NET Framework zu. Die sind auch scheisse langsam (und nicht nur die).Und wir werden sicher auch irgendeine langsame GUI Library für C++ finden, damit wir dann behaupten können dass C++ langsam ist.
-
Wenn es gehen würde hätte Sun Swing schon längst schneller gemacht. Aber es geht einfach nicht da Java zu langsam ist.
-
Tim schrieb:
D ist erstmal ein ganz großer Hype. Von "C++ überholen" kann nicht im Ansatz die Rede sein. Es mangelt an Tools etc. Der Hype ist wohl auch schon vorbei: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Kurz:
hustbaer schrieb:
ad 3: vergiss D
Danke, dass du mich an tiobe erinnerst. Ich wollte doch möglichst oft ein "delphi programming" einbringen.
-
Also, VB(.NET) und Java sehe ich von der Erlernbarkeit auf dem gleichen Niveau und VB war früher ein echter Schnarchzapfen (wie Java auch), trotzdem hielt sich das Gemotze über das Laufzeitverhalten von VB in Grenzen, obwohl da nur ein p-code- compiler dahintersaß und für die Ausführung das Systemverzeichnis mit z.T. zueinander inkompatiblen vbrun- DLLs zugemüllt werden mußte. So von wegen ist ja BASIC, ganz nett für Einsteiger, paar Buttons und Fensterchens hinzukriegen, hat man einfach hingenommen.
SUN/Java ist da vollmundiger eingestiegen (vs. die damalige WINTEL- Front), hat seine Versprechen aber auch erst schrittweise eingelöst und dabei ignoriert, daß die Welt das nur Microsoft vollständig verzeiht - naja, nach Vista auch nicht mehr ohne Murren.Mit den JIT- Compilern ist bei Java geschwindigkeitsmäßig viel passiert, VB baut jetzt auf dem .NET- Framework auf, aber als Gelegenheitsschnitzer fürn PC fasse ich Java dennoch ernsthaft ins Auge. Wenn man den Benchmarks glauben darf, spielt die Entscheidung für oder gegen Java keine wesentliche Rolle mehr, schnarchigen Müll zusammenschreiben kann man in jeder Sprache. Und wenn man eine in VB.NET(VS 03)geschriebene Mini-GUI unter Vista ums Verrecken nicht zum Laufen bekommt, besteht auch kein zwingender Grund, sich an ein müdes Framework zu binden.
