Re: WITHOUT_PROFILE=yes by default
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. Worked for me last time I tried as well. Was able to find the problems w/o a hassle. turning them off is plain wrong. Can we at least ship profiled libraries for the release? I didn't want to get in on the discussion, but for me every time you need to recompile software to get to feature A, I consider it a bug. Rebooting to enable a feature? Sure. Recompiling software to enable a feature? What? Is this the middle ages? What happened to shipping software/binaries that can work for everybody? The way I see it, profiling currently works for *both*, users that need the libs and users that don't need the libs. Reducing compile times is not a worthy goal, IMHO, as no user should ever have need to re-compile FreeBSD. Neither to tune something in GENERIC nor to rebuild world. Just my 2 cents, Uli ___ 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
Re: WITHOUT_PROFILE=yes by default
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 reasonable default to me. 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? -- chs, ___ 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
Re: WITHOUT_PROFILE=yes by default
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 they don't use. FWIW, I support keeping the build of profiled libraries. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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
Re: WITHOUT_PROFILE=yes by default
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 w/o a hassle. turning them off is plain wrong. Can we at least ship profiled libraries for the release? Warner ___ 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
Re: WITHOUT_PROFILE=yes by default
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 need to build their own custom FreeBSD? That seems even more nuts to me. Warner ___ 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
Re: WITHOUT_PROFILE=yes by default
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 want to take this? By this reasoning we should set all the knobs to NO to speed up the build. I mean we're all competent code builders running FreeBSD-current and know how to enable knobs in /etc/src.conf. Is speeding up the build import important to you then the default base system being an comfortable featureful development environment? On Thu, Dec 01, 2011 at 11:23:49PM -0800, 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 library and that change causes a dramatic change in the performance of one's code. And as Max pointed out in his OP, that only applies to a tiny fraction of our users, or even our developers. If you want to use them, turn the knob. Not only do I want to use them, I do use use profiled libraries. All those changes to libm that I've submitted over the years have been run through the profile. More importantly, we are discussion freebsd-current. I would hope that the other developers profile their changes to system before committing. Exactly! We want to *encourage* the use of profiling in development. Not make it harder. With out the profiled libs being readily available, it becomes yet another step to go thru and an impediment to quick performance checking. -- -- David (obr...@freebsd.org) P.S. Max, would you please turn off HTML mail when sending to FreeBSD mailing lists? Many of us use that as an indication of SPAM on these lists. I've missed your responses to me due to that. ___ 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
Re: WITHOUT_PROFILE=yes by default
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 sure you know how to stick NO_PROFILE=true in your /etc/src.conf. How far do you want to take this? By this reasoning we should set all the knobs to NO to speed up the build. I mean we're all competent code builders running FreeBSD-current and know how to enable knobs in /etc/src.conf. Is speeding up the build import important to you then the default base system being an comfortable featureful development environment? The most important thing is to have reasonable defaults. Having WITH_PROFILE by default does not seem to be a reasonable default to me. Max ___ 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
Re: WITHOUT_PROFILE=yes by default
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 /etc/src.conf solves the problem for you. Personally, I find building kernel modules to be intolerably slow, since I tend to run static linked kernels. I dealt with my preference by adding one line to my /etc/src.conf, not by submitting a patch request to disable the functionality in the builds. 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. --lyndon ___ 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
Re: WITHOUT_PROFILE=yes by default
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 library builds slow you down too much, a one line addition to your /etc/src.conf solves the problem for you. Personally, I find building kernel modules to be intolerably slow, since I tend to run static linked kernels. I dealt with my preference by adding one line to my /etc/src.conf, not by submitting a patch request to disable the functionality in the builds. 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. 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? Chris ___ 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
Re: WITHOUT_PROFILE=yes by default
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 non-starter. 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? Users don't run freebsd-current (unless they are willing to accept the inherit risks/warts associated with it). -- Steve ___ 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
Re: WITHOUT_PROFILE=yes by default
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 forcing each and every developer who wants to profile their code to modify their /etc/src.conf and then 'make buildworld' solely because Max can't be bothered to add one line to his own /etc/src.conf. Developers who profile their code makes up a greater proportion of our userbase than 'Max', so sensible defaults for them are more appropriate, right? --lyndon ___ 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
Re: WITHOUT_PROFILE=yes by default
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 profile your code has been obsolete in FreeBSD on i386 and amd64 for over six years now. ___ 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
Re: WITHOUT_PROFILE=yes by default
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 underlying profiling functionality. As a FreeBSD developer, you eat the cost of compiling everything. As a FreeBSD developer, if you are concentrating on a specific area at a particular time, turning off un-related parts of the build might speed things up for you. As a FreeBSD developer, you know how to do that. --lyndon ___ 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
Re: WITHOUT_PROFILE=yes by default
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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WITHOUT_PROFILE=yes by default
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 or deliberately misrepresenting what people have said. Obsolete does not mean it doesn't work. Chris ___ 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
Re: WITHOUT_PROFILE=yes by default
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 extensive job of profiling. But it's also a tool that is universally available to developers. Or was ... If you don't like it, don't use it. But don't turn that into an excuse to remove the functionality from the rest of us. If you really think profiling is truly useless in this day and age, the proposal should be to eradicate it from the system entirely. --lyndon ___ 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
Re: WITHOUT_PROFILE=yes by default
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, 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 introduces large measurement errors ___ 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
Re: WITHOUT_PROFILE=yes by default
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 introduces large measurement errors No, it just means it doesn't work for you. It does work for me, though. And for many others. Many a time I have shipped a profiled binary off to a customer site to determine where they are having performance problems. This works because they don't need to install any third-party tools or jump through other hoops. It's not perfect, but it is a useful debugging tool. The arguments I keep hearing here are I don't (understand how to effectively) use this tool, therefore it should be removed. Collectively that argument can be applied to each and every component of FreeBSD when taken across the entire user base. Thus we can infinately optimize the builds though 'rm -rf /usr/src'. Now can we please just leave WITHOUT_PROFILE alone and go fix real bugs? If it will help, I will toss in a few hundred bucks to help Max buy a faster build machine. --lyndon ___ 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
Re: WITHOUT_PROFILE=yes by default
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 quickly find code execution hot-spots. It's not dtrace, or any other plethora of tools that do a more extensive job of profiling. But it's also a tool that is universally available to developers. Or was ... Still is if you choose it. If you don't like it, don't use it. But don't turn that into an excuse to remove the functionality from the rest of us. Straw man argument. Nothing has been removed. If you really think profiling is truly useless in this day and age, the proposal should be to eradicate it from the system entirely. Isn't this about user choice, and making sensible defaults? No-one is removing anything. Please stick to facts. Chris ___ 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
Re: WITHOUT_PROFILE=yes by default
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. ___ 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
Re: WITHOUT_PROFILE=yes by default
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 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 introduces large measurement errors Difficult to use? % gfortran -o ang -pg ang.f90 % ./ang % gprof -b -l ./ang ang.gmon | more ... % cumulative self self total time seconds secondscalls ms/call ms/call name 35.0 0.01 0.010 100.00% _write [1] 33.3 0.02 0.010 100.00% _mcount [2] 15.0 0.02 0.00 1080 0.00 0.00 arena_purge [4] 5.6 0.02 0.000 100.00% .mcount (40) 2.2 0.02 0.0029600 0.00 0.00 __quorem_D2A [8] 1.7 0.02 0.00 1080 0.00 0.00 __dtoa [7] 1.1 0.02 0.0029552 0.00 0.00 __multadd_D2A [13] 1.1 0.02 0.00 7557 0.00 0.00 memcpy [12] Please show me how you would get the same information with pmcstat (or other tools) in the base system. Note, ang.f90 is a toy app I had lying around, which completes in a second or 2. If you want a non-toy example, I'll happily run one of my libm testcase for you. -- Steve ___ 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
Re: WITHOUT_PROFILE=yes by default
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 better build hardware, too. Suffer in silence There are a lot more than two or three users, we just choose not to join in a bikeshed because of other more pressing issues. Thanks, -Garrett ___ 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
Re: WITHOUT_PROFILE=yes by default
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 upgrades can toggle something in src.conf. This should make lazy devs happy, speed up build times for those upset about that, etc. it sucks for RE though. I was taught to use gprof in college and it was nice using the same tool on school sun and Linux boxes as well as my own iBook and FreeBSD desktop. This might be a fair compromise for now with a EOL date in a future release. At some point I assume dropping gnu tools with llvm transition makes sense Lucas Holt On Dec 2, 2011, at 1:39 PM, 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 better build hardware, too. ___ 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 ___ 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
Re: WITHOUT_PROFILE=yes by default
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, I am not a FreeBSD developer (though I do hunt down a bug occasionally), but for many, many years I do develop software using FreeBSD as a development platform. And for solving performance issues, mainly in long running, CPU intensive (numerical) applications gprof and all too often the profiled libraries appeared to be indispensable. I am mostly using STABLE, but occasionally switch to CURRENT to get a feeling for the newest developments (e.g. LLVM). One of the reasons I am still using FreeBSD is the out-of-the-box availability of tools like the profiler and profiled libraries. Maybe I could live with a switch in /etc/src.conf, if it were properly documented, but that would imply that the profiled libraries are not built anymore with any regularity. And of course we all know where that could lead to in the future ... I would certainly keep the profiled libraries by default in the build for CURRENT and maybe even in STABLE. With binary installations of RELEASE it could be an option, as it always was. Regards, Hans ___ 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
Re: WITHOUT_PROFILE=yes by default
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 off by default in the buildworld as anyone smart enough to do source upgrades can toggle something in src.conf. This should make lazy devs happy, speed up build times for those upset about that, etc. it sucks for RE though. I was taught to use gprof in college and it was nice using the same tool on school sun and Linux boxes as well as my own iBook and FreeBSD desktop. This might be a fair compromise for now with a EOL date in a future release. At some point I assume dropping gnu tools with llvm transition makes sense Lucas Holt On Dec 2, 2011, at 1:39 PM, 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 better build hardware, too. OK. I am NOT a developer but have run -current as a user for extended intervals (v4 through V6) as I needed hardware support for my laptop that was not available in -stable. I'm sure I am not alone.I may be installing current again to get Intel KMS support for my Sandybridge. I did discover the amount of time spent building profile libs and turned them off in make.conf (later src.conf), but I think it is really, really silly to have a default in -stable that is used by almost no one. and wastes a little disk space and some time (it was a LOT on my old AMD 450 MHz system). Beyond that, for the relatively small number of folks using the libs and the trivial effort for those who do use it to turn the build on if it was made non-default, I can't really see the argument for building them in -current as a winner, either. But please, please turn it off in -stable at the very least. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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
Re: WITHOUT_PROFILE=yes by default
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. 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 want to take this? ??By this reasoning we should set all the knobs to NO to speed up the build. ??I mean we're all competent code builders running FreeBSD-current and know how to enable knobs in /etc/src.conf. Is speeding up the build import important to you then the default base system being an comfortable featureful development environment? The most important thing is to have reasonable defaults. Having WITH_PROFILE by default does not seem to be a reasonable default to me. Common options set in make.conf WITHOUT_MODULES=YES WITHOUT_NLS=YES WITHOUT_LIB32=YES WITH_BSD_GREP=YES Here's some numbers to consider: WITH_PROFILE=YES rm -rf /usr/obj/* time make -j2 buildworld 6678.61 real 9752.40 user 1630.71 sys WITHOUT_PROFILE=YES rm -rf /usr/obj/* time make -j2 buildworld 6221.21 real 9171.41 user 1471.23 sys WITH_PROFILE=YES WITHOUT_CLANG=YES 3388.27 real 4804.24 user 1160.12 sys If one wants to speed up buildworld, it would seem to be prudent to compile clang with profiled libraries to determined why it is such a time sync. From dmesg.boot: CPU: AMD Opteron(tm) Processor 248 (2191.96-MHz K8-class CPU) Origin = AuthenticAMD Id = 0xf5a Family = f Model = 5 Stepping = 10 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 AMD Features=0xe0500800SYSCALL,NX,MMX+,LM,3DNow!+,3DNow! real memory = 8589934592 (8192 MB) avail memory = 8203833344 (7823 MB) -- Steve ___ 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
Re: WITHOUT_PROFILE=yes by default
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 support and not CTF data? Max ___ 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
Re: WITHOUT_PROFILE=yes by default
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 which has been reported. 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
Re: WITHOUT_PROFILE=yes by default
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: http://svn.freebsd.org/changeset/base/228143 Log: Turn off profiled libs build by default. Can be enabled back using WITH_PROFILE=yes in /etc/src.conf 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 -STABLE creation. -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play Jeopardy-style quoting ___ 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
Re: WITHOUT_PROFILE=yes by default
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 -STABLE creation. It's easier to do that than go review/re-engineer bloated code. :) 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
Re: WITHOUT_PROFILE=yes by default
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: Tue Nov 29 19:46:17 2011 New Revision: 228143 URL: http://svn.freebsd.org/changeset/base/228143 Log: Turn off profiled libs build by default. Can be enabled back using WITH_PROFILE=yes in /etc/src.conf Wow, a single day of discussion in freebsd-current@ was sufficient to invert a 17 year default. You still failed to name a single compelling reason to leave profiled libs even in -CURRENT. And it sounds like we should not fix 17-year old bugs or things that are no longer of any practical use because they were implemented 17 years ago. 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 -STABLE creation. Max ___ 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
Re: WITHOUT_PROFILE=yes by default
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 19:46:17 2011 New Revision: 228143 URL: http://svn.freebsd.org/changeset/base/228143 Log: Turn off profiled libs build by default. Can be enabled back using WITH_PROFILE=yes in /etc/src.conf 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. +1 In particular, many (most, all?) people running -current will have profiled libaries installed. These libraries will become stale/out-of-sync with the static and shared libraries as (if) changes are made to libc. -- Steve ___ 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
Re: WITHOUT_PROFILE=yes by default
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 -CURRENT. If you like, add it to the list of things to disable on -STABLE creation. It's easier to do that than go review/re-engineer bloated code. :) To what does that refer? -- Steve ___ 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
Re: WITHOUT_PROFILE=yes by default
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 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: http://svn.freebsd.org/changeset/base/228143 Log: Turn off profiled libs build by default. Can be enabled back using WITH_PROFILE=yes in /etc/src.conf 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. +1 In particular, many (most, all?) people running -current will have profiled libaries installed. These libraries will become stale/out-of-sync with the static and shared libraries as (if) changes are made to libc. This is a completely different thing and is actually what ObsoleteFilesInc/OptionalObsoleteFiles.inc mechanism is for. Max ___ 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
Re: WITHOUT_PROFILE=yes by default
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, 2011 at 07:46:17PM +, Max Khon wrote: Author: fjoe Date: Tue Nov 29 19:46:17 2011 New Revision: 228143 URL: http://svn.freebsd.org/changeset/base/228143 Log: Turn off profiled libs build by default. Can be enabled back using WITH_PROFILE=yes in /etc/src.conf Wow, a single day of discussion in freebsd-current@ was sufficient to invert a 17 year default. You still failed to name a single compelling reason to leave profiled libs even in -CURRENT. 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. PS: David was not complaining about fixing a 17 year old bug. He was stating that a single day of discussion changing a 17 year old practice seems a little too brief. PPS: I was on work-related travel for the last 4 days, and only saw this discussion after you pulled the trigger. -- Steve ___ 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
Re: WITHOUT_PROFILE=yes by default
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 out in his OP, that only applies to a tiny fraction of our users, or even our developers. If you want to use them, turn the knob. PS: David was not complaining about fixing a 17 year old bug. He was stating that a single day of discussion changing a 17 year old practice seems a little too brief. If it's a good idea, it's a good idea no matter how many different ways we flog it. :) Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
Re: WITHOUT_PROFILE=yes by default
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 dramatic change in the performance of one's code. And as Max pointed out in his OP, that only applies to a tiny fraction of our users, or even our developers. If you want to use them, turn the knob. Not only do I want to use them, I do use use profiled libraries. All those changes to libm that I've submitted over the years have been run through the profile. More importantly, we are discussion freebsd-current. I would hope that the other developers profile their changes to system before committing. PS: David was not complaining about fixing a 17 year old bug. He was stating that a single day of discussion changing a 17 year old practice seems a little too brief. If it's a good idea, it's a good idea no matter how many different ways we flog it. :) I think it is a horrible idea. Perhaps, we should discuss the technical issues before you start yet another bikeshed (see your recent posts concerning the ports repo for your hypocricy). -- Steve ___ 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
Re: WITHOUT_PROFILE=yes by default
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 library and that change causes a dramatic change in the performance of one's code. And as Max pointed out in his OP, that only applies to a tiny fraction of our users, or even our developers. If you want to use them, turn the knob. Not only do I want to use them, I do use use profiled libraries. All those changes to libm that I've submitted over the years have been run through the profile. I'm glad that you find them useful. How does changing the default affect your ability to do that? More importantly, we are discussion freebsd-current. I would hope that the other developers profile their changes to system before committing. I'd be happy if our developers would stop breaking the build. PS: David was not complaining about fixing a 17 year old bug. He was stating that a single day of discussion changing a 17 year old practice seems a little too brief. If it's a good idea, it's a good idea no matter how many different ways we flog it. :) I think it is a horrible idea. Perhaps, we should discuss the technical issues before you start yet another bikeshed (see your recent posts concerning the ports repo for your hypocricy). Um, you did see the smiley, right? -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
Re: WITHOUT_PROFILE=yes by default
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
Re: WITHOUT_PROFILE=yes by default
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 ___ 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
Re: WITHOUT_PROFILE=yes by default
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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WITHOUT_PROFILE=yes by default
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 pmcstat and callgrind/cachegrind. -- Jilles Tjoelker ___ 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
Re: WITHOUT_PROFILE=yes by default
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
Re: WITHOUT_PROFILE=yes by default
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 ___ 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 ___ 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
Re: WITHOUT_PROFILE=yes by default
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 ventur...@gmail.com 写道： I assume every who responded so far doesn't use dtrace? -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
WITHOUT_PROFILE=yes by default
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+: make buildworld 8265,06 real 6400,27 user 1059,2 sys make buildworld (WITHOUT_PROFILE=yes) 7840,05 real 5379,13 user 904,61 sys I would like to disable building profiled libraries by default. Opinions? Max ___ 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
Re: WITHOUT_PROFILE=yes by default
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 put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
Re: WITHOUT_PROFILE=yes by default
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 could do this for 9.0. Can we at least keep one (small) library compiled for profiling, so that compiling for profiling doesn't get broken by accident ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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
Re: WITHOUT_PROFILE=yes by default
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 install a new system for at least a decade. Ideally we could do this for 9.0. Can we at least keep one (small) library compiled for profiling, so that compiling for profiling doesn't get broken by accident ? I think WITH_PROFILE is probably a good idea for the tinderbox? -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
Re: WITHOUT_PROFILE=yes by default
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 this for 9.0. Can we at least keep one (small) library compiled for profiling, so that compiling for profiling doesn't get broken by accident ? I think WITH_PROFILE is probably a good idea for the tinderbox? Who is in charge for tinderbox these days? Max ___ 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
