At 12:37 PM 6/10/2003, Jon Stewart wrote:

...

I am not that big expert in CppUnit. If you could provide a feature list for CppTest I may do feature by feature comparison. But from what I view after perfunctory look on docs the feature lists seems incomparable. Though again I may be wrong.

Hi Gennadiy,

I'd be happy to provide you with a feature list. It may take a day or two.

Boost typically provides libraries that beat the pants off anything else out there, and I'm sure that you're working to make Boost::Test the best unit testing framework available for C++. However, unlike many of the other libraries that Boost provides, a reasonably functional and popular substitute (CppUnit) existed. I'm curious as to what led you to write your own rather than contribute to CppUnit and try to get it incorporated into

Boost (similar to how Spirit was incorporated)? Do you have different design goals for Boost::Test?

Gennadiy took over an existing library, and then contributed a seriously major upgrade supporting full unit testing (while still preserving simpler forms of testing when appropriate). And that is one of the major advantages of Boost.Test compared to packages that were available at the time we started the initial design. The three levels of use that Boost.Test supports are: -- Execution monitoring - this isn't really "testing" functionality, but rather is a tremendous help for production programs. It it unifies several disparate error reporting mechanisms, and permits unattended operation. I can't imagine putting a job into overnight production use without Boost.Test execution monitoring. -- Simple test scenarios. Not all testing needs a full unit-test suite. Boost.Tests' test tools do a really nice job for light or medium duty testing. Minimal learning curve. -- Full unit-test. Heavier-duty testing to meet heavier-duty needs. Lot's of test packages attack this level, but leave you hanging for the lower levels. In a way, the whole of Boost.Build and the Boost regression testing system are yet another layer which fits nicely on top of the Boost.Test layers. So that's a bit of background. In a nutshell, Boost.Test servers a whole hierarchy of needs. --Beman

Hi Alexis, you wrote:

I am trying to use the boost::ublas library in my code to speed up things, but I was a bit suspicious about the results.

You've read the documentation's remarks about abstraction penalty, haven't you?

So I ran my own tests, and I found that ublas is not as fast as the C implementation, but is actually about twice slower (for my test, which are very limited). Please find the source file below. I am not very familiar with expression template. Am I doing something wrong?

No (as far as I see).

Are the results specific to this test?

In a certain sense. [snip parts of code]

typedef int value_type;

Interesting data type ;-)

#define N 14 #define K 100000000

[snip other parts of code] I've been playing with these parameters and two compilers. For GCC 3.2.1 (compiler options -NDEBUG -O3) I see the following results on my box: n = 14, k = 100000000 c t=4.5 assign prod t=6.58 n = 14*14, k = 10000000 c t=5.59 assign prod t=7.76 n = 14*14*14, k = 1000000 c t=8.89 assign prod t=12.59 n = 14*14*14*14, k = 100000 c t=70.88 assign prod t=70.11 For ICC 7.1 (again compiler options -NDEBUG -O3): n = 14, k = 100000000 c t=3.16 assign prod t=6.22 n = 14*14, k = 10000000 c t=4.49 assign prod t=6.05 n = 14*14*14, k = 1000000 c t=6.91 assign prod t=10.19 n = 14*14*14*14, k = 100000 c t=70.37 assign prod t=70.78 It looks like the inner loops of the 'C' and C++ code are identical. I'm unsure if the abstraction penalty for small sizes can be eliminated by the compiler writers or if it justifies a 'tiny vector/matrix' abstraction a la Blitz++ (resulting in a corresponding compile time abstraction penalty ;-) Best, Joerg