![]() |
GOTOs verhindern das RAM-Cachen - ist das richtig?
Hallo;
mein Informatik-Lehrer hat vor längerer Zeit mal gesagt, dass wir u.a. deshalb keine GOTOs (Programmiersprache egal, aber in unserem Fall geht es um C) verwenden sollen, weil wir dadurch das korrekte Arbeiten des Caches verhindern. Konkret: der Cache ladet immer die Daten aus dem RAM nach, die vorraussichtlich benötigt werden. Durch eine goto-Anweisung springt die Programmausführung woanders hin und alles, was schon geladen wurde, kann der dann "wegschmeißen" und muss neu laden. Ungefähr so hat er es erklärt. Stimmt das? Wenn ja, wieso gibt es dieses Problem bei Schleifen, etc... nicht? Danke; Tubos. |
Re: GOTOs verhindern das RAM-Cachen - ist das richtig?
Halte ich für ein Gerücht, damit man sich sowas garnicht erst angewöhnt. :wink:
Grüsse! |
Re: GOTOs verhindern das RAM-Cachen - ist das richtig?
möglich...wir haben goto gar nicht gelernt *g*
|
Re: GOTOs verhindern das RAM-Cachen - ist das richtig?
ähm. Also ich dachte immer BASIC sei die einzige Hochsprache die einen "GOTO" Befehl hat. Hab ich mich da jetzt mit einer Bildungslücke geoutet?
|
Re: GOTOs verhindern das RAM-Cachen - ist das richtig?
Das ist schon richtig, bezieht sich aber nicht nur auf GOTOs, sondern auf jede Art von Sprüngen, also auch Funktionsaufrufe.
Der Grund ist folgender: Wird eine Anweisung ausgeführt, ist es sehr wahrscheinlich, dass die ncächsten Anweisungen ebenfalls ausgeführt werden. Deshlab werden die in den Cache vorgeladen. Erfolgt jetzt ein Sprung, sind auf einmal nicht die Daten im Cache, die als nächstes gebraucht werden, sondern andere. Das ganze Konzept des Vorladens nennt sich Pipelining und die Löcher nennt man Bubbles. Und Intels "Hyperthreading" (bei AMD gibts das auch, heißt nur anders) führt jetzt Code aus, während die Daten anderswo geladen werden. Zumindest hab ich das so in meinen Rechnerarchitektur-Vorlseungen verstanden ;) |
Re: GOTOs verhindern das RAM-Cachen - ist das richtig?
Zitat:
|
Re: GOTOs verhindern das RAM-Cachen - ist das richtig?
Aber ist es mittlerweile nicht schon soweit, dass moderne CPUs versuchen den zu verarbeitenden Code vorab zu interpretieren und so auch bereits den Sprung erkennen (könnten)? Da ein OP-Code i.d.R. ja je Befehl eine feste Länge hat, liesse sich doch so bereits der potentielle Zielbereich cachen!? :gruebel:
Grüsse! |
Re: GOTOs verhindern das RAM-Cachen - ist das richtig?
@rantanplan99: Ich kann kein Basic, ich weiß nur dass es sowohl in Pascal als auch in C++ einen Befehl namens goto gibt.
Zitat:
das ist ziemlich heftig :angle2: |
Re: GOTOs verhindern das RAM-Cachen - ist das richtig?
Zitat:
Ich hoffe, die heutigen Sprungvorhersagealgorithmen können wie schon angedacht solche Sprungbefehle berücksichtigen und dementsprechend anders cachen. [/edit] Wenn das wirklich stimmen sollte, dann ist ja ein Funktionsaufruf fast so "schlimm" wie ein GOTO :roll: Der einzige Grund, ein goto nicht zu benutzen, ist, dass dabei nicht auf Verschachtelungen (also den Stack) geachtet wird. Wenn du in einer Rekursion bist und mit GOTO plötzlich ausbrichst, dann hast du das Problem, dass die ganzen gepushten Daten der Funktionsaufrufe noch aufm Stack sind während du schon wieder ganz woanders bist. Ich benutze nie GOTOs, weil alle Angst vor GOTOs haben und ich keinem einen GOTO-durchsetzten Code zumuten will. Einen Code mit GOTOs zu schreiben, dürfte auch ein guter "Kopierschutz" sein :) (solange es kein OpenSource ist...) |
Re: GOTOs verhindern das RAM-Cachen - ist das richtig?
Auf Maschinenebene gibt es nur Sprünge, keine Funktionen. Man kann also mit gotos den gleichen Code erzeugen wie mit Funktionen. gotos werden nur geschmäht, weil sie sehr unübersichtlich sind. Funktionen sind abgeschlossene Blöcke, wärehdn Sprungmarken mitten in Blöcken vorkommen und sich eine goto-Sequenz wie Spaghetti durch deinen Code schlängeln kann (daher auch der Name).
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:24 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz