C# Betreibssystem
-
Also geht nicht direkt um ein Betriebssystem aber auch um Programmieren.
Da hier schon einige Programmiersprachen genannt wurden frage ich gleich.
Welche Sprache würdet ihr empfehlen um PC spiele zu Programmieren (EGO shooter)
Was ist schnell und was für Erfahrungen habt ihr schon gemacht ?
In welchen sprachen sind heutige egoshooter geschrieben auf welchen Grundlage fangen die(EA UBISOFT) an.
-
Martin Barber schrieb:
Also geht nicht direkt um ein Betriebssystem aber auch um Programmieren.
Da hier schon einige Programmiersprachen genannt wurden frage ich gleich.
Welche Sprache würdet ihr empfehlen um PC spiele zu Programmieren (EGO shooter)
Was ist schnell und was für Erfahrungen habt ihr schon gemacht ?
In welchen sprachen sind heutige egoshooter geschrieben auf welchen Grundlage fangen die(EA UBISOFT) an.C++
EDIT: Mit Sicherheit nich C#. Denn in der Computerspieleszene kommt es nunmal auf performacne an. man könnte fast schon sagen: Performance = Geld. Je niedriger die Systemvoraussetzungen sind, desto größer ist die potentielle Zielgruppe. Je performanter die engine geschrieben ist, desto mehr grafische Effekte können ins Spiel integriert werden, ohne die akzeptable FPS-Rate von 24 zu unterschreiten.
-
Da muss ich dich leider enttäuschen. Propagandamaterial wirst du da nicht finden, nur wissenschaftliche Abhandlungen die nicht von der Marketingabteilung geschrieben wurden, sondern von Wissenschaftlern die garatiert weit gebildeter sind als wir hier aufm Board und wissen was sie tun - aber naja, ignorante Menschen gibts überall.
Defakto ist C# zu langsam.
Diese Aussage ist quatsch. C# ist an sich genauso schnell wie jeder andere native Code, da C# genauso letztendlich in nativen Code kompiliert wird. Was C# subjektiv langsamer macht ist der JIT Compiler beim ersten Start einer Applikation und die höhere Abstraktion der Klassenbibliothek. Leider wird für Singularity ein Compiler benutzt der den managed Code direkt in Maschinencode kompiliert und auch wird nicht die .Net Klassenbibliothek verwendet sondern nur die managed Sprache an sich. Damit fallen die beiden Gründe was das .Net Framework auf hiesigen PCs langsam macht weg und übrig bleibt nativer Code der aus einer managed Sprache kompiliert wurde und kein bissle langsamer ist als die oben schon aufgeführten üblichen Verdächtigen wenns um OS Programmierung geht: ASM/C/C++. Wieso sollte das jetzt langsamer sein?!?
Übrigens disqualifiziert man sich mit Pseudoargumenten wie
Defakto...Punkt.
und
Das ist so
selbst schon aus jeder Diskussion da keinerlei Fakten genannt werden sondern nur rechthaberisch die eigene Meinung durchgesetzt werden soll. Ohne objektive Fakten hat man im vorhinein schon verloren...
-
Singularity sieht auf jeden Fall nach einem interessanten Projekt aus! Ich hab's größtenteils nur überflogen, aber kann es nicht auch sein, dass einige der Geschwindigkeitsvorteile (wie z.B. das ultra-schnelle Prozess-Laden) an der Technik liegen, also weil einige Konzepte einfach grundlegend verändert wurden verändert wurden (SIP z.B.)?
Auch wenn andere Techniken verwendet wurden (die Channels sahen auch interessant aus, hab ich aber noch nicht im Detail verstanden), haben mich die Geschwindigkeitstabellen doch erstaunt. Meine bisherigen (kurzen) Erfahrungen mit C# waren, dass die Programme, evtl wegen dem Overhead, doch um ein Stückchen langsamer waren. Naja, ich schau mir erstmal das Video davon an
-
Badestrand schrieb:
...also weil einige Konzepte einfach grundlegend verändert wurden verändert wurden (SIP z.B.)?...
Das ist genau der Punkt worum es in dem Projekt geht. Es ist ein Forschungsbetriebssystem an dem neue Konzepte ausprobiert werden. Heutige OS Architekturen sind auch net das gelbe vom Ei, und dort probiert man halt was anderes aus, was dem heutigen in einigen Bereichen überlegen ist.
Von den Ideen ist das Projekt wirklich hochinteressant.Nochmal zu dem Geschwindigkeitsding: Singularity ist in Sing# geschrieben welches eine Erweiterung von C# ist und damit eine managed Sprache - aber es wird nicht das .Net Framework benutzt wir wir es vom PC kennen. Das habe ich ja schon im vorherigen Beitrag vesucht zu erläutern dass der managed Code direkt in Maschinencode umgesetzt wird. Die Verwendung von managed Code hat halt den Vorteil das der Code von sich aus sicher ist. Wenn man jetzt dafür sorgt das der Compiler praktisch fehlerfrei arbeitet und der genügend verifiziert ist, dann ist automatisch sichergestellt das das ganze OS sicher ist. Das wird auf der Singularity Projektseite ja auch genannt, das ein großer Teil des Projektes sich auch mit dem Compiler, Codesicherheit, Verifizirbarkeit etc. befasst.
-
Ignoriert "du" einfach.
- Er ist ein Flamer aus dem Developia-Forum und mit TGGC "per du"
- Hat keinen Plan
- Flamer
- Uneinsichtig
- Nur auf seine beschränkte Sichtweise fixiertDer kann ruhig gebannt werden.
-
Talla schrieb:
...dass der managed Code direkt in Maschinencode umgesetzt wird. Die Verwendung von managed Code hat halt den Vorteil das der Code von sich aus sicher ist.
wenn er zu maschinencode umgewandelt wird, dann ist er aber nicht mehr 'managed'
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#.
-
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...