Re: C vs C++

Request for Enhancement.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Feb 17, 2015, at 3:03 AM, Jevgeni Astanovski <[email protected]> wrote:

> Jon,
> 
> what stands beyond the abbreviation RFE?
> 
> Jevgeni.
> 
> 
> On Mon, Feb 16, 2015 at 9:45 PM, Jon Paris <[email protected]> wrote:
>> 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.
>> 
> -- 
> 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.