schnelles java prog

[wizcer]

lololol seit ihr dumm

[knivil]

bevor eine OutOfMemoryException fliegt

Lesen, verstehen, antworten ...

Deswegen steht "out of memory ..." ja auch in Anfuehrungszeichen

lololol seit ihr dumm

http://www.seit-seid.de/

[Dravere]

knivil schrieb:

Deswegen steht "out of memory ..." ja auch in Anfuehrungszeichen. Konkret war's ein segmentation fault. Mittels top konnte ich zusehen, wie der Speicher anwuchs, obwohl die Menge der aktuellen Daten (auf die ich eine Referenz hatte) eher gering war. Tja und als 1.5 GByte voll waren, hats einfach Peng gemacht. Auch brauchst du mir nicht die Funktionsweise des gc's erklaeren. Er kam bei mir einfach nicht mit aufraeumen hinterher.

LoL? Vielleicht warst du auch einfach zu verschwenderisch mit den Ressourcen und hast deinen Programmierstil nicht angepasst. In Java programmiert man anders als in Sprachen ohne GC
Zudem gäbe es ja noch die folgende Möglichkeit:

System.gc();

@Topic,
Ich stimme Volkards Äusserungen zu. Meistens, wenn man langsame Java Programme hat, dann sollte man, wenn man kann, in den Quellcode reinschauen. Was da zum Teil gemacht wird, da würde wohl auch ein C++ Programm nicht mehr schnell laufen. Und erst recht bei einem Java Programm muss man ein wenig mehr auf die Geschwindigkeit achten als in C++. Aber z.B. ein BubbleSort ist nunmal einfach der falsche Algorithmus

Grüssli

[Gregor]

knivil schrieb:

Deswegen steht "out of memory ..." ja auch in Anfuehrungszeichen. Konkret war's ein segmentation fault. Mittels top konnte ich zusehen, wie der Speicher anwuchs, obwohl die Menge der aktuellen Daten (auf die ich eine Referenz hatte) eher gering war. Tja und als 1.5 GByte voll waren, hats einfach Peng gemacht. Auch brauchst du mir nicht die Funktionsweise des gc's erklaeren. Er kam bei mir einfach nicht mit aufraeumen hinterher.

Wenn es wirklich ein segmentation fault war, dann war es ein Fehler im C++ Code der JVM. Hättest halt einfach auf ne andere JVM wechseln müssen. Dann wär das Problem sehr wahrscheinlich gelöst gewesen. Von Sun zu IBM zum Beispiel.

"Nicht mit dem Aufräumen hinterherkommen" ist übrigens gar keine Dimension, in der man den GC beschreiben kann. Wenn der GC langsamer als das Programm ist, dann wird das Programm pausiert. Aus dem Grund kommt der GC immer mit dem Aufräumen hinterher.

Naja, ok. Wenn Du sagst, da gab es einen Fehler im C++ Code der JVM, dann muss ich das wohl akzeptieren.

[byto]

Segmentation fault in der JVM? Wohl kaum. Klingt eher nach einem Unix Fehler.

Edit: Gregor war schneller.

[knivil]

Vielleicht warst du auch einfach zu verschwenderisch mit den Ressourcen und hast deinen Programmierstil nicht angepasst. In Java programmiert man anders als in Sprachen ohne GC

Genau das war die Einsicht, die ich mit meinem Beispiel am Anfang darlegen wollte. Deswegen macht die Frage nach einem schnellen Java-Prog einfach keinen Sinn. Aber alle schreien erstmal Bloedsinn, LOL?, kannst nicht Programmieren etc ... Denken kommt manchmal viel zu kurz.

[Gregor]

Dravere schrieb:

Zudem gäbe es ja noch die folgende Möglichkeit:

System.gc();

IMHO völlig überflüssig. Keine Ahnung, warum es das überhaupt gibt.

[tfa]

knivil schrieb:

bevor eine OutOfMemoryException fliegt

Lesen, verstehen, antworten ...

Deswegen steht "out of memory ..." ja auch in Anfuehrungszeichen

Wie soll ich was lesen, was noch gar nicht geschrieben ist, als ich meine Antwort anfing?

Trotzdem netter Versuch, sich aus der Affäre zu ziehen.

[tfa]

Gregor schrieb:

Dravere schrieb:

Zudem gäbe es ja noch die folgende Möglichkeit:

System.gc();

IMHO völlig überflüssig. Keine Ahnung, warum es das überhaupt gibt.

Höchstens während des Testens brauchbar. In fertiger Software sinnlos.

[Shade Of Mine]

+fricky schrieb:

nö, nicht wirklich. einer funktion sieht man beim aufruf schon an, dass sie eine funktion ist. zweitens ist die bedeutung von operatoren vorbelegt (ein - steht z.b. für subtrahieren), was sinnvolles überladen stark einschränkt, wenn die aussage: 'ziehe x von y ab' erhalten bleiben soll.

selbes gilt für eine funktion mit namen subtract oder divide oder add
ups.
add ist ja garnicht so deutlich...

@knivil:
in den wind geraten -> du hattest zuviel boxing/unboxing im code.

der gc ist nämlich der vorteil von java in der geschwindigkeit.

[Beichtstuhlgang]

Lasst doch das arme Java in Ruhe, es wurde doch schon mit sich selber genug gestraft...

[byto]

Gregor schrieb:

Dravere schrieb:

Zudem gäbe es ja noch die folgende Möglichkeit:

System.gc();

IMHO völlig überflüssig. Keine Ahnung, warum es das überhaupt gibt.

Das sehe ich anders. Es gibt durchaus Anwendungsfälle dafür. Siehe z.B. in der Eclipse IDE die Heap Size Anzeige in der Statusleiste. Da kannst Du über den Button den GC manuell triggern. Das ist durchaus manchmal nützlich.

