March 2005 - Boost - lists.preview.boost.org

[serialization] current CVS not working for CW
by Joaquín Mª López Muñoz 14 Mar '05

14 Mar '05

Hello, None of the CW compilers being tested seems able to build the serialization lib against the current CVS. I seem to recall there were no problems of this kind a month ago or so. I know the author's probably aware of this, just wanted to know about the status of this problem. Thank you, Joaquín M López Muñoz Telefónica, Investigacion y Desarrollo

4 4

RE : FSM Review : Performance Issues
by jdspalding＠comcast.net 14 Mar '05

14 Mar '05

******************************************************************************* BOOST Re: FSM Review : Performance Issues. I'd like to add some overall comments about the FSM's perceived performance issues. To clarify my bias, previous comments, I have already submitted a positive review, focusing on usage issues. Context: On Sat, 12 Mar 2005 , Dave Garland wrote >On Sat, 12 Mar 2005 15:57:10 -0500, David Abrahams wrote >> >> Haven't a few people been reporting that they won't even begin to >> apply this one because of particular limitations? Anyone who needs >> higher performance won't even get started. >Sure, and on the other hand we've had at least one testimonial that this was >the best fsm library they found -- served them well in a project. I've heard >the same sort of argument from people comparing std::string to a char*. >std::string: Discussion : I believe the discussion of performance in the proposed boost FSM library is going in an unrewarding direction. Undefined design possibilities are being weighed against a working system. (notice : I am going to be sympathetic to the "working system".) On the "design possibilties" side there seem to be a number of major issues. - double dispatch is O(n), we'd like O(1). - overall performance is slow, state transitions in XXX nSec are too slow for a proposed application. - some people have the idea that the techniques used to allow FSM to extend over multiple translation units could be improved. Again and again someone writes in and says the design does not feel right, if we did XXX, FSM is likely to be able to fix YYY. However, the concrete solution is not yet conceived, and for now, a general plausability argument will have to do... Proposal: I think we could adopt a structured approach to evaluate these competing claims. A) One viewpoint of the FSM library is through the filter of application performance tradeoffs. IMHO we have exhausted the qualitative approach, and need the definiteness of the quantitative. I would think the FSM critics have the obligation here to provide support to their view, that FSM performace is inadequate. A.1) It is said that performance considerations will keep FSM from being considered for some applications. => Then could we specifically, and quantitatively define a class of applications for which FSM, as it exists today, would be inadequate? (model app) - in the timed performance area, what are the model app's FSM performace metrics, such as number of states, use of orthogonal states, depth of state nesting, number of events fired per second, number of events handled per second? - what are the model app's non FSM performance metrics, perhaps normalized to FSM metrics, such as lines of code or execution time, per state change, or per event fired? - please also include some details about the context for the app's execution, usage area, etc., to assist the readers from other experience domains. A.2) It is said that O(n) double dispatch is inadequate, that better design is required for acceptance. => To really assert this we really have to have a complete model of FSM's runtime behavior. Since this is different in different usage scenarios, what we really need are several usage scenarios, and an analysis/measurement of where FSM spends its time. I think Andreas has mentioned that he thinks other areas than double dispatch are more important. IMHO this is a quantitative issue, per usage scenario. B) A second viewpoint of the FSM library is that of usage requirements in the application's code. Here there are at least two areas of contention - B.1) The implications of the requirement for compilation in multiple translation units. - B.2) The overal ease of use of the FSM library's API. Finally, here is my submission of data for a model usage of FSM, in the above framework. ****************************************************** Quantitative data : example : from J. Spalding's use of FSM area : industrial control. A.1) Performance metric Number of states : 15-20. maximum state nesting depth : 5. use of orthogonal states : no. maximum number of events per second (burst) : 10. events handled per second (burst) : 10. context : Use of FSM in a machine control application. FSM controls application's execution "mode", and the hardware error monitoring state. remarks : model app not stressing FSM performance. A.2) Runtime behavior profile not carried out. FSM performance trivial component of model application. B.1) Multiple translation units. model application code was broken across multiple translation units, no particular problems occurred. B.2) API Ease of Use. API was expressive, easy to configure to solve the problem. The only difficulties encountered were found in tracing compile time initial useage mistakes. This is also a strength of the approach, incorrectly configured FSM machines will not compile. *********************************************************** My Opinion : per FSM acceptance into Boost: - I like the FSM API, think performance today is adequate for many/most applications, think UML connection is a plus, voted for FSM acceptance. - Seeing statements such as 100 nSec cost per event handled prevents serious use of FSM, does offend me, without a supporting application performance model/context. IMHO Andreas has requsted such info many times, and has not been rewarded with any quantitative data. - IMHO, If we were evaluating FSM for an engineering use today, it would be accepted, due to good API, good documentation. The only way FSM could fail is if FSM code grabbed > (XX) % of the app's compute cycles, or made an unacceptable latency hit. The alternatives, at least in the boost discussion of it, are all proposed concepts requiring evaluation & development. - Further it would be quick work to use FSM to prototype a proposed use, and numerically evalute its time/space/latency cost. Just write the proposed FSM on the target machine, install it with a test harness that puts out events at the required rate, and you have a use/not use decision with hard data. If FSM were included in Boost, then this evaluation might be accomplished a number of times in the future, and the fsm interest group may acquire data justifying a performace oriented new implementation/library. ***********************************************************

