was ist gute cache hit rate?



  • Kommt drauf an was dein Programm machen soll...

    hmm...es führt mathematische operationen auf matrizen aus. also 1 großer algorithmus sozusagen.


  • Mod

    Das ist wie zu Fragen, ab wie vielen Staubkörnern pro m² etwas "sauber" wäre. Kommt halt drauf an. So lange es nicht 0 ist, kann man da vortrefflich drüber streiten.

    Die meisten Leute würden deine Werte aber wohl als ziemlich gut ansehen. Falls du Performanceprobleme hast, liegen sie höchstwahrscheinlich nicht an Cache-Misses. Außer natürlich, du hast 125 M Durchläufe der inneren Schleife gemacht und die restlichen 25 G Fetches sind bloß drumherum in deinem Testprogramm. Was ein komisches Testprogramm wäre, aber ganz ohne Kontext kann man das natürlich nicht ausschließen.



  • SeppJ schrieb:

    Das ist wie zu Fragen, ab wie vielen Staubkörnern pro m² etwas "sauber" wäre. Kommt halt drauf an. So lange es nicht 0 ist, kann man da vortrefflich drüber streiten.

    Ab 16 kann man von einem Saustall sprechen.



  • SeppJ schrieb:

    Staubkörnern

    Geht das noch ungenauer? Um die ISO-Bedingungen eines Reinraums zu erfüllen muss genau festgelegt werden, wie viele Staubkörner welcher Grösse auftreten. Dann kann man sich nämlich nicht mehr darüber streiten sondern im entsprechenden ISO-Standard nachschlagen.

    Die valgrind-Werte sehen ganz gut aus, sie zu optimieren könnte nochmal bis zu 5% Speedup bringen, kannst selbst entscheiden, ob es das Wert ist.



  • ISO 14644-1 schrieb:

    Die valgrind-Werte sehen ganz gut aus, sie zu optimieren könnte nochmal bis zu 5% Speedup bringen, kannst selbst entscheiden, ob es das Wert ist.

    An was siehst Du das mit den "5%"? Aus meiner Sicht ist die einzige Frage, für was das Programm viel Zeit benötigt. Unter Umständen kann da auch eine sehr niedrige Cache-Miss Rate noch sehr relevant sein. Es kann aber genausogut sein, dass eine hohe Rate irrelevant ist.

    DISCLAMER: Das sind nur naive Annahmen. Ich kenne mich da nicht im Detail aus. Vielleicht übersehe ich etwas.



  • Gregor schrieb:

    An was siehst Du das mit den "5%"?

    Reine Überschlagsschätzung.

    Ich habe mal angenommen, dass das Programm Memory-Bound ist.

    0.5%-D1 Missrate machen total 5% unnötige Read-Zyklen, was 5% Performance sein kann. Oder auch nicht, wenn das Programm CPU-bound ist.



  • Ich habe mal angenommen, dass das Programm Memory-Bound ist.

    was genau heisst memory-bound?



  • XY-Bound heisst, dass der Flaschenhals XY ist.

    Es gibt Programme, die sind IO-bound. Zum Beispiel ein Programm, das über eine langsame Verbindung oder der Festplatte Daten holt und verarbeitet (z.B. Remote-Access, Online-Spiele, grep). Da ist die CPU kein Problem und Memory auch nicht, sondern Input/Output. Das Programm kann man nur schneller machen, wenn man den IO-Teil optimiert, die CPU-Auslastung zu vermindern bringt gar nichts.

    Manche Programme sind CPU-bound, die CPU wird immer voll ausgelastet (Video rendering). Das einzige, was sich da lohnt ist, den Assemblercode zu optimieren.

    Und viele Programme sind Memory-bound, d.h. die CPU ist nur am warten darauf, bis der nächste Speichereintrag gezogen wurde. Dann bringt auch optimieren des Codes nichts, weil dann wartet die CPU nur noch mehr. Hier hilft Datenstrukturen kompakt halten.

    Da wird auch zwischen den drei unterschieden, nur mal so um zu zeigen, dass ich diese Unterscheidung wirklich relevant ist: https://wiki.apache.org/spamassassin/FasterPerformance

    Es lässt sich schon grob sagen, dass wenn Memory der Flaschenhals ist, dann ist Memory optimieren das einzige, was etwas bringt oder wenn es die CPU ist, dann bringt Memory optimieren nichts. Dazwischen gibt es auch Graustufen, so kann ein Teil Memory-bound sein und ein anderer CPU-bound. Dafür kannst du mal mit Cachegrind schauen, wie sich die Cachemisses auf deine Codezeilen verteilen.



  • ISO 14644-1 schrieb:

    SeppJ schrieb:

    Staubkörnern

    Geht das noch ungenauer? Um die ISO-Bedingungen eines Reinraums zu erfüllen muss genau festgelegt werden, wie viele Staubkörner welcher Grösse auftreten. Dann kann man sich nämlich nicht mehr darüber streiten sondern im entsprechenden ISO-Standard nachschlagen.

    Die valgrind-Werte sehen ganz gut aus, sie zu optimieren könnte nochmal bis zu 5% Speedup bringen, kannst selbst entscheiden, ob es das Wert ist.

    Es kommt darauf an, ob man über einen "Reinraum" spricht. Ein Wohnraum, welches als sauber angesehen wird, hat mit Sicherheit mehr Staubkörner als der schlechteste standardisierte Reinraum. Und dennoch ist das Zimmer sauber. Eine Holzwerkstatt kann ich schrubben wie ich will und wird sicher immer mehr Staubkörner enthalten, als ein normales Zimmer. Wenn ein Wohnzimmer so viele Staubkörner enthält, wie die sauberste Holzwerkstatt, dann ist das Wohnzimmer sehr staubig.

    Also zusammenfassend, um zum Thema zu kommen: es kommt darauf an. Ich denke, die Messungen mit cachegrind und so bringen nur im Vergleich was. Wenn ich mein Programm umstelle, dann kann ich messen, ob das was gebracht hat. Aber man kann die cache-hit-rate eines Webservers nicht mit der eines Textverarbeitungsprogrammes vergleichen. Daher kann man einfach nicht pauschal sagen, ab soundso viel Prozent ist das gut oder schlecht.



  • ISO 14644-1 schrieb:

    Gregor schrieb:

    An was siehst Du das mit den "5%"?

    Reine Überschlagsschätzung.

    Ich habe mal angenommen, dass das Programm Memory-Bound ist.

    0.5%-D1 Missrate machen total 5% unnötige Read-Zyklen, was 5% Performance sein kann. Oder auch nicht, wenn das Programm CPU-bound ist.

    Erklär bitte wie ein Programm mit 0.5% cache miss rate memory bound sein kann.
    Und wie du davon ausgehend auf 5% kommst.


Anmelden zum Antworten