[FBSD] mmap() wesentlich langsamer als read(..., buf, ...
Matthias Andree
>>>Auffallend ist, daß die user-time bei mmap doppelt so hoch ist.
>> Komisch, dass es ausgerechnet bgrep trifft...
>
> Ich habe den Code gepostet.
Den ganzen? Lesbar? Wo? Seh' ich nicht.
> Niemand in dcoup hat darin eine Ursache entdeckt.
> Niemand in dcoup kann sich das Verhalten erklären.
Nein?
Um die Frage endlich mal zu stellen: Warum zur Hölle benutzt Du
eigentlich MAP_PRIVATE und nicht MAP_SHARED zum Lesen? Ist ja schon
irgendwie auffällig, dass das Teil auch bei kleinen Dateien immer
komplett in den Speicher "gesegfaultet" wird und nicht aus dem Cache
bedient wird.
In meinen Beispielbenchmarks war außerdem MADV_SEQUENTIAL nicht gesetzt,
obwohl es sinnvoll gewesen wäre; es war trotzdem reichlich schneller.
>> Möglicherweise kommt sie gar nicht von mmap. Den Nachweis dafür, dass
>> es
>> mmap() ist (z. B. strace -tt), hast Du bislang nicht erbracht.
>
> Ich habe nie gesagt, daß sie *von* mmap kommt, sondern *bei* Verwendung
> von mmap zum Zweck des Datenhereinholens (indirekt) entsteht.
Ja, einen Profiler hast Du trotzdem ebensowenig benutzt wie strace -tt.
Du weigerst Dich, Dein Problem vollständig zu beschreiben, und Du
weigerst Dich, es systematisch zu analysieren, auch fein nachzulesen auf
groups.google.com: immer derselbe Post, praktisch alle Postings
politisch motiviert, Seitenangriffe, Vermutungen, aber keine
Information, was Dein Programm wirklich wie lange tut. Kein strace, kein
truss, kein ktrace/kdump, kein gprof, kein gcov. Keine Reduzierung auf
ein Testmodell, das man komplett posten könnte. Du _willst_ Dein Problem
nicht gelöst haben.
Vom unlesbaren Code in <bk5vr9$1n0$05$1...@news.t-online.com> will ich gar
nicht erst reden, Michael von Elst, Uwe Ohse und Rudolf Polzer haben das
schon getan.
Geh weg, Du verschwendest Zeit, die Du nicht verdient hast.
Damit ist Ende der Durchsage.
--
Matthias Andree
Encrypt your mail: my GnuPG key ID is 0x052E7D95
Helmut Schellong
> Helmut Schellong <sche...@t-online.de> writes:
>
>
>>>>Auffallend ist, daß die user-time bei mmap doppelt so hoch ist.
>>>
>>>Komisch, dass es ausgerechnet bgrep trifft...
>>
>>Ich habe den Code gepostet.
>
>
> Den ganzen? Lesbar? Wo? Seh' ich nicht.
Braucht man denn printf-Ausgaben, Optionssetzen-Code, etc.,
um diese mmap-Erscheinung zu beurteilen?
Ist der Code (~10 Zeilen Algo.) unverstehbar?
>>Niemand in dcoup hat darin eine Ursache entdeckt.
>>Niemand in dcoup kann sich das Verhalten erklären.
>
>
> Nein?
>
> Um die Frage endlich mal zu stellen: Warum zur Hölle benutzt Du
> eigentlich MAP_PRIVATE und nicht MAP_SHARED zum Lesen? Ist ja schon
> irgendwie auffällig, dass das Teil auch bei kleinen Dateien immer
> komplett in den Speicher "gesegfaultet" wird und nicht aus dem Cache
> bedient wird.
>
> In meinen Beispielbenchmarks war außerdem MADV_SEQUENTIAL nicht gesetzt,
> obwohl es sinnvoll gewesen wäre; es war trotzdem reichlich schneller.
Ich habe mehr als einmal mitgeteilt, daß ich ALLES DIESES probiert habe!
Kein Unterschied!
>>>Möglicherweise kommt sie gar nicht von mmap. Den Nachweis dafür, dass
>>>es
>>>mmap() ist (z. B. strace -tt), hast Du bislang nicht erbracht.
>>
>>Ich habe nie gesagt, daß sie *von* mmap kommt, sondern *bei* Verwendung
>>von mmap zum Zweck des Datenhereinholens (indirekt) entsteht.
>
>
> Ja, einen Profiler hast Du trotzdem ebensowenig benutzt wie strace -tt.
>
> Du weigerst Dich, Dein Problem vollständig zu beschreiben, und Du
> weigerst Dich, es systematisch zu analysieren, auch fein nachzulesen auf
> groups.google.com: immer derselbe Post, praktisch alle Postings
> politisch motiviert, Seitenangriffe, Vermutungen, aber keine
> Information, was Dein Programm wirklich wie lange tut. Kein strace, kein
> truss, kein ktrace/kdump, kein gprof, kein gcov. Keine Reduzierung auf
> ein Testmodell, das man komplett posten könnte. Du _willst_ Dein Problem
> nicht gelöst haben.
Rate mal, warum ich das Problem gepostet habe?
Antwort: Ich habe gefragt, ob jemand solche Erscheinungen
*bereits kennt*, eine Erklärung bereits hat.
Wenn ich all die oben aufgeführten Dinge vorgehabt hätte,
hätte ich gar nichts gepostet.
http://www.schellong.com/bgrep
Aber keinen nichtpagealigned Offset (-o|-O) angeben bei -M.
Desweiteren sollte man es für möglich halten, daß ich als
Entwicklungsingenieur arbeiten muß: gestern 14 Stunden,
heute wohl 16 Stunden, bis 4 Uhr durchmachen, weil etwas
wegen eines Symposiums in Budapest plötzlich und dringend
von mir gebraucht wird.
> Vom unlesbaren Code in <bk5vr9$1n0$05$1...@news.t-online.com> will ich gar
> nicht erst reden, Michael von Elst, Uwe Ohse und Rudolf Polzer haben das
> schon getan.
Und Du forderst immer weitere Code-Postings von mir?!
Rate mal, warum ich da so zurückhaltend war und bin?
Antwort: Weil ich im voraus weiß, das der Code kaum/nicht nur im Sinne
des Problems betrachtet wird, sondern auch oder nur im Sinne
von Code-Styling und Geschmackssache.
--
Mit freundlichen Grüßen
Helmut Schellong po...@schellong.de po...@schellong.com
www.schellong.de www.schellong.biz sche...@t-online.de
http://www.schellong.de/c.htm
Matthias Andree
> Ist der Code (~10 Zeilen Algo.) unverstehbar?
So weit gehe ich gar nicht. Er ist nicht lesbar, ich erwarte von so
einem Code, dass er a) auf eine Bildschirmseite passt, b) dass ich ihn
in 30 s verstanden habe.
>> Um die Frage endlich mal zu stellen: Warum zur Hölle benutzt Du
>> eigentlich MAP_PRIVATE und nicht MAP_SHARED zum Lesen? Ist ja schon
>> irgendwie auffällig, dass das Teil auch bei kleinen Dateien immer
>> komplett in den Speicher "gesegfaultet" wird und nicht aus dem Cache
>> bedient wird.
>> In meinen Beispielbenchmarks war außerdem MADV_SEQUENTIAL nicht
>> gesetzt,
>> obwohl es sinnvoll gewesen wäre; es war trotzdem reichlich schneller.
Dein Newsreader ist kaputt. Bitte Kammquoting abstellen.
> Ich habe mehr als einmal mitgeteilt, daß ich ALLES DIESES probiert habe!
> Kein Unterschied!
Warum findet Google dann für 2003 keine Postings von Dir mit MAP_SHARED?
Dein übriges Gejanke über Deine Zeit und fremde Kritik an Deinem
unwartbaren Code lasse ich mal als unsachliches Beiwerk weg. (Mich
wundert bei _solchem_ Code aber nicht, dass Du 16 h am Stück arbeiten
musst, um Deine Arbeit getan zu bekommen.)
Helmut Schellong
> Helmut Schellong <sche...@t-online.de> writes:
>
>
>>Ist der Code (~10 Zeilen Algo.) unverstehbar?
>
>
> So weit gehe ich gar nicht. Er ist nicht lesbar, ich erwarte von so
> einem Code, dass er a) auf eine Bildschirmseite passt, b) dass ich ihn
> in 30 s verstanden habe.
Da kann ich kurz und flapsig antworten:
Wenn man ihn in 30s nicht versteht, dann liegt das nicht an mir,
sondern am Verstehensvermögen des Betrachters;
allerdings sind 30s allgemein ganz erheblich zu kurz.
>>Ich habe mehr als einmal mitgeteilt, daß ich ALLES DIESES probiert habe!
>>Kein Unterschied!
>
>
> Warum findet Google dann für 2003 keine Postings von Dir mit MAP_SHARED?
Weil ich nicht alle >10 Testvarianten meines Codes postete, sondern nur
eine, und weil ich *allgemein* erklärte, daß ich etwa 10 Varianten
probiert habe, also alles erdenkliche.
> Dein übriges Gejanke über Deine Zeit und fremde Kritik an Deinem
> unwartbaren Code lasse ich mal als unsachliches Beiwerk weg. (Mich
> wundert bei _solchem_ Code aber nicht, dass Du 16 h am Stück arbeiten
> musst, um Deine Arbeit getan zu bekommen.)
Siemens beispw. braucht für ein neues Produkt beispw. 1,5 Jahre Laufzeit.
Wir hingegen nicht selten 18 Tage netto für ein gleichartiges Produkt,
mit 8..50% des Hardware-Aufwandes, besserer Funktionalität, für 50%
des Preises...
Matthias Andree
> Matthias Andree wrote:
>> Helmut Schellong <sche...@t-online.de> writes:
>>
>>>Ist der Code (~10 Zeilen Algo.) unverstehbar?
>> So weit gehe ich gar nicht. Er ist nicht lesbar, ich erwarte von so
>> einem Code, dass er a) auf eine Bildschirmseite passt, b) dass ich ihn
>> in 30 s verstanden habe.
>
> Da kann ich kurz und flapsig antworten:
> Wenn man ihn in 30s nicht versteht, dann liegt das nicht an mir,
> sondern am Verstehensvermögen des Betrachters;
> allerdings sind 30s allgemein ganz erheblich zu kurz.
Ich wüßte nicht, warum ich länger brauchen sollte, um einen einfachen
Zehnzeiler zu erfassen. Mehr braucht es zur Demonstration des Verhaltens
sicherlich nicht. Lass es halt zwei Zehnzeiler sein (read, mmap),
#include nicht gezählt.
Dass Du nicht in der Lage oder willens bist, einen reduzierten Testfall
zu liefern, den man in so kurzer Zeit versteht, ist mir klar.
Wie in dcou.bsd geschrieben: Du hast kein Interesse, das Problem zu
lösen, sondern willst rumschwafeln und dass andere hellsehen können,
welchen Mist Du in Deinem nicht geposteten Code verzapft hast.
Helmut Schellong
Ach, ändert der vollständige Code etwas an der Betrachtung
hinsichtlich des beobachteten Phänomens?:
--------------------------------------------------------------------------
static int FindM(off_t fsz)
{
# define FILL (128*1024)
register char *bp;
const char * volatile fp;
register int nr, fl;
int nf, pgsz, o, a;
ulong fnd=0;
off_t nd;
pgsz= getpagesize();
if (Nmax>fsz) Nmax=fsz;
a= (int)Offs&(pgsz-1); Offs-=a;
for (Nr=0,o=nr=0,bp=0; (nd=Nmax-Nr, nd>0)&&(
(void)(bp?munmap(bp,nr):0),
nr= nd>=FILL?FILL:(int)nd,
bp= mmap(0, nr, PROT_READ, MAP_PRIVATE, FDi, Offs+Nr),
bp!=MAP_FAILED); )
{
Bnu=(Nr+=nr); o+=a; nf=nr-o;
do {
fp= FindS(bp+o, nf, Str, lStr);
if (!fp) { o=0; break; }
if (fl=(bp+o+nf)-fp, fl<lStr) {
if (o=0, Nmax-Nr>0&&Nr>=pgsz) Nr-=pgsz, o=pgsz-fl;
break;
}
if (++fnd, !(O1|Ol|Oc)) {
if (Pf&&writef(1, "%s:\t", Datei)<9)
writef(1, "\t");
writef(1, "%ld" NL, Offs-Offs0+Nr-nr+(fp-bp));
}
if (!Og) goto NOg;
if (!(fl-=lStr)) { o=0; break; }
o=(fp+lStr)-bp; nf=fl;
}
while (1);
}
NOg:;
if (bp&&bp!=MAP_FAILED) munmap(bp,nr);
nr= fnd?1:0;
if (Ol&&(Ov^(char)nr)) writef(1, "%s" NL, Datei);
if (Oc) { if (Pf&&writef(1, "%s:\t", Datei)<9) writef(1, "\t");
writef(1, "%lu" NL, fnd); }
if (bp==MAP_FAILED) Err(E_READDA, 0);
return (nr);
# undef FILL
}
--------------------------------------------------------------------------
Wie man sieht, hatte ich durchaus auf das Problem reduzierten, vollständigen
Code gepostet.
Oder ändern die jetzt vorhandenen stdout-Teile etwas?
--
Mit freundlichen Grüßen
Helmut Schellong v...@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Patrick Schaaf
Hat schonmal jemand die Funktion FindS() zu sehen bekommen,
die da fett in der inneren Schleife aufgerufen wird?
Neben MAP_SHARED vs. MAP_PRIVATE ist das bei dieser Irrfahrt
durch die Raetsel des Mysteriums fuer mich die zweite grosse
Unbekannte.
</langweilig>
wuensche Allseits ein entspanntes Wochenende
Patrick
Ullrich von Bassewitz
[Code]
War das jetzt der Quellcode oder das Binary?
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
1:30pm up 226 days, 20:13, 19 users, load average: 0.01, 0.02, 0.08
Thomas Ogrisegg
> Um die Frage endlich mal zu stellen: Warum zur Hölle benutzt Du
> eigentlich MAP_PRIVATE und nicht MAP_SHARED zum Lesen? Ist ja schon
Bei Readonly pages (die nicht von einem anderen Prozess beschrieben
werden) sollte das keinen Unterschied machen.
Hingegen ist MAP_SHARED kritisch, wenn ein anderer Prozess zB die
Datei "truncated".
Dann gibt es uU einen "Bus Error" oder ein Segfault.
Rainer Weikusat
> Ach, ändert der vollständige Code etwas an der Betrachtung
> hinsichtlich des beobachteten Phänomens?:
> --------------------------------------------------------------------------
> static int FindM(off_t fsz)
> {
> # define FILL (128*1024)
> register char *bp;
> const char * volatile fp;
> register int nr, fl;
> int nf, pgsz, o, a;
> ulong fnd=0;
> off_t nd;
>
> pgsz= getpagesize();
> if (Nmax>fsz) Nmax=fsz;
> a= (int)Offs&(pgsz-1); Offs-=a;
Er deutet stark darauf hin, daß Du die manpage zu mmap(2) nicht
gelesen hast. Ansonsten ist es ist für Dritte nicht zumutbar, das
entziffern zu müssen (geht im Zweifelsfall mechanisch, im dem man das
erst durch indent jagt und Schritt für Schritt die state obfuscation
wieder rückgängig macht. Der Rest ergibt sich von selber).
Du möchtest *dringend*
- Deinen Variablen verständliche Namen geben.
- Deinen Quelltext systematisch und nicht organisch
strukturieren (=> for).
- der Versuchung widerstehen, durch 'verknäulen' einzelne
Zeilen einzusparen.
Du machst übrigens mehr als doppelt soviele syscalls wie nötig, was
ein erkennbares Zeichen dafür ist, daß Du da selber auch nicht mehr
durchblickst.
Falls sich jemand für verschiedene Varianten gepufferter I/O
interessiert:
#include <time.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <inttypes.h>
#include <sys/mman.h>
uint32_t block_size = 8192; /* FreeBSD stdio blocksize */
int fd, mmap_flags = MAP_SHARED;
char *block, *buf;
off_t remain, pos, ninput, ndx;
void next_block_m(void);
void init_m(void)
{
remain = lseek(fd, 0, SEEK_END);
ninput = ndx = pos = 0;
next_block_m();
mmap_flags |= MAP_FIXED;
}
void next_block_m(void)
{
static int mmap_flags = MAP_SHARED;
ninput = remain > block_size ? block_size : remain;
block = mmap(block, ninput, PROT_READ, mmap_flags, fd, pos);
madvise(block, ninput, MADV_SEQUENTIAL);
pos += ninput;
ndx = 0;
remain -= ninput;
}
static inline int next_char_m(void)
{
if (ndx == ninput) {
if (!remain) {
munmap(block, ninput);
return -1;
}
next_block_m();
}
return block[ndx++];
}
void init_r(void)
{
block = malloc(block_size);
remain = lseek(fd, 0, SEEK_END);
lseek(fd, 0, SEEK_SET);
ndx = 0;
ninput = 0;
}
void next_block_r(void)
{
ninput = block_size < remain ? block_size : remain;
ninput = read(fd, block, ninput);
remain -= ninput;
ndx = 0;
}
static inline int next_char_r(void)
{
if (ndx == ninput) {
if (!remain) {
free(block);
block = NULL;
return -1;
}
next_block_r();
}
return block[ndx++];
}
int main(int argc, char **argv)
{
int mode = 'm', c;
FILE *fp;
clock_t c0;
while ((c = getopt(argc, argv, "mrsb:")) != -1)
switch (c) {
case 'r':
case 'm':
case 's':
mode = c;
break;
case 'b':
block_size = strtoul(optarg, NULL, 10);
}
fd = open(argv[optind], O_RDONLY, 0);
switch (mode) {
case 'r':
init_r();
c0 = clock();
while (next_char_r() != -1);
printf("read: %d\n", clock() - c0);
break;
case 'm':
init_m();
c0 = clock();
while (next_char_m() != -1);
printf("mmap: %d\n", clock() - c0);
break;
case 's':
fp = fdopen(fd, "r");
c0 = clock();
while (getc(fp) != -1);
printf("fgetc: %d\n", clock() - c0);
}
return 0;
}
Rainer Weikusat
MAP_SHARED and MAP_PRIVATE describe the disposition of write
references to the memory object. If MAP_SHARED is specified, write
references shall change the underlying object. If MAP_PRIVATE is
specified, modifications to the mapped data by the calling process
shall be visible only to the calling process and shall not change
the underlying object. It is unspecified whether modifications to
the underlying object done after the MAP_PRIVATE mapping is
established are visible through the MAP_PRIVATE mapping.
[SUS]
fcntl existiert.
Rainer Weikusat
> Ach, ändert der vollständige Code etwas an der Betrachtung
> hinsichtlich des beobachteten Phänomens?:
> --------------------------------------------------------------------------
> static int FindM(off_t fsz)
> {
> # define FILL (128*1024)
> register char *bp;
> const char * volatile fp;
> register int nr, fl;
> int nf, pgsz, o, a;
> ulong fnd=0;
> off_t nd;
>
> pgsz= getpagesize();
> if (Nmax>fsz) Nmax=fsz;
> a= (int)Offs&(pgsz-1); Offs-=a;
Er deutet stark darauf hin, daß Du die manpage zu mmap(2) nicht
Du möchtest *dringend*
void next_block_m(void);
void next_block_m(void)
{
Helmut Schellong
> <langweilig>
>
> Hat schonmal jemand die Funktion FindS() zu sehen bekommen,
> die da fett in der inneren Schleife aufgerufen wird?
>
> Neben MAP_SHARED vs. MAP_PRIVATE ist das bei dieser Irrfahrt
> durch die Raetsel des Mysteriums fuer mich die zweite grosse
> Unbekannte.
>
> </langweilig>
Wozu? Die wird doch in *beiden* (Find()+FindM()) aufgerufen.
> wuensche Allseits ein entspanntes Wochenende
> Patrick
Wurm-eMail-Schwemme-Wochenende.
Helmut Schellong
> Helmut Schellong <sche...@t-online.de> wrote:
> [Code]
>
> War das jetzt der Quellcode oder das Binary?
Na, mein Lieber, soll ich nun die FindS() auch noch posten,
wie von anderer Seite gefordert, oder nich?
Ich gebe hiermit mein Ehrenwort, daß das der momentane
Quellcode ist.
Helmut Schellong
> MAP_SHARED and MAP_PRIVATE describe the disposition of write
> references to the memory object. If MAP_SHARED is specified, write
> references shall change the underlying object. If MAP_PRIVATE is
> specified, modifications to the mapped data by the calling process
> shall be visible only to the calling process and shall not change
> the underlying object.
Das beantwortet, *warum* ich MAP_PRIVATE wählte.
> It is unspecified whether modifications to
> the underlying object done after the MAP_PRIVATE mapping is
> established are visible through the MAP_PRIVATE mapping.
> [SUS]
Das verstehe ich nicht, weil bei PRIVATE das Objekt eben *nicht*
geändert wird; oder mein Englisch ist nicht gut genug.
Helmut Schellong
Und, warum sollte ich SHARED nehmen, wo ich doch die Datei
auf gar keinen Fall ändern will?!
Mit einem bgrep will man das nicht.
Helmut Schellong
> Helmut Schellong <sche...@t-online.de> writes:
>
>>Ach, ändert der vollständige Code etwas an der Betrachtung
>>hinsichtlich des beobachteten Phänomens?:
>>--------------------------------------------------------------------------
>>static int FindM(off_t fsz)
>>{
>># define FILL (128*1024)
>> register char *bp;
>> const char * volatile fp;
>> register int nr, fl;
>> int nf, pgsz, o, a;
>> ulong fnd=0;
>> off_t nd;
>>
>> pgsz= getpagesize();
>> if (Nmax>fsz) Nmax=fsz;
>> a= (int)Offs&(pgsz-1); Offs-=a;
>
>
> Er deutet stark darauf hin, daß Du die manpage zu mmap(2) nicht
> gelesen hast.
Was deutet darauf hin? (in dem jetzt gezeigten writef-Code)
> Ansonsten ist es ist für Dritte nicht zumutbar, das
> entziffern zu müssen (geht im Zweifelsfall mechanisch, im dem man das
> erst durch indent jagt und Schritt für Schritt die state obfuscation
> wieder rückgängig macht. Der Rest ergibt sich von selber).
>
> Du möchtest *dringend*
>
> - Deinen Variablen verständliche Namen geben.
bp bufpointer
fp findpointer
nr Anzahl n von read
Nr dito, global
fl findlen
nf Anzahl n for find
pgsz pagesize
o offset
fnd found
a align for mmap-offset
Wo ist das Problem?
> - Deinen Quelltext systematisch und nicht organisch
> strukturieren (=> for).
Werde ich niemals machen, zumindest nicht nachträglich.
> - der Versuchung widerstehen, durch 'verknäulen' einzelne
> Zeilen einzusparen.
Hab ich mir inzwischen abgewöhnt, wegen gvim.
Aber auch nur, weil ich früher stets im schwarz-weiß-80x25-Modus
arbeitete.
> Du machst übrigens mehr als doppelt soviele syscalls wie nötig, was
> ein erkennbares Zeichen dafür ist, daß Du da selber auch nicht mehr
> durchblickst.
Wo?
Glaub ich eigentlich nicht.
Patrick Schaaf
>> Hat schonmal jemand die Funktion FindS() zu sehen bekommen,
>> die da fett in der inneren Schleife aufgerufen wird?
>Wozu? Die wird doch in *beiden* (Find()+FindM()) aufgerufen.
Ich weiss nicht, wozu. Dein Code hat mir bisher keine Idee
gegeben, wie Dein Phaenomen (mmap 2 mal langsamer als read)
zustande kommen koennte; also frage ich nach dem, was bisher
noch nicht zu sehen war. Das koennte vielleicht eine Erleuchtung
bringen, und wenn nicht, sollte DANN genug Code zusammen sein,
dass ich es fuer sinnvoll halten wuerde, zu versuchen, Dein
Phaenomen selbst nachzustellen.
>Wurm-eMail-Schwemme-Wochenende.
Ja. Ekelhaft. Bitte nicht per Mail antworten, ich habe meine Domain
voruebergehend von ihrem MX befreit.
Gruss
Patrick
Helmut Schellong
> Helmut Schellong <sche...@t-online.de> writes:
>
>
>>>Hat schonmal jemand die Funktion FindS() zu sehen bekommen,
>>>die da fett in der inneren Schleife aufgerufen wird?
>
>
>>Wozu? Die wird doch in *beiden* (Find()+FindM()) aufgerufen.
>
>
> Ich weiss nicht, wozu. Dein Code hat mir bisher keine Idee
> gegeben, wie Dein Phaenomen (mmap 2 mal langsamer als read)
> zustande kommen koennte; also frage ich nach dem, was bisher
> noch nicht zu sehen war.
FindS() hab ich inzwischen in dcoub gepostet.
>>Wurm-eMail-Schwemme-Wochenende.
> Ja. Ekelhaft. Bitte nicht per Mail antworten, ich habe meine Domain
> voruebergehend von ihrem MX befreit.
Ich hab in der Nacht meinen Spam-Löscher nichtinteraktiv erweitert
und lösche per CRON alle 15 Minuten mit einfachem Size-Filter.
Zum Glück! Ich erhielt heute nur deshalb eine unerwartete Mail von
meinem Rechtsanwalt!
Rainer Weikusat
>> Er deutet stark darauf hin, daß Du die manpage zu mmap(2) nicht
>> gelesen hast.
>
> Was deutet darauf hin? (in dem jetzt gezeigten writef-Code)
munmap
>> - Deinen Variablen verständliche Namen geben.
>
> bp bufpointer
> fp findpointer
> nr Anzahl n von read
> Nr dito, global
> fl findlen
> nf Anzahl n for find
> pgsz pagesize
> o offset
> fnd found
> a align for mmap-offset
>
> Wo ist das Problem?
Nirgends. If it takes more time to understand it than to rewrite it,
do the latter.
Rainer Weikusat
> Rainer Weikusat wrote:
>> It is unspecified whether modifications to
>> the underlying object done after the MAP_PRIVATE mapping is
>> established are visible through the MAP_PRIVATE mapping.
>> [SUS]
>
> Das verstehe ich nicht, weil bei PRIVATE das Objekt eben *nicht*
> geändert wird; oder mein Englisch ist nicht gut genug.
MAP_PRIVATE bezieht sich auf Schreibzugriffe von Dir.
Helmut Schellong
> Helmut Schellong <sche...@t-online.de> writes:
>
>>>Er deutet stark darauf hin, daß Du die manpage zu mmap(2) nicht
>>>gelesen hast.
>>
>>Was deutet darauf hin? (in dem jetzt gezeigten writef-Code)
>
>
> munmap
Erstens ist das am Zeitbedarf unerkennbar, zweitens habe ich
das: A
successful mmap deletes any previous mapping in the allocated address
range.
sehr wohl gelesen.
Die letzten 5 Worte sind mir aber zu unsicher, denn die Adresse wird
doch bei jedem Aufruf vom System ausgewählt, und ich hole mir doch
jedesmal einen anderen Abschnitt aus der Datei, und das +/- 1 Page,
je nach Algorithmus.
Das: bp=0; ...... bp= mmap(bp, ...
habe ich schon überlegt aber bisher nicht probiert.
>>> - Deinen Variablen verständliche Namen geben.
> Nirgends. If it takes more time to understand it than to rewrite it,
> do the latter.
Ich bin mathematisch geprägt, u.a. daran liegt das.
Helmut Schellong
Ach, die meinen, ob externe Änderungen für PRIVATEmich
sichtbar werden, ist unspezifiziert.
Das haben die aber bescheuert formuliert.
Da stehe ich nicht nach.
Michael van Elst
>Das beantwortet, *warum* ich MAP_PRIVATE wählte.
Das System erzeugt eine Kopie der Daten, wenn mehr als ein Prozess das
Mapping benutzt und wenn dann ein Prozess in den Speicherbereich _schreibt_.
In deinem Fall gibt es nur einen Prozess und es wird nicht geschrieben.
Das read-only-bit in der MMU-Tabelle erzeugt keinen Overhead.
>> It is unspecified whether modifications to
>> the underlying object done after the MAP_PRIVATE mapping is
>> established are visible through the MAP_PRIVATE mapping.
>> [SUS]
>Das verstehe ich nicht, weil bei PRIVATE das Objekt eben *nicht*
>geändert wird; oder mein Englisch ist nicht gut genug.
Die Frage ist, was passiert, wenn das Objekt (was ja auch eine Datei
sein kann), von aussen geaendert wird. Es kann sein, dass du das
siehst oder auch nicht.
Das MAP_PRIVATE bezieht sich nur auf Aenderungen die du durch das
Mapping ausfuehrst (indem du den read-only-trap ausloest).
--
--
Michael van Elst
Internet: mle...@serpens.de
"A potential Snark may lurk in every tree."
Rainer Weikusat
> Rainer Weikusat wrote:
>> Helmut Schellong <sche...@t-online.de> writes:
>>>Was deutet darauf hin? (in dem jetzt gezeigten writef-Code)
>> munmap
>
> Erstens ist das am Zeitbedarf unerkennbar,
Es ist vom 'Zeitbedarf' her auch unerkennbar, ob man da an irgendeiner
Stelle noch ein
i = ++j;
j = --i;
reinschreibt. Es bleibt überflüssig. Ein Unterschied ist übrigens
nicht zuverlässig meßbar.
>>>> - Deinen Variablen verständliche Namen geben.
>
>> Nirgends. If it takes more time to understand it than to rewrite it,
>> do the latter.
>
> Ich bin mathematisch geprägt,
Falls ich auf sowas in Quellcode stoße sollte, mit dem ich arbeiten
muß, würde ich das als erstes ohne nähere Betrachtung löschen. Einfach
so. Hast Du es dafür geschrieben?
Thomas Ogrisegg
>> Hingegen ist MAP_SHARED kritisch, wenn ein anderer Prozess zB die
>> Datei "truncated".
> fcntl existiert.
Ja und? Bei MAP_PRIVATE wird das schon mehr oder weniger implizit
gemacht. Wozu sollte man sich da noch mit fcntl herumspielen?
Rainer Weikusat
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
>>> Hingegen ist MAP_SHARED kritisch, wenn ein anderer Prozess zB die
>>> Datei "truncated".
> [...]
>> fcntl existiert.
>
> Ja und? Bei MAP_PRIVATE wird das schon mehr oder weniger implizit
> gemacht.
Es wird nicht. Deine Pages werden 'copy on write' gemappt. Zu
irgendeinem späteren Zeitpunkt werden sie in den Adreßraum
reingefaultet (mmap(2), SunOS 5.8: »The address range starting at pa
and continuing for len bytes will be legitimate for the possible
(not necessarily current) address space of the process.«). Dann
bekommst Du das, was zu diesem Zeitpunkt in dem file stand. Solange Du
keine Schreibzugriffe machst, bleibt dieser Zustand unverändert. Das
System kann außerdem jederzeit die pages als nicht-resident markieren
und den Speicher für etwas anderes benutzen. Später gibt es einen
weiteren page fault und dann bekommst Du das, was dann in dem file
steht. Es gibt weiterhin einen Mechanismus, der bei MAP_SHARED für
synchrone Änderungen in file und eventuell gemapptem Speicher
sorgt. Dieser Mechanismus kann so aussehen, das der Kernel das file
einfach in seinen Adreßraum mappt und bei read(2)/write(2) von dort in
den user space kopiert, dh mit etwas Pech sind Deine mappings solange
synchronisiert, bis Du auf jeder Seite einen Schreibzugriff gemacht
hast. Offensichtlich ist das ein race, falls ein anderer Prozeß mit
demselben file etwas anstellt. Weterhin verwandelt sich das dann in
ein anonymous memory object mit backing store im swap, dh dort wird
ggf Platz reserviert. Falls ein anderer Prozeß das file gemappt hatte
(lt Dokumentation zB Solaris cp oder cat), müssen außerdem alle
Speicherseiten, auf die Du schreibend zugegriffen hast, kopiert
werden, was Zeit und Platz braucht. Es hat außerdem den Nebeneffekt,
daß es einen eventuell vorhandenen cache leerfegt respektive mit Daten
füllt, auf die Du noch gar nicht zugreifen willst, weil sie am Ende
des files liegen. Das hat einen ähnlichen Effekt wie ein page fault,
nämlich das nächste mal, wenn code auf den Adreßraum Deiner Anwendung
zugreift, gibt es garantierte cache misses.
Das funktioniert nicht nur nicht, sondern ist mE außerdem kein
besonders brilliantes vorgehen.
Matthias Andree
>> Nirgends. If it takes more time to understand it than to rewrite it,
>> do the latter.
>
> Ich bin mathematisch geprägt, u.a. daran liegt das.
Dann scann' mal bitte Dein Diplom oder was Du so hast, sagen wir mal
einfach "beste Qualifikation", und stell' sie online.
Soweit ich weiss, lernen Mathematiker in erster Linie, sehr strukturiert
zu arbeiten. Dein Code liegt zu dem Punkt diametral gegenüber.
Matthias Andree
> Wo ist das Problem?
"Obfuscated code".
> Hab ich mir inzwischen abgewöhnt, wegen gvim.
> Aber auch nur, weil ich früher stets im schwarz-weiß-80x25-Modus
> arbeitete.
Gerade das ist ein Grund, strukturierten Code zu schreiben. Wenn die
Funktionen hinreichend selbstdokumentierend und kurz sind, muss man
nicht komprimieren.
Matthias Andree
> for (Nr=0,o=nr=0,bp=0; (nd=Nmax-Nr, nd>0)&&(
> (void)(bp?munmap(bp,nr):0),
> nr= nd>=FILL?FILL:(int)nd,
> bp= mmap(0, nr, PROT_READ, MAP_PRIVATE, FDi, Offs+Nr),
> bp!=MAP_FAILED); )
> {
Und DAS soll jetzt einer auseinanderklamüsern? Mit Initialisierung und
Schleifenbedingung auf derselben Zeile, während letzte sich über mehrere
erstreckt? Ohne Einrückungen?
> }
> --------------------------------------------------------------------------
>
> Wie man sieht, hatte ich durchaus auf das Problem reduzierten, vollständigen
> Code gepostet.
> Oder ändern die jetzt vorhandenen stdout-Teile etwas?
Alles, was mich interessiert, ist was, das ich compilieren und in ltrace
oder sotruss pusten kann, um zu gucken, was für Dummheiten Dein Code
macht, denn LESEN kann Deinen Code niemand.
Matthias Andree
> Rainer Weikusat wrote:
>> MAP_SHARED and MAP_PRIVATE describe the disposition of write
>> references to the memory object. If MAP_SHARED is specified, write
>> references shall change the underlying object. If MAP_PRIVATE is
>> specified, modifications to the mapped data by the calling process
>> shall be visible only to the calling process and shall not change
>> the underlying object.
>
> Das beantwortet, *warum* ich MAP_PRIVATE wählte.
Komisch nur, dass das auftaucht, nachdem jemand anders souffliert hat.
Sei's drum.
Michael van Elst
>macht, denn LESEN kann Deinen Code niemand.
Sie werden erstaunt sein, was ein disziplinierter Geist alles erreichen kann.
SCNR
Patrick Schaaf
>Matthias Andree <matthia...@gmx.de> writes:
>>macht, denn LESEN kann Deinen Code niemand.
>Sie werden erstaunt sein, was ein disziplinierter Geist alles erreichen kann.
Es hilft ungemein, bei Programmierkurs-Betreuung im universitaeren
Bereich ein paar Jahre Erfahrung gesammelt zu haben.
"Informatik fuer Koeche" nannten wir das. Praegend fuer's Leben.
Ich finde, ueber die Form von Helmuts Code haben wir fuer diesen
Monat genug gelaestert. Um wieder sachlich zu werden, haette ich
zwei Fragen fuer die Runde:
1) mit welchem tool a la strace schaut man sich eigentlich pagefaults an?
2) sind minor faults auf freeBSD wirklich so teuer, dass bei sequentiellem
Scannen read doppelt so schnell wie mmap ist?
Gruss
Patrick
Helmut Schellong
> Helmut Schellong <sche...@t-online.de> writes:
>
>
>>>Nirgends. If it takes more time to understand it than to rewrite it,
>>>do the latter.
>>
>>Ich bin mathematisch geprägt, u.a. daran liegt das.
>
>
> Dann scann' mal bitte Dein Diplom oder was Du so hast, sagen wir mal
> einfach "beste Qualifikation", und stell' sie online.
>
> Soweit ich weiss, lernen Mathematiker in erster Linie, sehr strukturiert
> zu arbeiten. Dein Code liegt zu dem Punkt diametral gegenüber.
Ich studierte ETechnik[Fachr. Inform.verarb.].
In der Mathematik werden bekanntlich einzelne Formelzeichen
als auch Einzeichen-Einheiten verwendet...
Wenn ich über 10 Seiten hinweg z.B. Laplace-Transformationen
mache, sieht man keinen einzigen Namen mit mehr als 1 Zeichen.
Helmut Schellong
> Helmut Schellong <sche...@t-online.de> writes:
>
>
>>Rainer Weikusat wrote:
>>
>>> MAP_SHARED and MAP_PRIVATE describe the disposition of write
>>> references to the memory object. If MAP_SHARED is specified, write
>>> references shall change the underlying object. If MAP_PRIVATE is
>>> specified, modifications to the mapped data by the calling process
>>> shall be visible only to the calling process and shall not change
>>> the underlying object.
>>
>>Das beantwortet, *warum* ich MAP_PRIVATE wählte.
>
>
> Komisch nur, dass das auftaucht, nachdem jemand anders souffliert hat.
>
> Sei's drum.
Bevor ich hier erstmals postete, hatte ich *alle* man-Pages zu
sys/mman.h gelesen und verstanden.
Matthias Andree
> 1) mit welchem tool a la strace schaut man sich eigentlich pagefaults
> an?
time.
> 2) sind minor faults auf freeBSD wirklich so teuer, dass bei sequentiellem
> Scannen read doppelt so schnell wie mmap ist?
Kann ich nicht feststellen, im Gegenteil; Testcode unter der Signatur.
Ich zweifele an, dass Helmuts Präsentation seriös ist. Weder legt er
nach mehrfacher Aufforderung den vollen Quelltext offen, dass mein
seinen Code auf dem eigenen Rechner versuchen könnte, noch legt ein ein
Profil vor. Er WILL, dass andere RATEN, warum sein Code lahmarschig ist,
um dann einen Rant über alles mögliche vom Leder zu ziehen.
Wer will, kopiert ihn auf Grundlage der GNU General Public License v2.
256 MB Testdatei (regulär), 128 MB RAM, FreeBSD 4.9-PRERELEASE (letzte
Nacht bauen lassen), SYM53C875 SCSI, Micropolis 4345WS (2 MB Cache,
7200/min); K6-2/300 auf VIA MVP3-Chipsatz (Tyan Trinity 100AT "S1590"),
FFS + softupdates.
Warnung: Die Einzelmessungen unten haben nur beispielhaften Charakter!
Weitere Stichproben sagen mir (nicht gezeigt, die Mail ist lang genug):
Die Balance user time <-> system time schwankt (erste Nachkommastelle),
ebenso ist die genaue page fault Zahl nicht genau konstant (Dürfte wohl
der Tribut an VM der übrigen Prozesse sein.)
csum ist der billige Weg, alle Bytes der Datei sicher angefasst zu
haben, ohne, dass der Compiler da irgendwas wegoptimieren kann.
Ohne madvise() ändern sich die Zeiten nicht erheblich.
Testablauf:
dd if=/dev/zero bs=1m count=256 of=/var/tmp/zero-256m
./try /var/tmp/zero-256m
mmap = mmap auf ganze Datei
chunked = mmap für 64kB-Ausschnitte der Datei
read = read in 64kB-Blöcken.
testing mmap
user: 6.125760
syst: 1.422669
minflt 19903; majflt 3520; swaps 0
testing chunked
user: 7.022194
syst: 1.229083
minflt 7706; majflt 3524; swaps 0
testing read
user: 4.882395
syst: 6.128661
minflt 16; majflt 0; swaps 0
csum: 0
read ist die teuerste Methode im Testfile.
--
Matthias Andree
Encrypt your mail: my GnuPG key ID is 0x052E7D95
-------------------------------------------
#include <sys/types.h>
#include <sys/mman.h>
#include <errno.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/resource.h>
void barf(const char *tag) {
perror(tag);
exit(EXIT_FAILURE);
}
void printdiff(const char *tag, struct timeval *t1, struct timeval *t2) {
int udiff = t2->tv_usec - t1->tv_usec;
int diff = t2->tv_sec - t1->tv_sec;
if (udiff < 0) { udiff += 1000000; diff --; }
printf ("%s: %d.%06d\n", tag, diff, udiff);
}
void printusage(struct rusage *r1, struct rusage *r2) {
printdiff("user", &r1->ru_utime, &r2->ru_utime);
printdiff("syst", &r1->ru_stime, &r2->ru_stime);
printf("minflt %lu; majflt %lu; swaps %lu\n", r2->ru_minflt - r1->ru_minflt,
r2->ru_majflt - r1->ru_majflt, r2->ru_nswap - r1->ru_nswap);
}
int main(int argc, char **argv) {
int fd = open(argv[1], O_RDONLY);
void *p;
int i;
char *t;
int size = 1 << 28;
int bsiz = 1 << 16;
int csum = 0;
struct rusage r1, r2;
if (fd < 0) barf("open");
puts("testing mmap");
getrusage(RUSAGE_SELF, &r1);
p = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0);
if (p == MAP_FAILED) barf("mmap");
(void)madvise(p, size, MADV_SEQUENTIAL);
for (t = p , i = 0; i < size; i++) {
csum += t[i];
}
munmap(p, size);
getrusage(RUSAGE_SELF, &r2);
printusage(&r1, &r2);
puts("testing chunked");
getrusage(RUSAGE_SELF, &r1);
for (i = 0; i < size; i+=bsiz) {
int j;
p = mmap(NULL, bsiz, PROT_READ, MAP_SHARED, fd, i);
if (p == MAP_FAILED) barf("mmap");
(void)madvise(p, bsiz, MADV_SEQUENTIAL);
for (j = 0; j < bsiz; j++) {
csum -= ((char *)p)[j];
}
munmap(p, bsiz);
}
if (p == MAP_FAILED) barf("mmap");
munmap(p, size);
getrusage(RUSAGE_SELF, &r2);
printusage(&r1, &r2);
puts("testing read");
getrusage(RUSAGE_SELF, &r1);
p = malloc(bsiz);
for (i = 0; i < size; i+=bsiz) {
int j;
if (read(fd, p, bsiz) != bsiz) barf("read");
for (j = 0; j < bsiz; j++) {
csum -= ((char *)p)[j];
}
}
free(p);
getrusage(RUSAGE_SELF, &r2);
printusage(&r1, &r2);
close(fd);
printf("csum: %d\n", csum);
return 0;
}
Helmut Schellong
> mle...@serpens.de (Michael van Elst) writes:
>
>
>>Matthias Andree <matthia...@gmx.de> writes:
>
>
>>>macht, denn LESEN kann Deinen Code niemand.
>
>
>>Sie werden erstaunt sein, was ein disziplinierter Geist alles erreichen kann.
>
>
> Es hilft ungemein, bei Programmierkurs-Betreuung im universitaeren
> Bereich ein paar Jahre Erfahrung gesammelt zu haben.
>
> "Informatik fuer Koeche" nannten wir das. Praegend fuer's Leben.
>
> Ich finde, ueber die Form von Helmuts Code haben wir fuer diesen
> Monat genug gelaestert.
Ja. Wer analytisch erfahren ist, erkennt:
do {
1) Im Buf nichts gefunden
2) Suchmuster auf Buf-Ende FFF|fff...
3) Suchmuster exakt bis Buf-Ende FFF|
4) Im Buf weitersuchen
}
while (1);
> Um wieder sachlich zu werden, haette ich
> zwei Fragen fuer die Runde:
>
> 1) mit welchem tool a la strace schaut man sich eigentlich pagefaults an?
Ich sehe in man getrusage(), daß man damit Zeiten feststellen kann
als auch Page-Reservierung und Page-Fehler erfahren kann.
> 2) sind minor faults auf freeBSD wirklich so teuer, dass bei sequentiellem
> Scannen read doppelt so schnell wie mmap ist?
Es sieht jedenfalls bei mir FBSD4.8 so aus.
Ich dachte, mmap sei *stets mindestens* so schnell wie read.
Patrick Schaaf
>mailer...@bof.de (Patrick Schaaf) writes:
>> 1) mit welchem tool a la strace schaut man sich eigentlich pagefaults
>> an?
>time.
Ich moechte nicht "wieviele" wissen, sondern haette gerne eine strace-artige
Ausgabe jedes Einzelnen, mit Timestamp & Adresse und idealerweise der
Unterscheidung major/minor, und ob read oder write. Also grob das, was
mir passend plazierte printk()s im Kernel-Pagefault-Handler sagen wuerden.
Hatte die Hoffnung, das koennte es "fertig" geben.
[tests mit code gesnippt, danke]
Gruss
Patrick
Helmut Schellong
>>---------------------------------------------------------
>> for (; 1; b=fp+1,fp=0,s=str) {
>> c=*s;
>> while (b<be && *b!=c) ++b;
>> if (b>=be) break;
>> fp= b++; ++s; l= lstr;
>> while (--l>0 && b<be && *b==*s) ++b,++s;
>> if (l<=0 || b>=be) break;
>> }
>>return fp;
>>---------------------------------------------------------
>
>
> Ich weiss ja nicht, WAS diese Funktion treiben soll, sie sieht
> jedenfalls sehr fischig und nach "ich erfinde memcmp(3) lieber selbst,
> als es anzuwenden" aus. Auch das for(), das eigentlich while(1) oder
> for(;;) sein wollte, stinkt.
Sie leistet wesentlich mehr als memcmp().
Immerhin schafft sie die Grundlage, innerhalb ~0.4 s 126 MB
nach einem Suchmuster zu durchsuchen, auf PIII/700.
> Unabhängig davon scheinen *b und *s monoton zu wachsen, ist also kein
> Grund, warum mmap() einen anderen Eignungsgrad als read() besitzen
> sollte -- es sei denn, str wäre sehr groß und würde paging auslösen.
str: "iso"
Helmut Schellong
> Matthias Andree wrote:
>
>> Helmut Schellong <sche...@t-online.de> writes:
>>
>>
>> Unabhängig davon scheinen *b und *s monoton zu wachsen, ist also kein
>> Grund, warum mmap() einen anderen Eignungsgrad als read() besitzen
>> sollte -- es sei denn, str wäre sehr groß und würde paging auslösen.
Einerseits streng monoton,
andererseits kann der Scan in der letzten Schleife
per b=fp+1 zurückspringen.
Rainer Weikusat
> Matthias Andree wrote:
>>>Ich bin mathematisch geprägt, u.a. daran liegt das.
>> Dann scann' mal bitte Dein Diplom oder was Du so hast, sagen wir mal
>> einfach "beste Qualifikation", und stell' sie online.
>> Soweit ich weiss, lernen Mathematiker in erster Linie, sehr
>> strukturiert
>> zu arbeiten. Dein Code liegt zu dem Punkt diametral gegenüber.
>
> Ich studierte ETechnik[Fachr. Inform.verarb.].
>
> In der Mathematik werden bekanntlich einzelne Formelzeichen
> als auch Einzeichen-Einheiten verwendet...
>
> Wenn ich über 10 Seiten hinweg z.B. Laplace-Transformationen
> mache, sieht man keinen einzigen Namen mit mehr als 1 Zeichen.
Fuer *Rechnungen* ist das auch vollkommen akzeptabel. Aber nicht fuer
Quellcode. Den kann man naemlich nicht jedes Mal 'von Anfang an'
'durchrechnen', falls man ggf zwei Zeilen aendern moechte.
Matthias Andree
> Ich studierte ETechnik[Fachr. Inform.verarb.].
Du benimmst Dich aber gar nicht so, siehe auch:
> In der Mathematik werden bekanntlich einzelne Formelzeichen
> als auch Einzeichen-Einheiten verwendet...
Falsch. Einheiten-Zeichen sind a) nicht Formelzeichen, (P und W sind
zwei Paar Stiefel) b) interessiert sich die Mathematik bestenfalls am
Rande für Physikalische Einheiten.
> Wenn ich über 10 Seiten hinweg z.B. Laplace-Transformationen
> mache, sieht man keinen einzigen Namen mit mehr als 1 Zeichen.
Ahja. Wozu auch immer beim Programmieren eine Laplace-T nütze sein
soll. Parsevalsches Theorem: die Entropie der meisten Deiner Postings
ist auch nach Laplace-Transformation weiterhin 0. :-P
Matthias Andree
> Bevor ich hier erstmals postete, hatte ich *alle* man-Pages zu
> sys/mman.h gelesen und verstanden.
Deswegen gab's auch Diskussion darüber, wessen Schreiboperationen nach
mmap(...MAP_PRIVATE...) unsichtbar sind, mit überraschendem Ausgang für
Dich...
Axel Schwenke
>
> Ich zweifele an, dass Helmuts Präsentation seriös ist.
| | / _ \ | |
| |__ | (_) || |__
|____| \___/ |____|
Hat H.S. jemals was anderes als Trollpostings geschrieben?
Dank Killfile sehe ich ihn ja nicht, aber IMHO gebt ihr euch
alle viel zu viel Mühe, mit ihm wie mit einem vernunftbegabten
Menschen zu diskutieren. Mein Rat: -> Tonne
XL
--
Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition,
die anderen sind einfach von sich aus unlogisch. -- Anselm Lingnau
Helmut Schellong
> Helmut Schellong <sche...@t-online.de> writes:
>
>
>>Ich studierte ETechnik[Fachr. Inform.verarb.].
>
>
> Du benimmst Dich aber gar nicht so, siehe auch:
>
>
>>In der Mathematik werden bekanntlich einzelne Formelzeichen
>>als auch Einzeichen-Einheiten verwendet...
>
>
> Falsch. Einheiten-Zeichen sind a) nicht Formelzeichen, (P und W sind
> zwei Paar Stiefel) b) interessiert sich die Mathematik bestenfalls am
> Rande für Physikalische Einheiten.
?
In der Mathematik werden bekanntlich einzelne Formelzeichen verwendet.
In der Mathematik werden bekanntlich Einzeichen-Einheiten verwendet.
Das ist korrekt.
Und wenn das Alphabet nicht ausreicht, wird das griechische dazugenommen.
Wenns immer noch nicht reicht, werden kryptische Strichelchen, Punktuationen
usw. um die Einzelzeichen drapiert, oder bei Mengen Doppelstriche verwendet.
Desweiteren sind Einheitengleichungen im Ingenieurbereich wichtig,
dies allerdings kaum in der reinen theoretischen Mathematik.
Helmut Schellong
> Helmut Schellong <sche...@t-online.de> writes:
>
>
>>Bevor ich hier erstmals postete, hatte ich *alle* man-Pages zu
>>sys/mman.h gelesen und verstanden.
>
>
> Deswegen gab's auch Diskussion darüber, wessen Schreiboperationen nach
> mmap(...MAP_PRIVATE...) unsichtbar sind, mit überraschendem Ausgang für
> Dich...
Ich hatte den letzten Satz einer geposteten SuS-Doku
rein sprachlich/logisch nicht verstanden.
Diese Doku steht *nicht* in den mman.h-man-Pages...
Diese Beschreibung von *SCO* ist übrigens bei weitem besser!
Das Doku-System ist übrigens eine der Stärken bei SCO
gegenüber FBSD, Linux:
(http://uw713doc.caldera.com/en/SDK_sysprog/_Creating_and_Using_Mappings.html)
-------------------------------------------------------------------------
MAP_SHARED and MAP_PRIVATE specify the mapping type, and one of them must be specified.
The mapping type describes the disposition of store operations made by this process into
the address range defined by the mapping operation. If MAP_SHARED is specified, write
references will modify the mapped object. No further operations on the object are
necessary to effect a change -- the act of storing into a MAP_SHARED mapping is equivalent
to doing a write system call.
NOTE: The private copy is not created until the first write; until then, other users who
have the object mapped MAP_SHARED can change the object. That is, if one user has an
object mapped MAP_PRIVATE and another user has the same object mapped MAP_SHARED, and the
MAP_SHARED user changes the object before the MAP_PRIVATE user does the first write, then
the changes appear in the MAP_PRIVATE user's copy that the system makes on the first
write. If an application needs isolation from changes made by other processes, it should
use read to make a copy of the data it wishes to keep isolated.
On the other hand, if MAP_PRIVATE is specified, an initial write reference to a page in
the mapped area will create a copy of that page and redirect the initial and successive
write references to that copy. This operation is sometimes referred to as copy-on-write
and occurs invisibly to the process causing the store. Only pages actually modified have
copies made in this manner. MAP_PRIVATE mappings are used by system functions such as
exec(2) when mapping files containing programs for execution. This permits operations by
programs such as debuggers to modify the ``text'' (code) of the program without affecting
the file from which the program is obtained.
-------------------------------------------------------------------------
Helmut Schellong
> Matthias Andree <matthia...@gmx.de> wrote:
>
>>Ich zweifele an, dass Helmuts Präsentation seriös ist.
>
> _ ___ _
> | | / _ \ | |
> | |__ | (_) || |__
> |____| \___/ |____|
>
> Hat H.S. jemals was anderes als Trollpostings geschrieben?
> Dank Killfile sehe ich ihn ja nicht, aber IMHO gebt ihr euch
> alle viel zu viel Mühe, mit ihm wie mit einem vernunftbegabten
> Menschen zu diskutieren. Mein Rat: -> Tonne
Lügnerische und unlogische Killfile-Memme.
Kai Ruhnau
> In der Mathematik werden bekanntlich Einzeichen-Einheiten verwendet.
Lass dir aus einer gewissen Erfahrung heraus sagen, dass die Mathematik
keine Einheiten kennt. Alles, was man gemeinhin als "Einheiten" bezeichnet,
ist viel zu speziell um damit anständige Mathematik zu betreiben. (Meistens
auf soetwas banales wie den drei-dimensionalen Raum beschränkt)
> Und wenn das Alphabet nicht ausreicht, wird das griechische dazugenommen.
Man kommt prinzipiell mit zweieinhalb Alphabeten aus: Griechisch -
groß/klein, "Westliche-Welt" - groß/klein, und die großen altdeutschen
Buchstaben. Der Rest wird mit Punkten, Strichen, Dächern, Schlangen,
obenIndex, untenIndex usw. erledigt.
Das schöne daran ist aber, dass man sich mit einer sehr großen Sicherheit
darauf verlassen kann, dass eine Vielzahl an Buchstaben auch nur in einem
gewissen Kontext vorkommen.
Beispielsweise das griechische Lambda: Taucht es in Zusammenhanb mit
Vektoren auf, ist es ein Skalar aus dem zugrundeligenden Körper.
Taucht es in Zusammenhang mit Integralen mit einem d direkt davor auf,
kannst du quasi blind davon aus gehen, dass es das Lebesgue-Mass ist.
> Wenns immer noch nicht reicht, werden kryptische Strichelchen, Punktuationen
> usw. um die Einzelzeichen drapiert, oder bei Mengen Doppelstriche verwendet.
Doppelstriche?
> Desweiteren sind Einheitengleichungen im Ingenieurbereich wichtig,
> dies allerdings kaum in der reinen theoretischen Mathematik.
Was mich ein wenig wundert ist, dass du versuchst das Chaos, was mal
Quelltext werden wollte, mit Mathematik in Verbindung zu bringen. Auf mich
machen die paar Zeilen, die ich gesehen habe, den Eindruch, als wolltest du
anstatt ein gegebenes Problem zu lösen, lieber mit undefinierbaren
Buchstabenkostrukten als Variablen oder Schleifenköpfen die sich über
mehrere Zeilen hinziehen eine Genialität vorspielen, die hier einfach nur
unangebracht ist.
Die Mathematik dagegen versucht, ein gegebenes Problem einfach und
verständlich zu lösen. Niemand in der Mathematik hat etwas davon, wenn
"irgend ein Guru" einen buchdicken Beweis vorlegt, den niemand außer ihm
verstehen kann. Denn ein solcher Beweis *kann* von einem anderen
Mathematiker niemals akzeptiert werden. Schließlich beweist er nichts, wenn
ihn keiner versteht.
Immer wenn ein neues Problem bewiesen werden konnte, versuchen sich
Mathematiker damit, den Beweis zu vereinfachen, neue Kniffe und andere
Begründungen zu finden, sodass das, was bewiesen werden sollte, leichter
verständlich, aber auch kürzer und knackiger wird. Dadurch wird der Beweis
einer "breiteren Masse" zugänglich.
Diese Punkte vermisse ich an dem Code-Schnippsel. Du tust mit dieser
erzwungenden Knappheit und dem fast schon unkonntrollierten
Zusammenstauchen niemandem einen Gefallen. Es macht einfach keinen Spaß,
den Qualtext zu lesen, solange man bei jeder einzelnen Zeile nachschauen
muss, wie eine Variable deklariert wurde, wann und wo und wie sie bisher
eingesetzt wurde und welchen Einfluss sie auf die aktuelle Zeile hat. Keine
der Variablen-Bezeichnungen bringt "von sich aus" eine Semantik mit, die
das Verständnis erleichtert.
Hier ist die Gemeinsamkeit zur Mathematik: Sowohl Beweise ("Formeln") als
auch Quelltext werden dazu gemacht, um vom *Menschen* gelesen zu werden.
Warum also sollte man an den Stellen, wo es dem Compiler eine mitgegebene
Semantik völlig egal ist, nicht einem geneigten Leser das Verständnis
erleichtern?
Grüße
Kai
Bernd Petrovitsch
> Das Doku-System ist übrigens eine der Stärken bei SCO
> gegenüber FBSD, Linux:
Nicht mehr lang.
SCNR,
Bend
--
Bernd Petrovitsch Email : be...@bofh.at
"For I was talking aloud to myself. A habit of the old: they choose
the wisest person present to speak to; the long explanations needed
by the young are wearying." --- Gandalf, the White
Helmut Schellong
> On Mon, 22 Sep 2003 22:26:59 +0200, Helmut Schellong wrote:
>
>>Das Doku-System ist übrigens eine der Stärken bei SCO
>>gegenüber FBSD, Linux:
>
>
> Nicht mehr lang.
>
> SCNR,
Schon möglich, wenn FBSD, Linux nachziehen...
Helmut Schellong
>>In der Mathematik werden bekanntlich einzelne Formelzeichen verwendet.
>>In der Mathematik werden bekanntlich Einzeichen-Einheiten verwendet.
>
>
> Lass dir aus einer gewissen Erfahrung heraus sagen, dass die Mathematik
> keine Einheiten kennt. Alles, was man gemeinhin als "Einheiten" bezeichnet,
> ist viel zu speziell um damit anständige Mathematik zu betreiben. (Meistens
> auf soetwas banales wie den drei-dimensionalen Raum beschränkt)
Willst Du ernshaft sagen, kein Mathematiker kenne Einheitengleichungen?
>>Wenns immer noch nicht reicht, werden kryptische Strichelchen, Punktuationen
>>usw. um die Einzelzeichen drapiert, oder bei Mengen Doppelstriche verwendet.
>
>
> Doppelstriche?
================
|| |
|| |
>
>
>>Desweiteren sind Einheitengleichungen im Ingenieurbereich wichtig,
>>dies allerdings kaum in der reinen theoretischen Mathematik.
--
Helmut Schellong
>>Wenns immer noch nicht reicht, werden kryptische Strichelchen, Punktuationen
>>usw. um die Einzelzeichen drapiert, oder bei Mengen Doppelstriche verwendet.
>
>
> Doppelstriche?
================
|| |
|| |
|| |
|| |
|| |
|| |
|| |
|| |
|| |
Noch nie als 'Die Menge T' gesehen?
Kai Ruhnau
>>>In der Mathematik werden bekanntlich einzelne Formelzeichen verwendet.
>>>In der Mathematik werden bekanntlich Einzeichen-Einheiten verwendet.
>>
>> Lass dir aus einer gewissen Erfahrung heraus sagen, dass die Mathematik
>> keine Einheiten kennt. Alles, was man gemeinhin als "Einheiten" bezeichnet,
>> ist viel zu speziell um damit anständige Mathematik zu betreiben. (Meistens
>> auf soetwas banales wie den drei-dimensionalen Raum beschränkt)
>
> Willst Du ernshaft sagen, kein Mathematiker kenne Einheitengleichungen?
Nein, wenn du genau gelesen hättest, wäre dir aufgefallen, dass ich "die
Mathematik" geschrieben habe.
>>>Wenns immer noch nicht reicht, werden kryptische Strichelchen, Punktuationen
>>>usw. um die Einzelzeichen drapiert, oder bei Mengen Doppelstriche verwendet.
>>
>> Doppelstriche?
>
> ================
> || |
> || |
Soll das ein Pi mit Doppelstrich sein? Falls ja: Wirst du nie finden.
Es geht dabei um international standardisierte Symbole für sehr spezielle
Mengen. Das hat den Vorteil, dass du damit überall sehr einfach sagen
kannst, was du meinst. Eine allgemeine Menge wird nie einen Doppelstrich
haben.
Grüße
Kai
Kai Ruhnau
> Kai Ruhnau wrote:
>>>Wenns immer noch nicht reicht, werden kryptische Strichelchen, Punktuationen
>>>usw. um die Einzelzeichen drapiert, oder bei Mengen Doppelstriche verwendet.
>>
>>
>> Doppelstriche?
>
> ================
> || |
> || |
> || |
> || |
> || |
> || |
> || |
> || |
> || |
>
> Noch nie als 'Die Menge T' gesehen?
Du meinst ein Periodenintervall einer 2pi-periodischen Funktion?
Grüße
Kai
Rudolf Polzer
> > In der Mathematik werden bekanntlich einzelne Formelzeichen verwendet.
> > In der Mathematik werden bekanntlich Einzeichen-Einheiten verwendet.
>
> Lass dir aus einer gewissen Erfahrung heraus sagen, dass die Mathematik
> keine Einheiten kennt. Alles, was man gemeinhin als "Einheiten" bezeichnet,
> ist viel zu speziell um damit anständige Mathematik zu betreiben. (Meistens
> auf soetwas banales wie den drei-dimensionalen Raum beschränkt)
>
> > Und wenn das Alphabet nicht ausreicht, wird das griechische dazugenommen.
>
> Man kommt prinzipiell mit zweieinhalb Alphabeten aus: Griechisch -
> groß/klein, "Westliche-Welt" - groß/klein, und die großen altdeutschen
> Buchstaben. Der Rest wird mit Punkten, Strichen, Dächern, Schlangen,
> obenIndex, untenIndex usw. erledigt.
> Das schöne daran ist aber, dass man sich mit einer sehr großen Sicherheit
> darauf verlassen kann, dass eine Vielzahl an Buchstaben auch nur in einem
> gewissen Kontext vorkommen.
Nicht anders ist das bei den einbuchstabigen Variablennamen in
Programmen, die meist feste Bedeutungen haben.
Ich beispielsweise verwende:
a: Array oder Zahl, meist double
b: Zahl, meist double
c: Konstante oder Zahl, meist double
d: Differenz/Distanz
f, g: "allgemeine" Funktionen (würde ich beispielsweise
verwenden, wenn ich foreach() aus der STL implementiere)
h: (unbenutzt)
i, j, k: Schleifenzähler einer innersten Schleife
l: Länge oder Rekursionsebene ("level")
m: (selten) weitere Anzahl
n: Anzahl (bspw. Arraygröße)
o: (unbenutzt)
p: Wahrscheinlichkeit ("if(rand() < p * RAND_MAX) ...") oder Zeiger
q: (selten) weitere oder Gegenwahrscheinlichkeit, zweiter Zeiger
r: Radius
s: String (char *) oder Summe
t: zweiter String oder Zeit
u: (unbenutzt)
v, w: Vektoren (d.h. mit fester Dimension, die ich meist mit
n oder m angebe)
x, y, z: Koordinaten
Aber auch nicht immer. Diese Bezeichnungen kommen bei mir in der
Regel nur in kurzen Abschnitten vor (kürzer als die Beispielfunktion
von Helmut beispielsweise).
--
The only thing that Babelfish is good at is proving that Vogons are
great poets.
Josef 'Jupp' Schugt in japan.anime.evangelion
Helmut Schellong
> Helmut Schellong wrote:
>>Willst Du ernshaft sagen, kein Mathematiker kenne Einheitengleichungen?
>
>
> Nein, wenn du genau gelesen hättest, wäre dir aufgefallen, dass ich "die
> Mathematik" geschrieben habe.
Und ich sprach zuvor schon von "reiner, theoretischer Mathematik", wo
Einheiten keine/kaum Bedeutung haben, im Unterschied zur praktischen
Mathematik des Ingenieurs.
>>>>Wenns immer noch nicht reicht, werden kryptische Strichelchen, Punktuationen
>>>>usw. um die Einzelzeichen drapiert, oder bei Mengen Doppelstriche verwendet.
>>>
>>>Doppelstriche?
>>
>> ================
>> || |
>> || |
>
>
> Soll das ein Pi mit Doppelstrich sein? Falls ja: Wirst du nie finden.
Das läßt sich hier nun mal nicht korrekt grafisch darstellen.
Außerdem hast Du hier den Unterteil sehr stark verkürzt, damit man
überhaupt erst ein Pi erkennen kann.
> Es geht dabei um international standardisierte Symbole für sehr spezielle
> Mengen. Das hat den Vorteil, dass du damit überall sehr einfach sagen
> kannst, was du meinst. Eine allgemeine Menge wird nie einen Doppelstrich
> haben.
Ich kenne es so, daß ganz dicht neben dem senkrechten Strich von Großbuchstaben
ein zweiter, dünnerer Strich rechts daneben gezogen wird.
Helmut Schellong
> Scripsit illa aut ille »Kai Ruhnau« <kai.ne...@tragetaschen.dyndns.org>:
>
>>>In der Mathematik werden bekanntlich einzelne Formelzeichen verwendet.
>>>In der Mathematik werden bekanntlich Einzeichen-Einheiten verwendet.
>>
>>Lass dir aus einer gewissen Erfahrung heraus sagen, dass die Mathematik
>>keine Einheiten kennt. Alles, was man gemeinhin als "Einheiten" bezeichnet,
>>ist viel zu speziell um damit anständige Mathematik zu betreiben. (Meistens
>>auf soetwas banales wie den drei-dimensionalen Raum beschränkt)
>>
>>
>>>Und wenn das Alphabet nicht ausreicht, wird das griechische dazugenommen.
>>
>>Man kommt prinzipiell mit zweieinhalb Alphabeten aus: Griechisch -
>>groß/klein, "Westliche-Welt" - groß/klein, und die großen altdeutschen
>>Buchstaben. Der Rest wird mit Punkten, Strichen, Dächern, Schlangen,
>>obenIndex, untenIndex usw. erledigt.
>>Das schöne daran ist aber, dass man sich mit einer sehr großen Sicherheit
>>darauf verlassen kann, dass eine Vielzahl an Buchstaben auch nur in einem
>>gewissen Kontext vorkommen.
>
>
> Nicht anders ist das bei den einbuchstabigen Variablennamen in
> Programmen, die meist feste Bedeutungen haben.
Genau. Das wird von vielen gemacht.
> Ich beispielsweise verwende:
>
> a: Array oder Zahl, meist double
> b: Zahl, meist double
> c: Konstante oder Zahl, meist double
char-Objekt
> d: Differenz/Distanz
> f, g: "allgemeine" Funktionen (würde ich beispielsweise
> verwenden, wenn ich foreach() aus der STL implementiere)
> h: (unbenutzt)
> i, j, k: Schleifenzähler einer innersten Schleife
> l: Länge oder Rekursionsebene ("level")
lim==Limit
> m: (selten) weitere Anzahl
> n: Anzahl (bspw. Arraygröße)
> o: (unbenutzt)
offset
> p: Wahrscheinlichkeit ("if(rand() < p * RAND_MAX) ...") oder Zeiger
> q: (selten) weitere oder Gegenwahrscheinlichkeit, zweiter Zeiger
> r: Radius
return-wert
> s: String (char *) oder Summe
cp==char-pointer
> t: zweiter String oder Zeit
T: Temperatur (besser so: xyz.T, wegen global)
> u: (unbenutzt)
> v, w: Vektoren (d.h. mit fester Dimension, die ich meist mit
> n oder m angebe)
> x, y, z: Koordinaten
double in Formeln
>
> Aber auch nicht immer. Diese Bezeichnungen kommen bei mir in der
> Regel nur in kurzen Abschnitten vor (kürzer als die Beispielfunktion
> von Helmut beispielsweise).
Nicht nur bei n, nr, ..., sind wir ja schon gleicher Meinung.
(..) Na, besorgt?
Ich verwendete übrigens auch überwiegend *zwei*buchstabige Namen,
oder mit noch mehr Zeichen.
Ich mache das auch nur in kleineren Funktionen.
Rainer Weikusat
>> Man kommt prinzipiell mit zweieinhalb Alphabeten aus: Griechisch -
>> groß/klein, "Westliche-Welt" - groß/klein, und die großen altdeutschen
>> Buchstaben. Der Rest wird mit Punkten, Strichen, Dächern, Schlangen,
>> obenIndex, untenIndex usw. erledigt.
>> Das schöne daran ist aber, dass man sich mit einer sehr großen Sicherheit
>> darauf verlassen kann, dass eine Vielzahl an Buchstaben auch nur in einem
>> gewissen Kontext vorkommen.
>
> Nicht anders ist das bei den einbuchstabigen Variablennamen in
> Programmen, die meist feste Bedeutungen haben.
>
> Ich beispielsweise verwende:
Sechs, setzen. Fällt Dir was auf, Rudolf? Sowohl Du als auch Hellmut
benutzen zwei unterschiedliche, nicht-triviale Schemata, die in
keinster Art und Weise aus dem Quelltext ableitbar sind. Bei Helmut
kann man noch konstatieren, daß er mehr Erfahrung hat, als Du,
deswegen folgt er eher eine mnemonischen und keiner willkürlichen
Konvention. Ihr könnt eure Sprachstörungen bitte woanders auskurieren,
*aber nicht in Computerprogrammen*. Finger weg wovon man nichts
versteht. Plain & simple.
Bernd Petrovitsch
> Kai Ruhnau wrote:
>> Lass dir aus einer gewissen Erfahrung heraus sagen, dass die Mathematik
>> keine Einheiten kennt. Alles, was man gemeinhin als "Einheiten" bezeichnet,
>> ist viel zu speziell um damit anständige Mathematik zu betreiben. (Meistens
>> auf soetwas banales wie den drei-dimensionalen Raum beschränkt)
>
> Willst Du ernshaft sagen, kein Mathematiker kenne Einheitengleichungen?
Einheitengleichungen funktionieren genauso wie normale Gleichungen, nur
mit anderen Symbolen. Wozu extra beschäftigen damit?
Bernd
Rainer Weikusat
> testing mmap
> user: 6.125760
> syst: 1.422669
> minflt 19903; majflt 3520; swaps 0
> testing chunked
> user: 7.022194
> syst: 1.229083
> minflt 7706; majflt 3524; swaps 0
> testing read
> user: 4.882395
> syst: 6.128661
> minflt 16; majflt 0; swaps 0
> csum: 0
>
> read ist die teuerste Methode im Testfile.
Das ist wenig aussagekräftig, weil die Resultate stark von der
Blockgröße abhängen:
4M:
method blocksize r/s/u maj/min
----------------------------------------------------
read 8192 0.58/0.13/0.39 0/56
mmap 8192 0.59/0.04/0.53 0/55
read 65536 0.65/0.46/0.17 0/70
mmap 65536 0.54/0.02//0.50 0/55
41M:
method blocksize r/s/u maj/min
----------------------------------------------------
read 8192 5.89/1.63/4.15 0/56
mmap 8192 5.48/0.52/4.87 0/55
read 65536 6.44/1.93/4.41 0/70
mmap 65536 4.98/0.13/4.76 0/55
(256Mhz-CPU)
Es ist auch auffällig, daß mmap in allen Fällen mehr 'user CPU'
braucht, als read. Helmut verwendet vermutlich eine für mmap
ungünstige Blockgröße und mappt Teile der Datei mehrfach, weil er die
Offsets 'page aligned' hält, dh bei einem mismatch am Ende des
mappings das file ab dem letzten Seitenoffset nochmal mappt und dann
an der alten Position mit der Suche wieder aufsetzt. Das ist
überflüssig, aber falsch dokumentiert => kernel.
Rudolf Polzer
> Rudolf Polzer wrote:
> > Ich beispielsweise verwende:
> >
> > c: Konstante oder Zahl, meist double
> char-Objekt
Die braucht man nicht zu erwähnen, bzw. wenn ich eines in größeren
Blöcken habe, benenne ich es.
> > l: Länge oder Rekursionsebene ("level")
> lim==Limit
Nö, mag ich nicht :) - ich nehme lieber "Variablenname + min/max",
beispielsweise imax, amin. Aber auch nur, wenn's keinen besseren
Namen dafür gibt.
> > o: (unbenutzt)
> offset
Den würde ich ausschreiben. Außer bei hardwarenaher Programmierung
vielleicht.
> > r: Radius
> return-wert
Der heißt bei mir ret.
> > u: (unbenutzt)
> > v, w: Vektoren (d.h. mit fester Dimension, die ich meist mit
> > n oder m angebe)
> > x, y, z: Koordinaten
> double in Formeln
Stimmt, betrifft bei mir aber nur x alleine. Außerdem kann z noch eine
komplexe Zahl sein.
> > Aber auch nicht immer. Diese Bezeichnungen kommen bei mir in der
> > Regel nur in kurzen Abschnitten vor (kürzer als die Beispielfunktion
> > von Helmut beispielsweise).
>
> Nicht nur bei n, nr, ..., sind wir ja schon gleicher Meinung.
Aber bei einigen anderen nicht.
> Ich verwendete übrigens auch überwiegend *zwei*buchstabige Namen,
> oder mit noch mehr Zeichen.
Genau das mache ich aus Lesbarkeitsgründen nicht. Von "sz" vielleicht
mal abgesehen. "buffer" kürze ich noch gerne zu "buf" ab, aber das
war's dann auch schon. Längere Namen sollen sagen, wozu die Variable
gut ist. Mehrbuchstabige Abkürzungen sehen einfach nur kryptisch
aus. Dann noch Missbrauch des Komma-Operators in for-Schleifen,
und das Programm wird (wie deines) unlesbar, d.h. der Aufwand, es
zu verstehen, ist größer als der, es neu zu schreiben.
Fup2p
Matthias Andree
> In der Mathematik werden bekanntlich einzelne Formelzeichen verwendet.
> In der Mathematik werden bekanntlich Einzeichen-Einheiten verwendet.
Nochmal ganz deutlich: Mathematik schert sich um Einheiten nicht, oder,
wenn Du eine Einheit für die abzählbare Menge der Schellongs haben
willst: die Einheit ist 1.
> Desweiteren sind Einheitengleichungen im Ingenieurbereich wichtig,
Erwarte nicht, dass /Du/ mir von SI (oder sollte ich MKSA schreiben) was
neues erzählen kannst.
Wie ich sagte: die Entropie (H, nicht S, bevor einer fragt) Deiner
Postings ist 0.
--
Matthias `wo ist mein Popcorn' Andree
Helmut Schellong
> Matthias Andree <matthia...@gmx.de> writes:
> Es ist auch auffällig, daß mmap in allen Fällen mehr 'user CPU'
> braucht, als read.
Genau.
> Helmut verwendet vermutlich eine für mmap
> ungünstige Blockgröße
Habe 32..128KB verstärkt probiert: kein Unterschied.
Nur wenn man noch kleiner wird, bemerkt man langsam
den Zeitbedarf der Außenschleife.
> und mappt Teile der Datei mehrfach, weil er die
> Offsets 'page aligned' hält, dh bei einem mismatch am Ende des
> mappings das file ab dem letzten Seitenoffset nochmal mappt und dann
> an der alten Position mit der Suche wieder aufsetzt.
Gilt jedoch nicht, wenn in 126 MB 17-mal "iso" vorkommt.
> Das ist
> überflüssig, aber falsch dokumentiert => kernel.
Helmut Schellong
> Helmut Schellong <sche...@t-online.de> writes:
>
>
>>In der Mathematik werden bekanntlich einzelne Formelzeichen verwendet.
>>In der Mathematik werden bekanntlich Einzeichen-Einheiten verwendet.
>
>
> Nochmal ganz deutlich: Mathematik schert sich um Einheiten nicht, oder,
> wenn Du eine Einheit für die abzählbare Menge der Schellongs haben
> willst: die Einheit ist 1.
Gilbert Becaud: 100000 [V]
Matthias Andree
>> read ist die teuerste Methode im Testfile.
>
> Das ist wenig aussagekräftig, weil die Resultate stark von der
> Blockgröße abhängen:
Mir geht's auch nur darum, die pauschale Aussage "mmap langsamer als
read" (die ja zusammen mit Helmuts übrigem Schwadronieren
Allgemeingültigkeit beansprucht) durch Gegenbeispiel zu
entkräften. Zu diesem Behufe ist mein Test hinreichend.
> Es ist auch auffällig, daß mmap in allen Fällen mehr 'user CPU'
> braucht, als read. Helmut verwendet vermutlich eine für mmap
> ungünstige Blockgröße und mappt Teile der Datei mehrfach, weil er die
> Offsets 'page aligned' hält, dh bei einem mismatch am Ende des
> mappings das file ab dem letzten Seitenoffset nochmal mappt und dann
> an der alten Position mit der Suche wieder aufsetzt. Das ist
> überflüssig, aber falsch dokumentiert => kernel.
Ich übersetz das mal als: "Schellong kann seinen eigenen Code nicht lesen".
--
Matthias Andree
Helmut Schellong
> Rainer Weikusat <weik...@students.uni-mainz.de> writes:
>
>
>>>read ist die teuerste Methode im Testfile.
>>
>>Das ist wenig aussagekräftig, weil die Resultate stark von der
>>Blockgröße abhängen:
>
>
> Mir geht's auch nur darum, die pauschale Aussage "mmap langsamer als
> read" (die ja zusammen mit Helmuts übrigem Schwadronieren
> Allgemeingültigkeit beansprucht) durch Gegenbeispiel zu
> entkräften. Zu diesem Behufe ist mein Test hinreichend.
Ich hatte von mir überraschend festgestellte Fakten mitgeteilt,
die hier bei mir so vorliegen.
Dazu fragte ich, ob jemandem speziell diese Fakten bekannt sind.
Ich habe nie Allgemeingültigkeit beansprucht.
Rainer Weikusat
> Rainer Weikusat wrote:
>> Matthias Andree <matthia...@gmx.de> writes:
>> Es ist auch auffällig, daß mmap in allen Fällen mehr 'user CPU'
>> braucht, als read.
>
> Genau.
>
>> Helmut verwendet vermutlich eine für mmap
>> ungünstige Blockgröße
>
> Habe 32..128KB verstärkt probiert: kein Unterschied.
Wie bereits von mehreren Leuten gepostet: Das ist unmöglich, insofern
es mmap und einen sequentiellen Zugriff auf alle Zeichen
hintereinander angeht.
Rainer Weikusat
>> Es ist auch auffällig, daß mmap in allen Fällen mehr 'user CPU'
>> braucht, als read. Helmut verwendet vermutlich eine für mmap
>> ungünstige Blockgröße und mappt Teile der Datei mehrfach, weil er die
>> Offsets 'page aligned' hält, dh bei einem mismatch am Ende des
>> mappings das file ab dem letzten Seitenoffset nochmal mappt und dann
>> an der alten Position mit der Suche wieder aufsetzt. Das ist
>> überflüssig, aber falsch dokumentiert => kernel.
>
> Ich übersetz das mal als: "Schellong kann seinen eigenen Code nicht
> lesen".
Das vermutlich auch :->>. Aber mmap(2) für FreeBSD 4.8 dokumentiert,
daß die offsets page aligned sein müssen, was allerdings nicht (mehr?)
stimmt. Der syscall im Kernel kümmert sich darum und der ruft eine
Routine auf, für die das gilt. Kurzes Beispiel:
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <sys/mman.h>
int main(void)
{
char *block;
int fd;
fd = open("/var/log/messages", O_RDONLY, 0);
block = mmap(NULL, 1024, PROT_READ, MAP_SHARED, fd, 1);
putchar(*block++);
putchar(*block);
putchar('\n');
return 0;
}
Sollte 'ep' ausgeben (und tut es hier auch).
Helmut Schellong
>>>ungünstige Blockgröße
>>
>>Habe 32..128KB verstärkt probiert: kein Unterschied.
>
>
> Wie bereits von mehreren Leuten gepostet: Das ist unmöglich, insofern
> es mmap und einen sequentiellen Zugriff auf alle Zeichen
> hintereinander angeht.
-rwxr-xr-x 1 root wheel 52076 Sep 23 23:42 bgrep128
-rwxr-xr-x 1 root wheel 52076 Sep 23 23:42 bgrep32
-rwxr-xr-x 1 root wheel 52076 Sep 23 23:42 bgrep64
116] ./bgrep -c @iso /usr/z.iso
0
121] repeat 5 /usr/bin/time ./bgrep32 -c @iso /usr/z.iso
0.87 real 0.45 user 0.38 sys
0.88 real 0.51 user 0.33 sys
0.88 real 0.48 user 0.35 sys
0.88 real 0.46 user 0.38 sys
0.88 real 0.44 user 0.40 sys
122] repeat 5 /usr/bin/time ./bgrep32 -cM @iso /usr/z.iso
1.04 real 0.94 user 0.04 sys
1.03 real 0.94 user 0.04 sys
1.04 real 0.95 user 0.03 sys
1.03 real 0.97 user 0.01 sys
1.03 real 0.97 user 0.03 sys
123] repeat 5 /usr/bin/time ./bgrep64 -cM @iso /usr/z.iso
1.02 real 0.94 user 0.03 sys
1.02 real 0.95 user 0.02 sys
1.01 real 0.94 user 0.03 sys
1.01 real 0.92 user 0.05 sys
1.01 real 0.93 user 0.04 sys
124] repeat 5 /usr/bin/time ./bgrep128 -cM @iso /usr/z.iso
1.02 real 0.95 user 0.01 sys
1.02 real 0.89 user 0.08 sys
1.01 real 0.94 user 0.03 sys
1.01 real 0.94 user 0.02 sys
1.01 real 0.92 user 0.04 sys
125]
Matthias Andree
> Rainer Weikusat wrote:
>> Helmut Schellong <sche...@t-online.de> writes:
>>>>Helmut verwendet vermutlich eine für mmap
>>>>ungünstige Blockgröße
>>>
>>>Habe 32..128KB verstärkt probiert: kein Unterschied.
>> Wie bereits von mehreren Leuten gepostet: Das ist unmöglich, insofern
>> es mmap und einen sequentiellen Zugriff auf alle Zeichen
>> hintereinander angeht.
>
> -rwxr-xr-x 1 root wheel 52076 Sep 23 23:42 bgrep128
> -rwxr-xr-x 1 root wheel 52076 Sep 23 23:42 bgrep32
> -rwxr-xr-x 1 root wheel 52076 Sep 23 23:42 bgrep64
>
> 121] repeat 5 /usr/bin/time ./bgrep32 -c @iso /usr/z.iso
> 0.87 real 0.45 user 0.38 sys
> 0.88 real 0.51 user 0.33 sys
[...]
Hör' endlich auf, die Newsgroups mit Deinen Zeiten aus immer demselben
Code vollzuspammen, dessen Richtigkeit Du als gegeben annimmst -- ohne
Dich mit der Vermutung, Dein mmap-Code lese im Gegensatz zu Deinem
read-Code Daten mehrfach, auseinanderzusetzen.
Herumfummeln an Parametern beseitigt den Bug nicht. Aber meinetwegen
setz' die Block-Größe auf 0 und schau vor dem nächsten Posting so lange
zu, bis die Kiste fertig ist. SCNR.
Matthias Andree
> Dazu fragte ich, ob jemandem speziell diese Fakten bekannt sind.
> Ich habe nie Allgemeingültigkeit beansprucht.
Deine "Fakten" sind nicht verifizierbar und daher keine Fakten. Du
schreibst "mmap wesentlich langsamer", aber baust kein Fragezeichen
ein. Du beharrst auf Deinem Standpunkt, ohne zur Klärung beizutragen.
Kurz: Geh weg.
Helmut Schellong
> Helmut Schellong <sche...@t-online.de> writes:
>
>
>>Dazu fragte ich, ob jemandem speziell diese Fakten bekannt sind.
>>Ich habe nie Allgemeingültigkeit beansprucht.
>
>
> Deine "Fakten" sind nicht verifizierbar und daher keine Fakten. Du
> schreibst "mmap wesentlich langsamer", aber baust kein Fragezeichen
> ein. Du beharrst auf Deinem Standpunkt, ohne zur Klärung beizutragen.
>
> Kurz: Geh weg.
Ich habe den relevanten Code zweimal gepostet, auch FindS().
Ich habe Messzeiten x-fach gepostet.
Warum sollte ich ein Fragezeichen einbauen? Ich bezweifle nicht
die Ausgaben von /usr/bin/time - Stoppuhr bringt gleiche Zeiten.
ru_minflt als auch ru_majflt zeigen stets 7 bzw. 0 an.
Nach all dem trage ich nicht zur Klärung bei?!
Die Wahrheit ist: niemand kann sich erklären, warum bei mir und
auch anderswo bei Verwendung von mmap die user-time höher liegt.
Deshalb: Es muß am Schellong liegen.
Helmut Schellong
> Helmut Schellong <v...@schellong.biz> writes:
>
>
>>Rainer Weikusat wrote:
>>
>>>Helmut Schellong <sche...@t-online.de> writes:
>>>
>>>>>Helmut verwendet vermutlich eine für mmap
>>>>>ungünstige Blockgröße
>>>>
>>>>Habe 32..128KB verstärkt probiert: kein Unterschied.
>>>
>>>Wie bereits von mehreren Leuten gepostet: Das ist unmöglich, insofern
>>>es mmap und einen sequentiellen Zugriff auf alle Zeichen
>>>hintereinander angeht.
>>
>>-rwxr-xr-x 1 root wheel 52076 Sep 23 23:42 bgrep128
>>-rwxr-xr-x 1 root wheel 52076 Sep 23 23:42 bgrep32
>>-rwxr-xr-x 1 root wheel 52076 Sep 23 23:42 bgrep64
> Hör' endlich auf, die Newsgroups mit Deinen Zeiten aus immer demselben
> Code vollzuspammen, dessen Richtigkeit Du als gegeben annimmst -- ohne
> Dich mit der Vermutung, Dein mmap-Code lese im Gegensatz zu Deinem
> read-Code Daten mehrfach, auseinanderzusetzen.
Was hat das mit dem Thema des Postings zu tun?:
>>>>>Helmut verwendet vermutlich eine für mmap
>>>>>ungünstige Blockgröße
>>>>
>>>>Habe 32..128KB verstärkt probiert: kein Unterschied.
>>>
>>>Wie bereits von mehreren Leuten gepostet: Das ist unmöglich, insofern
>>>es mmap und einen sequentiellen Zugriff auf alle Zeichen
>>>hintereinander angeht.
Der mmap-Code liest *nicht* mehrfach bei der verwendeten Testdatei!
Bei 17 Vorkommnissen von "iso" innerhalb von 31696 Pages ist diese
Annahme auch etwas fehl am Platz, um es milde auszudrücken.
Rainer Weikusat
>121] repeat 5 /usr/bin/time ./bgrep32 -c @iso /usr/z.iso
> 0.87 real 0.45 user 0.38 sys
> 0.88 real 0.51 user 0.33 sys
> 0.88 real 0.48 user 0.35 sys
> 0.88 real 0.46 user 0.38 sys
> 0.88 real 0.44 user 0.40 sys
>122] repeat 5 /usr/bin/time ./bgrep32 -cM @iso /usr/z.iso
> 1.04 real 0.94 user 0.04 sys
> 1.03 real 0.94 user 0.04 sys
> 1.04 real 0.95 user 0.03 sys
> 1.03 real 0.97 user 0.01 sys
> 1.03 real 0.97 user 0.03 sys
>123] repeat 5 /usr/bin/time ./bgrep64 -cM @iso /usr/z.iso
> 1.02 real 0.94 user 0.03 sys
> 1.02 real 0.95 user 0.02 sys
> 1.01 real 0.94 user 0.03 sys
> 1.01 real 0.92 user 0.05 sys
> 1.01 real 0.93 user 0.04 sys
Das besagt zunächst mal gar nichts außer das die Blockgröße für read
zu groß und für mmap zu klein und Deine Rechner zu schnell um für eine
Datei dieser Größe sinnvolle Messungen zu ermöglichen. Ferner ist die
annähernde Verdoppelugn der user-Zeit definitiv zu viel für eine
Implementierung, die auf den page-Unsinn verzichtet (es ist
entschuldbarer Unsinn, bleibt aber welcher).
Hier komme ich für eine 124M-Datei ~ auf ein Verhältnis von 1:2
zugunsten von mmap. Vergleichbarkeit können wir hier bestenfalls
herstellen, wenn wir denselben Code auf demselben mit dem demselben
file arbeiten lassen.
Jean Wolter
> 4M:
> method blocksize r/s/u maj/min
> ----------------------------------------------------
> read 8192 0.58/0.13/0.39 0/56
> mmap 8192 0.59/0.04/0.53 0/55
>
> read 65536 0.65/0.46/0.17 0/70
> mmap 65536 0.54/0.02//0.50 0/55
>
> 41M:
> method blocksize r/s/u maj/min
> ----------------------------------------------------
> read 8192 5.89/1.63/4.15 0/56
> mmap 8192 5.48/0.52/4.87 0/55
>
> read 65536 6.44/1.93/4.41 0/70
> mmap 65536 4.98/0.13/4.76 0/55
>
> Es ist auch auffällig, daß mmap in allen Fällen mehr 'user CPU'
> braucht, als read.
Die einfache Erklaerung dafuer waere doch (wenn man mal das Einlesen
der Daten, was ja in beiden Faellen passiert, ignoriert):
read: Kernel muss kopieren, braucht daher mehr system time
User liest aus warmem Cache und kann daher schneller suchen
mmap: Kernel macht nichts weiter, als on demand die Seiten
in die Pagetable eintragen und braucht dafuer wenig
system time
User liest aus kaltem Cache und braucht daher laenger
Ist die Erklaerung zu einfach?
MfG,
Jean
Matthias Andree
> Die Wahrheit ist: niemand kann sich erklären, warum bei mir und
> auch anderswo bei Verwendung von mmap die user-time höher liegt.
> Deshalb: Es muß am Schellong liegen.
Solange Schellong weder einen detaillierten Trace noch den KOMPLETTEN
Quelltext zur Verfügung stellt, ja.
Helmut Schellong
> Helmut Schellong <v...@schellong.biz> writes:
>
>
>>121] repeat 5 /usr/bin/time ./bgrep32 -c @iso /usr/z.iso
>> 0.87 real 0.45 user 0.38 sys
>> 0.88 real 0.51 user 0.33 sys
>> 0.88 real 0.48 user 0.35 sys
>> 0.88 real 0.46 user 0.38 sys
>> 0.88 real 0.44 user 0.40 sys
>>122] repeat 5 /usr/bin/time ./bgrep32 -cM @iso /usr/z.iso
>> 1.04 real 0.94 user 0.04 sys
>> 1.03 real 0.94 user 0.04 sys
>> 1.04 real 0.95 user 0.03 sys
>> 1.03 real 0.97 user 0.01 sys
>> 1.03 real 0.97 user 0.03 sys
>>123] repeat 5 /usr/bin/time ./bgrep64 -cM @iso /usr/z.iso
>> 1.02 real 0.94 user 0.03 sys
>> 1.02 real 0.95 user 0.02 sys
>> 1.01 real 0.94 user 0.03 sys
>> 1.01 real 0.92 user 0.05 sys
>> 1.01 real 0.93 user 0.04 sys
>
>
> Das besagt zunächst mal gar nichts außer das die Blockgröße für read
> zu groß
~22 KB const. > oder < wird langsamer.
> und für mmap zu klein
32, 64, 128 KB, 1, 32, 128 M
kein Unterschied!
Bei <=32 KB wird's langsamer.
(Ich wiederhole mich zum vielleicht 4. Mal)
> und Deine Rechner zu schnell um für eine
> Datei dieser Größe sinnvolle Messungen zu ermöglichen. Ferner ist die
> annähernde Verdoppelugn der user-Zeit definitiv zu viel für eine
> Implementierung, die auf den page-Unsinn verzichtet (es ist
> entschuldbarer Unsinn, bleibt aber welcher).
Ich löse mich mal von bisherigen Denkrichtungen und will das mal
mit meinem Ingenieur-Hardware-Wissen und Logik zu erklären versuchen:
1. Das Paging und die virtuellen Adressen sind in Hardware gegossen
und funktionieren ultraschnell. Der Prozessor hat dafür Units, die
in etwa parallel zur eigentlichen CPU (Pipelines,Instr.) arbeiten.
2. Der read-Buf hat ~22 KB und ist static.
Bei Anlage im Stack wird es ganz leicht langsamer.
Beim Start werden dem Programm 7 Pages (28K) zugeteilt.
3. Die Testdatei liegt vollständig im RAM (disk-cache).
4. mmap-Pages im Programm vergrößern entsprechend dessen Verbrauch.
Andere Pages werden also nicht in das Programm hineingelinkt.
Angesichts Multitasking und Write-->mmap-Pages wäre das auch unlogisch.
5. Wenn read die Datei liest, werden Datei-Pages in Buf-Pages kopiert.
Wenn mmap-Pages gelesen werden, werden sie aus den Datei-Pages gefüllt (kopiert).
6. Die beiden Vorgänge unter 5. sind unterschiedlich schnell.
Also wird unterschiedlich schnell kopiert.
Ob da unterschiedlicher Code unterschiedlich schnell programmiert wurde,
kann man allerdings nicht einfach so behaupten.
Helmut Schellong
> Rainer Weikusat wrote:
> ...
>> Helmut Schellong <v...@schellong.biz> writes:
[...]
> Ich löse mich mal von bisherigen Denkrichtungen und will das mal
> mit meinem Ingenieur-Hardware-Wissen und Logik zu erklären versuchen:
>
> 1. Das Paging und die virtuellen Adressen sind in Hardware gegossen
> und funktionieren ultraschnell. Der Prozessor hat dafür Units, die
> in etwa parallel zur eigentlichen CPU (Pipelines,Instr.) arbeiten.
> 2. Der read-Buf hat ~22 KB und ist static.
> Bei Anlage im Stack wird es ganz leicht langsamer.
> Beim Start werden dem Programm 7 Pages (28K) zugeteilt.
> 3. Die Testdatei liegt vollständig im RAM (disk-cache).
> 4. mmap-Pages im Programm vergrößern entsprechend dessen Verbrauch.
> Andere Pages werden also nicht in das Programm hineingelinkt.
> Angesichts Multitasking und Write-->mmap-Pages wäre das auch unlogisch.
> 5. Wenn read die Datei liest, werden Datei-Pages in Buf-Pages kopiert.
> Wenn mmap-Pages gelesen werden, werden sie aus den Datei-Pages
> gefüllt (kopiert).
> 6. Die beiden Vorgänge unter 5. sind unterschiedlich schnell.
> Also wird unterschiedlich schnell kopiert.
> Ob da unterschiedlicher Code unterschiedlich schnell programmiert wurde,
> kann man allerdings nicht einfach so behaupten.
Beweis mit getrusage(): utime + stime von FindS() [us]
FindS-mmap:
u=911520 s=22035
u=874872 s=65042
u=880763 s=66588
u=902112 s=37243
FindS-read:
u=223608 s=248330
u=282350 s=182253
u=228585 s=243196
u=207681 s=269450
Das deckt sich total mit allen bisherigen Messungen
mit /usr/bin/time, wobei time natürlich die gesamte
Programmzeit mißt. Insbesondere fehlt oben die read()-stime.
Man sieht, daß FindS() aus den read-Buf-Pages ~2-fach schneller
liest als aus den mmap-Pages (u+s).
Kai Ruhnau
>[Jede Menge nutzlose Zahlen ]
>
Ich hab gezeigt, dass das travel and salesman-Problem in P liegt
Beweis:
Mein Algorithmus hat O(n^15), aber der Quelltext ist geheim!
Wo ist die Millionen, die dafür ausgelobt wurde?
Wie wärs mal mit nem komplett lauffähigen Programm? Eins aus der Kathegorie
"~50 Zeilen, die das beschriebene Verhalten hervorrufen".
Nein, ich will eins von dir sehen. Nicht um mich über irgendeine Form zu
beschweren, sonder um eine Grundlage zu haben.
Grüße
Kai
Jean Wolter
> Ich löse mich mal von bisherigen Denkrichtungen und will das mal
> mit meinem Ingenieur-Hardware-Wissen und Logik zu erklären versuchen:
>
> 3. Die Testdatei liegt vollständig im RAM (disk-cache).
> 5. Wenn read die Datei liest, werden Datei-Pages in Buf-Pages
> kopiert.
Richtig. Der Kernel kopiert die Daten aus seinem internen Cache in
die Puffer des Nutzer. Die Daten gehen also von der Platte in den
internen Cache und dann via Kopie an den Nutzer.
> Wenn mmap-Pages gelesen werden, werden sie aus den Datei-Pages
> gefüllt (kopiert).
Falsch. Solange gelesen wird, macht der Kern nichts weiter, als die
Seiten seines Caches direkt beim Nutzer einzublenden. Der Nutzer
arbeitet also direkt auf den Daten, die auch im internen Cache des
Kernels liegen. Da wird nichts kopiert. Die Daten gehen von der Platte
in den internen Cache und sind dann via Adreßumsetzung auch beim
Nutzer sichtbar.
> 6. Die beiden Vorgänge unter 5. sind unterschiedlich schnell.
> Also wird unterschiedlich schnell kopiert.
Da bei mmap nicht kopiert wird, ist die Aussage falsch.
MfG,
Jean
Rainer Weikusat
> Die einfache Erklaerung dafuer waere doch (wenn man mal das Einlesen
> der Daten, was ja in beiden Faellen passiert, ignoriert):
>
> read: Kernel muss kopieren, braucht daher mehr system time
> User liest aus warmem Cache und kann daher schneller suchen
>
> mmap: Kernel macht nichts weiter, als on demand die Seiten
> in die Pagetable eintragen und braucht dafuer wenig
> system time
> User liest aus kaltem Cache und braucht daher laenger
>
> Ist die Erklaerung zu einfach?
Ja. So funktioniert ein L?-cache nicht.
Jean Wolter
Welcher der beiden Teile ist falsch und warum?
read: User liest aus warmem Cache oder
mmap: User liest aus kaltem Cache
Kannst Du da etwas ausführlicher werden?
Wenn ersterer: Ich habe nicht nach der Plattform gefragt, ich habe
einfach einen halbwegs aktuellen x86 angenommen. Gibt es da im
Augenblick welche, die kein write-allocate machen (also beim schreiben
einer nicht im Cache enthaltenen Zeile eine entsprechende Allokieren)?
Bei einem Cache mit write-allocate würde die obige Aussage stimmen.
Wenn er allerdings write through macht, ist das mit dem warmen Cache
natürlich falsch.
MfG,
Jean
Rainer Weikusat
> Rainer Weikusat <weik...@students.uni-mainz.de> writes:
>> Jean Wolter <j...@konrad.inf.tu-dresden.de> writes:
>> > Die einfache Erklaerung dafuer waere doch (wenn man mal das Einlesen
>> > der Daten, was ja in beiden Faellen passiert, ignoriert):
>> >
>> > read: Kernel muss kopieren, braucht daher mehr system time
>> > User liest aus warmem Cache und kann daher schneller suchen
>> >
>> > mmap: Kernel macht nichts weiter, als on demand die Seiten
>> > in die Pagetable eintragen und braucht dafuer wenig
>> > system time
>> > User liest aus kaltem Cache und braucht daher laenger
>> >
>> > Ist die Erklaerung zu einfach?
>>
>> Ja. So funktioniert ein L?-cache nicht.
[...]
> Kannst Du da etwas ausführlicher werden?
Ich bin weder daran interessiert, Dein Glaubensgebilde zum Einsturz zu
bringen, noch daran, es zu bestätigen.
Matthias Andree
> Beweis mit getrusage(): utime + stime von FindS() [us]
Das ist kein Beweis, sondern eine einzelne Stichprobe.
Matthias Andree
> 1. Das Paging und die virtuellen Adressen sind in Hardware gegossen
> und funktionieren ultraschnell. Der Prozessor hat dafür Units, die
> in etwa parallel zur eigentlichen CPU (Pipelines,Instr.) arbeiten.
"in etwa" gibt's nicht. Ja oder nein? Ich sag's Dir: Ja. Die Dinger
heißen nicht umsonst "Translation LOOKASIDE Buffer" (nenn' sie Address
Translation Cache, selbes Spiel).
> 2. Der read-Buf hat ~22 KB und ist static.
> Bei Anlage im Stack wird es ganz leicht langsamer.
Warum?
> Beim Start werden dem Programm 7 Pages (28K) zugeteilt.
> 3. Die Testdatei liegt vollständig im RAM (disk-cache).
> 4. mmap-Pages im Programm vergrößern entsprechend dessen Verbrauch.
Welchen Verbrauch und warum?
> Andere Pages werden also nicht in das Programm hineingelinkt.
> Angesichts Multitasking und Write-->mmap-Pages wäre das auch
> unlogisch.
Warum?
> 5. Wenn read die Datei liest, werden Datei-Pages in Buf-Pages kopiert.
Ja.
> Wenn mmap-Pages gelesen werden, werden sie aus den Datei-Pages
> gefüllt (kopiert).
Nein, sie werden gemappt. Das ist der Sinn der Übung: Kopieren
vermeiden.
> 6. Die beiden Vorgänge unter 5. sind unterschiedlich schnell.
Beweis?
> Also wird unterschiedlich schnell kopiert.
> Ob da unterschiedlicher Code unterschiedlich schnell programmiert wurde,
> kann man allerdings nicht einfach so behaupten.
Eben.
Matthias Andree
> Wenn er allerdings write through macht, ist das mit dem warmen Cache
> natürlich falsch.
Bist Du sicher, dass Du Paging, Caching und "write through" verstanden
hast? Ich nicht. Tip: "Write Through" vs. "Write Back" bestimmt nur den
Zeitpunkt des Cache Flush (und damit ggf. auch Synchronisation an das
Speicherinterface), es hat mit Cacheable oder Cache Invalidate herzlich
wenig zu tun.
Außerdem erübrigt sich die Betrachtung ohnehin schon bei einer
Dateigröße von 4 MB (damit bläst Du derzeit jeden Cache eines PC und
auch Caches vieler Workstations frei), das 32-fache davon steht zur
Diskussion.
Helmut Schellong
> Helmut Schellong <r...@schellong.biz> writes:
>
>
>>1. Das Paging und die virtuellen Adressen sind in Hardware gegossen
>> und funktionieren ultraschnell. Der Prozessor hat dafür Units, die
>> in etwa parallel zur eigentlichen CPU (Pipelines,Instr.) arbeiten.
>
>
> "in etwa" gibt's nicht. Ja oder nein? Ich sag's Dir: Ja. Die Dinger
> heißen nicht umsonst "Translation LOOKASIDE Buffer" (nenn' sie Address
> Translation Cache, selbes Spiel).
Gibt es sehr wohl - zeitlich gesehen.
Trotz Parallelität versteckt sich der Zeitbedarf nicht vollkommen
im Zeitbedarf anderer Einheiten. Eine parallele Unit muß u.a.
auch 'bedient' werden.
Die Arbeit einer parallelen Unit kann auch gewissen Zeitmehrbedarf
in anderen Units bewirken, durch indirekte Effekte.
>>2. Der read-Buf hat ~22 KB und ist static.
>> Bei Anlage im Stack wird es ganz leicht langsamer.
>
>
> Warum?
Weil Stack-Pages nach und nach 'reingenommen' werden.
>
>> Beim Start werden dem Programm 7 Pages (28K) zugeteilt.
>>3. Die Testdatei liegt vollständig im RAM (disk-cache).
>>4. mmap-Pages im Programm vergrößern entsprechend dessen Verbrauch.
>
>
> Welchen Verbrauch und warum?
top zeigt einen entsprechenden RAM-Bedarf von bgrep an.
Wenn ich 126 MB mappe UND LESE, zeigt top 126 MB Verbrauch an.
>> Andere Pages werden also nicht in das Programm hineingelinkt.
>> Angesichts Multitasking und Write-->mmap-Pages wäre das auch
>> unlogisch.
>
>
> Warum?
Man kann doch nicht Datei-Pages aus dem Disk-Cache in beliebig viele
Prozesse lediglich hineinmappen, wenn diese Prozesse darauf konkret
zugreifen. Zunächst schon, bei mmap allein, aber folgend nicht mehr.
>>5. Wenn read die Datei liest, werden Datei-Pages in Buf-Pages kopiert.
>
>
> Ja.
>
>
>> Wenn mmap-Pages gelesen werden, werden sie aus den Datei-Pages
>> gefüllt (kopiert).
>
>
> Nein, sie werden gemappt. Das ist der Sinn der Übung: Kopieren
> vermeiden.
Aber ja, sie werden zunächst gemapt durch mmap.
Deshalb ist der Aufruf von mmap auch fast ohne Zeitbedarf im Vergleich.
Aber bei Zugriff werden dann Page-Kopien erstellt.
>>6. Die beiden Vorgänge unter 5. sind unterschiedlich schnell.
>
>
> Beweis?
Meine geposteten getrusage-Zahlen.
>> Also wird unterschiedlich schnell kopiert.
>> Ob da unterschiedlicher Code unterschiedlich schnell programmiert wurde,
>> kann man allerdings nicht einfach so behaupten.
>
>
> Eben.
>
--
Helmut Schellong
> Helmut Schellong <r...@schellong.biz> writes:
>
>
>>Beweis mit getrusage(): utime + stime von FindS() [us]
>
>
> Das ist kein Beweis, sondern eine einzelne Stichprobe.
Das ist sehr wohl ein Beweis, daß es *bei mir* so ist.
Ich schildere hier *NUR MEINE* Beobachtungen von read+mmap!
Bernd Petrovitsch
> Ich habe den relevanten Code zweimal gepostet, auch FindS().
Du hast das gepostet, was du für den relevanten Code hältst, nicht
den kompletten.
> Die Wahrheit ist: niemand kann sich erklären, warum bei mir und
> auch anderswo bei Verwendung von mmap die user-time höher liegt.
> Deshalb: Es muß am Schellong liegen.
Der Schluß liegt nahe, zumal du den Gegenbeweis nicht antreten
willst.
Bernd
--
Bernd Petrovitsch Email : be...@bofh.at
"For I was talking aloud to myself. A habit of the old: they choose
the wisest person present to speak to; the long explanations needed
by the young are wearying." --- Gandalf, the White
Helmut Schellong
> Helmut Schellong <r...@schellong.biz> writes:
>>Wenn mmap-Pages gelesen werden, werden sie aus den Datei-Pages
>>gefüllt (kopiert).
>
>
> Falsch. Solange gelesen wird, macht der Kern nichts weiter, als die
> Seiten seines Caches direkt beim Nutzer einzublenden. Der Nutzer
> arbeitet also direkt auf den Daten, die auch im internen Cache des
> Kernels liegen. Da wird nichts kopiert. Die Daten gehen von der Platte
> in den internen Cache und sind dann via Adreßumsetzung auch beim
> Nutzer sichtbar.
Warum braucht dann die Funktion FindS beim Lesen vom mmap-Pointer
doppelt soviel Zeit wie beim Lesen vom read-Buf-Pointer?
Helmut Schellong
> On Wed, 24 Sep 2003 16:11:51 +0200, Helmut Schellong wrote:
>
>>Ich habe den relevanten Code zweimal gepostet, auch FindS().
>
>
> Du hast das gepostet, was du für den relevanten Code hältst, nicht
> den kompletten.
Ich postete jeglichen relevanten Code.
Total komplett, mit nichtrelevantem Code geht nicht, weil
Quellcode-Libs eingebunden sind. Ich postete dies schon einmal.
>>Die Wahrheit ist: niemand kann sich erklären, warum bei mir und
>>auch anderswo bei Verwendung von mmap die user-time höher liegt.
>>Deshalb: Es muß am Schellong liegen.
>
>
> Der Schluß liegt nahe, zumal du den Gegenbeweis nicht antreten
> willst.
Nein, man will offenbar den kompletten relevanten Code nicht benutzen, um
nicht Gefahr zu laufen, auf ähnliche Ergebnisse wie ich zu kommen.
Jeglicher restlicher Code, den ich nicht postete, dient *nur* der
Kommando-Options-Verarbeitung und ist vollkommen irrelevant!
Ausnahmen wie FDi= open("Datei" sind wohl trivial,
ebenso Offs=0, Nmax=nGB oder Nmax=filesz.
Matthias Andree
> Matthias Andree wrote:
>> Helmut Schellong <r...@schellong.biz> writes:
>>
>>>Beweis mit getrusage(): utime + stime von FindS() [us]
>> Das ist kein Beweis, sondern eine einzelne Stichprobe.
>
> Das ist sehr wohl ein Beweis, daß es *bei mir* so ist.
Du bist ein Idiot. Erst entschuldigst Du Deinen lausigen und unlesbaren
Code mit "Nähe zur Mathematik", dann behauptest Du, Du hättest
Elektrotechnik studiert (im ersten Semester abgebrochen?), und nun
willst Du durch eine nicht verifizierbare Messung einen direkten Beweis
führen. Verzieh Dich wieder an Deine Arbeit, Du bist nicht mehr lustig.
Matthias Andree
> Matthias Andree wrote:
>> Helmut Schellong <r...@schellong.biz> writes:
>>
>>>1. Das Paging und die virtuellen Adressen sind in Hardware gegossen
>>> und funktionieren ultraschnell. Der Prozessor hat dafür Units, die
>>> in etwa parallel zur eigentlichen CPU (Pipelines,Instr.) arbeiten.
>> "in etwa" gibt's nicht. Ja oder nein? Ich sag's Dir: Ja. Die Dinger
>> heißen nicht umsonst "Translation LOOKASIDE Buffer" (nenn' sie Address
>> Translation Cache, selbes Spiel).
>
> Gibt es sehr wohl - zeitlich gesehen.
> Trotz Parallelität versteckt sich der Zeitbedarf nicht vollkommen
> im Zeitbedarf anderer Einheiten. Eine parallele Unit muß u.a.
> auch 'bedient' werden.
> Die Arbeit einer parallelen Unit kann auch gewissen Zeitmehrbedarf
> in anderen Units bewirken, durch indirekte Effekte.
red herring. Du hast immer noch kein Profil Deines Codes vorgelegt.
>>>2. Der read-Buf hat ~22 KB und ist static.
>>> Bei Anlage im Stack wird es ganz leicht langsamer.
>> Warum?
>
> Weil Stack-Pages nach und nach 'reingenommen' werden.
Muss man nicht verstehen.
>>>4. mmap-Pages im Programm vergrößern entsprechend dessen Verbrauch.
>> Welchen Verbrauch und warum?
>
> top zeigt einen entsprechenden RAM-Bedarf von bgrep an.
Wenn Du glaubst, top(1) würde _RAM_-Bedarf anzeigen, bist Du verdammt
schief gewickelt.
>>> Andere Pages werden also nicht in das Programm hineingelinkt.
>>> Angesichts Multitasking und Write-->mmap-Pages wäre das auch
>>> unlogisch.
>> Warum?
>
> Man kann doch nicht Datei-Pages aus dem Disk-Cache in beliebig viele
> Prozesse lediglich hineinmappen, wenn diese Prozesse darauf konkret
> zugreifen. Zunächst schon, bei mmap allein, aber folgend nicht mehr.
Natürlich kann man, auch, wenn Du das nicht verstehst. "Unified
Cache"-Konzepte?
> Aber ja, sie werden zunächst gemapt durch mmap.
> Deshalb ist der Aufruf von mmap auch fast ohne Zeitbedarf im Vergleich.
> Aber bei Zugriff werden dann Page-Kopien erstellt.
Nein, wozu sollte man kopieren? Ob ich Original oder Kopie lese, ist
egal.
Du weißt nicht, was Du tust.
>>>6. Die beiden Vorgänge unter 5. sind unterschiedlich schnell.
>> Beweis?
>
> Meine geposteten getrusage-Zahlen.
Nein. Weil es heute um 18:48 Uhr 17,5°C draußen hat, hat es jeden Tag um
18:48 Uhr 17,5°C draußen.
Matthias Andree
> Bernd Petrovitsch wrote:
>> On Wed, 24 Sep 2003 16:11:51 +0200, Helmut Schellong wrote:
>>
>>>Ich habe den relevanten Code zweimal gepostet, auch FindS().
>> Du hast das gepostet, was du für den relevanten Code hältst, nicht
>> den kompletten.
>
> Ich postete jeglichen relevanten Code.
"relevant" ist er, wenn ich ihn auf meiner BSD- oder Linux-Maschine
übersetzen und laufen lassen kann.
> Total komplett, mit nichtrelevantem Code geht nicht, weil
> Quellcode-Libs eingebunden sind. Ich postete dies schon einmal.
Du bist auch schon mehrfach dazu aufgefordert worden, einen anderen Code
zur Analyse zur Verfügung zu stellen, der dasselbe Verhalten zeigt. Das
Angebot steht immer noch, Du gehst nicht darauf ein, deswegen rennst Du
mit dem Schädel gegen die Wand.
Vermutlich scheust Du, ihn zu schreiben, weil Dir dabei die Lampe auf-
oder angehen könnte, was in Deinem FindS() und dem Müll drumherum
schiefläuft, oder weil sich damit das Problem (mangels Bugs) nicht
zeigen lässt.
Matthias Andree
> Warum braucht dann die Funktion FindS beim Lesen vom mmap-Pointer
> doppelt soviel Zeit wie beim Lesen vom read-Buf-Pointer?
Das könnte Dir ein Profiler-Lauf oder ein Syscall-Tracer sagen, den Du
seit Wochen verweigerst.
Helmut Schellong
> Helmut Schellong <r...@schellong.biz> writes:
>
>
>>Matthias Andree wrote:
>>
>>>Helmut Schellong <r...@schellong.biz> writes:
>>>
>>>
>>>>Beweis mit getrusage(): utime + stime von FindS() [us]
>>>
>>>Das ist kein Beweis, sondern eine einzelne Stichprobe.
>>
>>Das ist sehr wohl ein Beweis, daß es *bei mir* so ist.
>
>
> Du bist ein Idiot. Erst entschuldigst Du Deinen lausigen und unlesbaren
> Code mit "Nähe zur Mathematik",
Wie bitte?!
Ich habe es nicht entschuldigt, sondern lediglich die Ursache *erklärt*.
Ich werde auch weiterhin meinen Privat-Code so schreiben, wie bisher
und wie ich es will.
Uns es mir vollkommen egal, ob mein Privat-Code für andere lesbar ist oder nicht.
Ich habe den Code erst nach mehrfacher Aufforderung gezeigt - nun seht zu,
wie ihr damit klar kommt.
Wer nicht mit diesem winzigen Code klar kommt, ist in meinen Augen schlicht
unfähig und hat sich disqualifiziert.
> willst Du durch eine nicht verifizierbare Messung einen direkten Beweis
> führen. [...]
Wer nicht in der Lage ist, anhand meines Codes zu verifizieren, ist meines
Erachtens unfähig und hat sich damit disqualifiziert, oder er will es
in Wahrheit absichtlich nicht, aus nur vermutbaren Gründen.
Helmut Schellong
> Helmut Schellong <r...@schellong.biz> writes:
>
>
>>Bernd Petrovitsch wrote:
>>
>>>On Wed, 24 Sep 2003 16:11:51 +0200, Helmut Schellong wrote:
>>>
>>>
>>>>Ich habe den relevanten Code zweimal gepostet, auch FindS().
>>>
>>>Du hast das gepostet, was du für den relevanten Code hältst, nicht
>>>den kompletten.
>>
>>Ich postete jeglichen relevanten Code.
>
>
> "relevant" ist er, wenn ich ihn auf meiner BSD- oder Linux-Maschine
> übersetzen und laufen lassen kann.
>
>
>>Total komplett, mit nichtrelevantem Code geht nicht, weil
>>Quellcode-Libs eingebunden sind. Ich postete dies schon einmal.
>
>
> Du bist auch schon mehrfach dazu aufgefordert worden, einen anderen Code
> zur Analyse zur Verfügung zu stellen, der dasselbe Verhalten zeigt. Das
> Angebot steht immer noch, Du gehst nicht darauf ein, deswegen rennst Du
> mit dem Schädel gegen die Wand.
Es gibt keinen anderen Code.
Ich zeigte den Code vollständig, mit dem man verifizieren kann.
> Vermutlich scheust Du, ihn zu schreiben, weil Dir dabei die Lampe auf-
> oder angehen könnte, was in Deinem FindS() und dem Müll drumherum
> schiefläuft, oder weil sich damit das Problem (mangels Bugs) nicht
> zeigen lässt.
Ich zeigte den relevanten Code vollständig. Niemand fand darin Bugs.
Ich stelle fest, daß hier eine extreme geistige und logische Unbeweglichkeit
seitens der meisten Teilnehmer vorliegt.
Ich sagte eingangs - ganz zu Anfang schon, daß mein Lesekode vom
mmap-Pointer halb so schnell liest wie vom read-Buf-Pointer.
*Diese Angabe allein* reicht schon, um die Sache komplett zu
verifizieren, sofern man tatsächliche Bugs in meinem Code ausschließt.
Man sehe und staune:
char volatile c;
while (bp<bp_end) c= *bp++;
reicht als FindS()-Ersatz voll aus!
Es zeigt sich das *gleiche* zeitliche Verhalten!
Aber auf ein solches reduziertes Ersatzszenario kommt hier niemand,
obwohl es logisch geboten ist.
Muß ich den Lieben noch erklären, was es mit bp und bp_end
auf sich hat?, oder reicht die Programmiererfahrung und -intelligenz
ohne meine Hilfe dazu aus?
Helmut Schellong
> Helmut Schellong <r...@schellong.biz> writes:
>
>
>>Warum braucht dann die Funktion FindS beim Lesen vom mmap-Pointer
>>doppelt soviel Zeit wie beim Lesen vom read-Buf-Pointer?
>
>
> Das könnte Dir ein Profiler-Lauf oder ein Syscall-Tracer sagen, den Du
> seit Wochen verweigerst.
Nein, was soll sich da denn anderes ergeben?!
Und was haste jetzt von Folgendem?:
% cumulative self self total
time seconds seconds calls ms/call ms/call name
97.5 0.94 0.94 991 0.95 0.95 FindS [4]
1.6 0.95 0.02 993 0.02 0.02 __syscall [5]
0.8 0.96 0.01 991 0.01 0.01 munmap [7]
0.1 0.96 0.00 Find [8]
0.0 0.96 0.00 991 0.00 0.02 mmap [6]
0.0 0.96 0.00 10 0.00 0.00 crc32 [10]
0.0 0.96 0.00 5 0.00 0.00 strlen_F [11]
0.0 0.96 0.00 5 0.00 0.00 testcrc [12]
0.0 0.96 0.00 2 0.00 0.00 GetEnv [13]
0.0 0.96 0.00 2 0.00 0.00 ___sysctl [156]
0.0 0.96 0.00 2 0.00 0.02 lseek [9]
0.0 0.96 0.00 2 0.00 0.00 sysctl [14]
0.0 0.96 0.00 2 0.00 0.00 write [15]
0.0 0.96 0.00 1 0.00 0.00 Conv3D2H [16]
0.0 0.96 0.00 1 0.00 961.88 FindM [3]
0.0 0.96 0.00 1 0.00 0.00 _close [157]
0.0 0.96 0.00 1 0.00 0.00 _mcleanup (158)
0.0 0.96 0.00 1 0.00 0.00 _open [159]
0.0 0.96 0.00 1 0.00 0.00 _profil [160]
0.0 0.96 0.00 1 0.00 0.00 autor [17]
0.0 0.96 0.00 1 0.00 961.91 bgrep [1]
0.0 0.96 0.00 1 0.00 0.00 getpagesize [18]
0.0 0.96 0.00 1 0.00 0.00 ioctl [19]
0.0 0.96 0.00 1 0.00 0.00 isatty [20]
0.0 0.96 0.00 1 0.00 0.00 moncontrol [21]
0.0 0.96 0.00 1 0.00 0.00 tcgetattr [22]
0.0 0.96 0.00 1 0.00 0.00 ultoa_F [23]
0.0 0.96 0.00 1 0.00 0.00 utoa_H [24]
0.0 0.96 0.00 1 0.00 0.00 writef [25]
% cumulative self self total
time seconds seconds calls ms/call ms/call name
53.6 0.43 0.43 6340 0.07 0.07 FindS [4]
46.1 0.80 0.37 6341 0.06 0.06 read [5]
0.1 0.81 0.00 1 0.98 805.66 Find [1]
0.1 0.81 0.00 .mcount (22)
0.0 0.81 0.00 21 0.00 0.00 memcpy_F [6]
0.0 0.81 0.00 10 0.00 0.00 crc32 [7]
0.0 0.81 0.00 5 0.00 0.00 strlen_F [8]
0.0 0.81 0.00 5 0.00 0.00 testcrc [9]
0.0 0.81 0.00 2 0.00 0.00 GetEnv [10]
0.0 0.81 0.00 2 0.00 0.00 write [11]
0.0 0.81 0.00 1 0.00 0.00 Conv3D2H [12]
0.0 0.81 0.00 1 0.00 0.00 ___sysctl [155]
0.0 0.81 0.00 1 0.00 0.00 _close [156]
0.0 0.81 0.00 1 0.00 0.00 _mcleanup (157)
0.0 0.81 0.00 1 0.00 0.00 _open [158]
0.0 0.81 0.00 1 0.00 0.00 _profil [159]
0.0 0.81 0.00 1 0.00 0.00 autor [13]
0.0 0.81 0.00 1 0.00 805.66 bgrep [2]
0.0 0.81 0.00 1 0.00 0.00 ioctl [14]
0.0 0.81 0.00 1 0.00 0.00 isatty [15]
0.0 0.81 0.00 1 0.00 0.00 moncontrol [16]
0.0 0.81 0.00 1 0.00 0.00 sysctl [17]
0.0 0.81 0.00 1 0.00 0.00 tcgetattr [18]
0.0 0.81 0.00 1 0.00 0.00 ultoa_F [19]
0.0 0.81 0.00 1 0.00 0.00 utoa_H [20]
0.0 0.81 0.00 1 0.00 0.00 writef [21]
Jean Wolter
> Außerdem erübrigt sich die Betrachtung ohnehin schon bei einer
> Dateigröße von 4 MB (damit bläst Du derzeit jeden Cache eines PC und
> auch Caches vieler Workstations frei), das 32-fache davon steht zur
> Diskussion.
Vielleicht habe ich ja den Code falsch verstanden, aber ich deute das
hier:
int bsiz = 1 << 16;
...
puts("testing read");
getrusage(RUSAGE_SELF, &r1);
p = malloc(bsiz);
for (i = 0; i < size; i+=bsiz) {
int j;
if (read(fd, p, bsiz) != bsiz) barf("read");
for (j = 0; j < bsiz; j++) {
csum -= ((char *)p)[j];
}
}
free(p);
getrusage(RUSAGE_SELF, &r2);
als n-maliges Lesen von 65536 Byte in einen via malloc allokierten
Puffer. Der Puffer ist immer der selbe, er passt (von Konflikten
aufgrund der potentiellen Abbildung auf die gleiche Cacheline mal
abgesehen) komplett in den Cache. Der Kern kopiert also Daten aus
einem wahrscheinlich nicht im Cache befindlichen Bereich seines
Filecaches in einen Bereich, der spätestens nach dem ersten Generieren
der Checksumme im Cache ist.
Und ich kann da nicht erkennen, daß der Cache aufgrund der Dateigröße
komplett rausgeblasen wird.
Um auch mal ein paar Messungen zur allgemeinen Erheiterung in die
Runde zu werfen: Performance-Counter auf dem P6 angeworfen und die
Memory Transaktionen gezaehlt:
#define P6_BUS_TRAN_MEM 0x6f /* (@) total memory txns */
#define P6CNT_U 0x010000 /* Monitor user-level events */
#define P6CNT_K 0x020000 /* Monitor kernel-level events */
#define P6CNT_EN 0x400000 /* enable counters (in PerfEvtSel0) */
eventcounter 0 : 0x410f6f
eventcounter 1 : 0x020f6f
Ergebnis (einer der Laeufe, die anderen aehneln diesem):
testing mmap
user: 1.880000
syst: 0.240000
minflt 3; majflt 65538; swaps 0
transactions: user : 84cefc kernel: 17def0
testing chunked
user: 1.660000
syst: 0.160000
minflt 0; majflt 65536; swaps 0
transactions: user: 83d24d kernel: 9696f
testing read
user: 1.000000
syst: 0.780000
minflt 16; majflt 0; swaps 0
transactions: user: d0aa kernel: 93cd63
Das spricht irgendwie fuer die These mit dem warmen Cache, der User
macht im read Falle kaum Memory-Transaktionen (0xd0aa beim read versus
0x83d24d beim mmap) und mir faellt ausser dem Cache kein Ort ein, wo
er die Daten herbekommen sollte.
> Jean Wolter <j...@konrad.inf.tu-dresden.de> writes:
>
> > Wenn er allerdings write through macht, ist das mit dem warmen Cache
> > natürlich falsch.
>
> Bist Du sicher, dass Du Paging ... verstanden hast? Ich nicht.
Hmm, es hat gereicht, um den architekturabhaengigen Teil der
Linux-Speicherverwaltung an unsere Plattform anzupassen. Ich nahm
bisher an, dass man dazu etwas von Paging verstanden haben muss. Aber
das kann natuerlich auch ein Irrtum sein.
> Tip: "Write Through" vs. "Write Back" bestimmt nur den Zeitpunkt des
> Cache Flush (und damit ggf. auch Synchronisation an das
> Speicherinterface), es hat mit Cacheable oder Cache Invalidate
> herzlich wenig zu tun.
Ich bin mir relativ sicher, daß ich die Begriffe richtig verstanden
habe. Aber ich kann ja nochmal eine Kurzform aufführen, nur um
sicherzugehen, dass wir über das gleiche reden:
- write through:
Bei einer Schreiboperation werden Daten immer sofort in den
Speicher geschrieben; Cachelines sind immer identisch mit dem
Inhalt des Speichers, den sie gerade "cachen"
- write back:
Ist die zu schreibende Adresse nicht im Cache, wird direkt in
den Speicher geschrieben.
Wird auf eine Adresse geschrieben, die im Cache enthalten ist,
wird nur die Cacheline verändert; der Speicher enthält
weiterhin den Originalwert; die Chacheline wird als Dirty
markiert. Wird die Cacheline anderweitig benötigt, wird erst
der Wert zurückgeschrieben und dann der neue Wert geladen.
Caches überwachen parallell laufende Aktivitäten wie DMA um
Änderungen der von Ihnen zwischengespeicherten Werte zu
erkennen und sie dann zu invalidieren
- write allocate:
Ist die zu schreibende Adresse nicht im Cache, wird sie
eingelesen und der Wert im Cache verändert. Rest siehe write
Back.
Wo ich irgendwas von cachable und cacheinvalidation geschrieben habe,
weiss ich nicht. Vielleicht die These nochmal etwas ausführlicher:
Beim read kopiert der Kern aus seinem File-Cache in den Puffer des
Nutzers. Arbeitet der Cache der CPU nicht nach write through, sind die
geschriebenen Daten jetzt wahrscheinlich im Cache, da:
- der Nutzer die cachelines durch das Berechen der Checksumme in
den Cache geholt hat,
- der Cache bei Vorhandensein der dazugehoerigen Cacheline die
Daten im Cache modifiziert und erst zurueckschreibt, wenn die
Cacheline verdraengt wird.
Der user berechnet die Checksumme also zum Grossen Teil ueber im
Cache befindlichen Daten. Das Zurueckschreiben der schmutzigen
Cachelines erledigt auch der Kern, da er derjenige ist, der die
Cachlines beim naechsten read verdraengen wird, wenn er die zu
kopierenden Daten aus seinem File-Cache liest.
Beim mmap-Fall dagegen sind die Daten garantiert nicht im Cache. Sie
werden von der Hardware per DMA in den Speicher geschrieben (die
Caches lauschen mit und invalidieren gegebenenfalls gecachte Daten,
falls sie ueberschrieben werden), der user findet also nach dem
Aufloesen des Seitenfehlers beim Zugriff auf die Daten nichts im Cache
vor und muss alles selber erst reinholen.
Aber das kann natuerlich auch alles falsch sein, da caches ja ganz
anders funktionieren und ich auch nichts von Paging verstehe.
MfG,
Jean
Helmut Schellong
> Matthias Andree <matthia...@gmx.de> writes:
> [...]
> Cachlines beim naechsten read verdraengen wird, wenn er die zu
> kopierenden Daten aus seinem File-Cache liest.
>
> Beim mmap-Fall dagegen sind die Daten garantiert nicht im Cache. Sie
> werden von der Hardware per DMA in den Speicher geschrieben (die
> Caches lauschen mit und invalidieren gegebenenfalls gecachte Daten,
> falls sie ueberschrieben werden), der user findet also nach dem
> Aufloesen des Seitenfehlers beim Zugriff auf die Daten nichts im Cache
> vor und muss alles selber erst reinholen.
>
> Aber das kann natuerlich auch alles falsch sein, da caches ja ganz
> anders funktionieren und ich auch nichts von Paging verstehe.
Ich denke in diesem Zusammenhang an den L1-Cache (16K+16K) und L2 (256K).
Mein read-Buf ist ja ~20K groß; 16..20K sind optimal, 32K langsamer.
Hingegen bei mmap waren Bereiche ab 32K bis nnn MB praktisch gleich schnell.
Beim Pentium1 mov[mem]-Instruktion: 2-4 Takte (hit/missing).
Die Caches scheinen für read zu arbeiten, nicht jedoch für mmap.
Allerdings hatte ich auch mal MAP_FIXED probiert und mmap(Buf,
verwendet, also immer die gleiche static-Buf-Adresse (wie bei read):
Keine Änderung beim Lesetempo.
Die Start-Pages von Buf waren hier wohl nicht mehr zugreifbar,
also keine Änderung zu ohne MAP_FIXED.