1 0

Re: Sockets: proposal for a library design
by Don G 13 Mar '05

13 Mar '05

Hi Boris, Thanks for all the effort and getting something posted! On first blush, my thoughts are as follows: I would suggest that a proposed Boost.Net library should focus on networking in a more abstract manner, and not be merely a socket encapsulation. IMHO, sockets are a terrible API and should be hidden as fast as possible. A socket wrapper class is appropriate, but I would not go to any trouble to change the socket API. Simply wrap the resources and provide portable access to the underlying system. The real end-user part of the Net library should not talk about sockets (unless one provides a method like get_native to return the socket handle, and that method is defined as non-portable). I think all desired I/O models should be available at run-time (see below). In my own work in this area I have seen that this approach does not greatly effect the implementation. In other words, there is virtually nothing to be gained by making async I/O optional at compile-time. As others have also suggested, I would agree that the net facilities not be tied up into I/O streams. It would be better to provide the network facilities and then layer on I/O streams for those that want it. There are really only a few abstract entities to worry about: Url, Address, Stream, Datagram, Acceptor. In my work (not related to Boost), I've also created a Network class to serve as the abstract factory and contain a thread pool for doing the async I/O. I believe your diagrams use "Client" and "Server". I think these terms are a bit too generic. I prefer the term "Acceptor". Usage examples: shared_ptr<Network> net (new SomeSpecificNetwork(some_arguments)); Url some_url = "http://www.boost.org"; shared_ptr<Address> addr = net->new_address(some_url); shared_ptr<Stream> str = addr->new_stream(); str->connect(); // now it's connected (blocking) shared_ptr<Address> localhost = net->new_local_address("ntp://"); shared_ptr<Datagram> dg = localhost->new_datagram(); // on the ntp port localhost = net->new_local_address("ftp://"); shared_ptr<Acceptor> ac = localhost->new_acceptor(); // "ftp" port str = ac->accept(); // blocking accept I've omitted any nonblocking/async methods for brevity. IMHO, blocking, nonblocking and free-threaded-async-w/callback are the only models worth providing. These models can be ported anywhere and can be implemented via whatever mechanism is best for the given platform. A select() based version can be made to work just about anywhere with minimal #ifdef logic, but may be less than ideal when the system supports poll() or NT I/O completion ports. One thing I think is essential when using a blocking model is cancellation. For example, I have a reset() method on Acceptor, Address, Datagram and Stream that can be called at any time to cause blocking methods to terminate with a cancel exception (obviously this must be from another thread). Ironically, these reset() methods meant I could not use blocking socket calls to implement my blocking methods - recv() cannot be canceled once it blocks (at least not portably)! The big issue in nonblocking I/O is how to notify the application that things have changed and now would be a good time to try more I/O. I like the free-threaded callback for this as it fits closely with async I/O and that way the nature of the I/O mechanism can still be encapsulated. Throughout the above I use the term "free threaded callback". By that I mean that the user supplied callback will be invoked directly by a worker thread. The reason for this is that it is the only way to approach the efficiency of a hand-rolled select/poll loop. When select() returns, the fd_set would be examined and steps taken to prepare for the next call to select(). Since multiple operations could complete, whatever state machines exist are pumped inside a processing loop between select() calls. When the abstraction comes in and hides the loop behind callbacks, if the callbacks are made directly, we add only the overhead of making the callbacks. If, on the other hand, all callbacks where marshalled out, the loop would not have the information needed to formulate the next call to select() and would likely have to be interrupted repeatedly to get to the proper state. The dangers of this approach should be obvious (deadlock to say the least). The user code is now forced to understand the execution model in order to properly code a callback. What I found is that a short list of allowed operations is sufficient. Any async I/O methods are OK, as are nonblocking methods, etc.. After that (long winded) explanation, what I have also seen is that very few applications need the performance that free-threaded callbacks provide and would opt out of the complexity if they could. My solution to this was an auto-marshalling callback. I'm not sure what facilities Boost provides for queued function<> calls, but the idea is to provide a callback that queues a callback. The pseudo code for me was something like this: str->async_read(buf, n, channel.bind_async_call(this, &This::foo)); The "channel" was my entity that could enqueue calls. The "(this, &This::foo)" would actually be a function<> object or something. The return from bind_async_call() is a function<> object that performs the actual call to channel.async_call() passing the user callback. Whew! Slightly more than $0.02, I know. :) Best, Don --- Boris <boris(a)gtemail.net> wrote: > I updated the Wiki pages for a net library at > http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet. > > After collecting all the information I found at the Wiki pages for > the socket and multiplexing library I try to explain how a net > library should basically look like. The proposal includes various > I/O models and is based on I/O streams. > > As usual any comments are appreciated, > Boris __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

