3. Multithreading, volatile, Cache usw.

Multithreading, volatile, Cache usw.


  • jenz schrieb:

    Das Lesen aus "fremden" cachelines würde ich "optimitisch" machen, also einfach draufloslesen. wenn die cacheline dann rausgeschmissen wird, dann wird der lesevorgang ab dann ungültig und muss wiederholt werden.

    Und wie bekommt die lesende CPU mit wenn die schreibende CPU gerade was schreibt während die lesende liest?
    Und die lesende dadurch Schrott gelesen hat?

    Also woher weiss die dann dass es Schrott war?

    0
  • J

    hustbaer schrieb:

    jenz schrieb:

    Das Lesen aus "fremden" cachelines würde ich "optimitisch" machen, also einfach draufloslesen. wenn die cacheline dann rausgeschmissen wird, dann wird der lesevorgang ab dann ungültig und muss wiederholt werden.

    Und wie bekommt die lesende CPU mit wenn die schreibende CPU gerade was schreibt während die lesende liest?
    Und die lesende dadurch Schrott gelesen hat?

    Also woher weiss die dann dass es Schrott war?

    Weil sich die "ID" der Line geändert hat.
    Dafür reicht dann auch ein Bit.

    0

  • Naja die ID könnte aber zufällig noch gepasst haben - kann ja alles mögliche rauskommen, auch was was teilweise stimmt.
    Der Leser müsste schon 2x lesen oder so, um zu checken dass da was nicht passt.

    OK, irgendwie liesse sich das vielleicht noch hinbiegen, aber einfach stell ich es mir nicht vor.

    0
  • J

    hustbaer schrieb:

    Naja die ID könnte aber zufällig noch gepasst haben - kann ja alles mögliche rauskommen, auch was was teilweise stimmt.
    Der Leser müsste schon 2x lesen oder so, um zu checken dass da was nicht passt.

    OK, irgendwie liesse sich das vielleicht noch hinbiegen, aber einfach stell ich es mir nicht vor.

    Er bräuchte nur das eine Bit zweimal lesen, einmal bevor er liest und einmal wenn er fertig ist. Das ergebniss wäre dann ein Cachemiss, also auch ganz "normal".

    Das Bit bräuchte auch immer nur zwischen 1 und 0 wechseln. Dabei gehe ich davon aus, dass das ersetzen einer Line wesentlich länger dauert als das Lesen eines Wertes.

    Also Ablauf:
    - line suchen
    -> möglicher cachemiss wenn nicht gefunden
    - line gültig?
    -> möglicher cachemiss wenn nicht ungültig
    - line bit speichern
    - wert aus line auslesen
    - line bit mit gespeichertem vergleichen
    -> möglicher cachemiss, wenn bit wert gewechselt hat.
    und das hier muss vielleicht auch noch mal gemacht werden:
    - line gültig?
    -> möglicher cachemiss wenn nicht ungültig

    0
  • S

    jenz schrieb:

    Er bräuchte nur das eine Bit zweimal lesen, einmal bevor er liest und einmal wenn er fertig ist. Das ergebniss wäre dann ein Cachemiss, also auch ganz "normal".

    Und was wenn während dem lesen 2 schreib-operationen waren? das bit sich also 2 mal geändert hat und beim 2. lesen wieder auf dem ursprungswert steht?

    0
  • J

    Shade Of Mine schrieb:

    jenz schrieb:

    Er bräuchte nur das eine Bit zweimal lesen, einmal bevor er liest und einmal wenn er fertig ist. Das ergebniss wäre dann ein Cachemiss, also auch ganz "normal".

    Und was wenn während dem lesen 2 schreib-operationen waren? das bit sich also 2 mal geändert hat und beim 2. lesen wieder auf dem ursprungswert steht?

    Ja, stimmt. Ich bin einfach mal davon ausgegangen, dass Lesen schneller ist als Schreiben.

    Wenn das falsch ist, dann hilft vielleicht nur ein (2-Bit?)-Counter

    0
  • J

    Hier hats mal jemand simuliert.

    ogun.stanford.edu/publications/ISCA96.pdf

    Der gemeinsame L1 Cache ist nicht genau so implementiert, wie ich mir das vorgestellt habe, aber es ist ein gemeinsamer L1 Cache.

    Scheint auch ganz gut abzuschneiden.
    Aber es wird auch gesagt, dass die auch ein paar ungenauigkeiten haben.

    0
  • K

    Ich habe beim Ueberfliegen keine MHz-Angabe gefunden. Ich denke bei 3 Ghz sieht die Sache anders aus. Mit sequenzieller Logik kann man keinen Blumentopf gewinnen. Aber hey, schaffen wir einfach Loesungen und suchen uns dann das Problem, so prinzipiell.

    0
  • C
    Mod

    Hat das jetzt eigentlich noch irgendwas mit C++ zu tun?

    0

  • @camper:
    Nö 🙂

    @jenz:

    jenz schrieb:

    Hier hats mal jemand simuliert.

    ogun.stanford.edu/publications/ISCA96.pdf
    (...)

    Dir ist schon aufgefallen dass das Paper ca. 15 Jahre alt ist. Also aus einer Zeit stammt wo das Internet noch aus Holz war, und CPUs mit Dampf betrieben wurden.

    0
  • J

    Shade Of Mine schrieb:

    jenz schrieb:

    Er bräuchte nur das eine Bit zweimal lesen, einmal bevor er liest und einmal wenn er fertig ist. Das ergebniss wäre dann ein Cachemiss, also auch ganz "normal".

    Und was wenn während dem lesen 2 schreib-operationen waren? das bit sich also 2 mal geändert hat und beim 2. lesen wieder auf dem ursprungswert steht?

    oh, ich glaube, du gehst von dem schreiben eines wertes aus.
    das muss natürlich ganz normal zwischen den prozessen synchronisiert werden.

    0
  • J

    hustbaer schrieb:

    @camper:
    Nö 🙂

    @jenz:

    jenz schrieb:

    Hier hats mal jemand simuliert.

    ogun.stanford.edu/publications/ISCA96.pdf
    (...)

    Dir ist schon aufgefallen dass das Paper ca. 15 Jahre alt ist. Also aus einer Zeit stammt wo das Internet noch aus Holz war, und CPUs mit Dampf betrieben wurden.

    oh, habe ich glatt übersehen.

    naja, habe noch ein bisschen gelesen, scheint auf lauftzeiten und "verdrahtung" hinauszulaufen, warum man die L1 caches trennt.

    0
  • O

    jenz schrieb:

    naja, habe noch ein bisschen gelesen, scheint auf lauftzeiten und "verdrahtung" hinauszulaufen, warum man die L1 caches trennt.

    Ach!

    0
  • J

    otze schrieb:

    jenz schrieb:

    naja, habe noch ein bisschen gelesen, scheint auf lauftzeiten und "verdrahtung" hinauszulaufen, warum man die L1 caches trennt.

    Ach!

    haste vorher gewusst, was?

    0
  • K

    self quote 4tw:

    knivil schrieb:

    Klar wird der Cache immer dicker, wenn er mehr Leitungen hat, aber das ist doch kein prinzipielles Problem.

    Doch!

    0
  • E

    Da es hier vorhin um langsame Mutex ging:
    Ein Mutex ist also langsam weil die Chaches meherer CPUs synchronisiert werden müssen.

    Ich habe folgenden Fall: Ich habe eine Datenstruktur, die EVENTUELL mal von mehreren Threads bearbeitet wird. Zur Zeit aber nur einer. Da ich die passende Infrastruktur möchte, wurde alles mit Locks ausgestattet.
    Bremsen die Locks jetzt den Thread auch so stark aus, wenn er eigentlich allein auf den Daten operiert?

    0

  • Ethon schrieb:

    Ein Mutex ist also langsam weil die Chaches meherer CPUs synchronisiert werden müssen.

    Ja, wobei es bei vielen CPUs nicht der Abgleich der "Nutzdaten" ist der bremst, sondern der CAS Befehl (Compare-and-Swap aka. InterlockedCompareExchange) der zum "Locken" der Mutex nötig ist.

    Ich habe folgenden Fall: Ich habe eine Datenstruktur, die EVENTUELL mal von mehreren Threads bearbeitet wird. Zur Zeit aber nur einer. Da ich die passende Infrastruktur möchte, wurde alles mit Locks ausgestattet.
    Bremsen die Locks jetzt den Thread auch so stark aus, wenn er eigentlich allein auf den Daten operiert?

    Es bremst auch wenn nur ein Thread zugreift. Mit einigen (allen?) CPUs bremst es aber weniger schlimm, als wenn wirklich zwei Threads abwechselnd zugreifen.

    0
Anmelden zum Antworten