RPG IV versus RPG III performance

[Anon Anon]

Hi, Does anyone have any metrics on RPG III versus RPG IV performance in a production system? For example, have you re-generated all or part of a Plex or 2E app from RPG III to RPG IV and if so were there any performance benefits? If so it would be useful to know what OS version was used. If you don't have detailed metrics then anecdotal experience would also be useful. Thanks, Daniel Message Edited by DanielLeigh on 07-03-2008 11:37 AM [left]

[Deactivated User]

Daniel,  This is purely anecdotal, so take it for what it is.  Given that the same language constructs are used (i.e. you are not using any RPGIV BIF's (Built In Functions) etc.) then...    There is absolutely no difference in performance between generated RPGIII & generated RPGIV code. The idea that there is any difference is an old wives tale (IMO)  My understanding is that the  RPG compilers optimize code and generate intermediary code (w-code) that is then handed off to another compiler and  compiled into machine code (where there is probably another level of optimization). I also am led to believe that the same cosntructs in both languages will result in the same machine code (and I have no reason to doubt that).  And, this point is really quite important to this discussion. Most applications on the IBM i platform are i/o intensive, and this is where normal bottlenecks occur. Worrying about whether RPGIII or RPGIV once compiled (by an set of compilers written by people waaay smarter than I could ever hope to be) is quicker than the other is really missing the point.  There's been a long (and sometimes heated) discussion on the System i news forums recently about whether subroutines are quicker than Procedures. it got to the point where someone testing calling a subroutine and a procedure 1 billion times to see what the difference was. These iterations both ran in under or close to 3 minutes (and the noticeable difference between the 2 was really not worth mentioning). The point being here is that the hardware has got so quick that perceived differences in the languages performance that was stated 15 years ago just does not apply to todays hardware. It's back to i/o again, and that's what really slows down an application, badly designed databases and poorly written logic that gets the same file data over and over again (for example).  Given that the 2E generator provides pretty much the same code in RPGIV as it does in RPGIII then there little reason for me to believe that there is any performance benefits to be gained from using one or the other.  So, the question becomes what are the benefits of using one vs. the other. I have some pretty strong opinions on this, but I will continue.  RPGIII is a dead language. It was replaced by RPGIV in 1994 (yes, that's nearly 15 years). I really wish that people would move to the RPGIV generators and stop using RPGIII. With V6R1 this is going to become a bigger issue because you will have to pay extra for each individual compiler (OPM vs. ILE) and the pricing will be by developer. IBM surely wants to get away from having to support two compilers, and they have made this pretty clear.  If you are using the RPGIV generator then you can start to take advantage of a lot of the features in RPGIV, such a string handling, prototyping, XML support (this list can get quite extensive, so I'll stop there). There are so many examples of long winded RPGIII code that can be replaced by a single line of RPGIV code that it's amazing. In situations like this, then I would agree that a well written RPGIV application taking advantage of the newer language features would be much better performing (but that isn't really your question, IMO).  The fact that CA has to continue providing support for the RPGIII generator is (again IMO) holding back the tools. The RPGIV generator cannot take advantage of new langauge constructs that cannot be supported by other langauges. There loads of RPGIV BIF's that would be really pleasing if you could use them directly within a 2E Action Diagram (or Plex for that matter) rather than having to drop down to source code. The RPGIV language is evolving, and it would be really nice to take advantage of that (well, I do, but just not natively).  Sorry if I got off topic, but I do think it is worth reading a little more into your question that perhaps you asked.  FYI, we generate all new code in RPGIV. As and when we change existing function we are changing them to be RPGIV as well (THANKS to some well received changes in the RPGIV generator that made this not feasible with the early released RPGIV generator) because it really is just a case of changing the language implementation (unless you have user source that needs to be rewritten, but that is not stopping us). We hope to eventually move completely off the RPGIII generator. We have found no evidence one way or the other that would indicate any change in performance between the two langauges. What we have found is that we can do a lot more with RPGIV. We can write HTTP requests to make calls into HTTP servers. We can write HTML, or XML to the IFS. We can access a vast number of IBM i API's that are not accessible from RPGIII (I have presented a few of these).  V5R4M5 on Power 6 570. Started using RPGIV with release 7.0+ of 2E (and whatever the current release of OS/400 was back then).  Crispin. Message Edited by Crispin on 07-03-2008 12:06 PM [left] Message Edited by Crispin on 07-03-2008 06:37 PM [left]

[Anon Anon]