Auch in anderen Anwendungen fallen mir Usecases ein. Man könnte den GC manuell triggern zur Idletime, wenn man weiss, dass gleich Last kommt.

[+fricky]

The-Kenny schrieb:

+fricky schrieb:

welch hartes urteil. die chance, schwer verständlichen code zu schreiben, ist hoch, wohingegen der nutzen überladener operatoren gering ist.
schau auch mal hier: http://yosefk.com/c++fqa/operator.html

Das einzige angeführte Argument gegen das Überladen von operator[] ist, dass manche IDE's diesen Syntax nicht mit ihrem IntelliSense (Ich nenne es mal so) verstehen...

na, eigentlich dass es oft nicht gut ist, wenn sich dinge als array ausgeben, die keine sind. und wenn's rumzickt, dann muss man suchen, was sich hinter dem [] eigentlich verbirgt.

[Dravere]

Gregor schrieb:

Dravere schrieb:

Zudem gäbe es ja noch die folgende Möglichkeit:

System.gc();

IMHO völlig überflüssig. Keine Ahnung, warum es das überhaupt gibt.

Das sehe ich nicht so. Ich war mal auf 60 MB in einem Java Programm begrenzt. Musste allerdings ein 40 MB Bitmap laden, später entladen und gleich danach ein neues reinladen. Ich konnte da drehen und machen was ich wollte, wenn zwischen dem entfernen der letzten Referenz auf das alte Bitmap und dem laden des neuen Bitmaps kein System.gc() Aufruf stattfand, gab es eine OutOfMemoryException .
Obwohl es keine Referenz mehr auf das alte Bitmap gab und dringend mehr Speicher benötigt wurde, hat der GC es doch nicht begriffen, dass er eigentlich Speicher freimachen kann. Nur wenn ich ihn explizit angewiesen habe, dann ging es.

Das war übrigens mit der JVM von Sun und dem SDK 1.6. Welches Update weiss ich nicht mehr.

@knivil,
So war das allerdings nicht gemeint. Das war die falsche Einsicht! Was du gemacht hast, ist die Sache mit dem Speicher so umgebogen, dass du immer noch mit dem alten Programmierstil programmieren kannst. Statt dass du dich eben umgestellt hast :p

Grüssli

[Gregor]

Um nochmal auf das Geschwindigkeitsproblem von Java zurückzukommen...

Es gibt natürlich sehr einfache Möglichkeiten, Java langsam zu machen. Zum Beispiel wenn man viele kleine Objekte nutzt. Man hat in Java für jedes Objekt einen Overhead von ein paar Byte, was den benötigten Speicher betrifft. Insofern steigt der Speicherverbrauch bei vielen kleinen Objekten sehr viel schneller an, als das bei C++ Programmen der Fall ist. ...und dann erreicht man selbstverstädlich viel schneller die Grenzen des Caches und muss auf wesentlich langsameren Speicher ausweichen. So kriegt man ein Javaprogramm sicherlich ganz schnell um einen Faktor ~10 langsamer als ein entsprechendes C++ Programm.

Aber das sind halt so Punkte, bei denen man aufpassen muss. Die gibt es in jeder Sprache. Auch in C++. Ich erinnere mich an einen kleinen Benchmark mit volkard, in dem es darum ging, viele Objekte auf dem Heap zu erzeugen und dann wieder zu löschen. Java war da zuerst wesentlich schneller als C++. Letztendlich hat volkard dann einen Small-Object-Allocator gebaut, mit dem er das C++ Programm deutlich beschleunigen konnte. Aber man muss halt erstmal wissen, wo die genutzte Sprache ihre Schwächen hat. Sonst nimmt man jede Performance-Falle mit, ohne es zu bemerken.

[knivil]

tfa schrieb:

Wie soll ich was lesen, was noch gar nicht geschrieben ist, als ich meine Antwort anfing?

Sie waren von Anfang an im Post, auf den du geantwortet hast. Gregor hat sie auch mitzitiert.

@Shade Of Mine: Ja, waehrend man in C oder so alles auf den Stack packen kann, hat man in Java nur den Heap. Deswegen programmiert man in Java anders. Aber wem erzaehle ich das eigentlich hier ...

Ich geniesse jetzt die Sonne!

[Shade Of Mine]

knivil schrieb:

@Shade Of Mine: Ja, waehrend man in C oder so alles auf den Stack packen kann, hat man in Java nur den Heap. Deswegen programmiert man in Java anders. Aber wem erzaehle ich das eigentlich hier ...

Dir ist schon klar was boxing ist?

[tfa]

knivil schrieb:

Sie waren von Anfang an im Post, auf den du geantwortet hast. Gregor hat sie auch mitzitiert.

Falsch!

Ich geniesse jetzt die Sonne!

Und vergiss bloß deinen Sonnenhut nicht! :p

[dfgdfgdgdfg]

wen interessiert eigentlich geschwindigkeit, mal von Spielen & sonstigem Rechenintensiven Kram abgesehen?

Also ich persönlich sitze nicht mit einer Stopuhr ausgestattet vor jedem Programmstart um danach einen Flame über 2 nanosekunden mehr zu starten.

Wenn es startet, dann startet es halt.

[JC++]

volkard schrieb:

das liegt aber dann wohl nicht an der sprache java, sondern daran, daß java inzwischen ausschließlich von untalentierten programmierern benutzt wird.

Sorry, aber das ist doch elitärer Unsinn. Ich kenne jeweils talentierte und untalentierte C++ und Java-Programmierer. Das kann man nicht pauschalisieren.