1. Foren
  2. Kommentare
  3. OpenSource-Forum
  4. Alle Kommentare zum Artikel
  5. › Linux: Kernel-Hacker müssen…

Assembler vs. C

  1. Thema
  1. 1
  2. 2

Neues Thema


  1. Assembler vs. C

    Autor: Ingwar 19.06.15 - 13:46

    Müssten die Torvalds Jünger jetzt nicht aufschreien, dass C unendlich viel langsamer als Assembler ist?!
    Ich meine das Geschrei ist ja schon Groß bei C++ :)

  2. Re: Assembler vs. C

    Autor: Linuxschaden 19.06.15 - 13:57

    Du kannst in C langsamen Code schreiben, und du kannst in Assembler langsamen Code schreiben. Aber für gewöhnlich wissen die Leute, die Assembler schreiben, was sie tun, das ist bei C nicht immer der Fall. Deswegen ist Assembler in der Regel schneller. Zudem gibt es auch Fälle, wo du Assemblercode verwenden MUSST - beispielsweise cpuid.

    Außerdem kompilieren C und Assembler schnell. C++ braucht da deutlich länger, bis am Ende die Binärdatei rauskommt. Und die zusätzliche Komplexität, die C++ mitbringt, und den Paradigmenwechsel mit all seinen Nachteilen macht mich froh, dass die nicht C++ zulassen.

  3. Re: Assembler vs. C

    Autor: M.P. 19.06.15 - 14:02

    <faketicker>
    Dafür gewinnt man in den Kernels für non x86 Prozessoren.
    Da muss der x86 Assembler-Code derzeit emuliert werden.
    Nach der Umstellung auf C kann man den Quellcode compilieren und bekommt dann sofort nativ z. B. auf ARM - Systemen laufenden Kernelcode
    </faketicker>


    SO ich glaube, damit ist mein Soll an Freitag-Nachmittags Postings erfüllt ;-)

  4. Re: Assembler vs. C

    Autor: Nifty 19.06.15 - 14:10

    Man kann c so schrieben das man exakt weiß man der Compiler daraus macht. Das kann durch die Compiler Optimierung dann sogar schneller sein als von von Hand geschriebener Assembler.

  5. Re: Assembler vs. C

    Autor: M.P. 19.06.15 - 14:15

    Ich glaube, bei Sachen, die direkt an das Eingemachte eines Betriebssystems gehen, wird man um ein paar Zeilen Assembler hier und da nicht herumkommen...

    Ich glaube nicht, daß man z. B. den Task-Wechsel ganz ohne Assembler hinbekommt...

  6. Re: Assembler vs. C

    Autor: Linuxschaden 19.06.15 - 14:18

    M.P. schrieb:
    --------------------------------------------------------------------------------
    > Ich glaube, bei Sachen, die direkt an das Eingemachte eines Betriebssystems
    > gehen, wird man um ein paar Zeilen Assembler hier und da nicht
    > herumkommen...
    >
    > Ich glaube nicht, daß man z. B. den Task-Wechsel ganz ohne Assembler
    > hinbekommt...

    Ist nur Korinthenkackerei - aber das macht nicht das Betriebssystem, das macht der Kernel. :) OS != Kernel

  7. Re: Assembler vs. C

    Autor: M.P. 19.06.15 - 14:58

    Der Kernel ist das Eingemachte des Betriebssystems ;-)

  8. Re: Assembler vs. C

    Autor: Dumpfbacke 19.06.15 - 15:07

    Nifty schrieb:
    --------------------------------------------------------------------------------
    > Man kann c so schrieben das man exakt weiß man der Compiler daraus macht.
    > Das kann durch die Compiler Optimierung dann sogar schneller sein als von
    > von Hand geschriebener Assembler.
    Jeder Compiler? Bezweifle ich, da es schon Sachen gab, die nach hinten losgegangen sind. Die Sicherheitslücke, die es unter einer Version von GCC gab, zeigt, dass es immer Probleme geben kann. Dabei wurde eine Schleife wegoptimiert, welche aber zu dem Sicherheitsproblem führte.

    mfg

  9. Re: Assembler vs. C

    Autor: Dumpfbacke 19.06.15 - 15:13

    M.P. schrieb:
    --------------------------------------------------------------------------------
    > Ich glaube, bei Sachen, die direkt an das Eingemachte eines Betriebssystems
    > gehen, wird man um ein paar Zeilen Assembler hier und da nicht
    > herumkommen...
    >
    > Ich glaube nicht, daß man z. B. den Task-Wechsel ganz ohne Assembler
    > hinbekommt...
    Warum nicht? Performence versus Stabilität ist hier die Frage.
    Microsoft hat in den 90ern an einer Windows Version, die nur auf c++ basiert, gearbeitet. Die wurde nie veröffentlicht, war zu langsam.

    mfg

  10. Re: Assembler vs. C

    Autor: Niantic 19.06.15 - 15:30

    M.P. schrieb:
    --------------------------------------------------------------------------------
    > > Dafür gewinnt man in den Kernels für non x86 Prozessoren.
    > Da muss der x86 Assembler-Code derzeit emuliert werden.
    > Nach der Umstellung auf C kann man den Quellcode compilieren und bekommt
    > dann sofort nativ z. B. auf ARM - Systemen laufenden Kernelcode
    >
    > SO ich glaube, damit ist mein Soll an Freitag-Nachmittags Postings erfüllt
    > ;-)


    na ganz so funktioniert das nicht... Wenn die architektur nen SSB statt pci bus hat, kannst du auch den assembler code für den pci bus nicht emulieren um den ssb an den start zu kriegen - der kernel muss nach wie vor an die architektur angepasst werden...

  11. Re: Assembler vs. C

    Autor: picaschaf 19.06.15 - 15:31

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > Du kannst in C langsamen Code schreiben, und du kannst in Assembler
    > langsamen Code schreiben. Aber für gewöhnlich wissen die Leute, die
    > Assembler schreiben, was sie tun, das ist bei C nicht immer der Fall.
    > Deswegen ist Assembler in der Regel schneller. Zudem gibt es auch Fälle, wo
    > du Assemblercode verwenden MUSST - beispielsweise cpuid.
    >
    > Außerdem kompilieren C und Assembler schnell. C++ braucht da deutlich
    > länger, bis am Ende die Binärdatei rauskommt. Und die zusätzliche
    > Komplexität, die C++ mitbringt, und den Paradigmenwechsel mit all seinen
    > Nachteilen macht mich froh, dass die nicht C++ zulassen.

    Wenn man Assembler auf einer Architektur wie x86 schreibt, dann *meint* man zu wissen was man tut. Einige Entwickler sind einfach noch nicht aus den 80ern im Hier und Jetzt angekommen.

  12. Re: Assembler vs. C

    Autor: motzerator 19.06.15 - 16:33

    Ingwar schrieb:
    --------------------------
    > Müssten die Torvalds Jünger jetzt nicht aufschreien, dass C unendlich viel
    > langsamer als Assembler ist?!

    Das halte ich für ein Gerücht. Die Compiler sollen viele Optimierungen
    vornehmen und somit durchaus effizienten Code erzeugen.

    Ich denke, in reinem Assembler muss man schon viel optimieren, um
    diese automatische Optimierung zu übertreffen. Das Ergebnis ist dann
    aber vermutlich so schwer lesbar, wie die betroffenen Codestellen, um
    die es hier geht.

  13. Re: Assembler vs. C

    Autor: M.P. 19.06.15 - 17:14

    Hmm,
    dann zeige mir mal ein reines C-Programm das den kompletten Prozessorstatus (Register, Flags usw.) in einen Speicherbereich schreibt, und wieder zurücklesen kann....

  14. Re: Assembler vs. C

    Autor: Bonita.M 19.06.15 - 18:07

    > Ich glaube nicht, daß man z. B. den Task-Wechsel ganz ohne Assembler
    > hinbekommt...

    Mit den Intrinsics die die heutigen Compiler bieten kann man alles was ein OS braucht in C/C++ entwickeln.

  15. Re: Assembler vs. C

    Autor: Bonita.M 19.06.15 - 18:09

    > Microsoft hat in den 90ern an einer Windows Version, die nur auf c++
    > basiert, gearbeitet. Die wurde nie veröffentlicht, war zu langsam.

    Weil die Compiler damals noch nicht weit genug waren.
    Heute kann man in C++ genausoschnellen Code wie in C entwickeln.

  16. Re: Assembler vs. C

    Autor: derats 19.06.15 - 19:16

    Linuxschaden schrieb:
    --------------------------------------------------------------------------------
    > Außerdem kompilieren C und Assembler schnell. C++ braucht da deutlich
    > länger, bis am Ende die Binärdatei rauskommt. Und die zusätzliche
    > Komplexität, die C++ mitbringt, und den Paradigmenwechsel mit all seinen
    > Nachteilen macht mich froh, dass die nicht C++ zulassen.

    Was die Builds bei vielen C++ Projekten langsam macht, ist exzessive Nutzung von Templates (Boost...) und unpassende Aufteilung von Definitionen auf Header. Wenn man das korrekt macht, ist der Geschwindigkeitsunterschied zu C nicht mehr sonderlich relevant.

  17. Re: Assembler vs. C

    Autor: 486dx4-160 20.06.15 - 01:57

    x86er-Assembler war schon in den 90ern scheiße, und damals war's noch erheblich einfacher. Außerdem sind die Compiler heute erheblich besser.
    In 99,999% der Fälle ist heute C schneller als selbstgeschriebenes Assembler - und: es ist leichter lesbar, bei quelloffener Software auch ein wichtiges Kriterium.

    Die niedrige Ausführungsgeschwindigkeit von C++ hat andere Gründe.

  18. Re: Assembler vs. C

    Autor: bombinho 20.06.15 - 07:57

    Nifty schrieb:
    --------------------------------------------------------------------------------
    > Man kann c so schrieben das man exakt weiß man der Compiler daraus macht.
    > Das kann durch die Compiler Optimierung dann sogar schneller sein als von
    > von Hand geschriebener Assembler.

    Na da bin ich ja von den Socken, das kann man ja noch nicht einmal in x86-Assembler. Ganz offensichtlich hat sich da C weiter entwickelt als es Assembler bisher geschafft hat.

    Gibt es da Dokumentationen/Konventionen, welchen Binaercode C unter welchen Umstaenden erzeugt?

    Edit: Okay, wenn man Befehle ueber db [xx] implementiert, wird es eineindeutig, mein Fehler ;)



    1 mal bearbeitet, zuletzt am 20.06.15 08:01 durch bombinho.

  19. Re: Assembler vs. C

    Autor: Moe479 20.06.15 - 10:22

    naja c wurde ja seinerzeit genau für diese aufgabe entwickelt, unterhaltungsoftware möglichst schnell von den automaten des einen herstellers auch auf denen anderer vertreilen zu können. d.h. nicht, dass das mit c automatisiert werden sollte/konnte sondern dass die strukturierungsmöglichkeiten es erlaubten schnell die nötigen stellen zum abändern zu finden und umschreiben können.

  20. Re: Assembler vs. C

    Autor: derats 20.06.15 - 10:31

    486dx4-160 schrieb:
    --------------------------------------------------------------------------------
    > Die niedrige Ausführungsgeschwindigkeit von C++ hat andere Gründe.

    Dumme Programmierer, die nix können, aber meinen C++ zu beherrschen?

  1. Thema
  1. 1
  2. 2

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. IT Workplace Administrator (w/m/d)
    RHI Magnesita GmbH, Mainzlar bei Staufenberg
  2. Systemingenieur*in für den Bereich IT-Security (w/m/d)
    Hensoldt, Ulm
  3. Entwicklungsingenieur Bildverarbeitung Python/C/C++ (m/w/d)
    pro-beam GmbH & Co. KGaA, Gilching (bei München),
  4. Anwendungsbetreuer*in Campus Management System (m/w/d)
    Humboldt-Universität zu Berlin, Berlin

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de


