Windows auf Maschienensprache ?

[moquai]

... ich merke hier gerade das Leute etwas dazu schrieben die wirklich GARKEINE Ahnung haben.

Würdest Du Ahnung haben, dann hättest Du erst gar nicht diese Fragen gestellt.

 

[ice-breaker]

Lies dir da mal die Nachteile durch. Es gibt haufenweise Programmierer, die nicht mal mit einer Hochsprache vernünftigen Code produzieren. Umso weniger wirst du welche finden, die brauchbaren assembler code fabrizieren. Spätestens wenn diese einen Unfall haben geht deren Firma bankrott, weil deren Code kein Mensch mehr versteht.

und das Compiler heute im großen und ganzen effizienteren Assembler-Code erstellen können, als ein Programmierer von Hand - verständlich bei den vielen Befehlssatzerweiterungen.
Nur in wenigen Fällen wird ein Mensch effizienteren Assemblercode zusammenschustern, als ein Compiler.

@ BlooDFreeZe

Nee, wenn du die einmal aufklappst dann sind die direkt an. Und wenn man die ganz neu bootet sind die auch sehr schnell und mit ner SSD sowieso !
Welches OS X hast du ? 10.5 ?

natürlich sind die in dem Fall schneller, Apple muss ja viel weniger verschiedene Hardware und Treiber verwalten, deren Aufwand ist ja minimalst, ein Linux oder Windows dagegen muss mit jeder Hardware arbeiten können und tausenden möglichen Treibern die sich an alle Prozesse dranhängen können.

 

[IceMatrix]

@ BlooDFreeZe

Nee, wenn du die einmal aufklappst dann sind die direkt an. Und wenn man die ganz neu bootet sind die auch sehr schnell und mit ner SSD sowieso !

Jetzt vergleichst du aber Äpfel und Birnen.. Windows bootet mit SSD ebenfalls sehr schnell!

 

[4nanai]

[...] und glaub mir niemand will ein Betriebssystem im Assembler schreiben Wäre zu abstrackt und die Dokumentantion ist schwer umsetzbar.

http://www.menuetos.net/

 

[IceMatrix]

und das Compiler heute im großen und ganzen effizienteren Assembler-Code erstellen können, als ein Programmierer von Hand - verständlich bei den vielen Befehlssatzerweiterungen.
Nur in wenigen Fällen wird ein Mensch effizienteren Assemblercode zusammenschustern, als ein Compiler.

Wenn der Programmierer etwas von seinem Handwerk versteht ist er dem Compiler praktishc immer überlegen. Es ist nur mit einem deutlich höheren Aufwand verbunden.

 

[mensch183]

Den Thread hätte man nach Beitrag #2 schließen können, denn damit war alles beantwortet und geklärt.

 

[AP Nova]

Wir haben vom Binär ins Dualsystem übersetzt

Sicher, dass ihr nicht doch vom Dezimalsystem in eins mit 10 als Basis übersetzt habt? Fällt dir was?

 

[bu1137]

There are only 10 types of people in the world: Those who understand binary, and those who don't.

 

[DAASSI]

so zur info: klar is Assembler hin und wieder flotter als ne "normale" Programmiersprache, aber eben nur weil es auf spezielle architekturen angepasst wurde, d.h. das würde nicht überall laufen..
Außerdem ist das aktuell schnellste und sicherste OS in C# geschrieben: Microsoft Singularity. Leider ist es nur ein Experimentiersystem von MS und wird nie erscheinen, aber Teile daraus

@bu1137: geiler Insider darf ich ihn aufklären für alle die keine ahnung haben?^^

achso und noch was produktives: ich hab echt mal versucht ein C Programm in Assembler und dann in Maschinensprache (1 und 0) zu übersetzen. Das ist sowas von eine Arbeit. Den Befehlsatz den ich hatte hatte knapp 200 Befehle und schon da drehste total hohl, was macht man erst bei ner CPU wie heute mit sehr weit über 1000 (ich glaub 5000 Befehle)? Da drehste nur noch am Rad

 

[Newk]

Wenn der Programmierer etwas von seinem Handwerk versteht ist er dem Compiler praktishc immer überlegen. Es ist nur mit einem deutlich höheren Aufwand verbunden.

Das Problem ist nur, dass ein Mensch und auch viele Menschen dort nicht überlegen sein können, da es viel zu komplex wird. Das kann niemand effektiv leisten. Ich denke, dass man heute sagen muss, dass man nur mit Hilfe von Maschinen Hochleistungs-Maschinen programmieren kann.

 

[BlooDFreeZe]

@ BlooDFreeZe

Nee, wenn du die einmal aufklappst dann sind die direkt an. Und wenn man die ganz neu bootet sind die auch sehr schnell und mit ner SSD sowieso !
Welches OS X hast du ? 10.5 ?