Actually, only the ILE Compilers produce w-code.  According to Dr. Soltis' "Fortress Rochester: The Inside Story of the IBM iSeries (pp. 138-143)" , the OPM compilers produce Intermediate Representation of a Program (IRP) code, which is converted to the OPM template containing MI instructions via the Program Resolution Monitor (PRM).   On a v4 and later RISC system, the OPM Template is then converted to an ILE template via "Magic" (that's what IBM actually calls the component responsible :)  The ILE compilers produce w-code, which is converted to an ILE template by the compiler back-end known as CUBE-3 (Common Use Back End - Generation 3).   Note that EPM compilers produce U-code, which is converted by CUBE-1 into IRP then on into a OPM template.  While both a native ILE template and a "magically" converted ILE template are passed to the ILE optimizing translator (OX), it is important to note that w-code and CUBE-3 are "designed to very efficiently support RISC processors."  While I've never really looked for it, here's at least two people who report run-time improvements simply by going from RPG III to RPG IV using CRTRPGSRC:http://archive.midrange.com/rpg400-l/200311/msg00057.html   (5-15%)http://archive.midrange.com/rpg400-l/200501/msg00526.html (50%)  Given the above, I might have to go looking for a test case,   if I do, I'll post the results I get.  Brabara Morris, of the IBM RPG compiler team had the following to say in response to the second message above: http://archive.midrange.com/rpg400-l/200501/msg00528.html There are a few areas where the ILE RPG compiler runs faster because of
the way the compiler and runtime are coded. For example, the handling
of eof and record-not-found is much faster for ILE RPG. Also, program
initialization is much faster when you have no PSDS or a small PSDS
(this is most dramatic when the called program returns immediately).

There may be some difference due to the fact that the ILE RPG runtime is
statically bound and the OPM runtime is not, but this may not be as big
a difference as you'd expect, because the OPM RPG runtime is used much
less than the ILE RPG runtime. Many OPM RPG programs only call the
initialization runtime program; all the code is generated directly into
the program rather than calling out to the runtime; system programs for
file handling are called directly from the generated code.

I think most of the difference is due to the optimizating translator
used by the ILE compilers, which takes the code generated by the
compiler and generates machine code.
   Another thing to consider is that the ILE RPG compiler and the back-end components continue to improved.   Whereas, the OPM RPG components haven't been updated in 15+ years.    Like Crispin, we do all new programs as RPG IV.   Anytime we modify an existing RPG III generated program, it gets converted to RPG IV. I also agree with Crispin about the continued support of RPG III is holding back the Plex product.  Honestly Daniel, I don't consider Plex generated RPG IV to be RPG IV.   It's simply RPG III with the column spacing adjusted so that the RPG IV compiler will accept it.   It doesn't appear that you even have two separate generators.   Instead there's one generator with a handful of IF statements that control the column spacing to use and the choice between d-specs or i-specs.   You don't make use of any RPGIV enhancements like EVAL and the other extended factor-2 opcodes, %BIFS(), long names or new data types like DATE, INTEGER and VARYING length strings.    Heck you want to see a big performance improvement?   Change to INTEGER data types wherever possible and using VARYING strings when doing string manipulation.   Want even better performance?   Give us ILE RPG support with bound Procedure calls instead of dynamic program calls.  Another easy way to improve performance, use SQL DDL to defined physical tables and (most) views instead of DDS.   That's a significant performance increase that can be had without needing to regen/recompile any programs that use the files.   It'd be an easy option for you folks, you already generate the SQL DDL for every other varient. I'm actually considering writing my own post-processor so that our Plex generated DDS can be converted to SQL DDL auto-magically.  Last but not least, from a performance perspective get rid of OPNQRYF when dealing with views that contain virtuals and use embedded SQL like every other varient.   While you're at it, let us use embedded via the SELECT WHERE AD statement and related.  I've only been using Plex for a year, I like the product and the possibilities.   But I also like the IBM System i and I am concerned that Plex has never moved forward in relation to the System i.   I'm not asking for v6r1 capabilities, instead I'd like to have v3r1 capabilities that have been available for 15+ years.   Heck, you're just now giving us 10-character objects names.  Plex would be a natural fit for ILE RPG and SQL, it's to bad Plex is stuck with RPG III.  I had somebody contact me from an System i mailing list wanting my opinions about Plex...I told them honestly that the product was impressive, but disappointing in its support of the System i vs. other platforms.  Charles                    

[Deactivated User]

