Discussion:
Java vs. C++
(zu alt für eine Antwort)
Gregor Szaktilla
2014-02-17 20:10:59 UTC
Permalink
Raw Message
Hallo zusammen!

Aus einem anderen Thread ist mir in Erinnerung geblieben, dass jemand
schrieb, C++ sei etwas „Übergestülptes“ und wenn man programmieren
lernt, solle man lieber eine Sprache lernen, die von Grund auf als
objektorientiert entworfen wurde (Java eben).

IMO kann man diese Meinung nur vertreten, wenn man C/C++ nicht gut genug
kennt. Wie ich das sehe, ist C++ ein Abstraktionsschritt weiter gedacht
(was keine Wertung darstellen soll) und führt lediglich zu größeren
Binarys (denke ich mir so, getestet habe ich das nicht). Der Vorteil ist
aber, dass man C++- und C-Code problemlos mischen kann. Man kann sich
also immer entscheiden, wie „nah“ man an der Hardware sein möchte.

Wie „nah“ an der Hardware kann man denn in Java programmieren? Wenn ich
das richtig verstanden habe, läuft ein Java-Programm immer in einer
virtuellen Maschine und ist dadurch grundsätzlich interpretierter
(langsamerer) Code. Liege ich da falsch?

Ich möchte hier keine Flamewars oder Shitstorms provozieren, sondern
lediglich den Unterschied ein bisschen nachvollziehen können. Links zu
Webseiten sind ebenso willkommen wie persönliche Meinungen.

Gruß

Gregor
Rainer Weikusat
2014-02-17 20:33:11 UTC
Permalink
Raw Message
Post by Gregor Szaktilla
Aus einem anderen Thread ist mir in Erinnerung geblieben, dass jemand
schrieb, C++ sei etwas „Übergestülptes“ und wenn man programmieren
lernt, solle man lieber eine Sprache lernen, die von Grund auf als
objektorientiert entworfen wurde (Java eben).
#include <string.h>
#include <stdio.h>

int main(void)
{
printf("%d\n", strcmp("C", "C++"));
return 0;
}

Vulgo "das ist hier off-topic". Es ist generall muessig, ueber 'OOP' zu
diskutieren, weil dass ein Marketingterminus ist, mit dem mehr
Sprachtheoretiker ihre radikal individuelle Vorstellung von 'einer
sinnvoll entworfenen Programmiersprache' schmuecken moechten, als es
IPv6-Addressen gibt, und das uebliche Resultat ist wildes Rumgeflame.
Gregor Szaktilla
2014-02-17 20:41:09 UTC
Permalink
Raw Message
Vulgo "das ist hier off-topic". ...
Wenn das der Fall ist, ist hier meinetwegen EOT.

Gruß

