- Boost - lists.boost.org

[odeint] gsoc 2011: finalization of odeint
by Mario Mulansky 23 Mar '11

23 Mar '11

Dear boost community, I would like to propose a project for the GSoC 2011, namely to improve the odeint library currently living in the boost sandbox [1] with the (optimistic) goal to put it on a level suitable for a boost review process. I have been working on this library for about one year now, although I couldn't spent much time on it during the last months. The other author of odeint is my colleague Karsten. We have had contact to this mailing list before [2], getting few, but rather positive feedback. The odeint library is a modern, template based, generic, C++ library for integrating (solving) initial value problems of ordinary differential equations. Such an ode is usually given as dx/dt = f(x,t) with x(t=0) = x0. x here is generally vector valued, possibly high dimensional. The easiest method to solve this problem is the Euler-method, where you introduce a small value Dt and then iterate x(t+Dt) = f(x,t)*Dt. Obviously, in real applications one uses more sophisticated methods, a well known class are the Runge-Kutta methods [3], suitable for many cases. Additionally, there exist special methods for system where the time evolution has conserved quantities, called symplectic methods. Furthermore there are methods for stiff systems and many others. For odeint, our first focus lies on Runge-Kutta methods. We have implemented several such methods together with error control routines and lately added dense output functionality. Our very recent code is a generic Runge-Kutta stepper that allows the user to build any Runge-Kutta method at compile time by providing the appropriate constants and is based on fusion::vectors. Karsten wrote a good article on that [4], unfortunately in German. There are also symplectic routines for Hamiltonian systems and we started to add implicit methods as well. We also have unit tests based on the boost test framework and some basic documentation. The library is currently at a level where it can be used in scientific applications and it is indeed in use by us and several other people in an academic environment. The major enhancement of our library over existing ones like gsl or methods from the numerical recipes is that our routines do not depend on the container type used to represent the vector x. So our library works with the usual std::vector<double> and array<double,N> but also with vector< complex<double> > (already a major improvement over gsl and nr, which we get for free, basically) and blitz++ arrays. The major strength of this approach, however, is seen when you want to solve odes on complex networks where you have to implement your own, non-trivial container type representing some kind of network. With odeint you can fully separate the network-implementation from the ode-solving algorithm. Furthermore, we are able to easily employ the power of CUDA devices to solve odes by the help of the thrust library and using thrust::device_vector as our container type. It is also possible to use odeint with arbitrary precision types like the gmp library. Some more, unfortunately slightly out-dated, information about odeint can be found in [5]. What are my plans for a GSoC? 1. There are still some parts of the library which are not satisfactorily designed and need to be rethought. This is where we could really need the help of an experienced mentor to create a clean, well structured library. 2. Add methods with varying order (burlisch stoer). 3. Add dense output and error control to the generic runge-kutta implementation. 4. Add convenience function that allow users an easier access to the libraries capabilities. 5. Create an observer interface that allows the user to analyze properties of the system while integrating the equations. 6. Make everything ready for a boos review. Points 1-5 can surely be realized during the GSoC period, I believe. And whatever time is left I will spend on documentation and review preparation. A few words to myself: I'm currently a PhD student in physics at the University of Potsdam working on problems in the field of nonlinear dynamics. Solving odes is basically every-day-work for me and I have a used many of the routines in odeint for my scientific research. Thanks for reading. I greatly appreciate any feedback! Regards, Mario Mulansky [1] https://svn.boost.org/svn/boost/sandbox/odeint/ [2] http://boost.2283326.n4.nabble.com/library-proposal-odeint-td2670019.html [3] http://en.wikipedia.org/wiki/Runge–Kutta_methods [4] http://www.c-plusplus.de/forum/282091 [5] http://www.codeproject.com/KB/recipes/odeint.aspx

4 6

[context review] Windows ABI requirements
by Holger Grund 23 Mar '11

23 Mar '11

