C# Betreibssystem
-
Bouncer schrieb:
wenn er zu maschinencode umgewandelt wird, dann ist er aber nicht mehr 'managed'
Wieso nicht? Wenn du heute ein Programm aufm PC in irgend einer .Net Sprache schreibst wird das vor der ausführung auch in Maschinencode kompiliert und es ist trotzdem managed
Die Runtime und den GC z.B. gibts in Singularity genauso wie im .Net Framework aufn PC. Der einzige Unterschied ist halt das der Code nicht durch nen Jitter vorm Programmstart kompiliert wird, sondern schon vorher.Ob Maschinencode oder nicht hat mit managed Code gar nichts zu tun. Managed bezeichnet nur die Überwachung durch die Runtime und die gibts auch in Singularity.
ausserdem hab' ich irgendwo gelesen, dass in singularity auch etwas ASM und C stecken, task switcher, bootloader, interrupt-routinen etc. gehen wohl nicht mit C#.
ASM ja, C nicht, dafür aber C++
Mal dazu nen Ausschnitt aus "Singularity: Rethinking the Software Stack:"
Counting lines of code, over 90% of the Singularity kernel is written in Sing#.
While most of the kernel is type-safe Sing#, a significant portion
of the kernel code is written in the unsafe variant of the language.
The most significant unsafe code is the garbage collector, which
accounts for 48% of the unsafe code in Singularity. Other major
sources of unsafe Sing# code include the memory management
and I/O access subsystems. Singularity includes small pockets of
assembly language code in the same places it would be used in a
kernel written in C or C++, for example, the thread context
switch, interrupt vectors, etc. Approximately 6% of the
Singularity kernel is written in C++, consisting primarily of the
kernel debugger and low-level system initialization code.
-
Talla schrieb:
Ob Maschinencode oder nicht hat mit managed Code gar nichts zu tun. Managed bezeichnet nur die Überwachung durch die Runtime und die gibts auch in Singularity.
Dazu mal eine Frage (bitte um Nachsicht falls sie irgendwie deplaziert oder offtopic wirkt
:Kann man "native code", der mit einem Debugger im Einzelschritt ausgeführt wird, auch als "managed code" bezeichnen ?
-
Talla schrieb:
Ob Maschinencode oder nicht hat mit managed Code gar nichts zu tun. Managed bezeichnet nur die Überwachung durch die Runtime und die gibts auch in Singularity.
und wie will sie den code überwachen, wenn er direkt auf dem prozessor läuft? oder läuft der prozessor im single-step betrieb, so dass die runtime vor jedem befehl diesen überprüfen kann?
merker schrieb:
Kann man "native code", der mit einem Debugger im Einzelschritt ausgeführt wird, auch als "managed code" bezeichnen ?
besser 'managed' geht schon gar nicht mehr.
-
Bouncer schrieb:
oder läuft der prozessor im single-step betrieb, so dass die runtime vor jedem befehl diesen überprüfen kann?
Wie realistisch wäre das ? Sind Prozessoren schon "schnell genug" ? Aber dazu bräuchte man keine runtime.
-
merker schrieb:
Bouncer schrieb:
oder läuft der prozessor im single-step betrieb, so dass die runtime vor jedem befehl diesen überprüfen kann?
Wie realistisch wäre das ? Sind Prozessoren schon "schnell genug" ?
prozessoren mit hardwaremässiger debugger-unterstützung gibt's schon lange, z.b. bei einigen ARMs die sogenannte 'trace macrocell' --> http://www.arm.com/products/solutions/ETM.html
merker schrieb:
Aber dazu bräuchte man keine runtime.
klar doch. irgendwas muss ja entscheiden, ob das, was das programm gerade machen will, erlaubt ist.
-
Interessant was alles so unter dem Begriff "managed" Verstanden wird
Erstmal hat nen Debugger nichts mit "managed" Code zu tun, auch nicht wenn man nach jedem Befehl anhält und erstmal schaut ob der gültig ist. Das macht auch nicht die Runtime
Und Hardware Debuggerunterstützung gibts schon seit Ewigkeiten, findet man auf jeden ordentlichen µC. Aber zurück um Thema.Mal nen Ausschnitt aus "Sealing OS Processes to Improve Dependability and Safety"(von der Singularity Seite) was denn die Runtime noch macht bei Singularity:
Because programs are compiled to native code at install time, Singularity’s language runtime can be quite small. The language runtime includes a GC, exception handling mechanisms, and a limited amount of reflection to determine the type of objects at runtime.
Okay, da haben wir den GC. Nun mag der Einwand kommen dass es auch für C++ Libs gibt die des machen, ist auch richtig. Nun ist der GC aber integraler Bestandteil der Runtime, genauso wie der Rest vom automatischen Memorymanagement und man hat gar nicht die Möglichkeit im Speicher rumzupfuschen. Das kann man von den unmanaged Sprachen nicht behaupten. Wenn z.B. Speicher angefordert wird in einer unmanaged Sprache, wird dazu halt von mir aus nen new/malloc je nach Sprache, Speicher angefordert und die einzelnen Anforderungen sind unabhängig voneinander, es wird jedes mal geschaut wo was frei ist und dann Speicher reserviert. Das ist bei dem automatischen Memorymanagement bissle anders. Dort wird der Runtime gesagt, hey ich brauch Speicher, und die schaut wie sie des am besten macht, und bei Singularity ist jetzt sogar der Trick dass jeder Prozess seine eigene Runtime hat, und die so wirklich völlig autark sind. In Singularity kann ein Prozess Amok laufen und es passiert gar nichts außer das dieser Prozess halt beendet wird. Auf dem PC mit dem .Net Framework können die .Net Prozesse auch Amok laufen und es passiert dem Host OS nichts, aber dadurch das es hier die Runtime nur einmal gibt für alle .Net Prozesse, werden unter Umständen alle beendet. Und bei unmanaged Sprachen ists ja jetzt so dass gar keine mehr über den Speicher wacht und der Speicher direkt beim OS angefordert wird, und da kann unter Umständen des ganze OS abgeschossen werden. Beispiele aus der Windows Welt sind ja hinlänglich bekannt
Ich hoffe des war verständlich was das managed jetzt im Speicherbereich meint.
Dann wurde im Ausschnitt noch das Exception Handling genannt. Auch dass gibts wieder in C++, wird aber anders implementiert. C++ unter Windows meist mit SEH, in .Net übernimmt de Runtime den Job und es gibt da auch ganz andee Anforderungen an das Exception Handling. Zu Details ist dieser Link empfehlenswert. Im groben ist es eigentlich wieder so. So ein C++ Programm ist beim Exception Handling wieder ziemlich auf sich gestellt und muss auch mehr Code generieren für das ganze Handling. Im managed Code übernimmt das die Runtime. Unter .Net für Windows z.B. müssen noch solche Dinge wie COM Eceptions(welche auch SEH benutzen) oder Exception passing über AppDomain Grenzen bedacht werden. Gerade Appdomains mit den abgegrenzten Speicher und Sicherheitsbereichen sind auch nur durch die Runtime möglich. Da sonst niemand schaun könnte ob der Code der ausgeführt wird, wirklich gültig ist in dem Kontext.
Den Reflection Punkt lass ich mal grad weg, des wird nur noch mehr Text
Eurer Punkt von wegen wie kann nativer Code managed sein, ist natürlich berechtig
Fangen wir mal auf der Windows Plattform an. Der Code eines .Net Programms liegt idr. ja in CIL Code vor, wird beim Aufruf durch den JITter in nativen Code kompiliert und dann ausgeführt. Trotzdem wird der Code dadurch nicht auf einmal unmanaged - warum? Es bleiben erstmal sämtlichen Aufrufe zur Runtime drin was wie z.B. oben genannt Speichersachen angeht. Dadurch hat die Runtime effektiv Kontrolle was das Programm darf und was nicht. Dann gibts ja neben dem native Code ja auch noch das CIL Image, und das steckt voller Metadaten was z.B. CAS(Code Access Securtity) angeht. Wenn z.B. das Programm jetzt an einen Punkt kommt wo es in einem bestimmten Sicherheitskontext laufen muss und sich dafür vielleicht extra Rechte anfordert, dann schaut die Runtime in den Metadaten welche des sind, evaluiert ob die Rechte dem Programm erteilt werden können, und falls ja, kann das Programm weiter normal ausgeführt werden, und falls nein hagelts ne Exception. Das Programm wird durch die Runtime überwacht was es machen darf. Genauso ists beim Memorymanagement etc. Das war jetzt nur ein Beispiel, aber hoffe das Prinzip ist klar wie ich des mein.Wer aufgepasst hat wird jetzt sagen "moment mal, das da oben klappt aber nur mit nem JITter" - richtig
Wie passt es also ins Bild, dass bei Singularity die Programme von Anfang an im nativen Code vorliegen. Und da kommt jetzt Bartok ins Spiel - der Sing# Compiler für Singularity.
Und da liegt der große Forschungsgedanke dahinter, wie bekomm ich es hin, statt solche Überwachung zur Laufzeit, schon zur Compilezeit hinzubekommen. Darüber dreht sich ein Großteil der Dokumente, wie man Programme verifizieren kann, authorisieren für bestimmte Tätigkeiten, Authorisierungen übertragen kann usw. ohne dabei die Sicherheit zu verlieren und das ganze wie gesagt zur Compilezeit, nicht zur Laufzeit da ja kein Zwischencode vorliegt.
Der geregelte Speicherzugriff und das Exceptionhandling aus dem Beispiel oben bleiben dabei genauso wie in der CIL->native Variante. Trotzdem ist es also ein Versuch den "managed" Gedanken, von der Laufzeit teilweise schon in die Compilezeit zu bekommen - und wie gesagt, das steht jetzt nicht einfach so da und es funktioniert, sondern das ist ein Forschungsteil bei Singularity, die Dokumente geben da mehr Aufschluss.Wenn man jetzt den Compiler genug verifizieren kann, kann man davon ausgehen das der Code der auf Singularity läuft sicher und managed ist. Das ist der Versuch der dahinter steckt - und deshalb ist auch native Code nicht gleich native Code
Es kommt stark darauf an wie er Zustandekommt und was da noch wie gemacht wird. Singularity z.B. benutzt überhaupt nicht die von der Hardware zur Verfügung gestellten Möglichkeiten des Speicherschutzes wie es z.b. jetzige gängige OSse es machen, sondern das macht die Runtime bei Singularity alles selber und hat damit mehr Freiheitsgrade Wenn man es so betrachtet kann man vielleicht sagen das nen OS in C# ohne weiteres nicht möglich ist so wie es uns zur Verfügung steht für den PC. Wenn man aber genügend Einsatz reinsteckt, gehts halt wie man am Beispiel von Singularity sieht doch.
-
Talla schrieb:
Wenn man jetzt den Compiler genug verifizieren kann, kann man davon ausgehen das der Code der auf Singularity läuft sicher und managed ist.
Ich möchte jetzt nichts schlecht machen oder runterziehen oder so.
Aber wenn ein Kompiler "genug verifizieren" kann, dann wäre jeder Code auf jedem Betriebssystem sicher.
Was "genug verifizieren" heisst, ist doch die Sache. Dazu braucht man weniger ein neues Betriebssystem sondern vielmehr eine "neue" Sprache, die aufgrund ihrer Syntax z.B. gewisse "Programmfehler" verhindert bzw. gar nicht erst zulässt.
Zu guter Letzt reicht sogar schon ein Loader, der "nicht genug verifizierte" Programme gar nicht erst in den Arbeitsspeicher lädt.
(Zu ganz guter Letzt kommt man an einer guten Programmiererausbildung eh nicht vorbei.)
-
merker schrieb:
(Zu ganz guter Letzt kommt man an einer guten Programmiererausbildung eh nicht vorbei.)
Um ein BS zu schreiben ist deutlich mehr notwendig als nur programmieren können.
-
Nice site!
-
Nice site!
-
Ja, C# ist 10000x langsamer als C
-
Alles klar, du Troll!
-
beleidigte Leberwurst...
-
BorisDieKlinge schrieb:
Ja, C# ist 10000x langsamer als C
Boris, nichts für ungut, aber dein getrolle ändert nichts daran das die Aussage falsch ist. Ja, C# erzeugt nach meinen bisherigen Erfahrungen langsameren Code, nein, theoretisch könnte C# sogar schneller als C-Code laufen - letzteres halte ich aber mehr für Theorie, nur wenigstens kann ich es begründen.
C# ist grundsätzlich auf Sicherheit ausgelegt, C nicht. Dies führt dazu das C# in der Regel noch einige Sicherheitsprüfungen etc. im erzeugten Code einbaut, in C müsste man dies alles Händisch tun, könnte aber auch ein "übervorsichtiges" Verhalten an Stellen wo man Fehler ausschließen kann vermeiden. Daher kann man schon mal Annehmen das hier zwangsläufig C schneller sein kann (aber auch im Zweifel unsicherer). Einen Faktor von 1:10.000 ist es aber noch lange nicht.
C# kann prinzipiell aber auch schneller sein, da es Code Plattformspezifisch compiliert, und daher besser optimieren kann. Anderseits muss der Code aber auch einmalig beim Aufruf in Maschinencode umgesetzt werden was etwas Zeit kostet. Je Häufiger der Code aber aufgerufen wird, um so eher kann C# punkten. Bedingt durch das oben genannte kann es dennoch einen Overhead geben.
Nichts desto trotz ist C# in der Praxis meist deutlich schneller als von dir angegeben, da Code zumeist mehr als einmal aufgerufen wird. Wenn du also nicht nur trollen willst unterlege es mit nachweisbaren Fakten die Praxistauglich sein (Oh, du hast keine, wie Schade aber auch)...
Ich kenne deine negative Meinung gegen Sprachen wie Java und C#, aber damit werden deine Aussagen auch nicht besser (eher im Gegenteil).
cu André
P.S: Es gibt sogar Fälle in denen Java schneller als C ist (es gab glaube ich vor kurzen mal einen Link im C++ Forum über einen kleinen Schleifenablauf, wo moderne Java-Umgebungen etwa mit C gleichauf lagen) - Ja, dies umfasst nur Teilbereiche und hat keine allgemeine Aussagekraft, aber das sollte dir zu denken geben ob nicht irgendwann die Sprachen wie C# und Java auch in größeren Anwendungen sich an C heranarbeiten.
-
Im Grunde ist die ganze Entwicklung doch positiv. Frueher ist der ganze Code unsicher, weil man im Grunde alles durfte. Nun ist der Code managed, wird also von einer dritten Instanz ueberwacht dass man nur erlaubte Sachen machen darf.
Mit einer managed Sprache wie Java oder C# kann man eigentlich keine Viren mehr schreiben, weil der Code ja von einem anderem Programm ueberwacht wird. Das ist ca. das gleiche wie wenn man ein AntiVirus-Programm im Hintergrund laufen laesst, der alle Processe ueberwacht.
Wenn man also nur noch managed Applications auf seinem System laufen laesst, dann koennte man sich keine Viren mehr einfangen.
In 3 Jahren haben wir dann eh 4 oder 6 Kern-Systeme im Haus, dann kann doch ein Kern das Ueberwachen uebernehmen und auf dem Rest laufen dann die Apps. Maximale Sicherheit, kein Gschwdk.-Verlust.
Zum Thema Spiele und Spezaileffekte: Ca. 80% der Leistung uebernimmt eh die GPU, die CPU ist doch nur fuer KI, Logik, Netzwerk zustaendig.
-
Zum Thema Singularity:
Schaut es euch doch einfach an, wenn ihr es nicht glauben wollt. Der Quellcode ist mittlerweile online zu haben, zusammen mit einem Makefile, was das ganze als VirtualPC-Image kompiliert.
-
asc schrieb:
Boris, nichts für ungut, aber dein getrolle ändert nichts daran das die Aussage falsch ist. Ja, C# erzeugt nach meinen bisherigen Erfahrungen langsameren Code, nein, theoretisch könnte C# sogar schneller als C-Code laufen - letzteres halte ich aber mehr für Theorie, nur wenigstens kann ich es begründen.
ParallelFx zB. .NET bietet die Infrastruktur für Parallelisierung. Dazu noch enorm starke GC Algorithmen und JIT. Das selbe gilt natürlich für Java auch.
.NET hat aber damit das potential für nicht Systemnahe Anwendungen deutlich schneller zu sein.
-
Microsoft bringt ein neues Betriebssystem raus das in C# geschrieben ist.
http://channel9.msdn.com/ShowPost.aspx?PostID=68302
http://research.microsoft.com/os/singularity/Das Betriebssystem heißt Singularity der Kernel ist ganz in C# geschrieben.
-
meld schrieb:
Microsoft bringt ein neues Betriebssystem raus das in C# geschrieben ist.
http://channel9.msdn.com/ShowPost.aspx?PostID=68302
http://research.microsoft.com/os/singularity/Das Betriebssystem heißt Singularity der Kernel ist ganz in C# geschrieben.
Setzen, Sechs.
-
Konrad Rudolph schrieb:
meld schrieb:
Microsoft bringt ein neues Betriebssystem raus das in C# geschrieben ist.
http://channel9.msdn.com/ShowPost.aspx?PostID=68302
http://research.microsoft.com/os/singularity/Das Betriebssystem heißt Singularity der Kernel ist ganz in C# geschrieben.
Setzen, Sechs.
Du willst doch nur hier einen Flamewar starten. 