Gregor
Juergen Ilse
2014-02-18 00:03:31 UTC
Permalink
Raw Message
Hallo,
Post by Gregor Szaktilla
Aus einem anderen Thread ist mir in Erinnerung geblieben, dass jemand
schrieb, C++ sei etwas ???Übergestülptes??? und wenn man programmieren
lernt, solle man lieber eine Sprache lernen, die von Grund auf als
objektorientiert entworfen wurde (Java eben).
Das "sauberere" objektorientierte Design wirst du (im Vergleich zu Java)
sicherlich eher in anderen Sprachen finden, z.B. in Smalltalk ...
Post by Gregor Szaktilla
IMO kann man diese Meinung nur vertreten, wenn man C/C++ nicht gut genug
kennt. Wie ich das sehe, ist C++ ein Abstraktionsschritt weiter gedacht
(was keine Wertung darstellen soll) und führt lediglich zu größeren
Binarys (denke ich mir so, getestet habe ich das nicht).
Ich bin mit nicht sicher, ob du C und C++ "gut genug kennst" ...
Post by Gregor Szaktilla
Der Vorteil ist aber, dass man C++- und C-Code problemlos mischen kann.
Das geht mit sehr vielen Sprachen (notfalls sogar mit z.B. TCL oder perl).
Post by Gregor Szaktilla
Man kann sich also immer entscheiden, wie ???nah??? man an der Hardware
sein möchte.
C-Programmierung ist nicht unbedingt hardwarenah. Eigentlich kann man
in C nur wirklich hardwarebah programmieren, wenn man den (portablen)
Boden des Sprachstandards verlaesst ...
Post by Gregor Szaktilla
Wie ???nah??? an der Hardware kann man denn in Java programmieren?
Man kann spaetestens mit dem "jni" (Java Native Interface) mit z.B.
C-Code (oder auch Assembler) mischen. Damit kommt man (ggfs. unter
Verzicht auf Portabilitaet) so nah an die Maschine heran wie mit
einer beliebigen anderen Sprache ...
Post by Gregor Szaktilla
Wenn ich das richtig verstanden habe, läuft ein Java-Programm immer
in einer virtuellen Maschine und ist dadurch grundsätzlich interpretierter
(langsamerer) Code. Liege ich da falsch?
Wie viel langsamer interpretierter Code ist, haengt immer vom Einzelfall
ab. Auserdem gibt es Compiler, die den Coder der VM wiederum in eine
andere Sprache compilieren koennen, und es gibt auch fuer Java auf ver-
schiedenen Plattformen "just in time compilation" ...
Post by Gregor Szaktilla
Ich möchte hier keine Flamewars oder Shitstorms provozieren, sondern
lediglich den Unterschied ein bisschen nachvollziehen können. Links zu
Webseiten sind ebenso willkommen wie persönliche Meinungen.
IMHO gehen deine Vorstellungen teils etwas an der Realitaet vorbei ...
Ich habe uebrigens irgendwo mal gelesen, dass an einigen franzoesischen
Unis fuer "systemnahe Programmierung" gern OCAML eingesetzt wird (kann
auch in Bytecode uebersetzt werden, der vom Runtimesystem interpretiert
wird, hat funktionale und objektorientierte Eigenschaften, ist auf keinen
Fall etwas, was du als "hardwarenahe Sprache" ansehen wuerdest ...).

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Thomas Richter
2014-02-18 09:04:54 UTC
Permalink
Raw Message
Post by Gregor Szaktilla
Aus einem anderen Thread ist mir in Erinnerung geblieben, dass jemand
schrieb, C++ sei etwas „Übergestülptes“ und wenn man programmieren
lernt, solle man lieber eine Sprache lernen, die von Grund auf als
objektorientiert entworfen wurde (Java eben).
Eigentlich gehört das hier nicht hin, wäre eher in einer C++ oder
Java-Gruppe aufgehoben.

