> From: Peter Jeremy <[EMAIL PROTECTED]>
>
> "Leif Neland" <[EMAIL PROTECTED]> wrote:
> >My 60MHz Pentium, FreeBSD
> >
> >time file /usr/home/leif/vnc-3.3.2r
> >/usr/home/leif/vnc-3.3.2r3_unixsrc.tgz: gzip compressed data, deflated,
> >original filename, last modified: Thu Jan 21 19:23:21 1999
> >
> >real    0m1.237s
> >user    0m0.758s
> >sys     0m0.394s
>
> I can't believe these figures.
>
> Matthew Dillon <[EMAIL PROTECTED]> wrote:
> >    Someone would have to compare file sources or profile it to figure
> >    out what is causing the slowness.
>
> I can't reproduce the complaint using a 64MB PII-266 running -CURRENT -
> there's no evidence of lack of speed, and profiling file(1) doesn't
> show any anomolies.
>
> It is somewhat slower on my 8MB 386, but not unreasonably so:
> pc0640% time file src/Z/dhcp-2.0b1pl26.tar.gz
> src/Z/dhcp-2.0b1pl26.tar.gz: gzip compressed data, deflated, last
> modified: Thu Jan  1 10:00:00 1970, os: Unix
> file src/Z/dhcp-2.0b1pl26.tar.gz  1.96s user 0.83s system 98% cpu 2.823
> total
> pc0640%
>
> Note that this is somewhat more than twice the time Leif claimed for
> his P-60 - and a P-60 should be more than twice the speed of a
> 386SX-25.
>
> Unfortunately, I can't profile it on my 386: It's running 2.x and I
> deleted the profiling libraries due to lack of space.  It will happily
> run the profiled ELF file(1), but doesn't generate any timing data.
>
> Looking at ktrace with MALLOC_OPTIONS=U, it does do a lot of
> realloc()ing (once for every 20 active lines in .../magic) and sbrk()s
> to a maximum size of ~390KB - not really significant.
>
> All I can think of is that Leif has a problem with his P-60 system.

  Alright, I'll bite this too:

  First of all, we are all making the same benchmark? For example, the first
time I run:

$ time file pm_3.5.3_BSDOS_2.0.tar.Z
pm_3.5.3_BSDOS_2.0.tar.Z: compress'd data 16 bits

real    0m0.162s
user    0m1.086s
sys     0m0.060s

  I get much higher times than when I issue the same a command a second (or
more) time:

$ time file pm_3.5.3_BSDOS_2.0.tar.Z
pm_3.5.3_BSDOS_2.0.tar.Z: compress'd data 16 bits

real    0m0.144s
user    0m0.090s
sys     0m0.053s

  Presumably the difference come from the first invokation loading all the
pages from the magic file into cache which gives the lower numbers on
subsequent invokations. I just wanted to make sure before we start pointing
fingers.

  Secondly, to compare with linux (as the original poster did):

On FreeBSD 3.2-STABLE from May 18th:

$ /usr/bin/time -l file radius_2.0.1_BSDOS_2.0.tar
radius_2.0.1_BSDOS_2.0.tar: tar archive
        0.14 real         0.09 user         0.04 sys
      1140  maximum resident set size
        20  average shared memory size
       593  average unshared data size
       135  average unshared stack size
      1411  page reclaims
         0  page faults
         0  swaps
         0  block input operations
         0  block output operations
         0  messages sent
         0  messages received
         0  signals received
         0  voluntary context switches
         2  involuntary context switches

  And from a RedHat Linux 5.2 (kernel 2.0.36) machine configured with
identical hardware (albeit different other processes running at the same
time):

$ /usr/bin/time -v file radius_2.0.1_Linux_2.0.tar
radius_2.0.1_Linux_2.0.tar: tar archive
        Command being timed: "file radius_2.0.1_Linux_2.0.tar"
        User time (seconds): 0.03
        System time (seconds): 0.00
        Percent of CPU this job got: 90%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.03
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 0
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 89
        Minor (reclaiming a frame) page faults: 169
        Voluntary context switches: 0
        Involuntary context switches: 0
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

$ /usr/bin/time --portability file radius_2.0.1_Linux_2.0.tar
radius_2.0.1_Linux_2.0.tar: tar archive
real 0.03
user 0.03
sys 0.01

  I find the linux numbers fairly inconsistent between invokations (ie the
CPU % fluctuating between 0% and 500%...on a uniprocessor system). The
number of faults fluctuated between 2 and about 200 for both "major" and
"minor" faults. My favorite is that it reports the process used 0k of
memory. :) I can only figure that linux isn't collecting those stats (who
really needs to know that anyway :> ) I verified that the inaccurate numbers
aren't because of the shortness of the process by using a script to invoke
file 100 times...the times were about 100x the values shown, as were the
faults, but everything listed as 0 above was still 0.

 Just FYI:
The linux system reports:
  Mem:  386320K av, 379568K used,   6752K free,  41140K shrd,   5440K buff
  Swap:  72256K av,     76K used,  72180K free                362108K cached
The FreeBSD system reports:
  Mem: 64M Active, 262M Inact, 31M Wired, 14M Cache, 5222K Buf, 5736K Free
  Swap: 768M Total, 768M Free

I really can't make heads or tails out of all of this, but I'm hoping that
I've provided some information to people who could use it.

  Kelly
 ~[EMAIL PROTECTED]~
  FreeBSD - The Power To Serve - http://www.freebsd.org/
  Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to