- Boost - lists.boost.org

RE: [boost] [Signals] Named slot group usage?
by Brian Braatz 11 Feb '05

11 Feb '05

Below: > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Doug Gregor > Sent: Friday, February 11, 2005 10:34 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] [Signals] Named slot group usage? > > > On Feb 11, 2005, at 11:49 AM, Peter Dimov wrote: > > > Doug Gregor wrote: > >> On Feb 11, 2005, at 9:51 AM, Peter Dimov wrote: > >> > >>> Douglas Gregor wrote: > >>>> Background: Signals performance is sub-par, and much of the problem > >>>> can be traced back to support for named slot groups. I'm trying to > >>>> determine the best way to proceed. > >>> > >>> Are you sure that this is the case? > >> > >> There may be other issues, but going from a std::list to a std::map > >> (as needed to efficiently support connection of named slots) hurts > >> iteration performance and increases executable code size. To counter > >> the latter problem, I've done some type erasure that slows it down > >> further and causes some of the extra heap allocations :( > > > > You mean disconnection of named slots, right? List connection is O(1), > > map - O(log N). You get ordering for free with a map, sure, but this > > is a separate issue. > > Both connection and disconnection of named slots are O(lg N), since we > need to keep the whole list ordered when named slots are present. > Connection/disconnection of unnamed slots is O(1) now. > > Iterating through a map really is slow, though... loops in operator++ > really hurt us. I've tried a few times to come up with some ultra-slick > formulation using a list for primary storage and a map indexing into > the list... but I've always failed to deal with the iterator > invalidation issues. > > > Anyway, I'm sure that few people would miss named slots. > > That's what I'm trying to figure out; but I suspect that you're right. > > > Lets' drop them. :-) > > You're not the only one to say that :) > > Doug [Brian Braatz] What about allowing the internal type to be policy\traited? i.e. I can use a vector instead of a map<> and is it possible to allow for meta-data while you're at it? Sincerely, Brian "wants the world on a silver platter" Braatz ;)

2 1

[fsm] Preliminary formal review version available
by Andreas Huber 11 Feb '05

11 Feb '05

Dear Boosters If everything goes according to plan, the fsm review will start on the 21st of February. A version that I expect to be *very* close to what will be available during the review period is available here: http://boost-sandbox.sf.net/fsm.zip The docs can also be browsed online: http://boost-sandbox.sf.net/libs/fsm This version has undergone testing on MSVC7.1 and various GCC versions. Tests on Intel are in progress. Results of tests on other compilers are very welcome. Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

RE: [boost] Re: Re: Re: Re: Latest version of the profiler
by Brian Braatz 11 Feb '05

11 Feb '05

See below > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of christopher diggins > Sent: Friday, February 11, 2005 6:51 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Re: Re: Re: Latest version of the profiler > > ----- Original Message ----- > From: "Brian Braatz" <brianb(a)rmtg.com> > > I might want to accumulate ALL of the calls, in one big honking list. > > You can already do that in a few different ways: > > 1) simply naming all of the profiles the same, > > 2) writing a new stats policy, > > 3) write: > > { > stats_map::iterator i = default_stats_policy::stats::begin(); > counted_sum cs; > while (i != default_stats_policy::stats::end) { > cs += *i++; > } > cout << "total profiler entries : " << cs.first << endl; > cout << "total elapsed time : " << cs.second << endl; > cout << "average time per profile : " << cs.second / cs.first << endl; > } > > 4) I could simply add some features to the default_stats_policy, if that > is > more appropriate. > > I don't know what the best option is. > > > Or > > I might want a "overview" of the average of each profile point. > > Currently also already provided in the default_stats_policy, if I > understand > you correctly. [Brian Braatz] YES- current implementation already gives me an average of the profile points. > > > I think we need both, in addition to allowing me to put metadata into > > the profile point. Because with the metadata, I can now go back through > > the accumulated list and filter out what I care about. > > I am seriously considering the metadata idea. > [Brian Braatz] BIG GRIN :) > I agree with your earlier ideas that the identifier for a profile should > not > be restricted to a char*. > A problem with the current design is that a by passing a type for the > profile idenitifer affects not just the profile, but also the stats policy > and the log policy. In this case of having three dependant policies, I > would > far prefer to have a single profile_management policy. This is not a huge > problem however. > > Thanks for your suggestions, > Christopher [Brian Braatz] Personally- I don't think having one honker policy object is the end of the world. In this case it is appropriate because the independent policies are somehow implicitly "bound" by concept. If they were not, I would argue for separate policies. Please check out the multi-index idea post earlier by me :) (that may give the flexibility, with just a little extra work, to make the profiler be "better than off the shelf". Which to me, is what Boost libraries are about :) )