Tesla Model 3: Die Mechanik ist das Problem
Tesla Model 3
Die Mechanik ist das Problem

Manche Probleme zeigen sich beim Elektroauto erst mit der Zeit. Beispielsweise, wenn Wasser den Bauteilen zusetzt. Bericht eines langjährigen Tesla-Fahrers.
Von Dirk Kunde

  1. Beschwerden über Übertreibungen Tesla senkt in aller Stille die Reichweitenschätzungen
  2. Nur Fremdmarken Kostenlose Ladeaktion bei Tesla
  3. Elektroautos Tesla übertrifft Auslieferungsrekord im Jahr 2023

Science-Fiction-Film Enemy: Liebe in Zeiten der Übertechnologisierung
Science-Fiction-Film Enemy
Liebe in Zeiten der Übertechnologisierung

Wenn man einen Menschen durch ein Roboter-Duplikat ersetzt, was passiert dann mit demjenigen, der ihn liebt? Interessante Frage, leider macht der Film einige Denkfehler.
Eine Rezension von Peter Osteried

  1. Doctor Who Christmas Special eröffnet ein neues Mysterium
  2. Lola Könnte die Vergangenheit unsere Gegenwart verhindern?
  3. Rebel Moon Director's Cut soll "gänzlich anderer Film" sein

Softwareentwicklung: Scrum-Abenteuer auf der grünen Wiese
Softwareentwicklung
Scrum-Abenteuer auf der grünen Wiese

Wie wir anderthalb Jahre lang im Greenfield-Projekt Scrum versuchten, über Bord warfen und völlig deformierten - um dann zu erkennen, dass wir es lebten.
Ein Erfahrungsbericht von Rene Koch

  1. Scrum of Scrums Ein leichtgewichtiges agiles Framework