[MOAB-dev] Discussion on return type of MOAB routines

Vijay S. Mahadevan vijay.m at gmail.com
Fri Jan 24 12:36:24 CST 2014


Wasn't near my machine before but here's the code that I modified
based on Danqing's original version. It now has couple more different
variations with randomized failures controllable with options. Look at
the code, most should be self-explanatory.

Define RANDOMIZE_FAILURES, appropriate FAILURE_RATE with NO_PRINT to
see what should happen in a typical case. When everyone always returns
a success, essentially, there are no RANDOMIZE_FAILURES and so
undefine that to see the timing results.

Vijay

On Fri, Jan 24, 2014 at 12:25 PM, Tim Tautges (ANL) <tautges at mcs.anl.gov> wrote:
> Ok, I tried explicit constructor/operator=, and they didn't change things
> much.  But, I get really different timing for the struct or class based
> version.  I also added a char* member to the class to check that too,
> without that much additional time being required after adding that.  I also
> changed the #loop iterations to 10^6 and the depth of recursion to 10, I
> think that's more realistic for MOAB.
>
> The times vary somewhat, but representative times are:
>
> class-based version, w/o funcs: .018-.025s (10 runs)
> class-based version, with funcs: .017-.030s (10 runs)
> POD version: .002-.003s (10 runs)
>
> Code is attached.  Vijay, could you run this too?
>
> Danqing, are you using an NFS-connected disk, or a local one?
>
> - tim
>
>
> On 01/24/2014 11:50 AM, Wu, Danqing wrote:
>>
>> Even with C style struct, without explicitly defined constructors, there
>> is still noticeable difference.
>>
>> Used g++ -O3 to build.
>> For returning plain enum type, the result on my laptop is
>> real    0m0.003s
>> user    0m0.000s
>> sys     0m0.000s
>>
>> For returning struct, the result is
>> real    0m4.114s
>> user    0m4.112s
>> sys     0m0.000s
>>
>> //////////////////////////////////////////////
>> #include <iostream>
>>
>> using namespace std;
>>
>> enum ErrorCode { MB_SUCCESS = 0, MB_FAILURE = 1 };
>>
>> struct ErrorInfo {
>>    ErrorCode mErrorCode;
>> };
>>
>> ErrorCode test_return_0(long n)
>> {
>>    if (n > 0)
>>      return test_return_0(n - 1);
>>
>>    return MB_SUCCESS;
>> }
>>
>> ErrorInfo test_return_1(long n)
>> {
>>    if (n > 0)
>>      return test_return_1(n - 1);
>>
>>    return ErrorInfo();
>> }
>>
>> int main()
>> {
>>    for (long i = 0; i < 100000; i++)
>>      test_return_0(100000); // Change to test_return_1(100000) for
>> comparison
>>
>>    return 0;
>> }
>> ________________________________________
>> From: Jed Brown [jed at jedbrown.org]
>> Sent: Friday, January 24, 2014 11:30 AM
>> To: Tautges, Timothy J.; Vijay S. Mahadevan
>> Cc: Wu, Danqing; Paul Wilson; moab-dev at mcs.anl.gov
>> Subject: Re: [MOAB-dev] Discussion on return type of MOAB routines
>>
>> "Tim Tautges (ANL)" <tautges at mcs.anl.gov> writes:
>>
>>> Yeah, but even the ErrorCode-only class version was way slower than
>>> the one returning only ErrorCode, that's what makes me think there's
>>> C++ stuff going on behind the scenes (or optimizations the class
>>> version doesn't get) that is causing the big jump.
>>
>>
>> Where is the exact code?  Also, it should be obvious in the assembly.
>>
>
> --
> ================================================================
> "You will keep in perfect peace him whose mind is
>   steadfast, because he trusts in you."               Isaiah 26:3
>
>              Tim Tautges            Argonne National Laboratory
>          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
>  phone (gvoice): (608) 354-1459      1500 Engineering Dr.
>             fax: (608) 263-4499      Madison, WI 53706
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: moab_errtest2.cpp
Type: text/x-c++src
Size: 10228 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20140124/262e9d4f/attachment.cpp>


More information about the moab-dev mailing list