Punkt ist: C++ unterstützt diverse Programmierparadigmen, man *kann*
damit objektorientiert arbeiten, die Sprache unterstützt es, aber es
geht eben auch rein imperativ. Bei java ist das insofern anders, als
dass java eine Gliederung eines Programmes in Objekte eher erzwingt als
C++. Java-Programme sehen fast immer irgendwie gleich aus, bei C++ kann
man diverse Programmierstile einsetzen, und ein C++ Programm wird recht
deutlich den Stil seines Programmierers widerspieglen. In Java gibt
eigentlich nur einen guten Stil. Das ist für Anfänger eigentlich gar
nicht schlecht, zumal die Sprache (Java) praxisrelevant ist, was man von
vielen akademischen Spielsprachen, die für Schulungszwecke eingesetzt
werden, nicht behaupten kann. (Zu meiner Zeit quälte man die Leute mit
ELAN, einer grausamen Mischung der Nachteile von Pascal und Basic, eine
Sprache die heute zum Glück in Vergessenheit geraten ist. Soviel zum
Thema "Mode".)
Post by Gregor Szaktilla
IMO kann man diese Meinung nur vertreten, wenn man C/C++ nicht gut genug
kennt. Wie ich das sehe, ist C++ ein Abstraktionsschritt weiter gedacht
(was keine Wertung darstellen soll) und führt lediglich zu größeren
Binarys (denke ich mir so, getestet habe ich das nicht).
"It depends". Hängt davon ab, wie man damit arbeitet. C++ ist insofern
mächtiger, als dass Templates den Compiler für die Code-Generierung
einsetzen können, Java "generics" verbirgt nur Datentypen und ist einen
ganzen Schritt einfacher (was nichts schlechtes sein muss).
Post by Gregor Szaktilla
Der Vorteil ist
aber, dass man C++- und C-Code problemlos mischen kann. Man kann sich
also immer entscheiden, wie „nah“ man an der Hardware sein möchte.
Kann ich auch mit C++ alleine. Fast jeder gültige C Code ist auch
gültiger C++ Code, die Unterschiede sind eher im marginalen Bereich. Bei
Java wird das etwas schwieriger, da man dazu aus der VM ausbrechen muss.
Das geht "im Prinzip" wirft in der Praxis aber eine ganze Menge Probleme
auf.
Post by Gregor Szaktilla
Wie „nah“ an der Hardware kann man denn in Java programmieren? Wenn ich
das richtig verstanden habe, läuft ein Java-Programm immer in einer
virtuellen Maschine und ist dadurch grundsätzlich interpretierter
(langsamerer) Code. Liege ich da falsch?
Ja. Also, Java kann "im Prinzip" nicht auf das Metall, es gibt aber eine
Schnittstelle, um von Java aus "nativen" Code aufzurufen, der auf's
Metall kann. Ich würde das nicht als "man kann" interpretieren, obwohl
theoretisch die Möglichkeit besteht. Eine Sprachunterstützung würde ich
mir anders vorstellen, wobei bei Java der Fall ja gerade so liegt, dass
das Sprachdesign ein Ausbrechen aus der VM ja verhindern will. Also,
"man kann schon", aber es ist eigentlich gegen das Design gebürstet,
genauso wie man "im Prinzip" mit C objektorientiert arbeiten kann, es
aber auch "gegen das Sprachdesign" gebürstet ist, weil C eben keine
Syntaxelemente unterstützt, die Objekte auszeichnen.

Kurz und gut, ich bleibe bei "nein".

Nein, Java wird schon lange nicht mehr interpretiert. Das ist ein
Just-in-Time Compiler, der den Code in Maschinensprache übersetzt,
sobald er "oft genug" verwendet wird. Insofern kann Java "im Prinzip"
genauso schnell wie C sein, und könnte auch schneller sein, da der
JNI-Compiler über zusätzliche Informationen verfügt, die ein C-Compiler
erstmal nicht hat - nämlich die Laufzeitstatistik des Programmes. In der
Praxis ist mir das trotz Werbeaussagen bislang allerdings noch nicht
untergekommen, dass Java hier einen Geschwindigkeitsvorsprung gebracht
hätte. Aber wie dem auch sei...

Also: Java ist nicht interpretiert, allerdings trotzdem meist langsamer.
In meiner Erfahrungwelt, und im Widerspruch zu den Aussagen einiger
anderer. Wobei ich viel Signalverarbeitung mache, nur zur Info, was für
Probleme ich mit den Sprachen so bearbeite. In anderen Bereichen mag das
anders aussehen, oder vermutlich sogar irrelevant sein. Die Hardware ist
ja heute schnell genug, und die meisten Probleme sind durch I/O-Zeit
beschränkt.

Grüße,
Thomas
Gregor Szaktilla
2014-02-18 11:19:25 UTC
Permalink
Raw Message
Hallo nochmal!

Hier ist meine Frage wohl wirklich OT.

Es sind aber ein paar Begleitfragen aufgetaucht, die ein Hirn in
Rotation versetzen können. Wenn ich wieder ein paar Fragen habe, gucke
ich nach einer passenden Gruppe.

Danke und ciao!

