Speicher granuliert; Vorschläge für Optimierungen?

[Krishty]

Hi,

Ich habe meinen dynamisch allokierten Speicher eben „granuliert“, d.h. jeder Speicherblock liegt nicht nur an einer an 16 Bytes ausgerichteten Adresse, sondern ist in der Größe auch ein glattes Vielfaches von 16 Bytes. Das macht ein paar Optimierungen bedeutend einfacher.

Was ich jetzt schon angepeilt habe ist:

• memcpy() rausschmeißen – alle Kopien von Speicher zu Speicher werden in 16-Byte-Schritten vollzogen
• vor Reallokationen prüfen, ob überhaupt eine 16-Byte-Grenze überschritten wurde, und in falls nicht, auch nichts reallokieren
• strcpy() rausschmeißen – alle Strings werden in 16-Byte- statt in 1-Byte-Schritten vollzogen
• strlen() rausschmeißen – wird ebenfalls in 16-Byte-Schritten vollzogen

Kommen euch sonst noch Ideen, was sich jetzt an Implementierungen von Strings, Arrays und Speicherverwaltung allgemein optimieren ließe?

Gruß, Ky

[eXile]

memcpy() rausschmeißen – alle Kopien von Speicher zu Speicher werden in 16-Byte-Schritten vollzogen

Wie kommst du darauf, dass das standardmäßige memcpy nicht in 16-Byte-Schritten vorginge? Öffne mal deine memcpy.asm und suche nach "SSE2". ;)

Kommen euch sonst noch Ideen, was sich jetzt an Implementierungen von Strings, Arrays und Speicherverwaltung allgemein optimieren ließe?

Naja, ganz generell würde ich meinen, dass Speicherpools schon etwas mehr bringen können.

[Krishty]

memcpy() rausschmeißen – alle Kopien von Speicher zu Speicher werden in 16-Byte-Schritten vollzogen

Wie kommst du darauf, dass das standardmäßige memcpy nicht in 16-Byte-Schritten vorginge? Öffne mal deine memcpy.asm und suche nach "SSE2". ;)

memcpy() ist ein Intrinsic und wird von dem Compiler oft geinlinet. Er kommt aber von allein nicht darauf, dass alle Blöcke an 16 Bytes ausgerichtet und ein glattes Vielfaches sind – darum landet der übrige Text, um nicht ausgerichteten Speicher zu kopieren, auch dauernd darin. Zumindest das wird nun der Vergangenheit angehören. :)

Kommen euch sonst noch Ideen, was sich jetzt an Implementierungen von Strings, Arrays und Speicherverwaltung allgemein optimieren ließe?

Naja, ganz generell würde ich meinen, dass Speicherpools schon etwas mehr bringen können.

Jaa, mit Copy on Write könnte man auch noch was reißen. Das wird dann aber schon aufwändiger als mal eben ein paar Bytes mehr rumzuschieben.

[Sternmull]

Auch wenn das jetzt absolut nicht ist was du lesen willst: Ich würde mir überlegen ob mir das alles überhaupt die Mühe wert ist. Zumindest in meinem Code haben Kopier-Operationen noch nie spürbar Performance gefressen (dafür sorgen in erster Linie Funktionen auf die ich angewiesen bin aber an denen ich nichts ändern kann, ganz viel später kommen zu grob gesetzte Critical Sections und als Spezialfall davon auch Allokationen). Ich wüsste auch nicht wann ich das letzte mal ein strcpy() aufgerufen hätte (Strings werden durch die üblichen Klassen wie std::string und CString verwaltet, und die wissen wie viele Elemente sie haben und können deshalb memcpy() verwenden statt nach jedes mal erneut nach der Null zu suchen). Außerdem sind da die ganzen Standard-Klassen (std::vector etc.) die sich wahrscheinlich ohnehin keine optimierten Kopieroperationen unterschieben lassen.

So viel zu meiner Sicht der Dinge. Aber vielleicht hast du ja wirklich innere Schleifen in denen in Minimalzeit millionenfach Strings umkopiert werden müssen und willst die Optimierung auch nur gezielt dort einsetzen. Ich hab vor einer Weile aus irgend einem Grund mal recherchiert was Memory prefetches bringen. So weit ich mich erinnere hing es stark von der verwendeten Hardware ab ob und wie man den Cache optimal ausnutzten kann. Aber vielleicht ist das ja noch ein Punkt den du noch nicht in betracht gezogen hast.

Aber mal ehrlich: Wenn du ein Kollege von mir wärst, dann würde ich auf dich einreden bis du deine Zeit mit was produktiverem verbringst als mit Mikrooptimierungen von denen ich mir kein spürbares Ergebnis erwarte außer erhöhter Komplexität und erhöhtem Wartungsaufwand :)

[Krishty]

Ich wüsste auch nicht wann ich das letzte mal ein strcpy() aufgerufen hätte (Strings werden durch die üblichen Klassen wie std::string und CString verwaltet, und die wissen wie viele Elemente sie haben und können deshalb memcpy() verwenden statt nach jedes mal erneut nach der Null zu suchen).

Ups, mein Fehler – strcmp() meinte ich!

Außerdem sind da die ganzen Standard-Klassen (std::vector etc.) die sich wahrscheinlich ohnehin keine optimierten Kopieroperationen unterschieben lassen.

Die STL benutze ich schon seit gut einem Jahr nicht mehr; ich habe volle Handlungsfreiheit

Ich hab vor einer Weile aus irgend einem Grund mal recherchiert was Memory prefetches bringen. So weit ich mich erinnere hing es stark von der verwendeten Hardware ab ob und wie man den Cache optimal ausnutzten kann. Aber vielleicht ist das ja noch ein Punkt den du noch nicht in betracht gezogen hast.

Prefetching gehört bei SSE-Optimierungen jawohl zum guten Ton

Aber mal ehrlich: Wenn du ein Kollege von mir wärst, dann wü

LALALALAAAALALALALALALA

Nachtrag: Das hier sieht ja mal lekker aus …

Öffne mal deine memcpy.asm und suche nach "SSE2". ;)

Was da nicht alles zum Vorschein kommt – u.a., dass memcpy() nur ein Plazebo ist, das exakt wie memmove() arbeitet …