Now that VS 2008 has been released via MSDN, I'm attempting to see if our app compiles and works using it. Following the instructions here ( http://thread.gmane.org/gmane.comp.lib.boost.user/27205/focus=27207 ) got boost compiled but the auto-link was still looking for vc80 in the library names. Adding the following to \boost\config\auto_link.hpp fixed the link issue #elif defined(BOOST_MSVC) && (BOOST_MSVC == 1400) // vc80: # define BOOST_LIB_TOOLSET "vc80" #elif defined(BOOST_MSVC) && (BOOST_MSVC >= 1500) // vc90: # define BOOST_LIB_TOOLSET "vc90" At this point everything appears to run. Is this the right way to start using boost in VS2008? At what point will boost 'properly' support VS2008? By properly I mean without me having to hack the boost src. Thanks- John
Can anybody tell me which one has better performance? thanks
Jin Sun wrote:
Can anybody tell me which one has better performance?
Well it depends what you mean :-) I'd be surprised if there was much difference between the core regex engines: maybe one would be slightly better at some things the other at different things. Where you gain with Boost.Regex is in the ability to write the surrounding code in a compiled language rather than have it interpreted. Whether you succeed in making your app faster as a result will mainly depend on how cunning you are at avoiding unnecessary copying/memory allocations in your code logic: to put it another way, badly written C++ can be the slowest thing around, while well written code can be as fast as any language out there. Oh, and not all regular expressions are created equal: if the problem is the speed of the regex matching, then it's likely a problem with the regex you're using. Just my - entirely biased - 2c, John Maddock.
Can anybody tell me which one has better performance?
Well it depends what you mean :-)
Just my - entirely biased - 2c, John Maddock.
I think the original poster would have gotten a more interesting response asking for a comparison of Boost and Greta :) I've used both but don't have much to say except that I've found that for certain regex subsets, and I'm sure this comes as no surprise, it is possible to get a big speed improvement by writing specialized code. Obviously, you don't need the regex code to find fixed, single, items and you can compile or index the expression or search string to great benefit in many cases- esp if you have thousands of queries against the same expression and can re-organize memory accesses to keep the cache more stable. Maybe the Greta or Boost people have particular references in this area they could share. I've written some code for ad hoc subsets and it makes a given application practical but there are probably more systematic approaches to the problem. I'm not sure if there is a regex evaluator that takes a vector of queries and expressions and optimizes the algorithm depending on operands.
From: john@johnmaddock.co.uk To: boost-users@lists.boost.org Date: Thu, 22 Nov 2007 09:46:53 +0000 Subject: Re: [Boost-users] boost.regex vs perl
Jin Sun wrote:
Can anybody tell me which one has better performance?
Well it depends what you mean :-)
I'd be surprised if there was much difference between the core regex engines: maybe one would be slightly better at some things the other at different things. Where you gain with Boost.Regex is in the ability to write the surrounding code in a compiled language rather than have it interpreted. Whether you succeed in making your app faster as a result will mainly depend on how cunning you are at avoiding unnecessary copying/memory allocations in your code logic: to put it another way, badly written C++ can be the slowest thing around, while well written code can be as fast as any language out there.
Oh, and not all regular expressions are created equal: if the problem is the speed of the regex matching, then it's likely a problem with the regex you're using.
Just my - entirely biased - 2c, John Maddock.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_________________________________________________________________ Put your friends on the big screen with Windows Vista® + Windows Live™. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_...
John Maddock wrote:
Jin Sun wrote:
Can anybody tell me which one has better performance?
Well it depends what you mean :-)
I'd be surprised if there was much difference between the core regex engines: maybe one would be slightly better at some things the other at different things. Where you gain with Boost.Regex is in the ability to write the surrounding code in a compiled language rather than have it interpreted. Whether you succeed in making your app faster as a result will mainly depend on how cunning you are at avoiding unnecessary copying/memory allocations in your code logic: to put it another way, badly written C++ can be the slowest thing around, while well written code can be as fast as any language out there.
Oh, and not all regular expressions are created equal: if the problem is the speed of the regex matching, then it's likely a problem with the regex you're using.
Just my - entirely biased - 2c, John Maddock.
Keeping in mind John's caveats, I find the language shootout website to be an interesting way to compare. Here's a c++ vs perl results: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gpp&lang2=... http://shootout.alioth.debian.org/gp4/benchmark.php?test=regexdna&lang=all The regex-dna test is written using boost-regex and tests out ~2.4 times slower and with a larger memory footprint than the perl version. Note that this is the *only* benchmark where perl outperforms c++. That said, it's one data point and what you're doing may have totally different results. That's not to mention the effect of the compiler -- gcc doesn't have a greatest reputation for optimization although it's been improving. And, you're also depending on other programmers to write good benchmarks. Jeff
Jeff Garland wrote:
Keeping in mind John's caveats, I find the language shootout website to be an interesting way to compare. Here's a c++ vs perl results:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gpp&lang2=...
http://shootout.alioth.debian.org/gp4/benchmark.php?test=regexdna&lang=all
The regex-dna test is written using boost-regex and tests out ~2.4 times slower and with a larger memory footprint than the perl version. Note that this is the *only* benchmark where perl outperforms c++.
:-(
That said, it's one data point and what you're doing may have totally different results. That's not to mention the effect of the compiler -- gcc doesn't have a greatest reputation for optimization although it's been improving. And, you're also depending on other programmers to write good benchmarks.
Yep, looking at the source code for the test, my first impression is that most of the time is likely to be taken up with the iostream code. I also notice that the C-language PCRE test takes almost exactly the same amount of time as the two C++ / Boost-Regex tests, in spite of avoiding high level constructs like std::string. Might be tempting to try and do better... Cheers, John.
John Maddock wrote:
Jeff Garland wrote:
That said, it's one data point and what you're doing may have totally different results. That's not to mention the effect of the compiler -- gcc doesn't have a greatest reputation for optimization although it's been improving. And, you're also depending on other programmers to write good benchmarks.
Yep, looking at the source code for the test, my first impression is that most of the time is likely to be taken up with the iostream code. I also
Interesting...
notice that the C-language PCRE test takes almost exactly the same amount of time as the two C++ / Boost-Regex tests, in spite of avoiding high level constructs like std::string.
Yeah, it makes me generally suspicious about the benchmark quality when a scripting language like perl outperforms C -- just because the internals of perl (and most everything else for that matter) are written in C. But in the case of regex I guess I can believe that the perl folks may have written a highly optimized regex implementation (in C of course) that makes things run fast.
Might be tempting to try and do better...
As I understand the shootout rules you're free to make it better :-) Jeff
the comparison is very impressive. i've been trying to find some proof to convince myself to use more boost.regex than perl. thanks Jeff Garland wrote:
John Maddock wrote:
Jeff Garland wrote:
That said, it's one data point and what you're doing may have totally different results. That's not to mention the effect of the compiler -- gcc doesn't have a greatest reputation for optimization although it's been improving. And, you're also depending on other programmers to write good benchmarks.
Yep, looking at the source code for the test, my first impression is that most of the time is likely to be taken up with the iostream code. I also
Interesting...
notice that the C-language PCRE test takes almost exactly the same amount of time as the two C++ / Boost-Regex tests, in spite of avoiding high level constructs like std::string.
Yeah, it makes me generally suspicious about the benchmark quality when a scripting language like perl outperforms C -- just because the internals of perl (and most everything else for that matter) are written in C. But in the case of regex I guess I can believe that the perl folks may have written a highly optimized regex implementation (in C of course) that makes things run fast.
Might be tempting to try and do better...
As I understand the shootout rules you're free to make it better :-)
Jeff _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Jin Sun MS-CS Michigan Technological University 1400 Townsend Dr. Houghton, MI-49931. Phone #: (906) 370 2261(H) (906) 487 4305(O) http://www.cs.mtu.edu/~jinsun
John Dunn wrote:
Now that VS 2008 has been released via MSDN, I'm attempting to see if our app compiles and works using it. Following the instructions here ( http://thread.gmane.org/gmane.comp.lib.boost.user/27205/focus=27207 ) got boost compiled but the auto-link was still looking for vc80 in the library names. Adding the following to \boost\config\auto_link.hpp fixed the link issue
#elif defined(BOOST_MSVC) && (BOOST_MSVC == 1400)
// vc80: # define BOOST_LIB_TOOLSET "vc80"
#elif defined(BOOST_MSVC) && (BOOST_MSVC >= 1500)
// vc90: # define BOOST_LIB_TOOLSET "vc90"
At this point everything appears to run. Is this the right way to start using boost in VS2008? At what point will boost 'properly' support VS2008? By properly I mean without me having to hack the boost src.
That fix is already in SVN Trunk, so I guess the answer to your question is "the next release". John.
participants (5)
-
Jeff Garland -
Jin Sun -
John Dunn -
John Maddock -
Mike Marchywka