Re: C vs C++

I had missed the packed bit - good catch Mark.

As far as “unclear why” - I believe that while the ILE C compiler was IBM i specific, the C++ compiler is basically just the AIX version running in PASE. I’m disappointed that they apparently made no changes in an area where there was obviously such a huge potential for performance issues as packed decimal operations.

Perhaps an RFE is appropriate.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Feb 16, 2015, at 2:31 PM, Jevgeni Astanovski <[email protected]> wrote:

> Mark, frankly speaking packed decimal was my suspect since I saw the
> difference. I saw the difference - it was intuitively clear that the
> implementations of packed decimal is fundamentally different in C and C++
> (however unclear why). What I'll do tomorrow, I'll write my own trivial
> benchmark using decimal arithmetics.
> Hopefully I shall see the difference.
> The program uses decimal (15,0), decimal (15,9) and decimal (11,7) - It
> seems that they all fit into 8 byte int.
> I'll then see which is better - staying on C and decimals or switch to C++
> and integers...
> 
> Thanks,
> Jevgeni.
> On Feb 16, 2015 8:29 PM, "Mark S Waterbury" <[email protected]>
> wrote:
> 
>> Jevjeni:
>> 
>> I just noticed near the bottom of your post, where you said:
>> 
>>        Program makes a lot of calculations with packed decimal.
>> 
>> There is a big difference in the way ILE C implements support for "packed
>> decimal" as a "native" data type -- versus the way it is "supported" in ILE
>> C++ -- in ILE C, the compiler directly genrerates in-line code (in WCode /
>> NMI)  to work on packed decimal data.  In the ILE C++ compiler, support for
>> "packed decimal" is through a C++ library called "BCD" -- there are a lot
>> of macros and such defined in the QSYSINC/H include member named BCD ... if
>> you take a peek at that member, I think you will see that this uses
>> "operator overloading" in C++ to trick the compiler into calling the
>> desired library functions when operations are performed on "packed decimal"
>> data.
>> 
>> This difference could easily account for the big differences you are
>> seeing.
>> 
>> And then, you said:
>> 
>>        ... is there anything that can be done about it?
>> 
>> In C++, you could look into converting the packed decimal data into 64-bit
>> integers, and then performing any calculations using those long integers.
>> This would be much faster than using packed decimal arithmetic, then
>> convert back to packed decimal format, if needed.  Or, just stick with ILE
>> C/400 for those programs that require doing a lot of packed decimal
>> arithmetic operations.
>> 
>> Hope that helps,
>> 
>> Mark S. Waterbury
>> 
>>> On 2/16/2015 9:56 AM, Jevgeni Astanovski wrote:
>> 
>>> Hi all.
>>> Does anyone have any idea why C++ program is significantly slower than
>>> C program?
>>> 
>>> Explain the situation.
>>> I have a number of API-s that are called via RPC, access some tables,
>>> make some calculations and return some structures to the caller.
>>> They've all been written on ILE/C.
>>> Recently I started to experiment with porting them to ILE/C++. There
>>> was a number of reasons why it would be nice.
>>> After I rewrote the first one, I started to measure performance. This
>>> is an issue for me as some of them are called hundreds of thousands
>>> times per day.
>>> Found out that it is approximately 2 times slower than C version.
>>> Shared a code to colleges - no one found anything suspicious. However
>>> one guy came out with a "brilliant" idea - he advised me to try to
>>> recompile my C program with CPP compiler and see the performance.
>>> Guess what? C program compiled with CPP compiler was the same 2 times
>>> slower than C program compiled with C compiler....
>>> 
>>> And the only modifications that I did for compiling C with CPP compiler
>>> was:
>>> 1. Substituted "#pragma mapinc" table structue definitions with those
>>> generated by GENCSRC;
>>> 2. Changed char and unsigned char in a couple of places as C++ is more
>>> strict;
>>> 3. Made a substitution for "NNNND" constants (like 100D for example)
>>> as C++ does not support that.
>>> 
>>> What I saw is that time increase looks like it has a proportional nature.
>>> I tested API in 3 cases (number of tests is over 100): simple request,
>>> medium request; complicated request and the timing is:
>>> Simple C: 1ms; Simple C++ : 2ms
>>> Medium C: 3ms; Simple C++ : 7ms
>>> Long C: 25ms; Long C++: 60ms.
>>> 
>>> The difference is in number of records read from table and a number of
>>> calculations.
>>> That is a simple one retrieves less that 10 records; medium - more
>>> than 10 and long - more than 100. Program makes a lot of calculations
>>> with packed decimal.
>>> 
>>> Any idea why it is like that and is there anything that can be done about
>>> it?
>>> 
>>> Thanks in advance,
>>> 
>>> Jevgeni.
>>> 
>> 
>> --
>> This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L)
>> mailing list
>> To post a message email: C400-L-Zwy7GipZuJhWk0Htik3J/[email protected]
>> To subscribe, unsubscribe, or change list options,
>> visit: http://lists.midrange.com/mailman/listinfo/c400-l
>> or email: C400-L-request-Zwy7GipZuJhWk0Htik3J/[email protected]
>> Before posting, please take a moment to review the archives
>> at http://archive.midrange.com/c400-l.
>> 
>> 
> -- 
> This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list
> To post a message email: C400-L-Zwy7GipZuJhWk0Htik3J/[email protected]
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/c400-l
> or email: C400-L-request-Zwy7GipZuJhWk0Htik3J/[email protected]
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/c400-l.
> 

-- 
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list
To post a message email: C400-L-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.