Not OK: perl v5.7.0 +DEVEL8069 on i586-linux-64all 2.2.12 (UNINSTALLED)

p5pRT commented 23 years ago

Migrated from rt.perl.org#4901 (status was 'resolved')

Searchable as RT4901$

p5pRT commented 23 years ago

From @nwc10

Mostly this is an OK no PERLIO env var

All tests successful. u=1.34 s=0.54 cu=72.52 cs=12.81 scripts=270 tests=14295

export PERLIO=mmap

All tests successful. u=1.32 s=0.53 cu=68.54 cs=11.4 scripts=270 tests=14295

export PERLIO=stdio

All tests successful. u=1.52 s=0.56 cu=71.37 cs=11.47 scripts=270 tests=14295

export PERLIO=unix

Failed 1 test script out of 270\, 99.63% okay. u=1.87 s=0.87 cu=88.89 cs=68.91 scripts=270 tests=14295

./perl t/lib/posix.t 1..27 ok 1 ok 2 ok 3 ok 4 ok 5 ok 6 ok 7 ok 8 ok 9 ok 10 ok 11 ok 12 ok 13 ok 14 ok 15 ok 16 ok 17 ok 18 # 13:15\, on 12/11/00 ok 19 ok 20 ok 21 ok 22 ok 23 ok 24 ok 25 ok 26 ok 27 @#!*$@(!@#$nick@liam [bleadperl]$

"nick@liam [bleadperl]$ " being the shell prompt. So same problem as BSD with "unix"

is "mmap" usually faster?

Nicholas Clark

Perl Info

``` Flags: category=install severity=none Site configuration information for perl v5.7.0: Configured by nick at Mon Dec 11 12:20:54 GMT 2000. Summary of my perl5 (revision 5.0 version 7 subversion 0) configuration: Platform: osname=linux, osvers=2.2.12, archname=i586-linux-64all uname='linux liam 2.2.12 #2 thu aug 26 11:46:26 pdt 1999 i586 unknown ' config_args='-Dusedevel -Ubincompat5005 -Uinstallusrbinperl -Dcf_email=nick@talking.bollo.cx -Dperladmin=nick@talking.bollo.cx -Dinc_version_list= -Dinc_version_list_init=0 -Duse64bitint -Duse64bitall -Duseperlio -de' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=define uselongdouble=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.95.2 20000220 (Debian GNU/Linux)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -ldb -ldl -lm -lc -lposix -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lposix -lcrypt -lutil libc=/lib/libc-2.1.3.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Locally applied patches: DEVEL8069 @INC for perl v5.7.0: lib /usr/local/lib/perl5/5.7.0/i586-linux-64all /usr/local/lib/perl5/5.7.0 /usr/local/lib/perl5/site_perl/5.7.0/i586-linux-64all /usr/local/lib/perl5/site_perl/5.7.0 /usr/local/lib/perl5/site_perl . Environment for perl v5.7.0: HOME=/home/nick LANG=C LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games PERLIO=unix PERL_BADLANG (unset) SHELL=/bin/sh ```

p5pRT commented 23 years ago

From @jhi

@#!*$@(!@#$nick@liam [bleadperl]$

"nick@liam [bleadperl]$ " being the shell prompt.

Could have fooled me\, with a host name like "talking.bollo.cx" :-)

So same problem as BSD with "unix"

is "mmap" usually faster?

I've yet to see any significant speedup in Digital UNIX / Solaris / Linux. I think the reason why there seems to be no much difference might be that it *used* to be that in then olden days mmap was faster than 'raw system io' since mmap\, errm\, really was faster. The basic system IO didn't yet used the same buffer as mmap (I think in some systems at least this new scheme is called the "unified buffer cache"). But in recent years the IO implementations have merged. Ergo\, no difference\, because there is no difference.

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

Jarkko spoke thus on 11 Dec 2000:

@#!*$@(!@#$nick@liam [bleadperl]$

"nick@liam [bleadperl]$ " being the shell prompt.

Could have fooled me\, with a host name like "talking.bollo.cx" :-)

So same problem as BSD with "unix"

is "mmap" usually faster?