SSD ist logisch, bau halt ne SSD innen Windows Rechner....hat man beide Betriebssysteme neu Installiert ist OSX etwas schneller. Hat man aber beide System seit einiger Zeit in Betrieb und OSX annähernd auf Windows Vielfalt erweitert sieht das schon etwas anders aus. Hab hier mehrere Laptops (MacBook Air, MacBook Pro (natürlich mit der neusten Version)).

 

[Fonce]

2. Glaube mit der "Maschinensprache" meint er Assembler, aber Windows wird in C programmiert, was auch schon recht Hardwarenahe ist, und glaub mir niemand will ein Betriebssystem im Assembler schreiben Wäre zu abstrackt und die Dokumentantion ist schwer umsetzbar.

Kein aktuelles Betriebssystem kommt ohne Assembler Code aus

Wenn der Programmierer etwas von seinem Handwerk versteht ist er dem Compiler praktishc immer überlegen. Es ist nur mit einem deutlich höheren Aufwand verbunden.

Wo willst du die Horden an Entwicklern herbekommen die so gut Assembler können um eine Software mit dem Umfang eines Windows zu programmieren?
Der Anteil der Entwickler welche dir "immer" einen besseren Assembler Code liefern wie ein Compiler dürfte, wenn überhaupt, im Promillebereich liegen!

Außerdem muss man den Code auch gescheit Warten können was sich auch durch Assembler Code deutlich schwerer gestalten lassen dürfte...

 

[antred]

Wenn der Programmierer etwas von seinem Handwerk versteht ist er dem Compiler praktishc immer überlegen. Es ist nur mit einem deutlich höheren Aufwand verbunden.

Das wird aber mit den heutigen System immer schwieriger. Viele Konstrukte und Prinzipien, mit denen ein gewitzter Assembler-Programmierer auf den in den 90ern vorherrschenden Systemen noch mit an Sicherheit grenzender Wahrscheinlichkeit jeden Compiler schlagen konnte, können auf heutigen Systemen eventuell den gegenteiligen Effekt haben. Moderne Systeme werden immer ausgefuchster und trickreicher und optimieren immer aggressiver, selbst zur Laufzeit. Da gehen Dinge ab, die abgesehen von ein paar Genies eigentlich kaum noch ein Programmierer nachvollziehen kann. Um mit Sicherheit behaupten zu können, daß eine handgestrickte Optimierung das schlagen kann, was ein guter, aggressiv optimierender Compiler ausspuckt, muß man eine extrem detailierte und tiefgründige Kenntnis des jeweiligen Systems haben. Was auf einem System vielleicht tatsächlich einen Performancegewinn bringt, kann auf einem anderen vielleicht sogar das System behindern.

 

[AntiUser]

Na ja ... OS X Maschinensprache?! Die wichtigen Teile (meist Geschwindigkeitsrelevant) Ja, aber der Rest nein. Sieh selbst:

Teil mit Maschinensprache:
http://www.opensource.apple.com/source/xnu/xnu-1504.9.37/libkern/ppc/
http://www.opensource.apple.com/source/xnu/xnu-1504.9.37/libkern/x86_64/

Aber auch genau so viel in C, wie der BSD Kern:
http://www.opensource.apple.com/source/xnu/xnu-1504.9.37/bsd/kern/

 

[Airbag]

Wahrscheinlich hat dein Physiklehrer Eingebungen ala Richard Huddy(Treiberabteilung von AMD) gehabt.
So nach dem Motto. Schafft die Low Level APIs wie D3D und OpenGL ab und macht alles hardwarenäher.
Nah klar bringt es Perfomancevorteile, aber versuch es mal auf möglichst vielen Systemen zu laufen zu bringen,

Da gehen Dinge ab, die abgesehen von ein paar Genies eigentlich kaum noch ein Programmierer nachvollziehen kann.

Was mich so spontan an Generics in Java errinnert. Aussage von meinem Dozenten: "Ich gebe zu, dass ich es nicht verstehe, aber ich kann es benutzen. Wahrscheinlich gibt es nur auf eine handvoll Menschen, die es verstehen."
Es gibt ja nicht umsonst ein 500 Seiten langes Paper zu den Generics.


edit:
Man sollte aber auch erwähnen, dass sich innerhalb der letzen 20 Jahre extrem viel bzgl. der Hardware und Komplexität der Anforderungen getan hat, weswegen eine Herangehensweise auf "alte" Weise nur bedingt geht.
Z.b. haben Grafikkarten heute nur noch bedingt "Fixed Functions"

 

[ice-breaker]

Außerdem ist das aktuell schnellste und sicherste OS in C# geschrieben: Microsoft Singularity. Leider ist es nur ein Experimentiersystem von MS und wird nie erscheinen, aber Teile daraus

