- Boost - lists.boost.org

Re: [boost] [BGL] Interest in a random-path algorithm.
by Cromwell Enage 16 Feb '04

16 Feb '04

> On a second thought and after a bit of googling, > don't you think that > Propp-Wilson Cycle Popping Random Tree algorithm > would be more efficient ? Actually, I'm looking for more path randomness, but competitive performance/speed is definitely a minimum requirement. > The paper describing the article is at > http://dbwilson.com/ja/ > It is very well explained and > pseudo-code is clear enough to easily implement it > :) I'll read up on it when I get back from the dentist. > Cheers, > Jonathan You too. Cromwell __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

1 0

[BGL] Interest in a random-path algorithm.
by Cromwell Enage 16 Feb '04

16 Feb '04

Hi, everyone. For your informal reviewing pleasure, I've uploaded a random path algorithm with accompanying documentation at <http://groups.yahoo.com/group/boost/files/bgl_algo/make_random_paths.zip> I've stated in an earlier thread that I was working on a multi-state-mazes project. Obviously the ability to create random underlying paths could give the application high reusability value. It's my hope that other developers here will also find use for this algorithm in their own projects. Feedback appreciated! Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

2 2

Re: [boost] Re: 1.31.0 regressions
by Reece Dunn 16 Feb '04

16 Feb '04

Aleksey Gurtovoy wrote: >Beman Dawes writes: > > All of our formats are also painfully slow on less than broadband > > connections if you try to drill down to see a specific failure. > >They are slow even on broadband. That page definitely needs to be >split, somehow. Would it not be possible to employ a technique like that used by the DocBook "chunking" stylesheet. This would allow you to have a HTML page for the summary and one for each of the test sets. Regards, Reece _________________________________________________________________ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband

4 3

Odd TOC numbering in the BoostBook docs
by Reece Dunn 15 Feb '04

15 Feb '04

If you look at the table of contents for the boost libraries: http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/index.html there is: 8. The BoostBook Documentation Format Introduction ... I. Boost.Build v2 User Manual 9. How to use this document 10. Installation ... This seems to be a bug in the DocBook numbering system given the current chapter, section, etc layout for the Boost docs. Regards, Reece _________________________________________________________________ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess

2 1

[boostbook] xsltproc using the internet?
by Ronald Garcia 15 Feb '04

15 Feb '04

Howdy, I'm trying to build the boostbook docs. Having looked through the boostbook.jam file, seems like I should get a warning message if any DTDs are going to be fetched over the internet. I set the location of the DTD and XSL files in user-config.jam to values that I *think* are correct. In any case, It appears that the command "xsl-xsltproc" is still fetching some data remotely. A) Should I be receiving a warning about this, or am I misunderstanding the boostbook jamfile B) How exactly do I make it stop? I'm trying to use the docbook-dtd and docbook-xsl information installed on my machine using a package manager (fink). If I incorrectly specify these directories, should I expect an error that specifically points this out, or general "badness" instead? Thanks, ron

3 5

RE: [boost] Re: status of wchar_t support in filesystem::path?
by Hurd, Matthew 15 Feb '04

15 Feb '04

> On Behalf Of Edward Diener > Subject: [boost] Re: status of wchar_t support in filesystem::path? > > Paul Miller wrote: > > I just started using boost recently and it seems excellent so far. > > > > One of the first classes I started using is filesystem::path, with the > > intention to use it portably on Windows, OS X, and Linux. > > > > On Windows and OS X, you can work with paths in Unicode. Presumably > > Linux still works with multi-byte characters. > > > > Is there progres toward a wchar_t-aware path? > <snip> As a philosophy, I consider boost's filesystem to be attempting to offer a portable filesystem ability, rather than being a portable interface to a file system. As it currently stands, without unicode support, it is not much use if you want to be able to deal with arbitrary file and directory names on win32 which is not a handicap if this is not its intention. For example, I could not use it for an archiving program as I must deal with the potential for unicode names and internal stream in files. It does an admirable job of dealing with your own files where you can control the naming. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

Re: [function] timing trivia
by matt＠finray.com 15 Feb '04

15 Feb '04