I've yet to see any significant speedup in Digital UNIX / Solaris / Linux. I think the reason why there seems to be no much difference might be that it *used* to be that in then olden days mmap was faster than 'raw system io' since mmap\, errm\, really was faster. The basic system IO didn't yet used the same buffer as mmap (I think in some systems at least this new scheme is called the "unified buffer cache"). But in recent years the IO implementations have merged. Ergo\, no difference\, because there is no difference.

For the little it is worth\, I experimented some with mmap on an external sort command\, (primarily on an SGI and a linux PC). The observed behavior was that mmap was a net *loss* on output\, and pretty much a tie on input (as contrasted with read() and write() calls of rather large block size). The one observed win was when the file in question had recently been read (as it often was\, when testing the performance of two sort implementations on the same input). In that case\, mmap was perceptibly faster\, almost certainly because it saved a copy of the data into the process's address space. This didn't seem like a case worth tuning for\, and there was the downside that paging policy on mmap-ed data might differ from the policy on malloc()ed space. In particular\, I was warned that Sun was rather glib about swapping out an mmap()ed page after it had been sequentially processed unless system-specific hints were passed in as flags. This would have been ugly for the sort\, where the records were processed at random after being scanned in sequentially. So I leave mmap()ing turned off by default. -- jpl

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

\nick@talking\.bollo\.cx writes:

This is a build failure report for perl from nick@talking.bollo.cx\, generated with the help of perlbug 1.33 running under perl v5.7.0.

----------------------------------------------------------------- [Please enter your report here]

Mostly this is an OK no PERLIO env var

All tests successful. u=1.34 s=0.54 cu=72.52 cs=12.81 scripts=270 tests=14295

export PERLIO=mmap

All tests successful. u=1.32 s=0.53 cu=68.54 cs=11.4 scripts=270 tests=14295

export PERLIO=stdio

All tests successful. u=1.52 s=0.56 cu=71.37 cs=11.47 scripts=270 tests=14295

export PERLIO=unix

Failed 1 test script out of 270\, 99.63% okay. u=1.87 s=0.87 cu=88.89 cs=68.91 scripts=270 tests=14295

./perl t/lib/posix.t ok 27 @#!*$@(!@#$nick@liam [bleadperl]$

"nick@liam [bleadperl]$ " being the shell prompt. So same problem as BSD with "unix"

That is the "expected" result for PERLIO=unix everywhere:

$| = 0; # The following line assumes buffered output\, which may be not true with EMX: print '@#!*$@(!@#$' unless ($^O eq 'os2' || $^O eq 'uwin' || $^O eq 'os390'); _exit(0);

It PERLIO=unix is explicitly saying don't do buffering. Running the suite with PERLIO=unix is interesting but I am not sure making everything pass is worth the bother.

is "mmap" usually faster?

It is supposed to be - that is the whole point. But depending on how smart system's read() caching is it may be not much different from perlio/stdio.

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

John P . Linderman \jpl@research\.att\.com writes:

For the little it is worth\, I experimented some with mmap on an external sort command\, (primarily on an SGI and a linux PC). The observed behavior was that mmap was a net *loss* on output\,

mmap PerlIO layer does not even try to use mmap for output. By the time you have jumped through all the ftruncate book-keeping it is near impossible to win.

and pretty much a tie on input (as contrasted with read() and write() calls of rather large block size).

I am considering what "options" it make sense to pass to layers it may well be worth allowing block size to be specified to perlio.

The one observed win was when the file in question had recently been read (as it often was\, when testing the performance of two sort implementations on the same input). In that case\, mmap was perceptibly faster\, almost certainly because it saved a copy of the data into the process's address space. This didn't seem like a case worth tuning for\, and there was the downside that paging policy on mmap-ed data might differ from the policy on malloc()ed space. In particular\, I was warned that Sun was rather glib about swapping out an mmap()ed page after it had been sequentially processed unless system-specific hints were passed in as flags.

There is token support for madvise() in PerlIO - but mainly to turn _ON_ that behaviour - the plan would be (if mmap is carried further) to allow access pattern (/random/sequential/) to be either specified at open time\, or intuited (sequential till 1st seek then random ?).

This would have been ugly for the sort\, where the records were processed at random after being scanned in sequentially. So I leave mmap()ing turned off by default. -- jpl

I have had day-job apps where mmap input was a win for exactly the reasons stated above - that recent files were still cached\, and that mmap files get paged out (freeing memory for more useful things) more quickly. The wins have been getting smaller as OS has improved.

Perl / perl5