schnelles java prog

tfa

knivil schrieb:

Kennt ihr ein schnelles Javaprogramm? Was ist denn das fuer eine Frage?

Klar kann man in Java auch performant programmieren, man schreibt seine Programme aber anders, so dass man nicht viel mit dynamischen Variablen oder dem garbage collector zu tun hat (statische Arrays etc.).

Extremer Blödsinn. Wer das heute noch glaubt, schreibt die langsamsten Programme...

Shade Of Mine

+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

Selbes Argument gilt übrigens auch für Funktionen.

knivil

Extremer Blödsinn. Wer das heute noch glaubt, schreibt die langsamsten Programme...

Mit glauben hat das nichts zu tun. Ich habe es auf normalem Weg getan und bin schnell an die Grenzen von Java gestossen. Zugegeben: es handelte sich um eine (numerische) Simulation. Umgeschrieben und es lief in akzeptabler Geschwindigkeit ohne mit einer "out of memory exception" (wegen dem Muell, der nicht aufgeraeumt wurde) abzubrechen.

PS: Deinen Kommentar finde ich recht unqualifiziert. Dumm wuerde ich sagen. Extrem voreilig.

Erinnert mich an die Typen hier: http://www.c-plusplus.net/forum/viewtopic-var-t-is-238071-and-highlight-is-.html , die einfach mal behaupten, das Laempchen des "Schraubenziehers" (Phasenpruefer) leuchtet in beiden Loechern der Steckdose (und andere Sachen). Leider haben sie es nie ausprobiert, ich schon.

Shade Of Mine 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

Selbes Argument gilt übrigens auch für Funktionen.

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.

Gregor

knivil schrieb:

Ich habe es auf normalem Weg getan und bin schnell an die Grenzen von Java gestossen. Zugegeben: es handelte sich um eine (numerische) Simulation. Umgeschrieben und es lief in akzeptabler Geschwindigkeit ohne mit einer "out of memory exception" (wegen dem Muell, der nicht aufgeraeumt wurde) abzubrechen.

Wenn Du jemals ernsthaft versucht hättest, mit Java zu programmieren, dann müsstest Du jetzt eigentlich wissen, dass OutOfMemoryExceptions nicht entstehen, weil der Garbage Collector seine Arbeit nicht macht. Der Garbage Collector ist zuverlässig. Aber er kann natürlich nur solche Objekte einsammeln, die nicht aus Deinem laufenden Programm über irgendwelche Referenzen erreicht werden können. Der zweite Punkt, warum so eine Exception fliegen könnte ist, dass Du den Speicher für die JVM einfach viel zu gering eingestellt hast. Normalerweise haben Java-Programme nicht gerade den vollen Hauptspeicher zur Verfügung. Man muss explizit mit einem -Xmx1024m einstellen, dass das Javaprogramm zum Beispiel 1GB an Speicher nutzen darf.

Sorry, aber wenn Du denkst, OutOfMemoryExceptions hätten irgendetwas mit dem Garbage Collector zu tun, dann steht es Dir nicht zu, über Java zu urteilen. Weil Du überhaupt keine Ahnung von Java hast.

The-Kenny

+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... super Argument!

knivil

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.

byto

knivil schrieb:

Mit glauben hat das nichts zu tun. Ich habe es auf normalem Weg getan und bin schnell an die Grenzen von Java gestossen.

Oder einfach nur an Deine Grenzen.

tfa

knivil schrieb:

Extremer Blödsinn. Wer das heute noch glaubt, schreibt die langsamsten Programme...

Mit glauben hat das nichts zu tun. Ich habe es auf normalem Weg getan und bin schnell an die Grenzen von Java gestossen. Zugegeben: es handelte sich um eine (numerische) Simulation. Umgeschrieben und es lief in akzeptabler Geschwindigkeit ohne mit einer "out of memory exception" (wegen dem Muell, der nicht aufgeraeumt wurde) abzubrechen.

Richtig. Mit Glauben hat das nichts zu tun. Es ist einfach Fakt. Du solltest dich lieber besser mit der Materie auseinander setzen, bevor du voreilig urteilst. Dann wüsstest du, dass der GC den Müll immer wegräumt, bevor eine OutOfMemoryException fliegt. Wenn er das nicht kann, hast du unsauber programmiert, oder zu wenig Speicher rerserviert. Dieses Problem mit "Wir machen uns jetzt überall statische Arrays" lösen zu wollen, geht leider am Thema vorbei. Dann bist du wieder in der C/Pascal/Basic-Welt.

PS: Deinen Kommentar finde ich recht unqualifiziert. Dumm wuerde ich sagen. Extrem voreilig.

Das trifft wohl eher auf dich zu.

Erinnert mich an die Typen hier: http://www.c-plusplus.net/forum/viewtopic-var-t-is-238071-and-highlight-is-.html , die einfach mal behaupten, das Laempchen des "Schraubenziehers" (Phasenpruefer) leuchtet in beiden Loechern der Steckdose (und andere Sachen). Leider haben sie es nie ausprobiert, ich schon.

Jetzt machst du dich komplett lächerlich.

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.

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