1 0

RE: [boost] Re: Re: Re: Re: Latest version of the profiler
by Brian Braatz 11 Feb '05

11 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Sérgio Vale e Pace > > On Thu, 10 Feb 2005 17:33:19 -0700, Brian Braatz <brianb(a)rmtg.com> wrote: > > Yes- those are the words I was trying to say. > > > > I might want to accumulate ALL of the calls, in one big honking list. Or > > I might want a "overview" of the average of each profile point. > > > > I think we need both, in addition to allowing me to put metadata into > > the profile point. Because with the metadata, I can now go back through > > the accumulated list and filter out what I care about. > > > > ** this is the big piece that is missing for me from off the shelf > > profilers ** > > smells like mixins to me. something like this would be apropriate (pseudo > code)? > { > profiler< log_all< log_overview<> > > prof; > // profiled code > } > > Sérgio [Brian Braatz] Hmm.. I think so. As long as there were enough methods available to me in the right fashion to allow the weave above to be able to do that. That answer would require more study. Part of the issue though, is I cannot put the metadata in, so the log_overview<> implementation might be convoluted since it is trying to double track things. Please see my next mail suggesting multi-index- I THINK that would speak to the issues I am talking about and it would give the users enough power to be able to use the profiler in MANY different ways.

1 0

What about Multi-Index? \ RE: [boost] Latest version of the profiler
by Brian Braatz 11 Feb '05

11 Feb '05

(Responding to my own post again. I guess I am one of those guys who could sit in a closet and carry on a conversation with himself) :) (Joaquin: ARE YOU OUT THERE?- Your thoughts appreciated) Was thinking about this more last night. I have NOT had deep experiences with the multi-index container from Joaquin Munez. So please excuse me if this is a bad idea. :) I am posting this as a question- What if instead of a map, you used Boost.MultiIndex container?. Then exposed the configuration of that to the users of the profiler. I propose you have a "stock, out of the box" simple version of profiler that "just works" with minimal work by the user. But also allow the user to re-configure the multi-index you are using internally. What this will buy: - The profiler now has multiple "views" - The different "ways" of looking at the data can be configured by the user - What I am storing in the profiler is also changeable via policy\traits Why do I want multiple Views? - Well in my example below, multi-index could give me all the operations that occurred with the given file - it could also give me a view that showed the average of all the calls to "savestufftofile()" - I could also JUST have a view that showed all the calls to savestufftofile() where the filename was "splat.txt" TAKING THIS FURTHER: I have not played with it, but Multi-Index supports serialization. You can now do this: * Run the test * Save the profile information * send your internal multi-index to disk * end the testing program * go make some coffee * come back later * run another program which re-serializes the data sent to file into ram again * I can now choose to report on it. Or I may have a "viewer" that I wrote specific to my application which allows me to travel through the different views of the multi-index container. SCOPE: All I am proposing is a heavily traited\ policy based implementation that uses multi-index and supports me giving it MY TYPES for id and metadata and configuring multi-index I am not proposing you write a viewer or what have you. But if you DO support this by design, I can now user your profiler class until the end of time because it does everything I could ever need until I die. (sorry for quoting all of below- it is relative to the conversation above) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Brian Braatz > Sent: Thursday, February 10, 2005 4:26 PM > To: boost(a)lists.boost.org > Subject: RE: [boost] Latest version of the profiler > > > > > -----Original Message----- > > [Brian Braatz] Wrote: > > > I for example- MIGHT take your library and stuff __FILE__ __LINE__ > into > > > the id. For this I would use a macro. This is also why I made the > > > request for the char*name type to be a template param. I may want to > > > plop in my own struct that has the __FILE__ and __LINE__ in it. > > > > The current implementation uses a map<string, pair<int, double> > for > > gathering of stats. This makes it easy to access data by profile name > and > > to > > accumulate data for a named profile. Of course this could be > rewritten, > > but > > my goal is to do as little work as possible. ;) > > > > Christopher Diggins Wrote: > > What if instead you wrote: > > > > #define PROFILE(TKN) BOOST_PROFILE(#TKN##__FILE__##__LINE__) > > > > Or better yet: > > > > #ifndef BOOST_PROFILING_OFF > > map<string, pair<int, string> > my_map; > > #endif > > > > #ifndef BOOST_PROFILING_OFF > > #define PROFILE(TKN) mymap[#TKN] = pair<int,string>(__LINE__, > __FILE__); > > BOOST_PROFILE(#TKN); > > #else > > #define PROFILE(TKN) /* */ > > #endif > > > > Would these be acceptable alternatives? > > > > [Brian Braatz] > I spent a little more time (that I really don't have today but the boost > mailing list "Draws me in..." :) ) Looking at your code at: > > http://www.cdiggins.com/profiler/profiler.hpp > > One thing that AT FIRST looked problematic for my usage is this: > > typedef map<string, counted_sum> stats_map; > > .... > > struct default_stats_policy > { > static stats_map stats; > > ... > > But, then I realized this is in a default Policy. So I can change that > (cool). I need to track on a per-thread basis each thread's profile > information. > > Hmm... > > On the metadata issue, things I need to track > __FILE__ > > > > I have the following needs: > 1- I have some code that is using wstring for everything else. > So the std::string seems weird here (yes I know boost is not completely > wstring compatible). > 2- I need to store BOTH the "average" for that area of code, and > also track the history of all the calls. I.e. look at the profile for > the last time we were in that function > 2- I need to be able to plug a structure of my metadata in there > somewhere. > - This will allow me to after the fact, scan the map and > find "sets" of profile information based on my specific stuff. > Examples: > Stuff threadID in there, so "later" I can filter > out just the stuff for that thread. > At runtime, set a particular flag on the > metadata based on a business condition in the code. > > > What I would like to see in the profiler: > > * An ability to give it something other than std::string for the KEY > type of the map > * An ability to track these readings in a list with my metadata > > Examples: > > Struct ProfileDataFileOperations > { > string sId; > std::string sFILE; > int iLine; > string sfiletouched; > > MyProfileData(string id, string file, int line,string > sFileYouTouched) > : sId(id), sFILE(file), iLine(line), > sfiletouched(sFileYouTouched) > {} > Bool operator==( ProfileDataFileOperations const & other) > { > return sId == other.sId; > } > } > > void savestufftofile(std::string sfile) > { > FileOpProfiler > > p(ProfileDataFileOperations("savestufftofile",__FILE__,__LINE__, > sFile)); > > } > > I would like to then, go back and generate a report on ALL operations > that touched a specific file. > > I would also like to go back and see all the things that touched > savestufftofile > > I might also want to go back and filter out based upon some other > combination of data. > > The things I am describing fall into my basic issue with using > profilers. They gave you MORE information than you need, without an > easily ability to filter out or cross cut the information. > > So the implementation of what I am suggesting is this: > > * Make the TYPE in the map be a typedef in the policy (the template > could default to std::string) > * allow me to provide my OWN way of storing the information > For above, I might want to keep a big old list > Or maybe I want what you have, but I want to plug a list<> into > the element you are using to track the profile information for a > "thing". > > I am sorry if it feels like I am blowing the scope of what you are > trying to do out of the water. > > I do think with some tweaks, though, you could have a profiler class > that could stand up to most of not all of the "weird" desires of folks > like me :) > >