Re: [boost] Re: [review] hash functions
by JOAQUIN LOPEZ MU?Z 13 Mar '05

13 Mar '05

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Domingo, Marzo 13, 2005 0:52 am Asunto: [boost] Re: [review] hash functions > Alberto Barbati <abarbati(a)iaanus.com> writes: > > > Ah! And there's one more case in which we are helpless, although > I'm > > curious to see an implementation that exploits such latitude: > the > > wording used in the standard does not guarantee that the mapping > from > > pointers to integers always produce the same value over time. In > other > > words: > > > > char* p = new char; > > size_t i1 = reinterpret_cast<size_t>(p); > > size_t i2 = reinterpret_cast<size_t>(p); > > assert(i1 == i2); // ??? > > char* q1 = reinterpret_cast<char*>(i1); > > char* q2 = reinterpret_cast<char*>(i2); > > assert(p == q1 && q1 == q2); > > > > The standard guarantees that the second assert passes, but says > nothing > > about the first assert. > > There are other cases too. reinterpret_cast could map all > pointers to > the same integer. If you allow me to be a little pedantic, this is not the case. reinterpret_cast<> guarantees back conversion, so it can't possibly map every pointer into the same integer. As for the rest of your argument, I agree 100%. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 5

Re: [boost] [review] hash functions
by brangdon＠cix.compulink.co.uk 13 Mar '05

13 Mar '05