Gregor
Stefan Reuther
2014-02-18 19:02:37 UTC
Permalink
Raw Message
Post by Gregor Szaktilla
IMO kann man diese Meinung nur vertreten, wenn man C/C++ nicht gut genug
kennt. Wie ich das sehe, ist C++ ein Abstraktionsschritt weiter gedacht
(was keine Wertung darstellen soll) und führt lediglich zu größeren
Binarys (denke ich mir so, getestet habe ich das nicht).
"Führt zu größeren Binaries" ist zumindest keine zwingende Folge der
Verwendung von C++. Mein letzter Bootloader bestand aus C++ und
Assembler und hatte irgendwas um die 4k Objektcode...
Post by Gregor Szaktilla
Wie „nah“ an der Hardware kann man denn in Java programmieren? Wenn ich
das richtig verstanden habe, läuft ein Java-Programm immer in einer
virtuellen Maschine und ist dadurch grundsätzlich interpretierter
(langsamerer) Code. Liege ich da falsch?
Java kann auch nativ compiliert werden. Und selbst wenn man eine
"normale" Java-VM mit JIT nutzt, kann der unter Umständen effizienteren
Code generieren, als ein "ahead-of-time" C- oder C++-Compiler das könn-
te. Er kann problemlos das ABI verletzen ("Parameter müssen über den
Stack übergeben werden") und hat globale Weltsicht ("Es gibt im ganzen
System nur eine einzige Klasse, die Interface IFoobar implementiert,
also kann der Dispatch über Funktionszeiger eliminiert werden").

Auch der Garbage Collector kann sich positiv auf die Geschwindigkeit
auswirken: ein C/C++-Programm muss immer brav alle Objekte wegräumen,
und das ist schön viel Code im regulären Ausführungspfad. In Java macht
das der GC automatisch, ohne, dass man jede Funktion aufblasen müsste.
Deswegen hat man ja auch Garbage Collectoren erfunden, die auch für
C/C++ funktionieren :-)

So schwarz/weiß "Java ist immer langsam" und "C/C++ ist immer schnell"
war die Welt früher mal.

Wie kommt man jetzt auf die Hardware? C und C++ haben Möglichkeiten, wie
man unter Verwendung von ein wenig implementations-definierten Verhalten
auf z.B. Hardwareregister zugreifen kann. Zum Beispiel sowas:
#define PEEK(adr) *(uint32_t*)(adr)
#define POKE(adr,val) *(uint32_t*)(adr) = (val)
Dass das so funktioniert, entspricht zwar dem Geiste des Standards, ist
aber nirgendwo hieb- und stichfest aufgeschrieben.

Um in Java auf die Hardware zu kommen, müsste deine VM ebenfalls etwas
implementations-definiertes anbieten. Zum Beispiel
class Memory {
public native int peek(int adr);
public native void poke(int adr, int value);
};

In anderen Worten: die *Sprache* Java verbietet dir das genausowenig wie
die Sprache C oder die Sprache C++. In der Praxis sind zum Hardware-
zugriff taugliche C-/C++-Compiler aber deutlich verbreiteter.


Stefan
Rainer Weikusat
2014-02-18 19:41:55 UTC
Permalink
Raw Message
Stefan Reuther <***@arcor.de> writes:

[...]
Post by Stefan Reuther
Java kann auch nativ compiliert werden. Und selbst wenn man eine
"normale" Java-VM mit JIT nutzt, kann der unter Umständen effizienteren
Code generieren, als ein "ahead-of-time" C- oder C++-Compiler das könn-
te. Er kann problemlos das ABI verletzen ("Parameter müssen über den
Stack übergeben werden") und hat globale Weltsicht ("Es gibt im ganzen
System nur eine einzige Klasse, die Interface IFoobar implementiert,
also kann der Dispatch über Funktionszeiger eliminiert werden").
Auch der Garbage Collector kann sich positiv auf die Geschwindigkeit
auswirken: ein C/C++-Programm muss immer brav alle Objekte wegräumen,
und das ist schön viel Code im regulären Ausführungspfad. In Java macht
das der GC automatisch, ohne, dass man jede Funktion aufblasen müsste.
Zumindestens ist das die huebsche Theorie und wohl auch da und dort in
einem sorgfaeltig arrangierten Laboratoriumsexperiment mal nachgewiesen
worden. Fuer einen Vergleich mit planlos programmiertem,
bibliothekslastigem C++ mag das vielleicht auch in der Praxis mal
vorkommen. Zumindestens koennte ich mir das vorstellen. Allerdings habe
ich in letzter Zeit einiges an Java produziert und die mir bekannte
Praxis sieht etwas anders aus --- Antwortzeiten im 0.0001s-Bereich sind
mit Perl kein Problem, mit C erst recht nicht, und fuer Java im Bereich
der Fabel. Genauso wie Programme, die nicht immer mal wieder ploetzlich
abstuerzen, weil kein Speicher mehr alloziert werden kann ...
Gregor Szaktilla
2014-02-18 20:30:53 UTC
Permalink
Raw Message
Am 18.02.2014 20:02, schrieb Stefan Reuther:
[reichlich]

Danke!

Hm.

Dass es reichlich Jahre braucht, bis man ein „guter“ Programmierer ist,
ist ja mal kein Wunder. Das Älterwerden ist geil :-)

