Linux gcc vs Windows Studo Net 2005

[Tamas Sashalmi]

Hello All,

I've compiled Quantlib and run some test on Windows (64-bit, but compiled  
as 32 all tests are OK) and Linux (64bit).
Can some body tell me why the windows test are so slow (more than 1h)  
while on linux 5 m 11 s?
Also, some test are failed on linux 64bit (CVS; 230 tests) (32bit version  
is OK). Seems to me some precision problem  32bit vs 64bit.


Actually I prefer Linux, so no problem for me, but I'm wondering why w32  
is slower. On windows I've used Studio Net 2005 Express...

Thanks,

Tamas
-------------------------------------------------
The error messages:

lowdiscrepancysequences.cpp(296): error in  
"LowDiscrepancyTest::testFaure": 3rd draw, dimension 2 (0.111111) in 3-D  
Faure sequence should have been 0.111111
lowdiscrepancysequences.cpp(301): error in  
"LowDiscrepancyTest::testFaure": 3rd draw, dimension 3 (0.444444) in 3-D  
Faure sequence should have been 0.444444
lowdiscrepancysequences.cpp(291): error in  
"LowDiscrepancyTest::testFaure": 4th draw, dimension 1 (0.111111) in 3-D  
Faure sequence should have been 0.111111
lowdiscrepancysequences.cpp(296): error in  
"LowDiscrepancyTest::testFaure": 4th draw, dimension 2 (0.444444) in 3-D  
Faure sequence should have been 0.444444
lowdiscrepancysequences.cpp(291): error in  
"LowDiscrepancyTest::testFaure": 5th draw, dimension 1 (0.444444) in 3-D  
Faure sequence should have been 0.444444
lowdiscrepancysequences.cpp(301): error in  
"LowDiscrepancyTest::testFaure": 5th draw, dimension 3 (0.111111) in 3-D  
Faure sequence should have been 0.111111
lowdiscrepancysequences.cpp(296): error in  
"LowDiscrepancyTest::testFaure": 6th draw, dimension 2 (0.222222) in 3-D  
Faure sequence should have been 0.222222
lowdiscrepancysequences.cpp(301): error in  
"LowDiscrepancyTest::testFaure": 6th draw, dimension 3 (0.888889) in 3-D  
Faure sequence should have been 0.888889
lowdiscrepancysequences.cpp(291): error in  
"LowDiscrepancyTest::testFaure": 7th draw, dimension 1 (0.888889) in 3-D  
Faure sequence should have been 0.888889
lowdiscrepancysequences.cpp(301): error in  
"LowDiscrepancyTest::testFaure": 7th draw, dimension 3 (0.222222) in 3-D  
Faure sequence should have been 0.222222
lowdiscrepancysequences.cpp(291): error in  
"LowDiscrepancyTest::testFaure": 8th draw, dimension 1 (0.222222) in 3-D  
Faure sequence should have been 0.222222
lowdiscrepancysequences.cpp(296): error in  
"LowDiscrepancyTest::testFaure": 8th draw, dimension 2 (0.888889) in 3-D  
Faure sequence should have been 0.888889
sampledcurve.cpp(75): error in "SampledCurveTest::testConstruction":  
sample curve regriding failed2 0.2 2.6633e-16 0.04
sampledcurve.cpp(75): error in "SampledCurveTest::testConstruction":  
sample curve regriding failed3 0.3 0.0490192 0.09

[Luigi Ballabio]

On Jan 22, 2006, at 4:48 AM, Tamas R Sashalmi wrote:
> I've compiled Quantlib and run some test on Windows (64-bit, but
> compiled as 32 all tests are OK) and Linux (64bit).
> Can some body tell me why the windows test are so slow (more than 1h)
> while on linux 5 m 11 s?

Are you sure you didn't compile the debug version on Windows? That
would slow down the tests mightily. Check that you're compiling in
Release configuration.

> Also, some test are failed on linux 64bit (CVS; 230 tests) (32bit
> version is OK). Seems to me some precision problem  32bit vs 64bit.