2 1

RE: [boost] Re: Re: Latest version of the profiler
by Brian Braatz 11 Feb '05

11 Feb '05

For me, I should be ready in a few weeks to apply the profiler to a rather large body of code and actually use it in production. HOWEVER, I need the functionality approximating what I have previously stated before I can do that. (please see the mail where I suggest Multi-Index as the internal container) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Sérgio Vale e Pace > Sent: Friday, February 11, 2005 5:48 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Re: Latest version of the profiler > > Hi, > the library evolved a lot since your first proposal, and it seens > very impressive. I agree with you about do not adding new > functionalities, in fact I would even remove some, I´m not > particularly liked the pause/resume thing, but that´s just me. I am > interested in submitting it to boost, but I have to say: I would never > be able to develop it as fast as you been doing, and I never made a > boost submission before, but I would like to give it a try. still I do > thing there is need to polish and stabilize the design a little, > gather some more use cases and document a fill "best pratices" before > trying to submitting it > > Sérgio > > On Thu, 10 Feb 2005 15:48:28 -0500, christopher diggins > <cdiggins(a)videotron.ca> wrote: > > Hey Sergio, > > > > It's nice to have a friendly and supportive voice. So what do you think > of > > the library so far? Personally I don't want to add much more > functionality > > at this time. I am however very open to helping out anyone who wants to > make > > changes and/or take over the responsibility of submitting it to boost. > Is > > this something you still might be interested in? > > > > CD > > > > > > _______________________________________________ > > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Boost.Bind overload failure
by John Maddock 11 Feb '05