In-Reply-To: <007e01c52597$b62c1980$6601a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > pair<int, int>, int[2], struct { int a; int b; } are different > representations of the same thing; it is not strictly necessary for > them to use the same algorithm, but it's desirable and will eliminate a > source of confusion and mistakes. Really? What kind of mistakes? In my experience, if you want two different things to hash the same, you need to write their hash functions with that in mind. It is a special case which justifies not using the default hash function. > void hash_range( size_t & seed, It first, It last ); > > should this function be added. You are welcome to spell the above as > > size_t hash_range( size_t seed, It first, It last ); I am also tempted by: size_t hash_range( It first, It last, size_t seed=0 ); perhaps replacing the 0 with some other default value. So people can ignore it if they don't need it. But doesn't this mean that hash_value( pair<int,int> ) also needs a seed argument, if you want it to match hash_range( int[2] ) ? -- Dave Harris, Nottingham, UK

2 2

Re: [boost] Re: [review] hash functions
by brangdon＠cix.compulink.co.uk 13 Mar '05

13 Mar '05

In-Reply-To: <d0vsa6$bkm$1(a)sea.gmane.org> abarbati(a)iaanus.com (Alberto Barbati) wrote (abridged): > 2) provide the hash function (with reintepret_cast<>) only for those > platforms that we are able to check in advance that will satisfy those > requirements and make any use of such function produce a static assert > for all other platforms In the case of (2), the platform may provide another implementation which can be used. For example, perhaps the pointers are segment+offset and the offset part is suitable. In my view, boost should be allowed to vary the implementation of the hash functions to suit the local platform. One interesting case is compacting garbage collectors. These already have problems with std::less() and I'd rather not make things worse by over-specifying hashing. -- Dave Harris, Nottingham, UK

1 0

Re: [boost] [aligned_storage][repost] problems with GCC 4.0.0 20050309
by JOAQUIN LOPEZ MU?Z 13 Mar '05

13 Mar '05

----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Domingo, Marzo 13, 2005 2:18 pm Asunto: Re: [boost] [aligned_storage][repost] problems with GCC 4.0.0 20050309 > JOAQUIN LOPEZ MU?Z wrote: > > The class aligned_storage in boost/aligned_storage.hpp has > > the following decl: > > > > template < > > std::size_t size_ > > , std::size_t alignment_ = std::size_t(-1) > >> > > class aligned_storage; > > > > GCC 4.0 complains about the default value for aligmnent_ saying > > that: > > > > '(size_t)((-1))' is not a valid template argument for type > > 'unsigned int' because it is a non-constant expression > > > > which is ruining some of the regression tests. > > Is GCC right or shall I submit a bug report at gcc.gnu.org/bugzilla? > > I don't see anything in the standard or in the issue lists that > prohibits > size_t(-1) as an integral constant expression. Bug report. > Alas, I tried to isolate this into a simple snippet #include <cstddef> template < std::size_t size_ , std::size_t alignment_ = std::size_t(-1)> class aligned_storage { }; int main() { aligned_storage<1> as; } but then the problem goes away. Would some kind soul with access to GCC 4.0.0 care to take a look at this? The actual problem is shown at: http://tinyurl.com/4hxy5 Thank you very much, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] Re: [review] hash functions
by JOAQUIN LOPEZ MU?Z 13 Mar '05

