Die Ebenen der Datenverarbeitung verstehen


9

Entschuldigung für meine verwirrte Frage. Ich suche nach Hinweisen.

Bisher habe ich hauptsächlich mit Java und Python auf der Anwendungsebene gearbeitet und ich habe nur ein vages Verständnis für Betriebssysteme und Hardware. Ich möchte viel mehr über die niedrigeren Computerebenen verstehen, aber es wird irgendwie wirklich überwältigend. An der Universität nahm ich an einem Kurs über Mikroprogrammierung teil, dh wie Prozessoren fest verdrahtet werden, um die ASM-Codes zu implementieren. Bisher dachte ich immer, ich würde nicht mehr erledigen, wenn ich mehr über das "niedrige Niveau" erfahren würde.

Eine Frage, die ich habe, ist: Wie ist es überhaupt möglich, dass Hardware fast vollständig vor dem Entwickler verborgen bleibt? Ist es richtig zu sagen, dass das Betriebssystem eine Softwareschicht für die Hardware ist? Ein kleines Beispiel: Beim Programmieren bin ich nie auf die Notwendigkeit gestoßen, zu verstehen, was L2- oder L3-Cache ist. Für die typische Geschäftsanwendungsumgebung muss man Assembler und die niedrigeren Rechenebenen fast nie verstehen, da es heutzutage für fast alles einen Technologie-Stack gibt. Ich denke, der springende Punkt dieser niedrigeren Ebenen ist es, eine Schnittstelle zu höheren Ebenen bereitzustellen. Andererseits frage ich mich, wie viel Einfluss die unteren Ebenen haben können, zum Beispiel diese ganze Grafik-Computing-Sache.

Auf der anderen Seite gibt es diesen theoretischen Zweig der Informatik, der an abstrakten Computermodellen arbeitet. Ich bin jedoch auch selten auf Situationen gestoßen, in denen ich es als hilfreich empfand, in den Kategorien Komplexitätsmodelle, Beweisverifizierung usw. zu denken. Ich weiß irgendwie, dass es eine Komplexitätsklasse namens NP gibt und dass sie irgendwie unmöglich zu lösen sind eine große Anzahl von N. Was mir fehlt, ist eine Referenz für einen Rahmen, um über diese Dinge nachzudenken. Es scheint mir, dass es alle möglichen Lager gibt, die selten miteinander interagieren.

In den letzten Wochen habe ich über Sicherheitsprobleme gelesen. Hier kommen irgendwie viele der verschiedenen Schichten zusammen. Angriffe und Exploits finden fast immer auf der unteren Ebene statt. In diesem Fall müssen Sie sich mit den Details der OSI-Schichten, dem Innenleben eines Betriebssystems usw. vertraut machen.


1
Es gibt eine gute Antwort auf diese Frage (die erste auf die Frage) programmers.stackexchange.com/questions/81624/…
Puckl

Angriffe und Exploits können auf allen Ebenen stattfinden. Wenn ich ein anfälliges PHP-Skript schreibe, kann es unabhängig vom zugrunde liegenden Betriebssystem ausgenutzt werden, geschweige denn von der Hardware.
tdammers

1
Ich habe ein großartiges Buch zum Thema gefunden: Die Elemente von Computersystemen: Aufbau eines modernen Computers nach ersten Prinzipien Noam Nisan, Shimon Schocken. Ein Vortrag von Herrn Schocken zu diesem Ansatz: youtube.com/watch?v=IlPj5Rg1y2w&feature=plcp
RParadox

In den Tagen von dos war die Verwendung der Assemblersprache für VGA-Grafikroutinen der einzige Weg, um eine Leistung zu erzielen, aber ich glaube, ich wusste nicht, was ich tat! Aber in den letzten 10 Jahren oder länger meiner Karriere musste ich mir nichts so Niedriges ansehen. Und ich weiß jetzt größtenteils nicht, was auf diesen Ebenen passiert. Selten muss ich sogar mein eigenes Gedächtnis zuordnen oder bereinigen. Ich vermute, viele in meinem Team wissen nicht, was ein Stapel ist! In vielerlei Hinsicht ist es nicht produktiv, auf einer solchen Ebene zu codieren und das Rad sozusagen neu zu erfinden. Vielmehr stehen wir auf den Schultern von Riesen.
Gavin Howden

Antworten:


19

Das Schlüsselwort zum Nachdenken über diese Dinge ist Abstraktion .

Abstraktion bedeutet nur, die Details eines Systems absichtlich zu ignorieren, damit Sie es als eine einzige, unteilbare Komponente betrachten können, wenn Sie ein größeres System aus vielen Subsystemen zusammensetzen. Es ist unvorstellbar leistungsfähig - das Schreiben eines modernen Anwendungsprogramms unter Berücksichtigung der Details der Speicherzuordnung und des Verschüttens von Registern sowie der Transistorlaufzeiten wäre auf idealisierte Weise möglich, aber unvergleichlich einfacher nichtum über sie nachzudenken und stattdessen nur Operationen auf hoher Ebene zu verwenden. Das moderne Computerparadigma stützt sich entscheidend auf mehrere Abstraktionsebenen: Festkörperelektronik, Mikroprogrammierung, Maschinenanweisungen, Programmiersprachen auf hoher Ebene, Betriebssystem- und Webprogrammierungs-APIs, vom Benutzer programmierbare Frameworks und Anwendungen. Praktisch niemand kann heutzutage das gesamte System verstehen, und es gibt nicht einmal einen denkbaren Weg, über den wir jemals zu diesem Zustand zurückkehren könnten.

