Javas Hotspot schneller als C?

Natürlich. Der genannte GMixer belegt aber nicht so viele Resourcen, weil er sicherer und komfortabler ist, als Alternativen.

Du hast schon Recht, dass für so etwas auch Resourcen drauf gehen. Es geht mir ja auch nicht darum, sondern es geht mir um die unter Entwicklern scheinbar allgemein vorherrschende, da immer wieder aus Entwicklerkreisen gehörte, Meinung, dass Performanz keine Rolle spielt. Meinst du nicht, das nimmt auch Einfluss auf die Qualität entwickelter Software?

Der Herr Professor Wirth hat ja auch nicht nur heiße Luft gespuckt, sondern durchaus auch Studien, teilweise anhand praktischer Arbeiten (Oberon System), zu dem Thema durchgeführt.

Sicher spielt auch Performance eine Rolle aber es wird halt nicht mehr wie früher jedes Fitzelchen per Assembler auf Laufzeit und Speicherverbrauch optimiert weil es keiner mehr bezahlen könnte bei der heutigen Komplexität der Software. Und wenn dann doch auch noch auf unterster Ebene so stark optimiert werden muss dann sind das meist Spezialanwendungen die nun mal nicht wirklich viele Prozent der gesamten Softwarebranche ausmachen.

Sicher könnte alles viel schneller und ressourcensparender sein, die Software könnte aber keiner mehr bezahlen bzw wäre sie bei weitem nicht so ausgereift weil viel zu viel Zeit fürs Optimieren drauf gegangen ist.

Scheppertreiber

Ein C-Programm wird kompiliert, es besteht aus Maschinencode.
Java wird interpretiert. Die Diskussion ist weitgehend sinnfrei.

Klar kann man auch in C lahme Programme schreiben, ist aber nicht
so einfach ...

Lies dir mal ein paar Schriften von Niklaus Wirth durch, dann verstehst du, was genau er meint. Es geht nicht um Mikrooptimierung, sondern es geht um von vornherein vernünftig designte Software. Da kannst du schnell mal 2 Fliegen mit einer Klappe schlagen: Ressourcen sparen und Produktivität erhöhen. Das schließt sich überhaupt nicht aus. Deswegen habe ich ja auf das Oberon-System verwiesen. Das war für seine Zeit durchaus ein voll funktionsfähiges Betriebssystem, wurde aber von nur 2 Personen innerhalb eines Jahres neben den anderen Pflichten, die sie an der Universität hatten, fertig entwickelt. Es geht also definitiv nicht um zeitraubende Mikrooptimierung.

A Plea for Lean Software:
d.linux-bg.org/download/docs/wirth.pdf

Die aktuelle Version nennt sich Active Oberon System (AOS) oder Bluebottle. Auch diese ist von einer Person als Dissertation entwickelt worden. Kein Assembler drin. Das kann man durchaus Produktiv und wirtschaftlich nennen.
http://e-collection.ethbib.ethz.ch/view/eth:26082

Es kann natürlich von den Features her nicht mit einem modernen Linux/Unix/Windows System mithalten, aber die Prinzipien nach denen dort entwickelt werden, finde ich genial. Und darum geht es ja in erster Linie in den Arbeiten.

Scheppertreiber schrieb:

Ein C-Programm wird kompiliert, es besteht aus Maschinencode.
Java wird interpretiert. Die Diskussion ist weitgehend sinnfrei.

Klar kann man auch in C lahme Programme schreiben, ist aber nicht
so einfach ...

Ein Java Programm wird erst interpretiert und dann entscheidet der JIT welche Teile in Maschinencode übersetzt werden. Dieses Kompilieren ist dann selbstverständlich auf die gerade eingesetzte Umgebung sehr gut angepasst. In späteren Versionen ist dann noch geplant das Assembler dann noch hochzuoptimieren, so dass es theoretisch möglich ist jedes C Programm alt aussehen zu lassen. Das schöne ist die ganzen Optimierungen laufen ohne zutun des Entwicklers, der sollte natürlich seinen Code auch performant schreiben denn auch in Java kann man gut mal den Faktor 100 raus holen in dem man Sachen anders implementiert.

Bei Java kannst du also davon ausgehen das Berechnungen in Schleifen schnell nur als reine nativer Maschinencode laufen und zwar nicht nur 386 optimiert sondern immer da was die CPU gerade hergibt.

WN schrieb:

Lies dir mal ein paar Schriften von Niklaus Wirth durch, dann verstehst du, was genau er meint. Es geht nicht um Mikrooptimierung, sondern es geht um von vornherein vernünftig designte Software. Da kannst du schnell mal 2 Fliegen mit einer Klappe schlagen: Ressourcen sparen und Produktivität erhöhen. Das schließt sich überhaupt nicht aus. Deswegen habe ich ja auf das Oberon-System verwiesen. Das war für seine Zeit durchaus ein voll funktionsfähiges Betriebssystem, wurde aber von nur 2 Personen innerhalb eines Jahres neben den anderen Pflichten, die sie an der Universität hatten, fertig entwickelt. Es geht also definitiv nicht um zeitraubende Mikrooptimierung.

A Plea for Lean Software:
d.linux-bg.org/download/docs/wirth.pdf

Die aktuelle Version nennt sich Active Oberon System (AOS) oder Bluebottle. Auch diese ist von einer Person als Dissertation entwickelt worden. Kein Assembler drin. Das kann man durchaus Produktiv und wirtschaftlich nennen.
http://e-collection.ethbib.ethz.ch/view/eth:26082

Es kann natürlich von den Features her nicht mit einem modernen Linux/Unix/Windows System mithalten, aber die Prinzipien nach denen dort entwickelt werden, finde ich genial. Und darum geht es ja in erster Linie in den Arbeiten.

