Re: Recent -current Performance Drop?

2000-07-13 Thread Poul-Henning Kamp

In message <[EMAIL PROTECTED]>, "Thomas D. Dean" writes:

>I turned off the malloc AJ flags, via malloc.conf.  It improved 'make
>world' by something like 17% == mean_aj/mean_AJ.

Make sense, make world is dominated by gcc/cc1 which is doing a 
lot of malloc/free operations.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


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



Re: Recent -current Performance Drop?

2000-07-13 Thread Thomas D. Dean

I turned off the malloc AJ flags, via malloc.conf.  It improved 'make
world' by something like 17% == mean_aj/mean_AJ.

Make World Statistics
-current SMP, 2xP133, 96MB RAM, IBM Superstor 9G disk.
Lines is the number of lines of output produced by 'make world'.
Date Lines Make Time Lines/Minute
 - - 
19991018 35281  6h40m16s 88.20 <== malloc aj?
2401 39490  7h56m18s 82.96  .
2402 39427  7h28m41s 88.01  .
2412 39404  7h10m21s 91.64  .
2621 38679  7h20m20s 87.91  .
2630 39530  7h56m20s 83.05 <== malloc aj?
2709 39679  8h40m28s 76.31 <== malloc AJ?
2710 39568  9h13m46s 71.55 <== malloc AJ?
2711 41178  9h22m05s 73.27 <== malloc AJ?
2712 39577  8h03m04s 81.94 <== malloc aj

tomdean


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



Re: Recent -current Performance Drop?

2000-07-12 Thread Brian Fundakowski Feldman

On Tue, 11 Jul 2000, Poul-Henning Kamp wrote:

> >I seem to see somewhat of a performance drop in the past week.
> 
> You should have read the commit messages :-)
> 
> I enabled malloc flags AJ by default, this has a performance
> cost.  It will be turned off for releases of course.
> 
> It has already exposed on bug (see peters commit).

 ^- Multiple bugs, thankyouverymuch :)

> You can disable it if you want to run benchmarks:

If you run a desktop system (need good response) and aren't willing to
take the large performance hit, too.  Note it's a large performance
hit when you tend to run a LOT of stuff and always dig into swap very
quickly.  I imagine for most people, the performance drop isn't nearly
as high, so they can live with it :)

>   ln -sf aj /etc/malloc.conf
> 
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD coreteam member | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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



Re: Recent -current Performance Drop?

2000-07-11 Thread Wesley Morgan

Actually in the past week or two I have seen a make buildworld drop from
205-210 minutes to 180-190 minutes. But I would be more inclined to
attribute that to changes in the source tree itself, not performance.

On Tue, 11 Jul 2000, Thomas D. Dean wrote:

> I don't know if this belongs in -current or -smp, so here goes.
> 
> I am running -current SMP, cvsup, etc. late last night PDT.
> 
> # uname -a
> FreeBSD celebris 5.0-CURRENT FreeBSD 5.0-CURRENT #0: \
>   Tue Jul 11 09:53:15 PDT 2000 \
>   tomdean@celebris:/usr/src/sys/compile/CELEBRIS-SMP i386
> 
> I have been using 'make world' as a stability/performance indicator.
> 
> The stability has been good.  I have had no recent panics, etc.,
> during 'make world'.  I choose the times to update carefully.
> 
> Good work core team.
> 
> I seem to see somewhat of a performance drop in the past week.
> 
> I save the output of 'make world' I know this is not a benchmark nor a
> very accurate indicator.  However, I believe 'make world' is a pretty
> good torque tool for a lightly loaded, interactive, 'play' system.
> And, disk I/O, compiling and executing user code is what interactive
> users do.
> 
> If 'make world' puts out approximately the same number of lines, I
> think it is doing about the same amount of work.
> 
> I see an increase in 'make world' time over the past week, or so.  The
> number of lines of output has gone up slightly.  The time elapsed has
> gone up more.
> 
> # world_time.sh
> Make World Statistics
> -current SMP, 2xP133, 96MB RAM, IBM Superstor 9G disk.
> Lines is the number of lines of output produced by 'make world'.
> Date Lines Make Time Lines/Minute
>  - - 
> 19991018 35281  6h40m16s 88.20
> 2401 39490  7h56m18s 82.96
> 2402 39427  7h28m41s 88.01
> 2412 39404  7h10m21s 91.64
> 2621 38679  7h20m20s 87.91
> 2630 39530  7h56m20s 83.05
> 2709 39679  8h40m28s 76.31
> 2710 39568  9h13m46s 71.55
> 2711 41178  9h22m05s 73.27
> 
> tomdean
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

-- 
   _ __ ___   ___ ___ ___
  Wesley N Morgan   _ __ ___ | _ ) __|   \
  [EMAIL PROTECTED] _ __ | _ \._ \ |) |
  FreeBSD: The Power To Serve  _ |___/___/___/
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!




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



Re: Recent -current Performance Drop?

2000-07-11 Thread Poul-Henning Kamp


>I seem to see somewhat of a performance drop in the past week.

You should have read the commit messages :-)

I enabled malloc flags AJ by default, this has a performance
cost.  It will be turned off for releases of course.

It has already exposed on bug (see peters commit).

You can disable it if you want to run benchmarks:

ln -sf aj /etc/malloc.conf

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


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



Re: Recent -current Performance Drop?

2000-07-11 Thread Adam

phk turned on some extra malloc options by default that a) catch more bugs
b) make it slower.  I hope you are reading cvs-all when you are using
-current.  

On Tue, 11 Jul 2000, Thomas D. Dean wrote:

>I don't know if this belongs in -current or -smp, so here goes.
>
>I am running -current SMP, cvsup, etc. late last night PDT.
>
># uname -a
>FreeBSD celebris 5.0-CURRENT FreeBSD 5.0-CURRENT #0: \
>  Tue Jul 11 09:53:15 PDT 2000 \
>  tomdean@celebris:/usr/src/sys/compile/CELEBRIS-SMP i386
>
>I have been using 'make world' as a stability/performance indicator.
>
>The stability has been good.  I have had no recent panics, etc.,
>during 'make world'.  I choose the times to update carefully.
>
>Good work core team.
>
>I seem to see somewhat of a performance drop in the past week.
>
>I save the output of 'make world' I know this is not a benchmark nor a
>very accurate indicator.  However, I believe 'make world' is a pretty
>good torque tool for a lightly loaded, interactive, 'play' system.
>And, disk I/O, compiling and executing user code is what interactive
>users do.
>
>If 'make world' puts out approximately the same number of lines, I
>think it is doing about the same amount of work.
>
>I see an increase in 'make world' time over the past week, or so.  The
>number of lines of output has gone up slightly.  The time elapsed has
>gone up more.
>
># world_time.sh
>Make World Statistics
>-current SMP, 2xP133, 96MB RAM, IBM Superstor 9G disk.
>Lines is the number of lines of output produced by 'make world'.
>Date Lines Make Time Lines/Minute
> - - 
>19991018 35281  6h40m16s 88.20
>2401 39490  7h56m18s 82.96
>2402 39427  7h28m41s 88.01
>2412 39404  7h10m21s 91.64
>2621 38679  7h20m20s 87.91
>2630 39530  7h56m20s 83.05
>2709 39679  8h40m28s 76.31
>2710 39568  9h13m46s 71.55
>2711 41178  9h22m05s 73.27
>
>tomdean
>
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-smp" in the body of the message
>



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