Am Donnerstag, den 24.05.2007, 12:00 +0200 schrieb Eric-Alexander Schaefer:
Was macht der GC schlechter als malloc/free?
Er soll tun was ich will, und wann ich will. Wir sind doch nicht bei Goethes Hexenmeisters Besen!
Wie ich eben an die Liste schrieb: malloc tut auch nicht was Du willst und wann Du willst.
Ich mach zu wenig C/C++ um das ensthaft beurteilen zu können. Für meine paar Zeilen reichts.
Schau Dir mal an, wie malloc Speicher alloziert und Lücken ausnutzt. Halte aber eine große Tüte bereit...
Naja, Zeit wird schon benötigt um Datenstrukturen auf- und abzubauen. Aber ohne GC ist der Programmierer gezwungen sich selbst Gedanken zu machen, und erkennt das der Rechner endlich ist.
Mit GC wird nur allokiert. Ich halte dies für eine ganz schlechte Wahl, weil der Programmierer dann eher leichtsinnig wird.
Aber dies ist schon ein sehr langer Streit, den ich mit dir nicht führen möchte. Ich bin nicht böse drüber mich bis jetzt um Java gedrückt zu haben, und wie es aussieht schaffe ich das noch eine Weile. ;-)
Jan
Am Thu den 24 May 2007 um 01:40:31PM +0200 schrieb Jan Rakelmann:
Am Do, den 24.05.2007, 12:00 +0200 schrieb Eric-Alexander Schaefer:
Schau Dir mal an, wie malloc Speicher alloziert und Lücken ausnutzt. Halte aber eine große Tüte bereit...
Naja, Zeit wird schon benötigt um Datenstrukturen auf- und abzubauen. Aber ohne GC ist der Programmierer gezwungen sich selbst Gedanken zu machen, und erkennt das der Rechner endlich ist.
Memory leaks kannst du in so gut wie jeder Sprache implementieren, ob nun mit oder ohne Zwang ist da Wurst.
Mit GC wird nur allokiert. Ich halte dies für eine ganz schlechte Wahl, weil der Programmierer dann eher leichtsinnig wird.
Aber dies ist schon ein sehr langer Streit, den ich mit dir nicht führen möchte. Ich bin nicht böse drüber mich bis jetzt um Java gedrückt zu haben, und wie es aussieht schaffe ich das noch eine Weile. ;-)
Wenn du kein OO brauchst, gut, ansonsten ist es das Mittel der Wahl. So gut wie keine andere Sprache ist so schön OO wie Java. Im Übrigen gibt es verdammt gute Software, die in Java implementiert ist (z.B. IntelliJ)
Tschau, andre
Am Donnerstag, den 24.05.2007, 14:02 +0200 schrieb André Schulze:
Hallo,
schön OO wie Java.
Die int's in Java sind nicht OO! Kennst du Eiffel? Java ist und bleibt Mist. Tut mir leid, es so drastisch auszudrücken.
Und die Aufgabe einer Uni ist es auch nicht billige Javacoder für die Industrie auszuspucken. Ich habe mal vor vielen Jahren eine Lehre gemacht, damals bildete die Wirtschaft Ihren Nachwuchs selbst aus. Jetzt stellt sie, vor allem im IT-Bereich, nur Forderungen.
Jan
So gut wie keine andere Sprache ist so schön OO wie Java.
Soso. Dein Horizont beschraenkt sich wahrscheinlich auf Basic, C++ und Java.
Einige wenige Leute kennen aber auch Smalltalk, ObjectiveC, Lisp und vieles mehr. Dagegen ist Java wirklich umstaendlich, da statisch typisiert, keine Closures.... Groovy ist da schon ein Fortschritt, obwohl ca 10 mal langsamer als Smalltalk...
Im Übrigen gibt es verdammt gute Software, die in Java implementiert ist
(z.B. IntelliJ)
Wieviel Speicher braucht man denn dafuer - 500 oder 1500Mbyte ?
Gruss
Frank
Frank Gerlach schrieb:
So gut wie keine andere Sprache ist so schön OO wie Java.
Soso. Dein Horizont beschraenkt sich wahrscheinlich auf Basic, C++ und Java.
Einige wenige Leute kennen aber auch Smalltalk, ObjectiveC, Lisp und vieles mehr. Dagegen ist Java wirklich umstaendlich, da statisch typisiert, keine Closures.... Groovy ist da schon ein Fortschritt, obwohl ca 10 mal langsamer als Smalltalk...
Warum nutzt kein Mensch Smalltalk, obwohl es schon ca. 30 Jahre alt sein dürfte?
Im Übrigen gibt es verdammt gute Software, die in Java implementiert ist (z.B. IntelliJ)
Wieviel Speicher braucht man denn dafuer - 500 oder 1500Mbyte ?
Das hat mit Java relativ wenig zu tun.
Viele Grüße, Eric
Warum nutzt kein Mensch Smalltalk, obwohl es schon ca. 30 Jahre alt sein dürfte?
Warum beherrschen nur so wenig Menschen den Umgang mit Differentialgleichungen ? Die Grundrechenarten sind doch viel einfacher....
Wieviel Speicher braucht man denn dafuer - 500 oder 1500Mbyte ?
Das hat mit Java relativ wenig zu tun.
Tatsache ist, dass Visual C++ fuer ein groesseres Programmierprojekt (nennen wir es X) ca 100Mbyte RAM verbraucht, Ecplise aber locker mal 500Mbyte fuer X haben will. Ich denke, das hat schon etwas mit der Ineffizienz von java zu tun. Wieso braucht zB jedes Objekt einen Monitor ? Warum kann man keine Objekte auf dem Stack allokieren ? Warum kann man Objekte nicht als Array effizient hintereinander im Speicher ablegen ? MeineKlasse[] array wird in java als Array von Zeigern abgelegt. Man braucht also Speicher fuer die Referenzen sowie Laufzeit fuer die Dereferenzierung. Und wenn MeineKlasse ein Member vom Typ MeineKlasse2 hat, braucht man nochmal eine Dereferenzierung. In C++ ist das einfach ein *einzelner* Speicherblock.
Gruss
Frank
Viele Grüße,
Eric
Lug-dd maillist - Lug-dd@mailman.schlittermann.de http://mailman.schlittermann.de/mailman/listinfo/lug-dd
Vielleicht kann ja einer der Java-Anhaenger mal den Linux Kernel mit Ecplise taggen lassen und dann berichten, wieviel RAM das verbraucht. Sofern er es ueberhaupt hinkriegt....
Gruss
Frank
Frank Gerlach schrieb:
Warum nutzt kein Mensch Smalltalk, obwohl es schon ca. 30 Jahre alt sein dürfte?
Warum beherrschen nur so wenig Menschen den Umgang mit Differentialgleichungen ? Die Grundrechenarten sind doch viel einfacher....
Wieviel Speicher braucht man denn dafuer - 500 oder 1500Mbyte ?
Das hat mit Java relativ wenig zu tun.
Tatsache ist, dass Visual C++ fuer ein groesseres Programmierprojekt (nennen wir es X) ca 100Mbyte RAM verbraucht, Ecplise aber locker mal 500Mbyte fuer X haben will. Ich denke, das hat schon etwas mit der Ineffizienz von java zu tun. Wieso braucht zB jedes Objekt einen Monitor ? Warum kann man keine Objekte auf dem Stack allokieren ? Warum kann man Objekte nicht als Array effizient hintereinander im Speicher ablegen ? MeineKlasse[] array wird in java als Array von Zeigern abgelegt. Man braucht also Speicher fuer die Referenzen sowie Laufzeit fuer die Dereferenzierung. Und wenn MeineKlasse ein Member vom Typ MeineKlasse2 hat, braucht man nochmal eine Dereferenzierung. In C++ ist das einfach ein *einzelner* Speicherblock.
Wenn man das so anlegt. Im allgemeinen wird man aber auch in C++ mit Zeigern hantieren. Außerdem spielt die Dereferenzierung außer in Extremfällen kaum eine Perfomance-relevante Rolle. Wenn Du schon an Java rummeckern mußt, dann doch bitte an den Dingen die wirklich Scheiße sind, wie zum Beispiel, dass Methoden per default virtuell sind. DAS ist wirklich ein Performancekiller.
Viele Grüße, Eric
On Thursday 24 May 2007, Eric-Alexander Schaefer wrote:
Wenn Du schon an Java rummeckern mußt, dann doch bitte an den Dingen die wirklich Scheiße sind, wie zum Beispiel, dass Methoden per default virtuell sind. DAS ist wirklich ein Performancekiller.
Das stimmt so auch nicht: auch in Smalltalk sind Methoden per default virtuell (nicht-virtuelle gibt es nicht). Smalltalk muss sogar noch einen Lookup mehr machen, weil die Typprüfung erst zur Laufzeit gemacht wird. Und trotztdem ist es um eine Größenordnung schneller als Java.
Konrad
Hallo Konrad,
Konrad Rosenbaum schrieb:
Das stimmt so auch nicht: auch in Smalltalk sind Methoden per default virtuell (nicht-virtuelle gibt es nicht). Smalltalk muss sogar noch einen Lookup mehr machen, weil die Typprüfung erst zur Laufzeit gemacht wird. Und trotztdem ist es um eine Größenordnung schneller als Java.
Mit SmallTalk habe ich keine Erfahrungen, würde dennoch gerne wissen, auf welchen Fakten sich diese Aussage stützt. Es gibt unter [1] einen Benchmark, der die Annahme zulässt, dass das Gegenteil der Fall ist. Verglichen wird im konkreten Beispiel das Java JDK mit Smalltalk VisualWorks. Natürlich sind Benchmarks nur eine Seite, und spiegeln nicht immer das tatsächliche Verhalten der Applikationen im realen Umfeld wieder. Dennoch erscheint mir der Unterschied zu offensichtlich. Aber das soll kein Flame sein, sondern wirklich eine Frage aus Interesse..
Viele Grüße, Matthias
[1] http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&a...
Frank Gerlach schrieb:
Tatsache ist, dass Visual C++ fuer ein groesseres Programmierprojekt (nennen wir es X) ca 100Mbyte RAM verbraucht, Ecplise aber locker mal 500Mbyte fuer X haben will. Ich denke, das hat schon etwas mit der Ineffizienz von java zu tun.
Hast Du Dich schon mal näher (intensiv) mit Eclipse befaßt? Vermutlich nicht, denn sonst würdest Du diesen Vergleich nicht anführen. Hint: VS ist eine IDE, Eclipse ist ein extrem umfangreiches Plug-In-basiertes Framework, für welches nebenbei ein Plug-In für Java-Entwicklung existiert. Ich habe mit minimalen Aufwand Dinge mit Eclipse angestellt, an die man bei VS nichtmal denken kann. Klar ist VS schneller und weniger Ressourcen-hungrig, aber ein Opel Corsa verbraucht auch weniger Sprit als ein Güterzug.
Viele Grüße, Eric
Am Donnerstag, den 24.05.2007, 17:56 +0200 schrieb Eric-Alexander Schaefer:
Warum nutzt kein Mensch Smalltalk, obwohl es schon ca. 30 Jahre alt sein dürfte?
Frag nicht hier, frag die Industrie. Einem Promotionsstudenten aus der Algebra haben sie OOP mittels Eiffel beigebracht. Ich glaub das war mal in Darmstadt.
Jan
On Thursday 24 May 2007, Eric-Alexander Schaefer wrote:
Warum nutzt kein Mensch Smalltalk, obwohl es schon ca. 30 Jahre alt sein dürfte?
Das kann ich so nicht stehen lassen: ich kenne alleine in Dresden über ein dutzend Leute, die SmallTalk produktiv einsetzen.
Konrad
Konrad Rosenbaum schrieb:
On Thursday 24 May 2007, Eric-Alexander Schaefer wrote:
Warum nutzt kein Mensch Smalltalk, obwohl es schon ca. 30 Jahre alt sein dürfte?
Das kann ich so nicht stehen lassen: ich kenne alleine in Dresden über ein dutzend Leute, die SmallTalk produktiv einsetzen.
"Gegenbeweis": Ich kenne keinen einzigen. Wieviel sind es absolut. Wieviele bei anderen Sprachen?
Viele Grüße, Eric
On Thursday 24 May 2007, Eric-Alexander Schaefer wrote:
Konrad Rosenbaum schrieb:
Das kann ich so nicht stehen lassen: ich kenne alleine in Dresden über ein dutzend Leute, die SmallTalk produktiv einsetzen.
"Gegenbeweis": Ich kenne keinen einzigen. Wieviel sind es absolut. Wieviele bei anderen Sprachen?
Machen wir mal eine qualifizierte Aussage aus beidem:
Die Smalltalk-Community ist um 1-2 Größenordnungen kleiner als die Java-Community (Ähnliches gilt für Eiffel, Ruby, etc.). Trotzdem ist Smalltalk nicht bedeutungslos, sondern wird in einigen kritischen Systemen eingesetzt - ich kenne Beispiele von Industriesteuerungen und Bankensoftware.
Konrad
On Thursday 24 May 2007, André Schulze wrote:
So gut wie keine andere Sprache ist so schön OO wie Java.
Autsch. Du hast noch nie echte OO gemacht.
Gegenargumente, warum Java nicht OO ist:
Es gibt Basistypen, die keine Objekte sind (int und co.).
Java hat keine Polymorphie: man kann durchaus Methoden mit dem selben Namen in unterschiedlichen Klassen anlegen, aber Java ist es nicht egal welche von diesen Klassen ich verwende. Die strenge Typprüfung von Java verhindert sehr effektiv, dass die (scheinbare) Polymorphie genutzt werden kann.
Konrad
Konrad Rosenbaum schrieb:
On Thursday 24 May 2007, André Schulze wrote:
So gut wie keine andere Sprache ist so schön OO wie Java.
Autsch. Du hast noch nie echte OO gemacht.
Gegenargumente, warum Java nicht OO ist:
Es gibt Basistypen, die keine Objekte sind (int und co.).
java.lang.Integer?
Java hat keine Polymorphie: man kann durchaus Methoden mit dem selben Namen in unterschiedlichen Klassen anlegen, aber Java ist es nicht egal welche von diesen Klassen ich verwende. Die strenge Typprüfung von Java verhindert sehr effektiv, dass die (scheinbare) Polymorphie genutzt werden kann.
Das hat nix mit Polymorphie zu tun, sondern mit dem static vs. dynamic typing. Was Du willst, kann man mit static typing auch. Generiere für die gewünschte Methode ein Interface und lass die entsprechenden Klassen dieses implementieren. Wenn Dir das nicht gefällt, dann nimm eine Sprache mit dynamic typing.
Viele Grüße, Eric
Jan Rakelmann schrieb:
Schau Dir mal an, wie malloc Speicher alloziert und Lücken ausnutzt. Halte aber eine große Tüte bereit...
Naja, Zeit wird schon benötigt um Datenstrukturen auf- und abzubauen. Aber ohne GC ist der Programmierer gezwungen sich selbst Gedanken zu machen, und erkennt das der Rechner endlich ist.
Es geht nicht nur um die Datenstrukturen. Es geht darum, wie malloc alloziert, wie es Lücken verwaltet und wann aufgeräumt wird. Aus Performancegründen wird da nämlich viel Zeug optimiert, was dann, wie beim GC, irgendwann einmal einiges mehr an Zeit kostet.
Mit GC wird nur allokiert. Ich halte dies für eine ganz schlechte Wahl, weil der Programmierer dann eher leichtsinnig wird.
Warum?
Viele Grüße, Eric
Am Donnerstag, den 24.05.2007, 14:49 +0200 schrieb Eric-Alexander Schaefer:
Eric,
Jan Rakelmann schrieb:
Schau Dir mal an, wie malloc Speicher alloziert und Lücken ausnutzt. Halte aber eine große Tüte bereit...
Bis jetzt habe ich den Debugger nicht gebraucht. Du kannst mir aber gern mal ein Beispiel schicken. Ich bin offen und seh mir sowas gern an.
Mit GC wird nur allokiert. Ich halte dies für eine ganz schlechte Wahl, weil der Programmierer dann eher leichtsinnig wird.
Warum?
Weil die Müllentsorgung irgendwelchen Algorithmen überlassen wird die dies nur halbherzig machen. Hab mir neulich mal per Azureus ein Buch stibitzt, und nebenbei noch etwas TeX gemacht, dann stand die Kiste aufeinmal still. Für so einen Kram ist ein 2,8 GHz Sempron nicht ausgelastet! Sowas kann nicht sein.
Wenn ich in Fortran z.B. folgendes mache:
INTEGER, DIMENSION(n:n), ALLOCATABLE :: A ! bin eine nxn-Matrix
READ(*,*) n ! belieber Größe ALLOCATE(A(n,n)) ... !Rechne mit A ... DEALLOCATE(A)
Dann ist A weg, genau hier. Dumm wenn ich penne! Und der Rechner lacht mch an, ala "Die nächste Matrix bitte..." ;-)
Jan
Jan Rakelmann schrieb:
Schau Dir mal an, wie malloc Speicher alloziert und Lücken ausnutzt. Halte aber eine große Tüte bereit...
Bis jetzt habe ich den Debugger nicht gebraucht. Du kannst mir aber gern mal ein Beispiel schicken. Ich bin offen und seh mir sowas gern an.
Ich habe kein Beispiel, ich weiß nur, daß die Verwaltung der free-list, bei malloc meistens eine sehr aufwändige Sache ist.
Mit GC wird nur allokiert. Ich halte dies für eine ganz schlechte Wahl, weil der Programmierer dann eher leichtsinnig wird.
Warum?
Weil die Müllentsorgung irgendwelchen Algorithmen überlassen wird die dies nur halbherzig machen.
Ich kenne nicht die ganzen Theorien hinter GCs, aber mMn. läuft das bei den meisten so, dass diese bei Erreichen einer bestimmen Speicherauslastung anfangen nach Objekten zu suchen, auf die keine Referenzen mehr zeigen. Wenn Du Speicher mit free/delete frei gibst, wird auch nur der Block als frei markiert, aber noch nicht wieder verwendet, bis malloc keinen Speicher mehr hat. Dann geht es seine Strukturen durch und sucht nach freien Stellen. Im Endeffekt ist es keineswegs schneller damit als ein vernünftiger GC. Ich weiß allerdings nicht ob alle mallocs so implementiert sind oder ob das gar eine veraltete Information ist, aber prinzipiell dürfte das hinkommen...
Hab mir neulich mal per Azureus ein Buch stibitzt, und nebenbei noch etwas TeX gemacht, dann stand die Kiste aufeinmal still. Für so einen Kram ist ein 2,8 GHz Sempron nicht ausgelastet! Sowas kann nicht sein.
Dann ist der GC (wenn er denn Schuld ist) Scheiße.
Wenn ich in Fortran z.B. folgendes mache:
INTEGER, DIMENSION(n:n), ALLOCATABLE :: A ! bin eine nxn-Matrix
Mathematiker? Fortran nutzt letzlich untendrunter auch nur malloc...
Viele Grüße, Eric
Am Donnerstag, den 24.05.2007, 16:29 +0200 schrieb Eric-Alexander Schaefer:
Mathematiker?
Soll mal am Ende so werden.
Fortran nutzt letzlich untendrunter auch nur malloc...
Aber es tut's. Und nicht schlecht.
Und die Jungs von der gfortran-Liste sind auch sehr nett, lustigerweise sind die meisten in der theoretischen Physik oder Chemie verankert.
Jan
lug-dd@mailman.schlittermann.de
-
André Schulze -
Eric-Alexander Schaefer -
Frank Gerlach -
Jan Rakelmann -
Konrad Rosenbaum -
Matthias Petermann