Wenn die Leute irgend was Revolutionäres erfunden hätte, dann hätte sich Microsoft oder ein anderes Unternehmen schon die Leute und das KnowHow eingekauft, so wie sie es immer tun. Der Knall im All war es dann wahrscheinlich nicht.

Scheppertreiber schrieb:

Ein C-Programm wird kompiliert, es besteht aus Maschinencode.
Java wird interpretiert. Die Diskussion ist weitgehend sinnfrei.

Klar kann man auch in C lahme Programme schreiben, ist aber nicht
so einfach ...

Wir leben doch nicht mehr in den 90er wo Java nur interpretiert wurde, das ist schon ganz lange History. Ich gehe jede Wette ein dass das dynamische Compilieren dem statischen Compilieren bald die Performancekrone streitig machen wird. Da steckt noch jede Menge Potential drin.

Scheppertreiber

Ja. Sehr viel Potential

Schon traurig wenn der Computerbildleser immer noch glaubt das Java nur interpretiert. Danke, habe gut gelacht.

Scheppertreiber

dahateinerahnung schrieb:

Schon traurig wenn der Computerbildleser immer noch glaubt das Java nur interpretiert. Danke, habe gut gelacht.

Dann möge Dir Dein Lachen sonstwo stecken bleibe. Dümmer geht's nimmer.

Du musst einfach nur das Forum hier mit dem von http://www.java-forum.org vergleichen, das sah auch mal so aus wie das hier, hat sich aber stark weiterentwickelt. Das hier passt aber auch zu C++, schön vintage.

Scheppertreiber schrieb:

Ein C-Programm wird kompiliert, es besteht aus Maschinencode.
Java wird interpretiert. Die Diskussion ist weitgehend sinnfrei.

Klar kann man auch in C lahme Programme schreiben, ist aber nicht
so einfach ...

typische, und sehr ignorante aussage
"manche leute haben einen geistigen horizont von 0 - das nennen sie dann ihren standpunkt"

@Schleppertreiber: Ein guter Rat für dich, einfach mal lesen und nicht nur Ego-Shooter spielen http://de.wikipedia.org/wiki/HotSpot

Scheppertreiber

LesenBildet schrieb:

@Schleppertreiber: Ein guter Rat für dich, einfach mal lesen und nicht nur Ego-Shooter spielen http://de.wikipedia.org/wiki/HotSpot

Habe gelesen. Du meinst nicht im Ernst, daß das etwas mit "schnell" zu tun hat ?
Das Teil erstickt ja an Verwaltungsaufwand.

Nein, native ausgeführter Maschinencode hat nix mit schnell zu tun Es tut mir sehr leid aber Java ist C++ ziemlich dicht auf den Fersen, besonders dann wenn der C++ Programmierer nicht der Guru seiner Sprache ist.

Hier schau dir mal neuste Benchmarks an da ist Java ca. 1-3fach langsamer und es ist davon auszugehen das die JIT-Technologie erst am Anfang steht, aber sie jetzt schon sehr gut mithalten kann. Wie schon hier geschrieben mit all den Vorteilen die Java dem Programmierer bietet. http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=all

@Schleppertreiber: Probiere mal in C++ mit viel Speicher zu hantieren dann wirst du sehen wie dir irgendwann der Speicher ziemlich fragmentiert. Diese Problem hat Java nicht und könnte dann sogar erheblich performanter laufen als deine C++ Software. Schreib mal Java nicht so schnell ab, es ist meist noch langsamer als C++ aber die jederzeit dynamische Anpassung kann irgendwann auch mal die veralteten statischen Compiler den Rang ablaufen.

Ich persönlich nutze fast nur noch Java und nur ganz wenig C++ weil es für mich folgende Vorteile bietet:

- stark Typensicher
- sehr sicher durch die VM
- relativ einfach zu erlernen
- optimiert sich während der Laufzeit
- Gabarge Collector verhindert viele Fehler und fragmentiert den Speicher nicht
- für Web und Desktop gleich gut einsetzbar
- GUI gehört zur Sprache
- sehr gute Standardbibliothek
- wirklich einsetzbare Exceptions
- Paketsystem
- Eine Datei, eine Klasse
- per JNI auch jeglicher Systemzugriff möglich
- keine schwere Entscheidung welchen Compiler oder IDE ich nehme
- sehr wirtschaftliche Entwicklung möglich
- große Verbreitung auch beim Nachwuchs, wichtig für neue Teamarbeit
.
.
.

Ich will dich hier nicht bekehren oder erzählen welche Sprache nun besser ist, das geht eh nicht, aber ich wollte dich nur mal etwas sensibilisieren. Ich weiß jedenfalls warum ich nur noch das notwendigste in C/C++ machen und nicht mehr alles

Zeus

Die Liste ist echt ein Witz

Schau dir mal die Stellenausschreibungen an für wie viele Leute Java kein Witz ist. Grob geschätzt wird doppelt so viel in Java entwickelt wie in C++ und das aus gutem Grunde. Nicht jeder Entwickler ist ein Geek und programmiert mit Retro-Sprachen, manche Menschen gehen mir der Zukunft

Menschen machen Fehler und davon kann man in C++ jede Menge machen. Ist auch gut das selbst Microsoft von der Sprache so langsam abkommt.

Der Thread ist mal wieder ein gutes Beispiel, dass die meiste Trollerei in diesem Forum tatsächlich von registrierten Mitgliedern ausgeht und nicht von Gästen. Das Thema war bereits auf Seite 1 erledigt, aber einige Mitglieder hier halten es wohl tatsächlich für angebracht ihr "Computer-Bild Wissen" - wie weiter oben so schön gesagt - verbreiten zu müssen...