Vorteile memcmp memcpy

Kai schrieb:
> Wenn man diese Funktionen nicht verwenden würde,
> bräuchte man auch die libs nicht zu inkludieren

Guck dir mal an, wie die bei Microsoft und Intel aufgebaut sind

https://github.com/dotnet/coreclr/blob/master/src/vm/arm/memcpy.asm

https://github.com/intel/intel-ipsec-mb/blob/master/include/memcpy.asm

und dann überlege, ob dein Compiler aus

https://github.com/gcc-mirror/gcc/blob/master/libgcc/memcpy.c

dasselbe macht.
Und dann überlege, warum Intel und Microsoft so einen Aufwand treiben.

Kai schrieb:
> Lohnt es sich diese
> Funktionen zu benutzen?
Na klar, warum sollte es sich nicht lohnen. Die Funktionen stehen nicht 
umsonst in den Standardlibs eines jeden C-Compilers drin. ;)
Kai schrieb:
> Quasi könnte man das auch alles mit einer
> for-loop machen.

Dann schau doch mal in memcpy und memcmp rein ;)

Kai schrieb:
> Wenn man diese Funktionen nicht verwenden würde,
> bräuchte man auch die libs nicht zu inkludieren (es sei denn man
> verwendet andere Funktionen aus dieser lib),was Platz sparen würde.

Das kommt auf deine Lösung an, das kann man nicht pauschal sagen, dass 
eigene Funktionen Platz sparen ;)

Kai schrieb:

> wie viel vorteilhafter sind die Funktionen memcpy und memcmp in c?

Die Frage ist unvollständig. Wieviel vorteilhafter im Vergleich womit? 
Und welche Eigenschaften des Programms betrachtest du, um einen Vorteil 
zu erkennen? Ausführungsgeschwindigkeit? Codegröße? Korrektheit?

> Wenn
> ich z. B. einen array mit 128 Einträgen habe. Lohnt es sich diese
> Funktionen zu benutzen?

Probiere es halt aus.

> Wenn man diese Funktionen nicht verwenden würde,
> bräuchte man auch die libs nicht zu inkludieren

Libs werden nicht includiert. Hederfiles werden includiert. Libs werden 
(dazu) gelinkt. Und es gibt kein Geld zurück, wenn man Libraryfunktionen 
nicht verwendet. Genauso wie es auch kein Geld zurück gibt für 
ungenutzten Flashspeicher.

Funktionen aus der Standardbibliothek sind meist hochoptimiert, nicht 
selten sind wesentliche Teile in Assembler formuliert. In den meisten 
Fällen sind diese Funktionen daher schneller und oft auch kleiner als 
eine händisch hingeschriebene Lösch- oder Kopierschleife.

Die vier Funktionen memcmp, memcpy, memmove und memset sind im 
Zusammenhang mit gcc speziell. Der Compiler darf jederzeit Aufrufe zu 
diesen Funktionen generieren - auch ohne libc - und tut das, wenn 
möglich auch.

Deine for-Schleife könnte also vom Compiler durch ein memcpy/memmove 
ersetzt werden.

S. R. schrieb:
> Die vier Funktionen … mit gcc speziell.

Nein.  Nicht nur diese, und nicht nur mit GCC.

Alle Funktionen der Standardbibliothek sind „speziell“ und dürfen in 
einem hosted environment vom Compiler so implementiert werden, dass er 
implizites Wissen darüber besitzt, was sie tun.

Das ist eine gute Sache, denn ich kann beispielsweise schreiben:

1

#define MSG "foobar"

2

3

// …

4

5

   memcpy(target, MSG, strlen(MSG));

… und der Compiler kann implizit auf eine ihm genehme Weise die 6 
Zeichen des Strings "foobar" an die Zieladresse übertragen. Insbesondere 
ist er nicht verpflichtet, für das strlen() irgendwie erst einen 
Funktionsaufruf zu generieren, denn es ist völlig klar, dass dieser 
immer eine 6 ergeben würde.

Auch ein memcpy() eines einzelnen Zeichens wird wohl so ziemlich jeder 
Compiler auf diese Weise inline auflösen können, ohne erst irgendwelche 
Funktionen zu bemühen. Schließlich und endlich könnte das System aus 
Compiler und Bibliothek ("the implementation") auch Sonderfälle haben, 
bei denen dem Compiler bekannt ist, dass unter bestimmten Umständen 
Dinge optimierbar sind, die nicht direkt aus dem Quelltext ersichtlich 
sind (bspw. Kopien in kompletten 32- oder 64-Bit-Einheiten durchführbar, 
wenn die Adressen passend ausgerichtet sind).

