effiziente Initialisirung mit Nullen

Joachim Drechsel schrieb:
> Hängt vom Rechenknecht ab. x86 kann das (glaube ich).

da eine CPU nicht mal arrays kennt, denke ich nicht das es dafür befehle 
gibt. Es wird maximal eine möglichkeit haben einen Speicherbereich mit 0 
zu überschreiben, aber auch das muss vom Programieren umgesetzt werden.

Joachim Drechsel schrieb:
> Die x86er haben so etwas wie "Stringbefehle". Ob da ein
> hardcodiertes memset dabei ist weiß ich jetzt gerade nicht.

ja aber diesen Befehl muss man expliziert für einen Speicherbereich 
ausführen. die CPU kennt keine Variablen. Sie kann also auch nicht 
wissen wann eine Array angelegt wird.

Such nach
memset efficiency
mit google. Ja, es geht "effizienter". Die CPU muss nicht wissen, ob das 
ein Array o.ae. ist. Der Compiler ist an dieser Steller gefragt.

avion23 schrieb:
> Der Compiler ist an dieser Steller gefragt.

ich würde denke hier ist mehr der Entwickler der glibc gefragt. Er muss 
dann memset anders implemtieren. Die Stringbefehle der CPU werden kaum 
von einem compiler umgesetzt.

Jörg Wunsch schrieb:
> AVR-GCC beispiels-
> weise expandiert memset() inline:

optimiert er den code oder "kennt" er memset und setzt es anders um? Ich 
hätte jetzt gedacht das es in der libc einfach als asm umgesetzt ist.

Jörg Wunsch schrieb:
> Was soll das "oder"?

es könnte ja sein das er die funktion erkennt das ein speicherberich 
genullt werden soll und dieses mit hilfe der STringfunktionen umsetzt.

for( ... ) {
  x[y] = 0;
}


oder er weiss was memset macht und ersetzt es durch eine eigene 
implementierung. Was aber nicht mehr geht wenn ich mir die memset 
funtion umbenenne.

Rolf Magnus schrieb:
>> Die Stringbefehle der CPU werden kaum von einem compiler umgesetzt.
> Warum sollten sie nicht?

ich hatte mal gelesen das sie zu "kompliziert" für dien Compiler sind. 
Sie sollen auch nicht wirklich geschwindigkeitsvorteile bringen. Die 
Befehle waren zu einer Zeit eingaut wurden wo man noch von Hand 
optimiert hat.

Und wenn gcc hier diese befehle bei memeset verwendet, dann vermute ich 
ganz stark das jemand dieses expliziert von hand codiert hat. Der 
normale Optimizer wird also nicht auf die Idee kommen diese befehle zu 
verwenden. Sonst hätte er es auch bei einer schleife gemacht.

Jörg Wunsch schrieb:

> Oder was
> dachtest du, wie der Compiler seinen Code generiert?
es ist doch wohl ein unterschied ob man eine complete funktion in ASM 
codiert wird (von hand) oder ob der optimierer anhand des C codes 
erkennen soll was gemeint ist und damit selber auf die Idee kommt die 
string befehle zu verwenden.

>> Der
>> normale Optimizer wird also nicht auf die Idee kommen diese befehle zu
>> verwenden.
> Deine Vorstellungen über die Art und Weise, wie ein Compiler optimiert,
> dürften aus dem letzten Viertel des vorherigen Jahrhunderts stammen.

du könntest mich davon überzeugen das es nicht stimmt, in dem du mir mal 
code zeigst wo der compiler die string-upcodes verwendet.

Jörg Wunsch schrieb:
> Peter II schrieb:
>> du könntest mich davon überzeugen das es nicht stimmt, in dem du mir mal
>> code zeigst wo der compiler die string-upcodes verwendet.
>
> Dazu müsstest du dir schon mal den Compiler-Sourcecode selbst
> auspacken und in der Datei i386.md nach beispielsweise stosq
> suchen.

ich meinte zwar eine beispiel C datei wo mit hilfe des compilers am ende 
ein stosq verwendet wird.
Das der compiler grunsätzlich den upcode kennt, ist ja noch kein hinweis 
darauf das er ihn auch in der praxis irgenwie verwendet. Außer man 
schreibt gleich ASM code.

Werde mir aber mal die quellen saugen.

Peter II schrieb:
> upcode

Mach dich erstmal schlau, wie man Opcode überhaupt schreibt. Mist, 
jetzt hab ich es verraten...

@Jörg Wunsch

danke für die Mühe. Ist das etwas neu in

GCC: (GNU) 4.8.0 20120530 (experimental)

?. Weil mit GCC 4.6 scheint es ja nicht zu passieren

> Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
> Datum: 05.07.2012 15:32
>
> (Gerade probiert, eine explizite Schleife optimiert er auch mit
> GCC 4.6 nicht, nur memset()).

oder liegt das am experimental?

es scheint zumindest noch nicht lange so zu sein. Mein 4.6 macht es 
nicht-

        .file   "test.c"
        .text
        .p2align 4,,15
        .globl  init_array
        .type   init_array, @function
init_array:
.LFB12:
        .cfi_startproc
        movl    $array, %eax
        .p2align 4,,7
        .p2align 3
.L2:
        movl    $0, (%eax)
        addl    $4, %eax
        cmpl    $array+256, %eax
        jne     .L2
        rep
        ret
        .cfi_endproc
.LFE12:
        .size   init_array, .-init_array
        .comm   array,256,32
        .ident  "GCC: (Debian 4.6.3-1) 4.6.3"
        .section        .note.GNU-stack,"",@progbits

Jörg Wunsch schrieb:
> Aber du siehst, dass er auch jeweils 4 Bytes zu einem Schreibzugriff
> zusammenfasst.

ja das ist auch gut so. Mir ging es aber extra um die String Opcodes. Da 
hatte ich mal gelesen das sie vom compiler nicht genutzt werden. Dies 
schein bis jetzt auch so zu sein.

.ident  "GCC: (Debian 4.7.1-2) 4.7.1"

macht es auch nicht. Etweder ist das ganze experimental oder es ist nach 
20Jahren wirklich mal einer auf die Idee gekommen es umzusetzen.

MS macht es sich einfach:

_init_array PROC
; File c:\test.c
; Line 10
  push  256          ; 00000100H
  push  0
  push  OFFSET _array
  call  _memset
  add  esp, 12          ; 0000000cH
; Line 11
  ret  0
_init_array ENDP
_TEXT  ENDS
END

Wenn bei Intel genau nachliest, dann findet man, daß es verschiede Arten 
von Opcodes gibt. Manche laufen optimal durch die Pipelines, andere, wie 
z.B. die Repeated Stringbefehle, passen nicht auf jeder CPU dazu und 
laufen dann effektiv langsamer als äquivalente Sequenzen "flinker" 
Befehle. Durchsatz und Latenz sind die Stichworte.