Gruß

Gregor
Rainer Weikusat
2014-02-18 23:02:08 UTC
Permalink
Raw Message
Stefan Reuther <***@arcor.de> writes:

[...]
Post by Stefan Reuther
Auch der Garbage Collector kann sich positiv auf die Geschwindigkeit
auswirken: ein C/C++-Programm muss immer brav alle Objekte wegräumen,
und das ist schön viel Code im regulären Ausführungspfad.
.. oder koennte das wenigstens sein wenn man annimmt, dass C "wie Java"
benutzt wird (oder wie C++ haeufig benutzt wird), dh fast alles wird auf
dem Heap abgelegt und muss vor Verlassen des momentanen scopes manuell
wieder dealloziert werden. Und "jegliche Heap-Allokation benutzt 'malloc
& free'". Das ist aber nicht notwendigerweise der Fall: C kann
'automatisches Management' fuer den Stack und man kann vieles auch auf
dem Stack allozieren, vor allem, wenn man alloca zur Verfuegung hat, und
"real existierendes C" kann intelligentere Speicherverwaltung als
'malloce staendig irgendwas und gebe das hoffentlich auch wieder frei'
betreiben. Groessere C-Programme haben normalerweise eine eigene
Speicherverwaltung. Beliebt ist ein 'pool-Modell' (Apache, Postgres) wo
Allokationen von einem Speicherpool erfolgen (wenige malloc/ $sonstwas
Aufrufe, die "grosse Speicherbereiche" anfordern, die dann
sub-alloziiert werden), der "im Block" zu einem bestimmte Zeitpunkt
freigegeben wird, zB nachdem der momentane Request bearbeitet wurde oder
nachdem die momentane Verbindung geschlossen wurde. Fuer lange laufende
Programme bietet es sich auch an, 'langlebige Objekte' via
Sub-Allokation aus einem groesseren Block zu holen und auf
Typ-spezifischen Freelisten solange aufzuheben, bis sie wieder
gebraucht werden. Generalisiert man das bekommt man einen sogenannten
'slab allocator', der als Standardverfahren fuer Objektallokationen in
Betriebssytem-Kerneln bezeichnet werden kann.
Thomas Koenig
2014-02-19 07:15:02 UTC
Permalink
Raw Message
Post by Rainer Weikusat
fuer den Stack und man kann vieles auch auf
dem Stack allozieren, vor allem, wenn man alloca zur Verfuegung hat,
... was ja leider nicht genormt ist. Wenn mann sich drauf verlassen
kann, dass alle Compiler, die jemals den Code zu sehen bekommen,
damit funktionieren, kann man das natürlich nehmen.

Vollständig implementierte VLAs würden auch helfen, aber die sind
ja in der letzten Version der Norm wieder verwässert worden :-|
Stefan Reuther
2014-02-19 20:25:02 UTC
Permalink
Raw Message
Post by Rainer Weikusat
[...]
Post by Stefan Reuther
Auch der Garbage Collector kann sich positiv auf die Geschwindigkeit
auswirken: ein C/C++-Programm muss immer brav alle Objekte wegräumen,
und das ist schön viel Code im regulären Ausführungspfad.
.. oder koennte das wenigstens sein wenn man annimmt, dass C "wie Java"
benutzt wird (oder wie C++ haeufig benutzt wird), dh fast alles wird auf
dem Heap abgelegt und muss vor Verlassen des momentanen scopes manuell
wieder dealloziert werden.
Praktisch wird das in C/C++ halt selten gemacht. Jedenfalls seltener als
in Java.