Die Kehrseite der Abstraktion ist der Machtverlust. Indem wir Entscheidungen über Details niedrigeren Ebenen überlassen, akzeptieren wir oft, dass sie mit suboptimaler Effizienz getroffen werden können, da die unteren Ebenen nicht das „Gesamtbild“ haben und ihre Funktionsweise nur durch lokales Wissen optimieren können und nicht so (potenziell) sind. intelligent wie ein Mensch. (Normalerweise. Zum Beispiel wird das Kompilieren von HLL zu Maschinencode heutzutage oft besser von Maschinen als von selbst dem erfahrensten Menschen durchgeführt, da die Prozessorarchitektur so kompliziert geworden ist.)

Das Thema Sicherheit ist interessant, da Fehler und "Lecks" in der Abstraktion häufig ausgenutzt werden können, um die Integrität eines Systems zu verletzen. Wenn eine API postuliert, dass Sie die Methoden A, B und C aufrufen dürfen, aber nur, wenn Bedingung X gilt, ist es leicht, die Bedingung zu vergessen und nicht auf die Auswirkungen vorbereitet zu sein, die auftreten, wenn die Bedingung verletzt wird. Beispielsweise nutzt der klassische Pufferüberlauf die Tatsache aus, dass das Schreiben in Speicherzellen zu einem undefinierten Verhalten führt, sofern Sie diesen bestimmten Speicherblock nicht selbst zugewiesen haben. Die API garantiert nur das etwaswird als Ergebnis passieren, aber in der Praxis wird das Ergebnis durch die Details des Systems auf der nächstniedrigeren Ebene definiert - was wir bewusst vergessen haben! Solange wir die Bedingung erfüllen, ist dies nicht wichtig, aber wenn nicht, kann ein Angreifer, der beide Ebenen genau versteht, normalerweise das Verhalten des gesamten Systems wie gewünscht steuern und schlimme Dinge verursachen.

Der Fall von Speicherzuordnungsfehlern ist besonders schlimm, da es sich als sehr, sehr schwierig herausgestellt hat, den Speicher ohne einen einzigen Fehler in einem großen System manuell zu verwalten. Dies könnte als ein fehlgeschlagener Fall der Abstraktion angesehen werden: obwohl es möglich ist, mit dem C alles zu tun, was Sie brauchenmallocAPI, es ist einfach zu leicht zu missbrauchen. Teile der Programmierergemeinschaft sind jetzt der Meinung, dass dies der falsche Ort war, um eine Ebenengrenze in das System einzuführen, und fördern stattdessen Sprachen mit automatischer Speicherverwaltung und Speicherbereinigung, die etwas an Leistung verlieren, aber Schutz vor Speicherbeschädigung und undefiniertem Verhalten bieten . Tatsächlich ist ein Hauptgrund für die heutige Verwendung von C ++ genau die Tatsache, dass Sie damit genau steuern können, welche Ressourcen wann erworben und freigegeben werden. Auf diese Weise kann das große Schisma zwischen verwalteten und nicht verwalteten Sprachen heute als Uneinigkeit darüber angesehen werden, wo genau eine Abstraktionsebene definiert werden soll.

Das Gleiche gilt für viele andere wichtige alternative Paradigmen im Computerbereich - das Problem taucht immer dann auf, wenn große Systeme konstruiert werden müssen, da wir einfach nicht in der Lage sind, Lösungen für die heute üblichen komplexen Anforderungen von Grund auf neu zu entwickeln. (Ein allgemeiner Standpunkt in der KI ist heutzutage, dass das menschliche Gehirn tatsächlich so arbeitet - Verhalten, das durch Rückkopplungsschleifen, massiv miteinander verbundene Netzwerke usw. entsteht, anstatt durch separate Module und Schichten mit einfachen, abstrahierten Schnittstellen zwischen ihnen, und deshalb sind wir es haben so wenig Erfolg bei der Simulation unserer eigenen Intelligenz gehabt.)


1
Vielen Dank. Das Beispiel der Speicherbereinigung / Speicherverwaltung ist wahrscheinlich das bekannteste Beispiel für diese Interaktion. Neil Gershenfeld hat einige interessante Sachen geschrieben, obwohl ich nur Teile davon verstehe.
RParadox

... Sehr guter Punkt über die Komplexität. Wenn nur Maschinen unsere Maschinen konstruieren können, wohin führt das? Wenn KI-Leute über KIs sprechen, die intelligentere KIs erstellen, sind wir vielleicht fast da. ;)
RParadox
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.