11 Feb '05

I'm trying to figure out what the problem is with the following code, given: double test_proc(int a, char b, long c) { return a+b+c; } Then: boost::bind<double>(&test_proc, 0, 0, 0); The code compiles fine with VC7.1 but with gcc-3.3.3 I get: ../../../libs/tr1/test/test_3_6.cpp:65: error: call of overloaded `bind(double (*)(int, char, long int), int, int, int)' is ambiguous c:/data/boost/develop/boost/boost/bind/bind_cc.hpp:47: error: candidates are: boost::_bi::bind_t<R, R (*)(B1, B2, B3), typename boost::_bi::list_av_3<A1, A2, A3>::type> boost::bind(R (*)(B1, B2, B3), A1, A2, A3) [with R = double, B1 = int, B2 = char, B3 = long int, A1 = int, A2 = int, A3 = int] c:/data/boost/develop/boost/boost/bind.hpp:1148: error: boost::_bi::bind_t<R, F, typename boost::_bi::list_av_3<A1, A2, A3>::type> boost::bind(F, A1, A2, A3) [with R = double, F = double (*)(int, char, long int), A1 = int, A2 = int, A3 = int] And with Intel 8.1 I get: ..\..\..\libs\tr1\test\.\test_3_6.cpp(65): error: more than one instance of over loaded function "boost::bind" matches the argument list: function template "boost::bind(R (*)(B1, B2, B3), A1, A2, A3)" function template "boost::bind<R,F,A1,A2,A3>(F, A1, A2, A3)" argument types are: (double (*)(int, char, long), int, int, int) check_bind0(boost::bind<double>(&test_proc, 0, 0, 0), double(0)); ^ Who's correct here? Normally I would trust EDG/Intel to get this correct if anyone would. Thanks, John.

2 1

RE: [boost] Re: Re: Re: Re: Latest version of the profiler
by Brian Braatz 11 Feb '05

