Java ist schneller als C++!
-
Knasti schrieb:
...
Na, da würde ich doch sagen, kann man doch C++-Programme sparsamerweise lieber in einer Sandbox (z.B. Sandboxie für NT) oder in einem Jail (in FreeBSD serienmäßig) laufen....Wenn einem das Betriebssystem selbst eine VM anbietet: Umso besser.
Ändert aber nichts a meinem Argument: Eigenschaften des "VM-Betriebs" sind nur sehr schwache Argumente für/gegen eine Sprache.Gruß,
Simon2.
-
Belegst Du das Argument noch oder ist es am Ende doch nur Deine persönliche Meinung?
-
byto schrieb:
Belegst Du das Argument noch oder ist es am Ende doch nur Deine persönliche Meinung?
Jeweils unter der Annahme einer "perfekten VM":
(Programm in der der Sprache X geschrieben) + (läuft in VM) => Laufzeitchecks durch die VM => größere "Sicherheit" (keine Beeinträchtigung von OS und -Ressourcen) + größere Laufzeit
(Programm in der der Sprache X geschrieben) + (läuft OHNE VM) => KEINE Laufzeitchecks durch die VM => Keine größere "Sicherheit" (keine Beeinträchtigung von OS und -Ressourcen) + keine höhere Laufzeit
Gruß,
Simon2.
-
Am Ende ist es eine Frage, wie die längere Laufzeit und die höhere Sicherheit zu bewerten ist - jeweils bezogen auf die spezfischen Anforderungen. Dementsprechend wichtig imo ist auch die Entscheidung für oder gegen eine Sprache mit VM.
-
byto schrieb:
Am Ende ist es eine Frage, wie die längere Laufzeit und die höhere Sicherheit zu bewerten ist - jeweils bezogen auf die spezfischen Anforderungen. Dementsprechend wichtig imo ist auch die Entscheidung für oder gegen eine Sprache mit VM.
Der Sicherheitsaspekt ist ja nur einer von vielen bei einer VM. Eine VM erleichtet z.B. die Portierung, Speichermanagment, Debuging, Profiling, uvm.
-
byto schrieb:
Am Ende ist es eine Frage, wie die längere Laufzeit und die höhere Sicherheit zu bewerten ist - jeweils bezogen auf die spezfischen Anforderungen. Dementsprechend wichtig imo ist auch die Entscheidung für oder gegen eine Sprache mit VM.
Ich würde sagen: "Dementsprechend wichtig ist die Entscheidung für oder gegen eine VM." !!
Denn das Vorhandensein irgendeiner VM bedeutet noch nicht die Lösung aller meiner Probleme - schlimmstenfalls bekomme ich eine VM vorgesetzt, die für meine Belange untauglich ist.
Und für die Frage der eingesetzten Sprache muss man dann auch die Möglichkeiten der favorisierten VM einbeziehen.
BTW: Es geht auch nicht um "Sicherheit" absolut, sondern um die speziellen Sicherheitsaspekte der jeweiligen Umgebung - hier entsteht ein wenig der Eindruck, als ob z.B. das Betriebssystem selbst überhaupt keinerlei Sicherheitsmechanismen böte.DEvent schrieb:
...
Der Sicherheitsaspekt ist ja nur einer von vielen bei einer VM. Eine VM erleichtet z.B. die Portierung, Speichermanagment, Debuging, Profiling, uvm.Sagen wir mal so: Diese Aspekte werden halt von der Entwicklung der Anwendung weg verlagert - hin zu der Entwicklung der VM.
Prima, wenn sich jemand schon diese Arbeit (und sie gut) gemacht hat: Man muss das Rad nicht neu erfinden.
Blöd, wenn jemand diese Arbeit schlecht/für mich unpassend erledigt hat: Man muss sich vermutlich die Finger brechen.;)Gruß,
Simon2.
-
Simon2 schrieb:
BTW: Es geht auch nicht um "Sicherheit" absolut, sondern um die speziellen Sicherheitsaspekte der jeweiligen Umgebung - hier entsteht ein wenig der Eindruck, als ob z.B. das Betriebssystem selbst überhaupt keinerlei Sicherheitsmechanismen böte.
Der gleiche Eindruck entsteht aber auch beim Thema "längere Laufzeit" durch die VM.
-
byto schrieb:
Simon2 schrieb:
BTW: Es geht auch nicht um "Sicherheit" absolut, sondern um die speziellen Sicherheitsaspekte der jeweiligen Umgebung - hier entsteht ein wenig der Eindruck, als ob z.B. das Betriebssystem selbst überhaupt keinerlei Sicherheitsmechanismen böte.
Der gleiche Eindruck entsteht aber auch beim Thema "längere Laufzeit" durch die VM.
Stimmt!
-
-fricky- schrieb:
ob ein programm nun bugs einer vm oder eines betriebssystems ausnutzt, um böses zu tun, ist im prinzip das selbe.
Nein, der äquivalente Fehler wäre ein Bug in der MMU, der es erlaubte das OS direkt überschreiben zu können. Der kleinste Fehler in der JVM hebelt sie komplett aus! Das ist der Unterschied. Ein simpler Fehler im OS bedeutet nicht gleich den GAU.
-fricky- schrieb:
ich sehe da absolut keinen unterschied. ausser vielleicht, dass fehler im OS erheblich schlimmere folgen haben können, als sicherheitslücken einer VM.
Ein Fehler im OS kann nur dann schlimmere Auswirkungen haben, wenn man die Sicherheitsfunktionen der JVM nicht traut und das OS diese garantieren muß. Denn wenn die JVM gleichwertig wäre, dann wäre der Schaden es ebenfalls. Schön, daß Du mir indirekt zustimmst.
-fricky- schrieb:
vielleicht ist das auch der grund, warum es nicht wirklich viele schlimme viren gibt, die in Java programmiert wurden.
Java zieht viel Leistung beim Starten der JVM, das dürfte der Hauptgrund sein, weshalb es auf PCs keine Java Viren gibt. Sie würden dadurch nur auffallen. Auf Handys wäre ich mir mit dem "keine Java Viren" nicht so sicher.
-
~john schrieb:
-fricky- schrieb:
ob ein programm nun bugs einer vm oder eines betriebssystems ausnutzt, um böses zu tun, ist im prinzip das selbe.
Nein, der äquivalente Fehler wäre ein Bug in der MMU, der es erlaubte das OS direkt überschreiben zu können.
...und ein äquivalenter fehler auf software-ebene wäre eine sicherheitslücke, die es z.b. usern mit guest-account erlaubt, dem kernel code unterzujubeln.
~john schrieb:
Der kleinste Fehler in der JVM hebelt sie komplett aus! Das ist der Unterschied. Ein simpler Fehler im OS bedeutet nicht gleich den GAU.
im gegenteil. selbst grobe fehler in der VM können dem sicherheitskonzept des OS nichts anhaben. es sei denn, das OS selbst ist total buggy. eine VM ist im normalfall ein einfacher benutzerprozess, über den das OS die volle kontrolle hat. versucht die VM, oder client-code der VM, irgendwas unerlaubtes, dann sollte ein gutes OS sowas zu verhindern wissen.
~john schrieb:
-fricky- schrieb:
vielleicht ist das auch der grund, warum es nicht wirklich viele schlimme viren gibt, die in Java programmiert wurden.
Auf Handys wäre ich mir mit dem "keine Java Viren" nicht so sicher.
so weit ich weiss, nutzen die meisten handy-viren sicherheitslücken und bugs des betriebssystems. auf der ebene können sie auch viel mehr ausrichten. java-viren auf handys sind sicherlich für netzbasierte attacken wie 'phishing', usw. sehr beliebt, aber weniger für zerstörerische aktionen.
-
Tut mir leid ich habe nur den Anfang des Threaads gelesen, trotzdem möchte ich was dazu schreiben:
Eine Sprache mit der man Hardwarenah programmieren kann, kann nie langsammer sein als Hardware.
-
neoexpert schrieb:
Eine Sprache mit der man Hardwarenah programmieren kann, kann nie langsammer sein als Hardware.
ist das eine art naturgesetz?
-
Ja bei C++ hängt die geschwindigkeit der anwendungen von erfahrung des Programmierers ab.
In C++ code kann man auch direkt Assemblercode einbauen, und schneller als Assembler ist nichts.
-
neoexpert schrieb:
Ja bei C++ hängt die geschwindigkeit der anwendungen von erfahrung des Programmierers ab.
In C++ code kann man auch direkt Assemblercode einbauen, und schneller als Assembler ist nichts.*hier stand mal ein denkfehler, aber der ist kaffee kochen gegangen*
-
Xantus schrieb:
neoexpert schrieb:
Ja bei C++ hängt die geschwindigkeit der anwendungen von erfahrung des Programmierers ab.
In C++ code kann man auch direkt Assemblercode einbauen, und schneller als Assembler ist nichts.doch, schlecht geschriebener assembler
interessant. Du meinst nähmlich: schlecht geschriebener assembler ist schneller als gut geschriebener assembler.
-
Xantus schrieb:
neoexpert schrieb:
Ja bei C++ hängt die geschwindigkeit der anwendungen von erfahrung des Programmierers ab.
In C++ code kann man auch direkt Assemblercode einbauen, und schneller als Assembler ist nichts.doch, schlecht geschriebener assembler
Achso, schlecht geschriebener Assembly Code ist schneller als normaler Assambly Code? Wie geht denn das?
-
Das frage ich mich auch die ganze zeit
-
Mein Farrad ist schneller als Java!!!!!!!!!!!!!!!111elf
-
neoexpert schrieb:
...
Eine Sprache mit der man Hardwarenah programmieren kann, kann nie langsammer sein als Hardware.Welche Höchstegeschwindigkeit hat denn C++ so ? ... und Java ?
Gruß,
Simon2.
-
neoexpert schrieb:
Eine Sprache mit der man Hardwarenah programmieren kann, kann nie langsammer sein als Hardware.
Auch nicht wenn man Birnen neben Äpfel legt und höflich bittet?