On Mon, 2011-12-19 at 12:50:42 -0700, Warner Losh wrote:
On Dec 2, 2011, at 9:52 AM, Lyndon Nerenberg wrote:
Using profiled libs and gprof to profile your code has been obsolete
in FreeBSD on i386 and amd64 for over six years now.
Funny, it still seems to work on my systems.
On Mon, Dec 19, 2011 at 8:46 PM, Warner Losh i...@bsdimp.com wrote:
On Dec 2, 2011, at 3:37 PM, Steve Kargl wrote:
On Fri, Dec 02, 2011 at 04:21:14PM +0700, Max Khon wrote:
The most important thing is to have reasonable defaults.
Having WITH_PROFILE by default does not seem to be a
Now all users that want to profile anything need to build their own custom
FreeBSD? That seems even more nuts to me.
So that all users that do not want to profile anything need to build
their own custom FreeBSD?
No. It simply means these users will have profiled libraries available
that
On Dec 2, 2011, at 9:52 AM, Lyndon Nerenberg wrote:
Using profiled libs and gprof to profile your code has been obsolete
in FreeBSD on i386 and amd64 for over six years now.
Funny, it still seems to work on my systems.
Worked for me last time I tried as well. Was able to find the problems
On Dec 2, 2011, at 3:37 PM, Steve Kargl wrote:
On Fri, Dec 02, 2011 at 04:21:14PM +0700, Max Khon wrote:
The most important thing is to have reasonable defaults.
Having WITH_PROFILE by default does not seem to be a reasonable default to
me.
Now all users that want to profile anything
On Fri, Dec 02, 2011 at 11:56:31AM +0700, Max Khon wrote:
You still failed to name a single compelling reason to leave profiled
libs even in -CURRENT.
Sorry Joe, I don't think your reasoning is compelling.
I'm sure you know how to stick NO_PROFILE=true in your /etc/src.conf.
How far do you
David,
On Fri, Dec 2, 2011 at 3:35 PM, David O'Brien obr...@freebsd.org wrote:
On Fri, Dec 02, 2011 at 11:56:31AM +0700, Max Khon wrote:
You still failed to name a single compelling reason to leave profiled
libs even in -CURRENT.
Sorry Joe, I don't think your reasoning is compelling.
I'm
Max, I think a reasonable default is to continue building and shipping
profiled libraries. This keeps FreeBSD consistent with every other UNIX
variant released in the last (at least) 30 years.
If you personally find profiled library builds slow you down too much, a
one line addition to your
On 2 Dec 2011 15:57, Lyndon Nerenberg lyn...@orthanc.ca wrote:
Max, I think a reasonable default is to continue building and shipping
profiled libraries. This keeps FreeBSD consistent with every other UNIX
variant released in the last (at least) 30 years.
If you personally find profiled
On Fri, Dec 02, 2011 at 04:23:40PM +, Chris Rees wrote:
On 2 Dec 2011 15:57, Lyndon Nerenberg lyn...@orthanc.ca wrote:
If you choose not to profile your code, that's entirely your choice.
Breaking this functionality for everyone else who *does* make the effort to
profile their code is a
Nothing is being broken here, just a default being changed.
Users make up a greater proportion of our userbase than developers, so
sensible defaults for them are more appropriate, right?
This has no impact on non-developer end-users.
For developer end-users, this has a huge impact. You are
On Fri, Dec 2, 2011 at 10:56 AM, Lyndon Nerenberg lyn...@orthanc.ca wrote:
If you choose not to profile your code, that's entirely your choice.
Breaking this functionality for everyone else who *does* make the effort to
profile their code is a non-starter.
Using profiled libs and gprof to
Something else I forgot to mention ...
The point of -CURRENT is to make sure everything works before it becomes
-STABLE and -RELEASE. Not building significant components of the system
ensures those components don't get tested. This includes the actual build
process, as well as the
Using profiled libs and gprof to profile your code has been obsolete
in FreeBSD on i386 and amd64 for over six years now.
Funny, it still seems to work on my systems.
___
freebsd-current@freebsd.org mailing list
On 2 Dec 2011 16:54, Lyndon Nerenberg lyn...@orthanc.ca wrote:
Using profiled libs and gprof to profile your code has been obsolete
in FreeBSD on i386 and amd64 for over six years now.
Funny, it still seems to work on my systems.
I wonder if you're either not reading these emails properly
Obsolete does not mean it doesn't work.
No, these days 'obsolete' seems to mean 'it does not have a sexy
Flash-driven web GUI.'
Profiling is a simple basic tool that makes it easy to quickly find code
execution hot-spots. It's not dtrace, or any other plethora of tools that
do a more
On Fri, Dec 2, 2011 at 12:07 PM, Lyndon Nerenberg lyn...@orthanc.ca wrote:
No, these days 'obsolete' seems to mean 'it does not have a sexy
Flash-driven web GUI.'
In this case, 'obsolete' means it's a difficult-to-use tool that
requires recompiling your application, can't be used in production,
In this case, 'obsolete' means it's a difficult-to-use tool that
requires recompiling your application, can't be used in production,
doesn't work when shared libraries are in the picture, offers
limited-to-no visibility into the underlying reasons why a particular
code path is a hotspot and
On 2 Dec 2011 17:07, Lyndon Nerenberg lyn...@orthanc.ca wrote:
Obsolete does not mean it doesn't work.
No, these days 'obsolete' seems to mean 'it does not have a sexy
Flash-driven web GUI.'
Straw man argument. This is irrelevant.
Profiling is a simple basic tool that makes it easy to
Isn't this about user choice, and making sensible defaults?
There are two or three users out of thousands complaining about the
default. If the extra build time bugs you that much, I'll contribute
towards buying you better build hardware, too.
___
On Fri, Dec 02, 2011 at 01:12:42PM -0500, Ryan Stone wrote:
On Fri, Dec 2, 2011 at 12:07 PM, Lyndon Nerenberg lyn...@orthanc.ca wrote:
No, these days 'obsolete' seems to mean 'it does not have a sexy
Flash-driven web GUI.'
In this case, 'obsolete' means it's a difficult-to-use tool that
On Fri, Dec 2, 2011 at 10:39 AM, Lyndon Nerenberg lyn...@orthanc.ca wrote:
Isn't this about user choice, and making sensible defaults?
There are two or three users out of thousands complaining about the
default. If the extra build time bugs you that much, I'll contribute
towards buying you
What if it was still included in tinderbox builds and releases. For the latter,
the profiled versions could be in a separate distribution set much like doc or
games. The ugly part is freebsd-update..
It could still be off by default in the buildworld as anyone smart enough to do
source
On 12/02/11 19:39, Lyndon Nerenberg wrote:
Isn't this about user choice, and making sensible defaults?
There are two or three users out of thousands complaining about the
default. If the extra build time bugs you that much, I'll contribute
towards buying you better build hardware, too.
Well,
On Fri, Dec 2, 2011 at 12:11 PM, Lucas Holt l...@foolishgames.com wrote:
What if it was still included in tinderbox builds and releases. For the
latter, the profiled versions could be in a separate distribution set much
like doc or games. The ugly part is freebsd-update..
It could still be
On Fri, Dec 02, 2011 at 04:21:14PM +0700, Max Khon wrote:
David,
On Fri, Dec 2, 2011 at 3:35 PM, David O'Brien obr...@freebsd.org wrote:
On Fri, Dec 02, 2011 at 11:56:31AM +0700, Max Khon wrote:
You still failed to name a single compelling reason to leave profiled
libs even in -CURRENT.
Sevan,
On Thu, Dec 1, 2011 at 6:56 AM, Sevan / Venture37 ventur...@gmail.comwrote:
On 30/11/2011 16:03, Sevan / Venture37 wrote:
system breaks if you try to add dtrace support to a system built with
profile support.
sorry, I meant *without* profile support.
Are you sure you mean profile
On 1 December 2011 10:44, Max Khon f...@samodelkin.net wrote:
Are you sure you mean profile support and not CTF data?
Hi Max,
I mean profile support.
Havent tested on 9.0, but definitely the case with prior versions.
Will try repeat the process report back if this is not a common
occurrence
On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote:
I would like to disable building profiled libraries by default. Opinions?
On Tue, Nov 29, 2011 at 07:46:17PM +, Max Khon wrote:
Author: fjoe
Date: Tue Nov 29 19:46:17 2011
New Revision: 228143
URL:
On 2 December 2011 09:51, David O'Brien obr...@freebsd.org wrote:
Wow, a single day of discussion in freebsd-current@ was sufficient to
invert a 17 year default.
I'd like to see the profile libs remain built by default in -CURRENT.
If you like, add it to the list of things to disable on
David,
On Fri, Dec 2, 2011 at 8:51 AM, David O'Brien obr...@freebsd.org wrote:
On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote:
I would like to disable building profiled libraries by default. Opinions?
On Tue, Nov 29, 2011 at 07:46:17PM +, Max Khon wrote:
Author: fjoe
Date:
On Thu, Dec 01, 2011 at 05:51:33PM -0800, David O'Brien wrote:
On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote:
I would like to disable building profiled libraries by default. Opinions?
On Tue, Nov 29, 2011 at 07:46:17PM +, Max Khon wrote:
Author: fjoe
Date: Tue Nov 29
On Fri, Dec 02, 2011 at 12:41:00PM +0800, Adrian Chadd wrote:
On 2 December 2011 09:51, David O'Brien obr...@freebsd.org wrote:
Wow, a single day of discussion in freebsd-current@ was sufficient to
invert a 17 year default.
I'd like to see the profile libs remain built by default in
Steve,
On Fri, Dec 2, 2011 at 1:33 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
On Thu, Dec 01, 2011 at 05:51:33PM -0800, David O'Brien wrote:
On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote:
I would like to disable building profiled libraries by default.
Opinions?
On Fri, Dec 02, 2011 at 11:56:31AM +0700, Max Khon wrote:
David,
On Fri, Dec 2, 2011 at 8:51 AM, David O'Brien obr...@freebsd.org wrote:
On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote:
I would like to disable building profiled libraries by default. Opinions?
On Tue, Nov 29,
On 12/01/2011 22:41, Steve Kargl wrote:
Having a set of profiled libraries in-sync with the static
and shared libraries allows one to run the profiler on their
code when someone changes a library and that change causes
a dramatic change in the performance of one's code.
And as Max pointed
On Thu, Dec 01, 2011 at 10:59:59PM -0800, Doug Barton wrote:
On 12/01/2011 22:41, Steve Kargl wrote:
Having a set of profiled libraries in-sync with the static
and shared libraries allows one to run the profiler on their
code when someone changes a library and that change causes
a
On 12/01/2011 23:23, Steve Kargl wrote:
On Thu, Dec 01, 2011 at 10:59:59PM -0800, Doug Barton wrote:
On 12/01/2011 22:41, Steve Kargl wrote:
Having a set of profiled libraries in-sync with the static
and shared libraries allows one to run the profiler on their
code when someone changes a
Quick! Martinis for all conversation participants, stat!
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
On 30/11/2011 01:16, Doug Barton wrote:
What does dtrace have to do with profiled libs?
system breaks if you try to add dtrace support to a system built with
profile support. on the other hand it could be argued that the system
currently needs to be rebuilt anyway.
Sevan
On 30/11/2011 16:03, Sevan / Venture37 wrote:
system breaks if you try to add dtrace support to a system built with
profile support.
sorry, I meant *without* profile support.
Sevan
___
freebsd-current@freebsd.org mailing list
On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote:
I would like to disable building profiled libraries by default.
Opinions?
Agreed. There are better profiling tools available now that do not
require recompiling the program with special options and statically
linking it. Examples are
I assume every who responded so far doesn't use dtrace?
Sevan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
I think dtrace for freebsd userland is close to complete( after
r227290, at least no more kernel panic). but is not suitable for a
daily use now.
在 2011年11月30日 上午5:42，Sevan / Venture37 ventur...@gmail.com 写道：
I assume every who responded so far doesn't use dtrace?
Sevan
What does dtrace have to do with profiled libs?
On 11/29/2011 17:14, Paul Ambrose wrote:
I think dtrace for freebsd userland is close to complete( after
r227290, at least no more kernel panic). but is not suitable for a
daily use now.
在 2011年11月30日 上午5:42，Sevan / Venture37
Hello!
Are there any compelling reasons for having profiled libs to be built by
default?
They are of no use for 100% users and 99,999% developers and just slow down
world and universe builds.
Here are the results of running buildworld on 1 core on AMD Athlon(tm) 64
X2 Dual Core Processor 4400+:
On 11/28/2011 02:38, Max Khon wrote:
Are there any compelling reasons for having profiled libs to be built by
default?
Nope. It's been one of the first things I disable after I install a new
system for at least a decade.
Ideally we could do this for 9.0.
Doug
--
We could
In message 4ed4222e.5010...@freebsd.org, Doug Barton writes:
On 11/28/2011 02:38, Max Khon wrote:
Are there any compelling reasons for having profiled libs to be built by
default?
Nope. It's been one of the first things I disable after I install a new
system for at least a decade.
Ideally we
On 11/28/2011 16:33, Poul-Henning Kamp wrote:
In message 4ed4222e.5010...@freebsd.org, Doug Barton writes:
On 11/28/2011 02:38, Max Khon wrote:
Are there any compelling reasons for having profiled libs to be built by
default?
Nope. It's been one of the first things I disable after I
Doug,
On Tue, Nov 29, 2011 at 7:35 AM, Doug Barton do...@freebsd.org wrote:
Are there any compelling reasons for having profiled libs to be built by
default?
Nope. It's been one of the first things I disable after I install a new
system for at least a decade.
Ideally we could do
50 matches
Mail list logo