Kai schrieb:
> Quasi könnte man das auch alles mit einer for-loop machen.

Das wäre dann die worst-case-Implementierung. Eine solche primitive 
Implementierung wird wohl jede Standardbibliothek allemal vorhalten 
können, in der Regel aber (wie bereits geschrieben worden ist) wird sie 
sehr wahrscheinlich eine bessere Implementierung anbieten können.

Aber dein Grund-Missverständnis war ja offensichtlich ohnehin, dass das 
"Inkludieren" (also Linken) einer Bibliothek in irgendeiner Form da 
gleich alles reinziehen würde, was sonst noch in der Bibliothek 
vorhanden ist. Dem ist natürlich nicht so.

keinerniemand schrieb:
> eine for-loop bei deinen 128 Bytes noch schneller sein sollte, eventuell
> wegen overheads oder so

Das hängt natürlich ganz entscheidend davon ab:

* welchen Prozessor du überhaupt benutzt
* wie "intelligent" der Compiler ist

Wie ich schon schrieb, ist es durchaus möglich, dass ein Compiler auch 
solche Effekte "kennt" und berücksichtigen kann, d.h. einen 
Funktionsaufruf nur dann generiert, wenn ihm klar ist, dass der einen 
Vorteil bringt.

Pauschal kann man daher gar nichts sagen. Sowas im Einzelfall auf paar 
Mikrosekungen mit der Hand zu "optimieren" riskiert stets, dass es mit 
der nächsten Compilerversion wieder zerbricht, weil dort alles ganz 
anders umgesetzt wird.

memcpy kopiert IMHO Byteweise. Mit einer for-Schleife könnte man 4Byte 
Integer kopieren, was zumindest bei einer 32 Bit Architektur schneller 
sein sollte.

Grüsse

Dr. Sommer schrieb:
> Es könnte z.B. automatisch erkennen wenn
> die Adressen 4-Byte-Aligned sind

könnte ist jetzt aber auch Konjunktiv! Weiß wer was genaueres?

Grüsse

A. S. schrieb:

>> Nein.  Nicht nur diese, und nicht nur mit GCC.
>
> Die Aussage von S.R. war ein andere, nämlich: Der GCC darf, wenn er den
> Code des TO sieht, memcpy aufrufen obwohl der TO es nirgends nutzt.

Wobei ich das noch nirgends in freier Wildbahn erlebt habe.

> Bei Komplexen
> Funktionen (z.b. printf) geht das allerdings nicht immer, so dass es
> hier manchmal extra Compiler (Linker)-Schalter gibt, mit denen man z.B.
> Floating-Point Unterstützung AN oder AUSschalten kann.

Das liegt schlicht und ergreifend nicht daran, dass printf per se 
"komplex" ist, sondern dass es erst zur Laufzeit anhand seiner 
Format-Strings entscheidet, welche Umwandlungen wirklich erfolgen 
müssen. Daher müssen sie als Bibliothekscode erst einmal alle verfügbar 
sein. Für (zur Compileizeit) konstante Format-Strings könnte man sich 
noch vorstellen, dass das System aus Compiler, Linker und Bibliothek da 
irgendwelche Analysen und Entscheidungen durchführt, aber Format-Strings 
lassen sich natürlich auch prinzipiell erst zur Laufzeit 
zusammenbasteln.

Jörg W. schrieb:
>>> Nein.  Nicht nur diese, und nicht nur mit GCC.
>> Die Aussage von S.R. war ein andere, nämlich: Der GCC darf, wenn er den
>> Code des TO sieht, memcpy aufrufen obwohl der TO es nirgends nutzt.
> Wobei ich das noch nirgends in freier Wildbahn erlebt habe.

Steht in der Manpage:
https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Link-Options.html
dort unter z.B. -nostdlib oder -nodefaultlibs:
"The compiler may generate calls to memcmp, memset, memcpy and memmove."

Wenn man größere Strukturen kopiert und auf Codegröße optimiert, dann 
sieht man das auch in freier Wildbahn.

Wird dann interessant, wenn man memcpy implementieren möchte:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888

S. R. schrieb:
> Wenn man größere Strukturen kopiert

Ja, gut, dafür kann ich mir es in der Tat vorstellen.

Gebhard R. schrieb:
> memcpy kopiert IMHO Byteweise.

Nur wenn der Programmierer zu faul war, es besser zu machen.

Gebhard R. schrieb:
>> Es könnte z.B. automatisch erkennen wenn
>> die Adressen 4-Byte-Aligned sind
>
> könnte ist jetzt aber auch Konjunktiv! Weiß wer was genaueres?