Gerade Programme wie "wir fressen irgendeine Datei rein, parsen die,
bauen eine Datenstruktur, machen irgendwas, und dann terminiert der
Prozess" können von Garbage Collection gewinnen. Man erkauft dann
Geschwindigkeit für die "üblichen" Fälle mit Speicher, und hat den GC
noch in der Hinterhand für die "übergroßen" Fälle.

Dass GC kein Allheilmittel ist, sollte aber auch klar sein. Ich kämpfe
hier gerade gegen eine GC-Implementation, die der Meinung ist "oh,
Newspace ist voll, aber ich kann 3 Byte freiräumen -- fertig!". Das
macht sie knapp ein dutzend Mal, verbrät dabei 500 ms CPU, bis sie
feststellt, dass sie jetzt doch mal langsam Objekte aus dem Newspace in
den Oldspace verschieben könnte, um die ursprüngliche Anforderung nach
einem Kilobyte zu befriedigen.


Stefan
Peter J. Holzer
2014-02-20 19:06:02 UTC
Permalink
Raw Message
Post by Stefan Reuther
Post by Rainer Weikusat
[...]
Post by Stefan Reuther
Auch der Garbage Collector kann sich positiv auf die Geschwindigkeit
auswirken: ein C/C++-Programm muss immer brav alle Objekte wegräumen,
und das ist schön viel Code im regulären Ausführungspfad.
.. oder koennte das wenigstens sein wenn man annimmt, dass C "wie Java"
benutzt wird (oder wie C++ haeufig benutzt wird), dh fast alles wird auf
dem Heap abgelegt und muss vor Verlassen des momentanen scopes manuell
wieder dealloziert werden.
Praktisch wird das in C/C++ halt selten gemacht. Jedenfalls seltener als
in Java.
Gerade Programme wie "wir fressen irgendeine Datei rein, parsen die,
bauen eine Datenstruktur, machen irgendwas, und dann terminiert der
Prozess" können von Garbage Collection gewinnen.
Naja, gerade in den "wir machen irgendwas und dann terminiert der
Prozess" kann man sich das aufräumen bei manueller Deallozierung häufig
sparen (wenn der Prozess terminiert, wir eh der ganze Speicher en bloc
freigegeben). Eine automatische Garbage Collection wird aber oft
trotzdem jedes einzelne Objekt vor dem Terminieren freigeben (könnte ja
sein, dass eines davon einen Destructor hat), und das braucht bei
komplexeren Datenstrukturen signifikant Zeit. Das ist z.B. bei Perl
durchaus spürbar.

hp (eigentlich auch GC-Fan)
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Stefan Reuther
2014-02-21 18:02:22 UTC
Permalink
Raw Message
Post by Peter J. Holzer
Post by Stefan Reuther
Gerade Programme wie "wir fressen irgendeine Datei rein, parsen die,
bauen eine Datenstruktur, machen irgendwas, und dann terminiert der
Prozess" können von Garbage Collection gewinnen.
Naja, gerade in den "wir machen irgendwas und dann terminiert der
Prozess" kann man sich das aufräumen bei manueller Deallozierung häufig
sparen (wenn der Prozess terminiert, wir eh der ganze Speicher en bloc
freigegeben). Eine automatische Garbage Collection wird aber oft
trotzdem jedes einzelne Objekt vor dem Terminieren freigeben (könnte ja
sein, dass eines davon einen Destructor hat), und das braucht bei
komplexeren Datenstrukturen signifikant Zeit. Das ist z.B. bei Perl
durchaus spürbar.
Das, was Perl macht, ist ja auch nicht wirklich Garbage Collection,
sondern Referenzzählung. Vorteil: man kann sowas wie Destruktoren haben,
und zwar ziemlich deterministisch. Nachteil: man muss eben wirklich über
die Referenzen wachen und zahlt damit den Preis bei jeder Variablen, die
aus dem Scope geht.