11 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of christopher diggins > > ----- Original Message ----- > From: "Gennadiy Rozental" <gennadiy.rozental(a)thomson.com> > >> > 1. Profiler type 1 > >> > Log clock units and report mks into ostream > >> > 2. Profiler type 2 > >> > Log system/user time anf reports into Boost.Test log > >> > > >> > Both profiler I want to be able to use as scoped or accumulating. > >> > > >> > Gennadiy > >> > >> Can you please be more specific. I don't understand what you want and > >> precisely what the problem is. I am pretty sure we have different ideas > >> of > >> what a "report" is and what it means to "log". > > > > 1. Profiler type 1 > > Collect clock units and report mks into ostream > > 2. Profiler type 2 > > Collect system/user time anf reports into Boost.Test log > > > > Both profiler I want to be able to use as scoped or accumulating. > > > > Gennadiy > [Brian Braatz] Yes- those are the words I was trying to say. I might want to accumulate ALL of the calls, in one big honking list. Or I might want a "overview" of the average of each profile point. I think we need both, in addition to allowing me to put metadata into the profile point. Because with the metadata, I can now go back through the accumulated list and filter out what I care about. ** this is the big piece that is missing for me from off the shelf profilers ** > Christopher Diggins Wrote: > > Gennadiy, > > Your post makes almost as little sense as before, simply changing "Log" to > "Collect" doesn't help me out much. What you wrote is virtually > incomprehensible! It seems to me that you aren't really making an effort > to > help me out here. > > What does "report mks into ostream" mean? When do you want to do these > reports? What do you want reported. As far as I can tell you can do this > with my code. Why do you think you can't? How and when do you want to > "collect system/user time"? Why would you want to log it? How would you > report it? And why can't you do this with the current library? Is "anf" > some > kind of acronym? > > If you don't want to take the time to respond to my questions carefully, > and > respectfully than I would ask that you simply don't respond. I am at the > limit of my patience with your negative attitude and lack of courtesy. > [Brian Braatz] Part of the problem with all communication is we all have buzzwords and different ways of phrasing concepts. I know I for one, have a HARD TIME getting an idea typed out (as you will see in my previous post :) ). I cannot speak for Gennadiy, but I believe he was just trying to share his thoughts and I do not think you should get offended. This list is a pretty big thing and we are bound to run into situations where a few lines of text make sense to some but not others. The funny thing, is I saw his post and went "YES! That is what I was trying to say!". Which is a different reaction than you had. Brian

3 2

BOOST_CHECK_THROW gives spirious warning
by Vladimir Prus 11 Feb '05

11 Feb '05

Hello, when running "bjam test" in libs/program_options/test, I get this: ../../../libs/program_options/test/cmdline_test.cpp:472: warning: statement with no effect Line 472 contains: BOOST_CHECK_THROW(cmdline cmd(1, (const char*const *)argv, allow_long), invalid_command_line_style); and I did not touch that line for a long time. I think the warning is caused by some Boost.Test change. Any change to fix this? Thanks, Volodya

2 1

RE: [boost] Re: Profiling Library suggestion
by Brian Braatz 11 Feb '05

11 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Jonathan Turkanis > Sent: Friday, February 04, 2005 2:45 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: Profiling Library suggestion > > christopher diggins wrote: > > I was searching around boost for mention of a profiling library. A > > fellow by the name of Carl Daniels posted something about an invasive > > profiling library. I was wondering in anyone knows what happened to > > that project? Profiling seems lacking at Boost, is anyone else > > interested in such a thing? > > > > Would a trivial policy driven RAII type be sufficient to garner > > interest as > > a mini-library? > > > > e.g. > > > > struct ProfilerDefaultPolicy { > > OnElapsed(int msec) { > > cout << "time elapsed (msec): " << msec << endl; > > } > > }; > > > > template<typename Policy_T = ProfilerDefaultPolicy> > > class Profiler { > > public: > > Profiler() { mnStart = GetTickCount(); }; > > ~Profiler() { Policy_T::OnElapsed(GetMSecElapsed()); }; > > int GetMSecElapsed() { return GetTickCount() - mnStart; }; > > int GetTickCount() { return int(double(clock()) * 1000 / > > CLOCKS_PER_SEC); }; > > private: > > int mnStart; > > }; > > > > usage: > > > > void MyRoutine() { > > Profiler<> p; > > // do stuff > > } > [Jonathan Turkanis]: > How about: > > typedef profiled< MyClass, Interface, Profiler<> > > MyProfiledClass; > > ? [Brian Braatz] That is a good idea (use a AOP style weave). It begs asking here- when we talk about profiling, what are the use cases you guys see. I have some stuff to implement profiling on in the coming weeks. My situations are as follows: * Profile and log the profiling results of my unit tests between the checkpoints -> Either explicitly or I may redefine BOOST_CHECKPOINT * Profile an application for when makes certain method calls on some COM objects- Also log this information. -> Problem is, folks have coded directly to the COM objects proxy class. Because of this, the AOP style typedef trick will not work unless I push the proxy classes into a namespace- and redefine them in the global namespace with a weave in place. (structurally this might be more work than I want to deal with) * profiling specific operations which cross cut many areas of the system and only doing that when certain dynamic conditions exist I am asking you guys for how you need to use profiling because by talking aobut the problem that is to be solved, it might make the discussion of what the solution is easier to address.

4 4