Hi, I've had a very brief look at the x64 ASM Windows code as I think I raised concerns about this before. As always, I'm pretty busy and I probably won't be able to properly review the entire lib. Looking at the fcontext_x86_64_ms_pe_masm.asm it would seem that several ABI requirements are violated and it is not clear to me why this would always work. For instance, the stack is not properly aligned in the call to _exit & set_fcontext. At least _exit can call into user code, IIRC (preterminators & terminator registered via .crt$x* sections) and that code may require a properly aligned stack. I don't see proper unwind descriptors. What happens if an async exception is triggered in the middle of set_fcontext? The x86 Windows version seems to have similar problems. IIRC, the dispatch logic checks for EH registration nodes to be on the stack for x86. What happens if an untrapped exception is trigger in a code path called from the context entrypoint? It would seem that there is an unwind chain via make_fcontext (which doesn't appear to have any unwind description and would therefore assumed to be a leaf function). Is its state necessarily live when set_fcontext is called? What guarantees are there that poking a few fields in the TIB is good enough to properly switch the context? At least FLS has more than one field in the TIB. There's also bookkeeping for whether registered callbacks have been called. Why is saving the register you save enough? Why wouldn't a future version of Windows just take down the process if it detects stack hacks. I believe, the unwinder checks the stack pointer in the unwind context against stack limits and for 8-byte align at each caller in the chain until a barrier is found. How are you certain that kernel32/kernelbase/ntdll don't assume that there's a guard page (where guard page has the Windows defined meaning as in PAGE_GUARD) at the end of the stack? Even if that all works today, how can you be sure it will on Win8, 9 and beyond? To be honest, I don't think a library outside the operating system is not the proper place to do this kind of thing at all (and even if you're part of the OS it's an incredibly hard thing to get right -- UMS had tons of problems in Win7 RTM) BTW, glancing over the docs, an implicit conversion from size_t to protected_stack seems weird, but that might just be a glitch in the doc build. Thanks! -hg

2 4

Getting started guide updates
by Vladimir Prus 23 Mar '11

23 Mar '11

Folks, I've tried to update the getting started guide (for Unix so far) to better explain building, in particular: - To make the "bootstrap + bjam" process the only documented one, since it turns out to be fairly painless on Unix - To clarify some common questions inline The result can be previewed at http://lvk.cs.msu.su/~ghost/unix-variants.pdf , see section 5. I would appreciate if folks take a look and suggest whether it can be improved further. I plan to make a similar update for Windows, but it's somewhat tricker. Thanks, -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40

5 8

stream-cons & stream-cdr using boost.proto & boost.fusion
by Niitsuma Hirotaka 23 Mar '11

23 Mar '11

I try to make stream-cons & stream-cdr using boost.proto & boost.fusion. code is here http://d.hatena.ne.jp/niitsuma/20110323/1300850731 But this is not work in the following case auto s= stream_cons(2,stream_cons(1,0)); auto ss= stream_cons(3, s); std::cout << proto_force( proto_force(ss.cdr.car).cdr.car).car << std::endl; //not work std::cout << stream_cdr(stream_cdr(ss)).car << std::endl; //not work Where is problem?

1 0

Boost Talk: "How I Code" (?)
by Gottlob Frege 23 Mar '11

23 Mar '11

I was wondering if anyone here wanted to take part in a Boost talk about real world programming experiences. Something like "rules to code by" or "nuggets of experience" or...? ie if you had to give your 1 favorite rule you code by, what would it be? For me it might be: - Inversion Principle or - Comments with the word "otherwise" are the best comments I could explain the Inversion Principle, or tell the story of when I started using "otherwise" in comments, within 10-15 minutes, maybe less. Then someone else could explain something helpful they've learned over the years. It could be the easiest way to get your feet wet in giving a talk - you just need to do a few minutes. I don't think there is much detail needed actually - I think just knowing that the author of so-and-so library actually does use TDD daily, or that a respected regular on the list does things this way, etc - just *knowing* that someone you respect does things a certain way, might be all that is needed. You can always find more details about certain rules/principles on the web, so in-depth explanations aren't really necessary. The important part, I think, is that someone you know (even just "virtually") is doing things that way. I'm thinking it would be called "How I Code". Not "How you should code" (although that might be implied). Just how each presenter codes in real world programming tasks. But I can't do this alone - no one wants to hear just about how I code - they want to hear about how you code. Plus I will probably have another Boost talk to frantically make last minute changes to, so I can't handle 2 talks - but I can help get people together and organize this and do a part. Overall, hopefully it would be more discussion than presentation, and maybe even some contradicting favorite rules - real life programming is never that simple such that one rule always works, right? Tony Van Eerd

10 19

[review scoreboards]
by Sid Sacek 23 Mar '11

23 Mar '11

When I go onto sports web sites, they contain scoreboards for active games. The boost reviews are a bit like those active games. When a review starts, there generally is a huge flurry of emails that hits the boost mailing list, and a lot of heated debates go on in these mails. I generally don't have time to read through hundreds and hundreds of mails to get to the actual reviews. What I would like instead is an active scoreboard. It would contain a single page for a particular review, the current count of yeas and nays, the people who actually contributed to the reviews, and links to their reviews. It would also contain a final status of the review, and any contingent actions needed for completion. I assume this does not yet exist, and if not, how difficult would it be to set up something like this? Or maybe I should ask whether anyone else would prefer something like this? -Sid Sacek

3 4

[aligned storage] namespace conflict
by Tobias Germer 22 Mar '11

22 Mar '11

Hi all, while patching the interprocess library (see ticket #5230) we found a namespace conflict in aligned_storage.hpp. The source refers to the (local) namespace "detail::". In the context of interprocess, this could be resolved to "boost::detail" or "boost::interprocess::detail", causing an ambiguity. I suggest to use the absolute namespace in aligned_storage, i.e., every "detail::" is replaced with "::boost::detail::" (see below for the patch). Are there any arguments against this? If nobody protests, Ion would apply the patch. Regards, Tobias Suggested patch: Index: aligned_storage.hpp =================================================================== --- aligned_storage.hpp (revision 70385) +++ aligned_storage.hpp (working copy) @@ -50,7 +50,7 @@ typename mpl::eval_if_c< alignment_ == std::size_t(-1) - , mpl::identity<detail::max_align> + , mpl::identity<::boost::detail::max_align> , type_with_alignment<alignment_> >::type align_; } data_; @@ -76,12 +76,12 @@ #else public #endif - detail::aligned_storage::aligned_storage_imp<size_, alignment_> + ::boost::detail::aligned_storage::aligned_storage_imp<size_, alignment_> { public: // constants - typedef detail::aligned_storage::aligned_storage_imp<size_, alignment_> type; + typedef ::boost::detail::aligned_storage::aligned_storage_imp<size_, alignment_> type; BOOST_STATIC_CONSTANT( std::size_t -- Dr. Tobias Germer | tgermer(a)think-cell.com Software Engineer think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

3 2

Re: [boost] Missing Documentation on Building and Installing Documentation.
by Stirling Westrup 22 Mar '11

22 Mar '11

On Mon, Mar 21, 2011 at 7:25 PM, Julian Gonggrijp <j.gonggrijp(a)gmail.com> wrote: > Stirling Westrup wrote: > >> Julian Gonggrijp wrote: >> > I think you should consider the Boost tree to be your installation of > Boost. The additional copies of the headers and the libraries are just > for convenience. If you throw away the Boost tree, you throw away your > Boost installation together with the documentation that starts at > $BOOST_ROOT/index.html. If I were to simply untar Boost into my include directory I would end up with documentation files in my include directory, where they don't belong, and where my system will not look for them, and were I to build the libraries, they would end up putting large amounts of extraneous files into the my include directory. So, I generally approve of the fact that bjam is capable of building the libraries and installing them and the headers into the canonical locations for my system. The only problem is that bjam does not know about the documentation. All I want is someone to tell it how to relocate the docs. If this breaks any documentation, then arguably this is just as much of a bug as having headers that break when relocated, and can be addressed on a case-by-case basis. > > Note that Boost is not only targeted at Linux users. Moreover, the > getting started guide is very clear about the structure of the Boost > tree, including the location of the documentation. It may be clear about the structure of the Boost tree, but the fact that Installation guide provides an installation method makes the structure of the Boost tree appear irrelevant to everyone except the developers of Boost. -- Stirling Westrup Programmer, Entrepreneur. https://www.linkedin.com/e/fpf/77228 http://www.linkedin.com/in/swestrup http://technaut.livejournal.com http://sourceforge.net/users/stirlingwestrup

1 0

[context review] Several Questions
by Artyom 22 Mar '11

22 Mar '11

Hello, Before I start working with this library for review I need a clarification of several statements to understand actual usefulness of this library: > > A context switch between threads costs usually thousands of CPU > cycles on x86 compared to a user-level context switch with few > hundreds of cycles. > Performance ----------- One of the first things I did when read this statement and take a look on measurements is to write my own benchmark of context switch. I've run it on: - Intel i5 2.5GHz CPU 2 cores 4 threads. - Linux x86_64, Ubuntu 10.10 And compared context switch performance using sched_yeild and jump_to. I used default boost::context<> settings and default build (against Boost-1.46.0) and used dummy switch to measure actual operations beyond the switching There were two threads giving each one a time quanta and measured how much time context switch takes (of course included some warm up) sched_yeild - 377us Boost.Contex - 214us Dummy - 10us All tests done on a single CPU using taskset 0x1 ./test params So finally I can see that Boost.Context does not behave **much** better then OS context switch? I understand that I probably used by default ucontext but it is default and this is how it is going to be shipped by most distributions as it would probably be the safest. I need to see rationale, limitations and so on, in very explicit way. Usefulness of N:M model (or even 1:M model) ------------------------------------------- Long time ago OS developers used N:M threading model where several kernel threads were mapped to several user-space thread: - Solaris < 9 or 10 - Linux <= 2.4, - FreeBSD < 8 All these OSs today moved to 1:1 model as most efficient one, so I can't buy it that N:M or even 1:N model in this case would give performance advantage. As you know, even POSIX 2008 deprecated ucontext at all. So I would like to see some very good and based rationale with description of specific use cases and examples. I understand that it may be very useful paradigm but as long as I see most of implementations move away of N:M model... Why do you bring it back despite of huge drawbacks users space threads have: like interaction with blocking system calls, interaction with physical CPUs and so on? -------------------- Thanks, I'd like to see an answer on this topics before I continue. Artyom

3 25

[Review] Type Traits Extension ending tomorrow
by Joel Falcou 22 Mar '11

22 Mar '11

Dear All, The fast track review of Frédéric Bron's extensions to the Type Traits Library is ending tomorrow. If you plan to submit a review, please do so as soon as possible. Thanks in advance to all participants of the review. =========== What is it? =========== This extension adds 37 new traits corresponding to the following 37 operators: - binary: ==, !=,<,<=,>,>=, , +, -, *, /, %, +=, -=, *=, /=, %=, , &&, ||, ,&, |, ^,<<,>>,&=, |=, ^=,<<=,>>= - prefix: ++, --, +, -, !, ~, * - postfix: ++, -- Each trait can detect if the operator can be used with particular types and if needed, if the return type is convertible to some type. =================== Getting the library =================== The latest version can be downloaded by different ways: - from the vault with unix line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… - from the vault with dos line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… - from the sandbox:http://svn.boost.org/svn/boost/sandbox/type_traits/ The entry point of the documentation is type_traits/libs/type_traits/doc/html/boost_typetraits/category/value_traits/operators.html The library has been tested with: - MSVC 8, 9, 10 on Windows, - g++ 4.4.5 on Linux, - intel 10.0 and 11.1 on Linux. To test the library, the simplest is to untar the headers in your boost include directory. For this, you can download the header part of the extension: - from the vault with unix line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… - from the vault with dos line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t…

16 38