Ein Mark/Sweep-GC kann einfach den Speicher wegwerfen. Dass die
Finalizer (sofern vorhanden) ausgeführt werden, ist nicht garantiert.


Stefan
Bernd Nawothnig
2014-03-02 18:20:49 UTC
Permalink
Raw Message
Post by Stefan Reuther
Das, was Perl macht, ist ja auch nicht wirklich Garbage Collection,
sondern Referenzzählung. Vorteil: man kann sowas wie Destruktoren haben,
und zwar ziemlich deterministisch. Nachteil: man muss eben wirklich über
die Referenzen wachen und zahlt damit den Preis bei jeder Variablen, die
aus dem Scope geht.
Ein weiterer Nachteil: zirkulare Referenzen können so nicht
freigegeben werden.
Post by Stefan Reuther
Ein Mark/Sweep-GC kann einfach den Speicher wegwerfen. Dass die
Finalizer (sofern vorhanden) ausgeführt werden, ist nicht garantiert.
Das muss man nur wissen und gut ist, zumindest besser als Pythons
__del__ Methoden, die, falls vorhanden, das sonst mögliche Abräumen
zirkularer Referenzen blockieren. Grund, wie Du oben schon anführtest:
es ist dann keine deterministische Reihenfolge mehr garantiert. Ich
habe nicht schlecht gestaunt, als ich darüber gestolpert bin.




Bernd
--
no time toulouse
Thomas Koenig
2014-02-19 07:01:53 UTC
Permalink
Raw Message
Post by Stefan Reuther
"normale" Java-VM mit JIT nutzt, kann der unter Umständen effizienteren
Code generieren, als ein "ahead-of-time" C- oder C++-Compiler das könn-
te. Er kann problemlos das ABI verletzen ("Parameter müssen über den
Stack übergeben werden") und hat globale Weltsicht ("Es gibt im ganzen
System nur eine einzige Klasse, die Interface IFoobar implementiert,
also kann der Dispatch über Funktionszeiger eliminiert werden").
Lies mal die Dokumentation zu dem -flto - Flag von gcc durch :-)
Bonita Montero
2014-02-19 12:57:51 UTC
Permalink
Raw Message
... kann der unter Umständen effizienteren Code generieren,
als ein "ahead-of-time" C- oder C++-Compiler das könne.
Java bzw die existierenden VMs haben zwei große Probleme: In C oder
C++ kannst Du problemlos eine Datenstruktur in eine andere legen und
die innere wird dann im Speicher der äußeren platziert. Bei den aktu-
ellen Java-VMs bekommt jedes Objekt einen eigenen Speicherblock auf
dem Heap; eine Escape Analyse gibt es nur für Objekte auf dem Stack
und deren von "innen" referenzierte Objekte kommen wieder auf dem
Heap zu liegen. Das macht zu mehr Allokationen als nötig und führt
zu weniger Cache-Lokalität beim Speicherzugriff.
Außerdem führt jedes Objekt zur Speicherverwaltung moch Metainfor-
mationen mit sich was den Speicher- und somit Cache-Verbrauch auf-
bläst.
Desweiteren ist es möglich auf jedem Objekt synchronized {} auszu-
führen weswegen dafür auch noch Extra-Informationen mit sich geführt
werden.
Metainformationen für die Speicherverwaltung gibt es bei malloc()
-Implementationen zwar auch, aber die fallen nicht so ins Gewicht
weil es wirklich verschachtelte Strukturen bzw Objekte in in C bzw
C++ gibt und malloc-Implementationen oft weniger Metadaten mit sich
führen als eine Java-VM (bei der Oracle-VM sind's 16 Byte pro Ob-
jekt).
Deswegen hat man ja auch Garbage Collectoren erfunden, die auch
für C/C++ funktionieren :-)
Nein, nicht aus Performance-Gründen, sondern weil's komfortabler ist.
Loading...