Probably. We might have set a too low tolerance. If you have some time
(unfortunately, I don't have a 64-bit machine myself) could you check
what tolerance would be required for the tests to pass?

Thanks,
        Luigi

[Tamas Sashalmi]

Hello Luigi,

Yes, you're right. I've compiled with debug mode on windows..

On the 64bit problem: in the first part the error is in
lowdiscrepancysequences.cpp .
In this file there is no tolerance setting, after creating one as:
line begin at 287 in lowdiscrepancysequences.cpp:
----------------------------------------------------------------
+ Real tolerance = 1.0e-7;

    for (i=0; i<points; i++) {
        point = rsg.nextSequence().value;
-      if (point[0]!=FaureDimensionOneOfThree[i]) {
+        if (std::fabs(point[0]-FaureDimensionOneOfThree[i])/point[0]
> tolerance) {

            BOOST_ERROR(io::ordinal(i+1) << " draw, dimension 1 (" << point[0]
                        << ") in 3-D Faure sequence should have been "
                        << FaureDimensionOneOfThree[i]);
        }
-   if (point[1]!=FaureDimensionTwoOfThree[i]) {
+        if (std::fabs(point[1]-FaureDimensionTwoOfThree[i])/point[1]
> tolerance) {
            BOOST_ERROR(io::ordinal(i+1) << " draw, dimension 2 (" << point[1]
                        << ") in 3-D Faure sequence should have been "
                        << FaureDimensionTwoOfThree[i]);
        }
-   if (point[2]!=FaureDimensionThreeOfThree[i]) {
+        if (std::fabs(point[2]-FaureDimensionThreeOfThree[i])/point[2]
> tolerance) {
            BOOST_ERROR(io::ordinal(i+1) << " draw, dimension 3 (" << point[2]
                        << ") in 3-D Faure sequence should have been "
                        << FaureDimensionThreeOfThree[i]);

        }
-------------------------------------------------------------------
will solve this problem.
/////////////////////////////////////////////////////////
//please update cvs if you agree with the changes, maybe the all
//if (something != expected)
//statements should be change to
//if (abs(something - expected)/something > tolerance)..
//like in the rest of the test code.
////////////////////////////////////////////////////////////

However the second part of the error is apear at sampledcurve.cpp(75)
need a little more investigation, since the expected value is 0.04
(calculetd 2.6633e-16) and 0.09
(calculeted 0.0490192). I will try to solve it later.

Thanks,

Tamas


2006/1/22, Luigi Ballabio <[hidden email]>:

>
> On Jan 22, 2006, at 4:48 AM, Tamas R Sashalmi wrote:
> > I've compiled Quantlib and run some test on Windows (64-bit, but
> > compiled as 32 all tests are OK) and Linux (64bit).
> > Can some body tell me why the windows test are so slow (more than 1h)
> > while on linux 5 m 11 s?
>
> Are you sure you didn't compile the debug version on Windows? That
> would slow down the tests mightily. Check that you're compiling in
> Release configuration.
>
> > Also, some test are failed on linux 64bit (CVS; 230 tests) (32bit
> > version is OK). Seems to me some precision problem  32bit vs 64bit.
>
> Probably. We might have set a too low tolerance. If you have some time
> (unfortunately, I don't have a 64-bit machine myself) could you check
> what tolerance would be required for the tests to pass?
>
> Thanks,
>         Luigi
>
>

[Tamas Sashalmi]

Hello Luigi,

Yes, you're right. I've compiled with debug mode on windows..

On the 64bit problem: in the first part the error is in  
lowdiscrepancysequences.cpp .
In this file there is no tolerance setting, after creating one as:
line begin at 287 in lowdiscrepancysequences.cpp:
----------------------------------------------------------------
+ Real tolerance = 1.0e-7;

     for (i=0; i<points; i++) {
         point = rsg.nextSequence().value;
-     if (point[0]!=FaureDimensionOneOfThree[i]) {
+        if (std::fabs(point[0]-FaureDimensionOneOfThree[i])/point[0] >  
tolerance) {

             BOOST_ERROR(io::ordinal(i+1) << " draw, dimension 1 (" <<  
point[0]
                         << ") in 3-D Faure sequence should have been "
                         << FaureDimensionOneOfThree[i]);
         }
-   if (point[1]!=FaureDimensionTwoOfThree[i]) {
+        if (std::fabs(point[1]-FaureDimensionTwoOfThree[i])/point[1] >  
tolerance) {
             BOOST_ERROR(io::ordinal(i+1) << " draw, dimension 2 (" <<  
point[1]
                         << ") in 3-D Faure sequence should have been "
                         << FaureDimensionTwoOfThree[i]);
         }
-   if (point[2]!=FaureDimensionThreeOfThree[i]) {
+        if (std::fabs(point[2]-FaureDimensionThreeOfThree[i])/point[2] >  
tolerance) {
             BOOST_ERROR(io::ordinal(i+1) << " draw, dimension 3 (" <<  
point[2]
                         << ") in 3-D Faure sequence should have been "
                         << FaureDimensionThreeOfThree[i]);

         }
-------------------------------------------------------------------
will solve this problem.
/////////////////////////////////////////////////////////
//please update cvs if you agree with the changes, maybe the all
//if (something != expected)
//statements should be change to
//if (abs(something - expected)/something > tolerance)..
//like in the rest of the test code.
////////////////////////////////////////////////////////////

However the second part of the error is apear at sampledcurve.cpp(75)
need a little more investigation, since the expected value is 0.04  
(calculetd 2.6633e-16) and 0.09 (calculeted 0.0490192). I will try to  
solve it later.

Thanks,

Tamas

------
error
sampledcurve.cpp(75): error in "SampledCurveTest::testConstruction":  
sample curve regriding failed2 0.2 2.6633e-16 0.04
sampledcurve.cpp(75): error in "SampledCurveTest::testConstruction":  
sample curve regriding failed3 0.3 0.0490192 0.09

On Sun, 22 Jan 2006 06:39:01 -0600, Luigi Ballabio  
<[hidden email]> wrote:

>
> On Jan 22, 2006, at 4:48 AM, Tamas R Sashalmi wrote:
>> I've compiled Quantlib and run some test on Windows (64-bit, but  
>> compiled as 32 all tests are OK) and Linux (64bit).
>> Can some body tell me why the windows test are so slow (more than 1h)  
>> while on linux 5 m 11 s?
>
> Are you sure you didn't compile the debug version on Windows? That would  
> slow down the tests mightily. Check that you're compiling in Release  
> configuration.
>
>> Also, some test are failed on linux 64bit (CVS; 230 tests) (32bit  
>> version is OK). Seems to me some precision problem  32bit vs 64bit.
>
> Probably. We might have set a too low tolerance. If you have some time  
> (unfortunately, I don't have a 64-bit machine myself) could you check  
> what tolerance would be required for the tests to pass?
>
> Thanks,
> Luigi
>

[Tamas Sashalmi]

I've compiled the QuantLib with the Release config and the Tests completed in 8 m 57 s.
Still slower than Linux ( 5 m 11 s)...but mach faster then in Debug mode.

Tamas

[Luigi Ballabio]

On 1/22/06, Tamas Sashalmi <[hidden email]> wrote:
> On the 64bit problem: in the first part the error is in
> lowdiscrepancysequences.cpp .
> In this file there is no tolerance setting, creating one [...] will solve this problem.

Tamas,
    thanks. Was 1e-7 the smallest tolerance that let the tests pass?

Luigi

[Tamas Sashalmi]

Hello Luigi,

so I've checked again. The differnces are around:
  1.11022e-16
so very small.

Also there is a second solution for this (if you don't like the tolerance,  
but maybe gives more problems later) if I cast the Real type to (float)
example line 295:

  if ((float) point[1]!=(float) FaureDimensionTwoOfThree[i])

however if both double (Real) the original error will pop up (of course),  
with a difference (diffi below)~1e-16 as I mentioned above.
I guess the solution is to use tolerance.

Thanks,

Tamas



-----------
lowdiscrepancysequences.cpp(293): error in  
"LowDiscrepancyTest::testFaure": 4th draw, dimension 1 (0.111111) in 3-D  
Faure sequence should have been 0.111111 diffi= 1.38778e-17
lowdiscrepancysequences.cpp(293): error in  
"LowDiscrepancyTest::testFaure": 5th draw, dimension 1 (0.444444) in 3-D  
Faure sequence should have been 0.444444 diffi= 5.55112e-17
lowdiscrepancysequences.cpp(293): error in  
"LowDiscrepancyTest::testFaure": 7th draw, dimension 1 (0.888889) in 3-D  
Faure sequence should have been 0.888889 diffi= 1.11022e-16
lowdiscrepancysequences.cpp(293): error in  
"LowDiscrepancyTest::testFaure": 8th draw, dimension 1 (0.222222) in 3-D  
Faure sequence should have been 0.222222 diffi= 2.77556e-17

On Thu, 02 Feb 2006 09:03:39 -0600, Luigi Ballabio  
<[hidden email]> wrote:

> On 1/22/06, Tamas Sashalmi <[hidden email]> wrote:
>> On the 64bit problem: in the first part the error is in
>> lowdiscrepancysequences.cpp .
>> In this file there is no tolerance setting, creating one [...] will  
>> solve this problem.
>
> Tamas,
>     thanks. Was 1e-7 the smallest tolerance that let the tests pass?
>
> Luigi

[Luigi Ballabio]

On 2/3/06, Tamas R Sashalmi <[hidden email]> wrote:
> so I've checked again. The differnces are around:
>   1.11022e-16
> so very small.
>
> Also there is a second solution for this (if you don't like the tolerance)

I do like setting a tolerance---checking floating-point values for
strict equality is not a good idea in general---but 1e-7 had me
worried. If we had needed such a large value, it might have pointed at
some problem in the implementation. 1e-15 is ok, I will update the
test shortly.

Thanks,
    Luigi

[Luigi Ballabio]

On 2/3/06, Luigi Ballabio <[hidden email]> wrote:
> I will update the test shortly.

Done. Can you update from CVS and confirm that the tests pass?

Thanks,
    Luigi

[Tamas Sashalmi]

Confirmed,
Also maybe this is the time to change to 64bit. Same machine on 32bit will  
do this test in 7 m 41s.

Thank you.

Tamas

Tests completed in 5 m 44 s
*** No errors detected
PASS: quantlib-test-suite



On Fri, 03 Feb 2006 04:50:40 -0600, Luigi Ballabio wrote:

> On 2/3/06, Luigi Ballabio wrote:
>> I will update the test shortly.
>
> Done. Can you update from CVS and confirm that the tests pass?
>
> Thanks,
>     Luigi

[Luigi Ballabio]

On 2/3/06, Piero Foscari <[hidden email]> wrote:
> Just as a side note, it's usually good numerical practice using relative
> tolerances, better than absolute. Maybe this is not so important here
> (still have to really look at QL) - as in places where the order of
> magnitude is kinda stable - but it's always a good habit to get, and
> eventually only get rid of it where performance requirements are
> critical, anyway some care still needs to be taken then...

Yes. The test case is one where the order of magnitude is known, but
in general we have a close(x,y) function which implements Knuth's
algorithm for floating-point equality.


> While I'm at it, is QL intended to get parallel someday? Or is it
> already and I just missed it? Couldnt find this on the faq...

Not much at this time. There's just a hook in there which can be used
for bypassing the most obvious point where it's not parallel---see the
thread at <http://sourceforge.net/mailarchive/forum.php?thread_id=8151830&forum_id=4299>.

Luigi