Charles,  I had a sneaky feeling I got that wrong after I thought about it more. I remembered there being a way to get the IRP listing, but for some reason I thought that had been removed (maybe it has) and that got me thinking they both went through w-code. Thanks for setting me straight on that one :-)  While not very imperical (I think performance can be very difficult to be precise with unless a dedicated system and exact resources) I ran a couple of tests.  File A has 5.8 million records in it. I created a 2E RPGIII & RPGIV program to read the file and increment a counter for each record read.  CPYF created the file in 77 seconds.  RPGIII Program Read the file in 21 seconds.RPGIV Program Read the file in 20 seconds.  The timings for the RPGIII Program vs. the RPGIV Program were consistent over quite a few different tries, including signing off between tries (at one point the RPGIV program took 105 seconds, but I think the system was busy with other requests at that point, as I was unable to reproduce that time (unless the system just paged the file in and never out, which wouldn't surprise me).  CPU hit about 40%, which leads be to believe that the programs were i/o bound (a tight loop takes the CPU up into 200-250% range, depending on the other processors/partitions etc.)  This was a really simple test, and only with a READ and a counter increment (I changed the counter increment to a binary and then an integer, and still got the same results).  So, what's the point of all this.  I think in both of these cases the processing time was incredibly similar, to the extent that an interactive user wouldn't even notice the difference. Almost 6 million reads is probably not that common in interactive applications.  I still have not seen any imperical evidence that moving to RPGIV has improved performance in our 2E generated applications.  It's funny that I would argue that, considering my stance on the RPGIII generator :-)  Regarding DDL. I would really like DDL to be generated alongside DDS, so that the native 2E code can still use the DDS files, yet the system can take advantage of the indexes etc. created by the DDL. I had a look at that with the 2E compiler (similarly to you with post generation process to create the DDL) and was quite successful in getting things to co-exist. But, I couldn't get further because of known issues with SQL generation in 2E. That was quite a while ago, and I didn't take it any further, but I agree that DDL is shown to improve performance as well. I may be forgetting the exact issues I ran into though...  But yes, RPGIV is a much better choice...  Crispin.

[Anon Anon]

I am sorry to stray away from III vs. IV to SQL but...  How can a Select/fetchnext be faster than SETLL/READE?   Please do not take this to be a support for "RPG io" but, isn't rpg io "closer to the metal"?  All things considered, I'd rather that Plex generated RPG IV use SQL for io and DDL.  In my perfect world, RPGIII would be "stabilized"(bullet put in it's head) and RPG IV would be aligned with the way that Java and C# are generated, run and called, of course still being RPG and System i.  Internal Functions = *NOMAIN modulesExternal Function = Modules that have a MainUse Code Library modeling to build Executable programs and/or Service ProgramsSQL for ioRPG support for C data types.Generate source into WDSC/RDi (WebSphere Development Studio Client/Rational Developer for i)

[Deactivated User]

Chris,  I don't think anyone could say that SQL performs better than Native i/o. I also think that the same holds in the reverse.  It truly depends on the situation. Sometimes a SQL result set will be returned more quickly than RPG i/o reading through the data. Nowadays with SQL it is becoming more important to maintain indexes, and there are a lot of tools available that will tell you what indexes the system is building temporarily because they don't exist. SQL's quite clever like that. RPG i/o cannot benefit from that, because you're so close to the metal.    If you're doing random access (i.e. a CHAIN) then native i/o will more than likely win. SQL isn't that good at that sort of database access, whereas native i/o is extremely good at it.  This is one of the reasons I would want granular control over what uses what :-)  As you may have noticed, I'm with you re:RPGIII :-)  When integrating with other applications that are  hand written I think it is going to become more important to be able to build Service Programs. Otherwise the native developers will soon be asking questions like why do I have to call programs in your application to get at your business rules...  Crispin.

[Anon Anon]

Actually,  The last time I saw any benchmarks, RPG native i/o was as fast as you could get for single record i/o...ie. FETCHEQ (CHAIN).   SQL was slower, but that was at least a couple of OS versions ago.   Given the improvments in the SQE,   its possible that SQL has matched native i/o at this point.  The same thing applies for cursor operations where you are fetching one record at a time.  On the other hand, for set based operations, SQL outperforms native i/o.   At the time the benchmarks I saw were done, it took about 100 records for SQL to beat RPG.   So for example, a BlockFetch that used SQL to fetch 64 rows in a single statement ( FETCH FOR 64 ROWS FROM MYCURSOR INTO : Output) would quite possiblly perform better than the RPG native I/O version.   The reason SQL has the edge is that it has to make fewer trips into and out of the lower layers of OS code.  IMHO, the biggest benefit to SQL is flexiblity.   With RPG native, you can't offer mutliple sorting/select criteria quickly and simply without specific logical files.     Whereas with SQL, the query engine can make use of multiple indexes to give you acceptable performance even if the "perfect" index doesn't exist.  Charles

[Anon Anon]

Christopher_Smith wrote:
...Internal Functions = *NOMAIN modulesExternal Function = Modules that have a MainUse Code Library modeling to build Executable programs and/or Service ProgramsSQL for ioRPG support for C data types.Generate source into WDSC/RDi (WebSphere Development Studio Client/Rational Developer for i) To extend this: implementation name = sup-procedure name file name = module name (allow multiple sub-procedures in a single module) package = service program name (only internal functions allowed here) allow an internal function to be defined to be generated inline potentially as an extension to the function type triple (might be unnecessary as meta can serve this purpose as well) support packed data type in SQL (Decimal = Packed, Numeric = Zoned) a couple new triples to handle activation group FUN Activation Group SYS (*Default, New, Caller, *Named)  ... TRP Name NME ________________________ (default is QILE if unspecified)      Message Edited by MarkMurphy on   07-08-2008   01:45 PM [left]

[ca.portal.admin]

Just re-reading this thread as it has come of interest at my site.   I agree.   Would be great to see this happen but also in 2e.   Would we be able to generate better RPG IV ILE and COBOL if the support for old RPG is removed?   In my perfect world, RPGIII would be "stabilized"(bullet put in it's head) and RPG IV would be aligned with the way that Java and C# are generated, run and called, of course still being RPG and System i.     

[Anon Anon]

Crispin ,  I agree that performance of RPG III and RPG IV for most if not all interactive programs is a moot point from the user stand point.  Batch programs are another story.   In particular, if you have large records, using RPG IV to do record I/O directly into a data structure will provide considerable improvement.  As far as integer vs. packed decimal, my test show integers as being about three times faster than packed decimal.A simple for loop of 500M iterations took 17s of CPU time when the index (I) was an integer vs. 46s when using packed decimal.   Granted, 500M iterations is awfully high, but the results are even more interesting when you add an EVAL Z = X * Y into the loop.   With I, X, Y and Z being integer the loop takes 18s vs. 83s when I,X, Y, and Z as packed decimal.  Now would it make a difference in an i/o bound process, of course not.   But what if your process was CPU bound?  Then consider the overall effect if every DB file and every RPG program used integers wherever possible, would that make a difference in overall CPU usage?   Quite possibly.  Of course, considering that neither Plex nor 2E take advantage of RPG IV.....       

[Deactivated User]

Charles,  Good information.  With an integer I found it took  4 seconds for 500M iters and with a packed I found it took 7 seconds.The I tried your second set, and found the integer still took 4 seconds, but the packed took 27 seconds!  So, you're absolutely spot on with the improvement using integers. That's something I'd like to be able to use now :-)  As well as integers I'd also like to see pointer support. In 2E I can use pointers, but I can't use them directly because they are invalidated once moved to a non-pointer field (very frustrating). This makes program to program calls passing pointers extremely difficult, if not impossible, so you end up going back to monolithic code :-(  Of course this is all conjecture. As you point out, the code is the same whichever generator is used...  Ah well, back to real coding :-)  Crispin. Message Edited by Crispin on 07-15-2008 10:09 AM [left]

[Anon Anon]

Just as an FYI: but CA has fix to enable integer support in Plex.  I was able to convince them that the lack of support was a bug, since the database supported integers it was possible that files populated by a non-Plex program could have an true integer value outside the range supported by the 9b0 variables Plex was using.   (In fact, the DB table in question could have been Plex generated).   Not to mention the various IBM APIs that use true integer variables as parameters.  Document:47848     Problem:1397  https://support.ca.com/irj/portal/kbproblem?ipLogNrow=0&productcd=CPLEX&docid=478484&problemnbr=1397  I've been testing the fix that added the support and so far, it's been fine.    Charles

[Deactivated User]

Good job Charles (and CA development)! That's one off the list :-)  Crispin. Message Edited by Crispin on 01-30-2009 09:28 AM [left]

[Anon Anon]

I was doing some benchmarking for reason other than this thread, but I thought I'd pass this along...

                                           5M       50M
OPM calling OPM                 6s     62s            
Dynamic Program Call     12s     122s
Bound Procedure                 1s      4s

In the first case, an RPG III PGM was calling another RPG III PGM (which returned with LR = *OFF).   In the second case, an RPG IV PGM was calling another RPG IV PGM (which returned with LR = *OFF).

In the third, an RPG IV PGM was calling a RPG IV procedure in a SRVPGM.
Both of the called programs and the called procedure simply RETURN. I was going to check to see how much of the 12s was from the dynamic call vs. the RPG cycle, by replacing the called RPG program with an ILE C program, but the system I was testing on, a 515 running v5r4, didn't have the C complier installed.   I'm a little surprise to see RPG III program calls performing better than RPG IV program calls..   I thought perhaps it was activation group related.   Initially, I had NEW calling CALLER.   I tried changing both program to run in the same named activation group.   That had no effect.   So I tried changing both to DFTACTGRP(*YES). That had a little effect, lowering the times to 11s and 110s.

 Charles

Message Edited by CharlesWilt on 07-24-2008 10:19 AM [left]

[Deactivated User]

Charles,  Did you use CALL on both, or was the RPGIV call prototyped? Just curious if there is something odd going on with Prototyping or if it is CALL vs. CALL.  I'm very surprised that there is such a difference. Once the pointer to the called program is resolved, and the fact it is leaving INLR OFF, what is there that would be left to do in the RPGIV calls?  Can you post the code you used?  BTW, I'm really not surprised that the Procedure calls are that much quicker. Initial overhead of loading the service program (which is very light by the sounds of it) is offset by the faster execution. Another good reason for Service Programs!  Thanks,  Crispin. Message Edited by Crispin on 07-24-2008 10:32 AM [left]

[Anon Anon]

Crispin,

Yes to both.   Originally the call was prototyped.   But I tried a non-prototyped call also to see if there was a differenence

I also moved from a FOR loop to a DO loop like the RPG III.....

* Begin OPMPGM1

     I              50000000              C         NBRLPS
     I              'OPMPGM2'             C         PGM
     C           1         DO   NBRLPS    IDX    100
     C                     CALL PGM
     C                     ENDDO
     C                     MOVE *ON       *INLR
     C                     RETRN

 

         * Begin OPMPGM2

     C                     RETRN

 

 

 

     //Begin DYNPGMCALL

     h dftactgrp(*YES)
     d i               s             10i 0

     c     1             do        50000000      i
     c                   call      'CALLEDPGM'
     c                   enddo
     c                   eval      *inlr = *on
     c                   return 

 

       //begin CALLEDPGM

     h dftactgrp(*YES)
     c                   return

I also tried the following, using 50M iterations: OPM --> ILE     took 207s  ILE --> OPM       took 55s

So it appears the difference isn't in the CALL itself, but instead is in the startup of the called program.

Charles

[Deactivated User]

Charles,  The calls are differrent. The RPGIII call is using a variable. Does that make a difference (theoretically you could change the called program in debug). That sitll doesn't explain why RPGIII is quicker...  I can't see why there would be any startup on subsequent calls. Cornfused :)  Crispin.

[Deactivated User]

Charles,  I just ran your code, but I changed the RPGIII call to hard code the program name instead of using a constant.  RPGIV took 136 secs.RPGIII took 60 secs.  Same RPGIII calling the same RPGIV took 258 secs.Same RPGIV calling the same RPGIII took 60 secs  The RPGIII->RPGIV kept calling the following...  QLEAWI         QSYS                   14                               Q LE leActivationInit  ...even though the PEP remained active.  Crispin.

[Anon Anon]

Uhm...  What Crispy said...  :-)

[ca.portal.admin]

Just echoing one or two points.  If everyone moved to RPGIV then the tools will evolve more as CA are restricited to the lowest common denominator when including functionality into the base product.  Field widthsAPI'sStringsExpotential Calculations etc  Many of these are overcome with RPGIV and source modification.  I personally like the fact that the source is available when debugging ILE programs and I must admit that pre 8.0 the ILE generator had issuess.   One small one left is that parameters BOTH and OUTPUT are not returned to Y2CALL.   Being fixed in 8.5 and IMHO once this is done, apart from User Source and little features like obtaining number of parameters from the object, ILE RPG is the way forward for RPG shops.  Lee.

[Deactivated User]

LeeDare wrote:
 I personally like the fact that the source is available when debugging ILE programs...  Lee. Lee,  Just FYI (and I would only recommend this if you are forced to use RPGIII),  I would change the CRTRPGPGM Model Message to include OPTION(LSTDBG). This way, if you STRDBG OPMSRC(*YES) you can use the debugger in the same way you do for your ILE programs...  Crispin.