Entscheidend ist nur, was hinten rauskommt. Es gibt klar definierte 
Randbedingungen, innerhalb derer die Implementierung von memcpy tun 
darf, was sie will. Viel genauer wirds nicht.

Berücksichtigung von Alignment ist ein uralter Hut.

Der Microcode von Intel/AMD x86 optimiert Befehle wie REP MOVS ebenfalls 
abhängig von Alignment, Anzahl Interationen und wassweissich. Da dürften 
dann auch die Caches Berücksichtigung finden.

x^y schrieb:
> GCC Library Funktionen sind heute mehr auf Geschwindigkeit wie Größe
> ausgelegt.

Kannst du so pauschal nicht sagen, denn es gibt nicht allgemein „GCC 
Library Funktionen“. Die Standardbibliothek wird nicht vom GCC-Team 
selbst gepflegt, sondern es gibt sehr verschiedene Implementierungen 
dafür: glibc, BSD libc, newlib (teils BSD, teils aus anderen Quellen 
zusammengekramt), avr-libc, …

> Wir tun dies, wobei diese Implementierungen
> zusätzlich NULL Pointer-Safe sind und mit überlappenden
> Speicherbereichen generell korrekt funktionieren. Dies ist btw. der
> subtile Unterschied zwischen Standard memcpy() und memmove().

Eben. Daher halte ich es für unsinnig, auch memcpy() wie memmove() zu 
implementieren, denn das verhindert Optimierungen. Das ist ja auch der 
einzige Grund, warum es überhaupt für praktisch die gleiche Aufgabe im 
Standard zwei verschiedene Funktionen gibt.

Auch NULL-Pointer-safe finde ich Quatsch, es hilft höchstens, Bugs zu 
kaschieren statt sie zu entdecken.

x^y schrieb:
> Fiktives Beispiel

Kompiliert nicht, taugt eh nicht.

memcmp fehlt die Länge, und strcmp wäre passender, und schon lange gibt 
es lstrcmp

A. K. schrieb:
> Gebhard R. schrieb:
>>> Es könnte z.B. automatisch erkennen wenn
>>> die Adressen 4-Byte-Aligned sind
>>
>> könnte ist jetzt aber auch Konjunktiv! Weiß wer was genaueres?
>
> Entscheidend ist nur, was hinten rauskommt. Es gibt klar definierte
> Randbedingungen, innerhalb derer die Implementierung von memcpy tun
> darf, was sie will. Viel genauer wirds nicht.
>
> Berücksichtigung von Alignment ist ein uralter Hut.
>
> Der Microcode von Intel/AMD x86 optimiert Befehle wie REP MOVS ebenfalls
> abhängig von Alignment, Anzahl Interationen und wassweissich. Da dürften
> dann auch die Caches Berücksichtigung finden.

memcpy() ist wichtig. Da wird sich wohl jede C-Implementierung bemühen, 
das möglichst effizient zu machen. Und wenn es auf Alignment ankommt, 
wird die Implementierung das berücksichtigen.
Das gilt auch für andere oft verwendete Bibliotheksfuntionen wie 
memcmp(), memset(), strchr(), strcpy(), strncpy(), etc.

Philipp

x^y schrieb:
> Jemand schrieb:
>> Anstatt Bugs/Pfusch zu verstecken, könnte (sollte!) man das Programm
>> hier einfach kontrolliert abstürzen lassen.
>
> Und wie genau willst du das sicherstellen?

Indem Zugriff auf einen Nullpointer halt eine Exception wirft.

Aber wir sind jetzt schon ziemlich weit weg vom Ursprungsthema. :)

Michael B. schrieb:
> und dann überlege, ob dein Compiler aus
>
> https://github.com/gcc-mirror/gcc/blob/master/libgcc/memcpy.c
>
> dasselbe macht.

Dann aber bitte nicht Äpfel mit Birnen vergleichen; hier zum Beispiel 
Implementierungen der Newlib

Armv7a (ca 500 Zeilen Assembler):
http://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/machine/arm/memcpy-armv7a.S;h=cd7962e075a30cb90ec073d77b177c3536429b9b;hb=HEAD

x86_64:
http://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/machine/x86_64/memcpy.S;h=81dd0c4235001521a16af5dbfbdebbcec5f85daa;hb=HEAD

Die Public Domain Immplementierung beim GCC dient i.W. um in der 
Entwicklungsphase ein memcpy in der libgcc zu haben, um den Compiler 
(besser) testen zu können, da GCC memcmp / memset erzeugen kann, auch 
wenn dies nicht explizit in der Quelle steht.

In der endgültigen Toolchain wird man in der libc eine auf die Maschine 
optimierte Version haben (wollen), wie in avr-libc oder den obigen 
Beispielen aus der Newlib.