13 Mar '05

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Domingo, Marzo 13, 2005 4:52 am Asunto: [boost] Re: [review] hash functions > JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> writes: > > > ----- Mensaje original ----- > > De: David Abrahams <dave(a)boost-consulting.com> > > Fecha: Domingo, Marzo 13, 2005 0:52 am > > Asunto: [boost] Re: [review] hash functions > > > >> Alberto Barbati <abarbati(a)iaanus.com> writes: > >> > >> > Ah! And there's one more case in which we are helpless, > although > >> I'm > >> > curious to see an implementation that exploits such latitude: > >> the > >> > wording used in the standard does not guarantee that the > mapping > >> from > >> > pointers to integers always produce the same value over time. > In > >> other > >> > words: > >> > > >> > char* p = new char; > >> > size_t i1 = reinterpret_cast<size_t>(p); > >> > size_t i2 = reinterpret_cast<size_t>(p); > >> > assert(i1 == i2); // ??? > >> > char* q1 = reinterpret_cast<char*>(i1); > >> > char* q2 = reinterpret_cast<char*>(i2); > >> > assert(p == q1 && q1 == q2); > >> > > >> > The standard guarantees that the second assert passes, but > says > >> nothing > >> > about the first assert. > >> > >> There are other cases too. reinterpret_cast could map all > >> pointers to > >> the same integer. > > > > If you allow me to be a little pedantic, this is not the > > case. reinterpret_cast<> guarantees back conversion, so it can't > > possibly map every pointer into the same integer. > > 4 A pointer can be explicitly converted to any integral type large > enough to hold it. The mapping function is implementation-defined > [Note: it is intended to be unsurprising to those who know the > addressing structure of the underlying machine. ] > > 5 A value of integral type or enumeration type can be explicitly > converted to a pointer. 64) A pointer converted to an integer of > sufficient size (if any such exists on the implementation) and back > to the same pointer type will have its original value; mappings > between pointers and integers are otherwise implementation-defined. > > There's no guarantee that the integer type will have sufficient size. OK, with that provision in mind I buy your thesis now. > > > As for the rest of your argument, I agree 100%. > > Now you agree with all of it ;-) > (I hope) > Definitely! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[review] hash functions
by Thorsten Ottosen 13 Mar '05

13 Mar '05

Dear All, It's a pleasure to announce that the review of Daniel James' hash functions library starts today (8th of March) and ends the 12th of March. The library is fairly small and can be seen as an extension to boost.functional. Therefore the review is a fast-track review. >From the introduction of the library: "boost::hash is an implementation of the hash function object specified by the C++ Standard Library Technical Report. It is being proposed as an addition to Boost.Functional" "The hash functions have several possible uses, but the main intention of boost::hash is for indexing a hash table such as the unordered associate containers in the Technical Report, or the hash index for the Boost Multi-Index Containers Library. A hash table stores its values in buckets which are numbered by their keys' hash values. Given a key, the bucket the object lies in can be quickly found be calculating its hash value and looking in the corresponding bucket. This requires the hash function to be fast - since the point is to find the object quickly. Collisions need to be minimised, to reduce the number o objects in each bucket, and thus the number of comparisons required to find objects in a bucket." . If you decide to do a review, please follow the guidelines described in http://www.boost.org/more/formal_review_process.htm#Comments The library can be downloaded from http://boost-sandbox.sourceforge.net/vault/index.php?directory=Hash best regards Thorsten, review manager -- Thorsten Ottosen ---------------------------- www.dezide.com www.cs.aau.dk/index2.php?content=Research/bss www.boost.org www.open-std.org/JTC1/SC22/WG21/

12 48

Re: [boost] Re: FSM Review
by 辉李 13 Mar '05

13 Mar '05

Hi all, I'm a new guy in boost list. --- Alexander Nasonov <alnsn(a)yandex.ru> wrote: > Because classical approach to implement POAManager > and the like > is not overly complex and because no special skills > are needed, > new library should have several advantages (to give > answers to problems > 1-3, at least) and it should have very clear and > easily understandable > model. > Tutorial of this library should describe how to > solve typical problems > of classical approach. > Support Alexander's opinion., I have seen the tutorial of FSM library, I think the tutorial is too UML-style. As I know FSM has been used widely before UML become popular. Some classical usage of FSM have simple state transfer and action style, but has many states. The tutorial should give some examples in the classical style, or we should call this library boost::FSM::UML-style. The performance of FSM is very important for some application with simple usage of FSM. When using a FSM lib, the user of this kind of FSM should not pay the loss in performance for the functions they don't need. If the trade between performance and functionality can not satisfy some FSM users in this design, maybe the boost can accept this library but should provide an opportunity for accept other design of FSM with high performance but some simple functionality. regards William Lee _________________________________________________________ Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂 http://music.yisou.com/ 美女明星应有尽有，搜遍美图、艳图和酷图 http://image.yisou.com 1G就是1000兆，雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_…

1 0