Bcc:
Subject: Re: [on-discuss] [pkg-discuss] [osol-discuss] ON/SXCE bi-weekly
schedule not valid anymore?
Reply-To:
In-Reply-To: <[email protected]>
On Tue, Aug 25, 2009 at 07:50:19PM -0500, Mike Gerdts wrote:
> Silly example, but is representative of something that needs to be
> done from time to time.
>
> Solaris 10:
>
> $ uname -srvi
> SunOS 5.10 Generic_141414-02 SUNW,SPARC-Enterprise-T5120
>
> $ ptime grep -w ls /var/sadm/install/contents
> [snip]
> real 2.771
> user 2.653
> sys 0.115
>
> OpenSolaris:
>
> $ uname -srvi
> SunOS 5.11 snv_111b SUNW,SPARC-Enterprise-T5120
>
> $ ptime pkg search -l ls
> [snip]
> real 34.130866085
> user 30.690454076
> sys 0.774897050
This one is a bit tough, since there isn't a SysV packaging command to
find the package that a file belongs to.
That said, the performance is a lot better on x86, where on an Ultra 27
with nv121, I get the following for a local search:
real 8.613470157
user 8.323895802
sys 0.280899637
> My experience with hardware that I can order from Sun today says that
> the new software takes 12x longer for equivalent tasks. There is a
> very high startup cost with pkg that does not exist with pkgadd. With
> pkgadd I don't think too far ahead to be sure to group as many
> operations into one invocation as possible. When I use pkg, I most
> certainly try to lump as many operations as possible into each
> invocation to avoid this startup penalty.
Is this 12x on SPARC, or in all cases? Most of the analysis that I've
done so far has been on x86, and is generally quite fast.
We also haven't performed any optimization for startup costs yet. There
are some options available today, and some that we hope will be
available in the future.
> When I look at the publicly disclosed/speculated road map for CMT
> systems, I don't see things improving for the simple operations
> without fixing the software. I eagerly await the SAT solver and any
> other improvements that are in the works.
We know that there are some things that need to be fixed for CMT systems
now. We're also aware the more analysis need to be performed before an
enterprise release gets shipped. We've talked about making
decompression and hash verification occur in parallel. There has also
been some discussion about finding and removing recursive algorithms,
because the spill/fill traps on SPARC are quite costly.
> Right now I'm not complaining - I know the software is young and the
> primary development platform is x86 where the regression isn't so
> apparent. Once I start hearing that there aren't big performance
> improvements coming, I will start opening support calls if the
> performance is still worse than before.
Thanks for being reasonable. It doesn't make a lot of sense for us to
spend lots of time optimizing performance in portions of our code that
are going to change soon. Once the feature set has stabilized more, our
expectation is that we'll have more time to find and fix performance
problems that are platform specific. That said, we continue to make
algorithmic improvments that should benefit all platforms.
-j
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