"Pavel Vozenilek" wrote in message news:c0nfp0$pp5$1@sea.gmane.org... > > "Hurd, Matthew" <hurdm(a)sig.com> wrote > > > This is an Intel P43.2 I'm running on now and I'm getting output like: > > > > boost function measurements: median time = 250.698 microseconds > > direct in-line: median time = 250.691 microseconds > > > > You see here I look at the median time for boost function and > > direct-inline and see only a 7 ns difference which is probably smaller > > than I can truly measure I suspect... > > > I wrote my own test (the most simple one, call function/boost::fn > in loop and measuring total time). > > The numbers I got give me ~18 microseconds overhead per single > boost::function call (raw call takes ~404 microseconds). > > I use Intel C++ 8.0 plugged in VC6 IDE,, release mode, > Athlon XP 2200+, W2K. > > /Pavel > <snipped code> > ---------------------------------- > > test1() and test2() took each 30-40 seconds. > GetTickCount() resolution is at least 10 milliseconds. Thanks Pavel. I ran your test with vc7.1 in an optimised form as is with the only change being test1 and test1 returning tick2-tick1 as a long. Similar ball park figures for overall run time as you. test1 = 33312 ms test2 = 30625 ms Yep, boost function call based loop is faster. vc7.1, athlon 2800+, xp1a Also the 18 microseconds cost you measured, or roughly 30 microseconds benefit measured with my optimisation settings, can't just be put down to the boost::function difference I think as 18 microseconds is 36,000 cycles at 2 GHz and I don't think boost function could possibly cost that. If I crank the loop down to #define MAX_FN_LOOP 1e2 with 10,000,000 iterations in the test fn's I get test1 = 3578 ms test2 = 3219 ms Still curiously faster. Though the overhead indicated is 3.6 nanoseconds... If I turn my optimisations off for the last case, but still run in release mode I get: test1 = 8594 ms test2 = 8797 ms Which is the way around you'd expect it to be with boost::function being slower given some kind of abstraction penalty. So, I guess the insight is, your mileage may vary, optimisers are strange beasts, benchmarks are often misleading and weird... cliches are cliches. By the way, I have a slightly improved little bench harness that correctly measures emptiness at zero nanoseconds for an instrusive style of benchmark now if you or any one is interested I can email it to you. That is it correctly measures: inline double blank( matt::timer& t ) { double now; t.restart(); now = t.elapsed(); return now; } to be zero ns consistently for me. Thanks again for your numbers Pavel. Regards, Matt Hurd.

2 1

Re: [boost] Re: A VC6 bug in const_reverse_iterator implementation?
by RGProlog＠aol.com 15 Feb '04

15 Feb '04

I am talking about 1.30.2 version of Boost Libraries. I tried the following in the VC6 enviroment: array<int, 3> arr = {{1, 2, 3}}; array<int, 3>::const_iterator ci = arr.begin(); // works fine array<int, 3>::const_reverse_iterator cri = arr.rbegin(); // fails to ompile

1 0

RE: [boost] Re: [function] timing trivia
by Hurd, Matthew 15 Feb '04

15 Feb '04

> On Behalf Of Pavel Vozenilek > Subject: [boost] Re: [function] timing trivia > > > "Matthew Hurd" <matt(a)finray.net> wrote > > [snip boost::function benchmark info] > > > Can't explain it. Boost function can't be faster for the 10 million > loop > by > > more than a millisecond. I see none of this whacky behaviour with > release > > optimized code. > > > Can you post complete test code somewhere? > > /Pavel Probably small enough to post here... (12KB) Open the .sln, compile and run the "test" project and you should see something similar to: This is an Intel P43.2 I'm running on now and I'm getting output like: --------------------------------------------------------------------- quick time before overhead estimate= 393.5650855126686 nanoseconds time including previous console output = 1.157412246893155 milliseconds overhead estimate = 127.8459831920134 nanoseconds quick time after overhead estimation = 95.25779139797076 nanoseconds time including previous console output = 1.160907957159062 milliseconds --------------------------------------------------------------------- new timer for checking static carry --------------------------------------------------------------------- quick time -1.253391992078558 nanoseconds quick time -5.013567968314233 nanoseconds overhead estimate = 127.8459831920134 nanoseconds quick time 2.506783984157143 nanoseconds quick time -5.013567968314233 nanoseconds --------------------------------------------------------------------- check timing jitter on a simple loop --------------------------------------------------------------------- --------------------------------------------------------------------- estimating indirect function call overhead --------------------------------------------------------------------- --------------------------------------------------------------------- boost function measurements --------------------------------------------------------------------- median time = 250.698 microseconds 90% range size = 6.26696 nanoseconds widest range size (max - min) = 149443 nanoseconds minimum time = 250.695 microseconds maximum time = 400.138 microseconds 50% range = (250.695, 250.701) microseconds 50% range size = 6.26696 nanoseconds stop the optimiser eliding garbage = 3.33328e+017 stop the optimiser eliding garbage = 3.33328e+017 --------------------------------------------------------------------- direct in-line --------------------------------------------------------------------- median time = 250.691 microseconds 90% range size = 6.26696 nanoseconds widest range size (max - min) = 29324.4 nanoseconds minimum time = 250.688 microseconds maximum time = 280.013 microseconds 50% range = (250.688, 250.692) microseconds 50% range size = 3.76018 nanoseconds stop the optimiser eliding garbage = 3.33328e+017 stop the optimiser eliding garbage = 3.33328e+017 Press any key to continue . . . You see here I look at the median time for boost function and direct-inline and see only a 7 ns difference which is probably smaller than I can truly measure I suspect... At the top of looper.hpp there is #define MAX_FN_LOOP 1e5 which controls the iterations in the timing loop. If my hacked up untidy code is buggy or if you have some insight I would love to hear about it. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

Boost Filesystem Build On GCC
by Stephan T. Lavavej 15 Feb '04

15 Feb '04

When Boost Filesystem is built with bjam "-sTOOLS=gcc" or bjam "-sTOOLS=mingw" on MinGW, the resulting static library is a .lib consisting of .obj files. However, it is traditional for gcc to use .a files which consist of .o files. I fix this by hand by renaming the .obj files to .o and then executing ar rvs libboost_filesystem.a *.o , but it would be nice if bjam would get it correctly by itself. Stephan T. Lavavej http://nuwen.net

4 3