Hi, good to see that boost.log is being formally reviewed! From what I read in the documentation so far, I am really looking forward to seeing the library included in boost. I sure want to do some tests, hoping to replace our current logging system, soon, but today I can only answer the following review item: - Did you try to use the library? With what compiler? Did you have any problems? Yes, I tried and failed to compile it. Details are below. Platform: Ubuntu 8.04, 64bit, g++ 4.2.4 Intel QuadCore 2.5GHz, 8GB Ram Compilation: ============ Sounds embarassing, but I failed to compile the library. I copied the folders boost, lib and doc from boost-log-RC4 to boost_1_42_0, called ./bootstrap.sh ./bjam -d+2 --build-dir=build --with-log --prefix=/my/install/path link=shared runtime-link=shared install All looked well until this point: gcc.compile.c++ build/boost/bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/filter_parser.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -fno-strict-aliasing -DBOOST_ALL_NO_LIB=1 -DBOOST_DATE_TIME_DYN_LINK=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LOG_DLL -DBOOST_LOG_SETUP_BUILDING_THE_LIB=1 -DBOOST_LOG_SETUP_DLL -DBOOST_LOG_USE_NATIVE_SYSLOG=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DDATE_TIME_INLINE -DNDEBUG -I"." -c -o "build/boost/bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/filter_parser.o" "libs/log/src/filter_parser.cpp" The process cc1plus was running about 20 minutes (100%CPU, moderate RAM usage) before anything else happened. Then, after lots and lots of very long error messages, it continues like this: ...skipped <pbuild/boost/bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi>libboost_log.so.1.42.0 for lack of <pbuild/boost/bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi>attribute_set.o... Hmm. Not sure how to proceed. Should I send the whole bunch of error messages to the list as an attachment? Regards, Roland
Roland Bock wrote:
Hi,
good to see that boost.log is being formally reviewed! From what I read in the documentation so far, I am really looking forward to seeing the library included in boost.
I sure want to do some tests, hoping to replace our current logging system, soon, but today I can only answer the following review item:
- Did you try to use the library? With what compiler? Did you have any problems?
Yes, I tried and failed to compile it. Details are below.
Platform: Ubuntu 8.04, 64bit, g++ 4.2.4 Intel QuadCore 2.5GHz, 8GB Ram
Compilation: ============ Sounds embarassing, but I failed to compile the library. I copied the folders boost, lib and doc from boost-log-RC4 to boost_1_42_0, called ./bootstrap.sh ./bjam -d+2 --build-dir=build --with-log --prefix=/my/install/path link=shared runtime-link=shared install
All looked well until this point:
gcc.compile.c++ build/boost/bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/filter_parser.o
"g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -fno-strict-aliasing -DBOOST_ALL_NO_LIB=1 -DBOOST_DATE_TIME_DYN_LINK=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LOG_DLL -DBOOST_LOG_SETUP_BUILDING_THE_LIB=1 -DBOOST_LOG_SETUP_DLL -DBOOST_LOG_USE_NATIVE_SYSLOG=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DDATE_TIME_INLINE -DNDEBUG -I"." -c -o "build/boost/bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi/filter_parser.o"
"libs/log/src/filter_parser.cpp"
The process cc1plus was running about 20 minutes (100%CPU, moderate RAM usage) before anything else happened.
It looks like 4.2 is somehow unhappy with the code. Then, after lots and lots of very
long error messages, it continues like this:
...skipped <pbuild/boost/bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi>libboost_log.so.1.42.0
for lack of <pbuild/boost/bin.v2/libs/log/build/gcc-4.2.4/release/threading-multi>attribute_set.o...
Hmm. Not sure how to proceed. Should I send the whole bunch of error messages to the list as an attachment?
I think you better locate the first error message from the compiler and post that. Further errors are likely induced. I wonder if the first error message is "ran out of memory", though. - Volodya
Vladimir Prus wrote: [snip]
The process cc1plus was running about 20 minutes (100%CPU, moderate RAM usage) before anything else happened.
It looks like 4.2 is somehow unhappy with the code.
Following a hint from Sean Chittenden, I downloaded the current code from the boost.log svn. Compilation still seems to take forever (20 minutes), but it now compiles. Here is the 20min gap: -rw-r--r-- 1 rbock rbock 5690672 2010-03-09 18:19 filter_parser.o -rw-r--r-- 1 rbock rbock 4972776 2010-03-09 18:39 formatter_parser.o I wonder if it is possible to speed it up (or to break it up into smaller packages). I almost killed the process after 15 minutes... Anyway, I am going to start experimenting tomorrow...
I think you better locate the first error message from the compiler and post that. Further errors are likely induced. I wonder if the first error message is "ran out of memory", though.
No, it was some template error starting with ./boost/intrusive/detail/is_stateful_value_traits.hpp: In instantiation [snip] With the source from the SVN, these messages are gone :-) Regards, Roland
On 03/09/2010 08:53 PM, Roland Bock wrote:
Vladimir Prus wrote: [snip]
The process cc1plus was running about 20 minutes (100%CPU, moderate RAM usage) before anything else happened.
It looks like 4.2 is somehow unhappy with the code.
Following a hint from Sean Chittenden, I downloaded the current code from the boost.log svn. Compilation still seems to take forever (20 minutes), but it now compiles. Here is the 20min gap:
-rw-r--r-- 1 rbock rbock 5690672 2010-03-09 18:19 filter_parser.o -rw-r--r-- 1 rbock rbock 4972776 2010-03-09 18:39 formatter_parser.o
I wonder if it is possible to speed it up (or to break it up into smaller packages). I almost killed the process after 15 minutes...
Anyway, I am going to start experimenting tomorrow...
These parsers do, indeed, give a hard time to compilers. I tried to reduce the footprint but apparently some compilers still barely cope with them. Not sure what can be done, but I'll try to experiment some more. Suggestions from Boost.Spirit gurus are welcome. :)
I think you better locate the first error message from the compiler and post that. Further errors are likely induced. I wonder if the first error message is "ran out of memory", though.
No, it was some template error starting with
./boost/intrusive/detail/is_stateful_value_traits.hpp: In instantiation [snip]
With the source from the SVN, these messages are gone :-)
I assume it was the anonymous namespaces bug in GCC that was worked around in trunk.
Andrey Semashev wrote:
On 03/09/2010 08:53 PM, Roland Bock wrote:
Vladimir Prus wrote: [snip]
The process cc1plus was running about 20 minutes (100%CPU, moderate RAM usage) before anything else happened.
It looks like 4.2 is somehow unhappy with the code.
Following a hint from Sean Chittenden, I downloaded the current code from the boost.log svn. Compilation still seems to take forever (20 minutes), but it now compiles. Here is the 20min gap:
-rw-r--r-- 1 rbock rbock 5690672 2010-03-09 18:19 filter_parser.o -rw-r--r-- 1 rbock rbock 4972776 2010-03-09 18:39 formatter_parser.o
I wonder if it is possible to speed it up (or to break it up into smaller packages). I almost killed the process after 15 minutes...
Anyway, I am going to start experimenting tomorrow...
These parsers do, indeed, give a hard time to compilers. I tried to reduce the footprint but apparently some compilers still barely cope with them. Not sure what can be done, but I'll try to experiment some more. Suggestions from Boost.Spirit gurus are welcome. :)
What are the parsers? If they are for things like "[%TimeStamp%]: %_%" then do you actually need Boost.Spirit? - Volodya
On 03/09/2010 10:36 PM, Vladimir Prus wrote:
What are the parsers? If they are for things like
"[%TimeStamp%]: %_%"
then do you actually need Boost.Spirit?
That's the simplest case. Named parameters and escape characters are also allowed, like that: [%TimeStamp(format="%Y-%M-%D %H:%M:%S", blah=10)%]:\t%_% But the syntax of formatters is much simpler than the one of filters, which support boolean expressions, including parenthesis and user-defined predicates.
Andrey Semashev wrote:
These parsers do, indeed, give a hard time to compilers. I tried to reduce the footprint but apparently some compilers still barely cope with them. Not sure what can be done, but I'll try to experiment some more. Suggestions from Boost.Spirit gurus are welcome. :)
Would you be willing to move to Spirit 2.1 and away from classic? I could offer a patch once my work load frees up some. michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On 03/09/2010 10:48 PM, Michael Caisse wrote:
Andrey Semashev wrote:
These parsers do, indeed, give a hard time to compilers. I tried to reduce the footprint but apparently some compilers still barely cope with them. Not sure what can be done, but I'll try to experiment some more. Suggestions from Boost.Spirit gurus are welcome. :)
Would you be willing to move to Spirit 2.1 and away from classic? I could offer a patch once my work load frees up some.
If it does offer better compile times, I'm willing to try. I just haven't had any real experience with Spirit 2.x before. The patch would be much appreciated. :)
Andrey Semashev wrote:
On 03/09/2010 10:48 PM, Michael Caisse wrote:
Andrey Semashev wrote:
These parsers do, indeed, give a hard time to compilers. I tried to reduce the footprint but apparently some compilers still barely cope with them. Not sure what can be done, but I'll try to experiment some more. Suggestions from Boost.Spirit gurus are welcome. :)
Would you be willing to move to Spirit 2.1 and away from classic? I could offer a patch once my work load frees up some.
If it does offer better compile times, I'm willing to try. I just haven't had any real experience with Spirit 2.x before. The patch would be much appreciated. :)
There's a page with migration hints: http://www.boost.org/doc/libs/1_41_0/libs/spirit/doc/html/spirit/notes/porti... I assume that the Spirit experts will be able to re-write that code with ease.
On Tue, Mar 9, 2010 at 2:40 PM, Roland Bock <rbock@eudoxos.de> wrote:
Andrey Semashev wrote:
On 03/09/2010 10:48 PM, Michael Caisse wrote:
Andrey Semashev wrote:
These parsers do, indeed, give a hard time to compilers. I tried to reduce the footprint but apparently some compilers still barely cope with them. Not sure what can be done, but I'll try to experiment some more. Suggestions from Boost.Spirit gurus are welcome. :)
Would you be willing to move to Spirit 2.1 and away from classic? I could offer a patch once my work load frees up some.
If it does offer better compile times, I'm willing to try. I just haven't had any real experience with Spirit 2.x before. The patch would be much appreciated. :)
There's a page with migration hints:
http://www.boost.org/doc/libs/1_41_0/libs/spirit/doc/html/spirit/notes/porti...
I assume that the Spirit experts will be able to re-write that code with ease.
Why yes, yes we can. :) I did not know you were using a rather ancient version, I would have rewritten that already if I knew you were using Spirit at all. I have not been paying too much attention to all this review process, so if you can give me the SVN link to the latest version, I can rewrite the Spirit code to use the *much* faster Spirit2.1, it will both compile and execute faster, and I can submit a patch. I am craving doing some programming. Been *so* busy with stuff recently that I have not been able to do much, other then moving in to my new place I actually have some free time again so I can do this.
On 03/11/2010 05:16 AM, OvermindDL1 wrote:
On Tue, Mar 9, 2010 at 2:40 PM, Roland Bock<rbock@eudoxos.de> wrote:
I assume that the Spirit experts will be able to re-write that code with ease.
Why yes, yes we can. :) I did not know you were using a rather ancient version, I would have rewritten that already if I knew you were using Spirit at all. I have not been paying too much attention to all this review process, so if you can give me the SVN link to the latest version, I can rewrite the Spirit code to use the *much* faster Spirit2.1, it will both compile and execute faster, and I can submit a patch. I am craving doing some programming.
There you go. :) The link to SVN trunk is: https://boost-log.svn.sourceforge.net/svnroot/boost-log/trunk/boost-log There are three major parsers that use Spirit: libs/log/src/filter_parser.cpp libs/log/src/formatter_parser.cpp libs/log/src/init_from_stream.cpp The former two give the most significant impact to compile times. Also, there are smaller parsers in other places, but I can take care of them eventually. You can search for "spirit" in src to find them, if you're interested. Thank you for the help. And happy house-warming. :)
OvermindDL1 wrote:
On Tue, Mar 9, 2010 at 2:40 PM, Roland Bock <rbock@eudoxos.de> wrote:
Andrey Semashev wrote:
On 03/09/2010 10:48 PM, Michael Caisse wrote:
Andrey Semashev wrote:
These parsers do, indeed, give a hard time to compilers. I tried to reduce the footprint but apparently some compilers still barely cope with them. Not sure what can be done, but I'll try to experiment some more. Suggestions from Boost.Spirit gurus are welcome. :)
Would you be willing to move to Spirit 2.1 and away from classic? I could offer a patch once my work load frees up some. If it does offer better compile times, I'm willing to try. I just haven't had any real experience with Spirit 2.x before. The patch would be much appreciated. :) There's a page with migration hints:
http://www.boost.org/doc/libs/1_41_0/libs/spirit/doc/html/spirit/notes/porti...
I assume that the Spirit experts will be able to re-write that code with ease.
Why yes, yes we can. :) I did not know you were using a rather ancient version, I would have rewritten that already if I knew you were using Spirit at all. I have not been paying too much attention to all this review process, so if you can give me the SVN link to the latest version, I can rewrite the Spirit code to use the *much* faster Spirit2.1, it will both compile and execute faster, and I can submit a patch. I am craving doing some programming. Been *so* busy with stuff recently that I have not been able to do much, other then moving in to my new place I actually have some free time again so I can do this.
Regarding the use of Spirit within Boost.Log: If I get it right, spirit::karma supposed to be extremely fast in serializing. In another thread I read that one of the performance issues is the serialization of DateTime (http://lists.boost.org/Archives/boost/2010/03/162905.php). Would it make sense to use karma here to speed things up? Regards, Roland
On 03/11/2010 11:28 AM, Roland Bock wrote:
Regarding the use of Spirit within Boost.Log: If I get it right, spirit::karma supposed to be extremely fast in serializing. In another thread I read that one of the performance issues is the serialization of DateTime (http://lists.boost.org/Archives/boost/2010/03/162905.php).
Would it make sense to use karma here to speed things up?
Yes, one of my thoughts was to rework Boost.DateTime IO to employ Boost.Spirit. Another thing that ought to be done is to parse format strings only once, during the facet initialization. And the third thing is to move all that code into the compiled binary of Boost.DateTime. It really adds quite a bit to users' binary size now.
Andrey Semashev wrote:
On 03/11/2010 11:28 AM, Roland Bock wrote:
Regarding the use of Spirit within Boost.Log: If I get it right, spirit::karma supposed to be extremely fast in serializing. In another thread I read that one of the performance issues is the serialization of DateTime (http://lists.boost.org/Archives/boost/2010/03/162905.php).
Would it make sense to use karma here to speed things up?
Yes, one of my thoughts was to rework Boost.DateTime IO to employ Boost.Spirit. Another thing that ought to be done is to parse format strings only once, during the facet initialization. And the third thing is to move all that code into the compiled binary of Boost.DateTime. It really adds quite a bit to users' binary size now.
OK, sounds very nice. I noticed earlier that Boost.DateTime's parsing is pretty slow in comparison to Boost.Spirit. So all of this make very much sense to me.
participants (5)
-
Andrey Semashev -
Michael Caisse -
OvermindDL1 -
Roland Bock -
Vladimir Prus