das fand ich auch eine sau geniale Idee, schade, dass es nicht weiter verfolgt wurde (oder vllt doch?)

 

[lynxx]

10% eines Codes verbrauchen 90% der Rechenzeit, welche Teile das sind kann man mit Profilern rauskriegen und dann entsprechend in der Hochsprache optimieren (Schleifen auflösen, Variablen vorberechnen usw usf), doch gleich dafür auf Assembler zu wechseln ist übertrieben und macht nur bei Programmen die dauerhafte hohe CPU-Last erzeugen Sinn. (Raytracer etc)

Es gibt bessere Möglichkeiten Windows zu verbessern, z.B:
1) Alle Dateien eines Programs in nur EINEM Ordner, auch wenn es Settings speichert etc (dann wäre so ein Wust wie mit Winsxs gar nicht nötig).

2) Programme haben generell nur lese/schreib-rechte im eigenen Ordner, ansonsten muss man bei Installation extra Rechte vergeben.

 

[Backslash]

Nee, wenn du die einmal aufklappst dann sind die direkt an.

Ich habe ein MacBook und ja, das ist so. Ist aber bei Windows aus dem Standby kein Stück anders.

 

[IceMatrix]

Das wird aber mit den heutigen System immer schwieriger. Viele Konstrukte und Prinzipien, mit denen ein gewitzter Assembler-Programmierer auf den in den 90ern vorherrschenden Systemen noch mit an Sicherheit grenzender Wahrscheinlichkeit jeden Compiler schlagen konnte, können auf heutigen Systemen eventuell den gegenteiligen Effekt haben. Moderne Systeme werden immer ausgefuchster und trickreicher und optimieren immer aggressiver, selbst zur Laufzeit. Da gehen Dinge ab, die abgesehen von ein paar Genies eigentlich kaum noch ein Programmierer nachvollziehen kann.

Ich kann dir hier sogar ein Paradebeispiel geben... libx264! Diese Library ist der Konkurenz deshalb so überlegen, weil die Programmierer ihr Handwerk verstehen.

Dass moderne Systeme immer ausgefuchster sind trifft nur zum Teil zu. Der Kern hinter der Optimierung auf Assembly ist der gleiche wie vor 10 Jahren. Die einzige Technik die sich nennenswert verändert hat ist SIMD (speziell das SSE Instruction Set). An dieser Stelle versagt bis jetzt jeder gebräuchliche Compiler, obwohl gerade hier der größte Leistungsgewinn zu finden ist.

Es hat gute Gründe warum viele C-Bibliotheksfunktionen noch immer in Assembly programmiert werden. Ein Compiler kann nur das optimieren was im Quellcode steht. Viele Dinge lassen sich aber über spezielle Tricks oder eigens dafür vorhandene Instructions viel eleganter und v.a. schneller lösen. Kugg dir nur mal die Implementierung von strlen() als Beispiel an.

Um mit Sicherheit behaupten zu können, daß eine handgestrickte Optimierung das schlagen kann, was ein guter, aggressiv optimierender Compiler ausspuckt, muß man eine extrem detailierte und tiefgründige Kenntnis des jeweiligen Systems haben. Was auf einem System vielleicht tatsächlich einen Performancegewinn bringt, kann auf einem anderen vielleicht sogar das System behindern.

Viele Optimierungen sind deshalb spezifisch auf eine bestimmte CPU-Baureihe ausgerichtet. Die Mehrzahl der Optimierungen sind aber allgemeingültig und bringen auf allen Baureihen Vorteile, z.B. durch manuelle Einsparungen von Speicherzugriffen etc. (siehe strlen()).

 

[antred]

Oh, das glaube ich dir sogar. Ich sage ja auch nicht, daß Assember tot oder nutzlos ist, nur eben, daß tatsächliche Optimierungen schwieriger zu finden sind als damals. Ich bin auf diesem Gebiet zugegebenermaßen Laie und habe mein (Halb-)Wissen diesbezüglich nur aus dem / der einen oder anderen Artikel / Internetdiskussion.

Was sich da, so weit ich es mitbekommen habe, im letzten Jahrzehnt schon nennenswert verändert hat, sind das solche Techniken wie:

• Out-of-order execution
• Branch prediction
• Pipelining

immer stärker und in ausgeklügelteren Formen zur Anwendung gekommen sind und es schwierig(er) machen, vorherzusagen welchen Effekt ein eventueller Optimierungsversuch tatsächlich haben wird. Dann kommt noch dazu, daß moderne Systeme völlig andere Stärken und Schwächen bezüglich Cache / Register / RAM-Zugriffe haben, so daß diesbezügliche Annahmen, die vor 10 Jahren noch zutreffend waren, es heute nicht mehr sein müssen, und so weiter und so fort.