× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: How are CPU Speed and Overall CPW Related?
  • From: "Nathan M. Andelin" <nathanma@xxxxxxxxx>
  • Date: Fri, 4 May 2001 12:43:43 -0600

> Date: Fri, 4 May 2001 10:45:46 -0500
> From: "Alexei Pytel" <pytel@us.ibm.com>
> Subject: Re: How are CPU Speed and Overall CPW Related?
>
> 1. There are very few purely interpretive languages today. They all
> precompile the source to some internal form, which is really very close to
> compile. Which is especially true in your test, where you have very short
> loop. Do you really think that FoxPro interprets every statement in your
> loop as it is encountered ?

Yes, Foxpro intreprets every statement.  But the bulk of the work is in the
alltrim() function, which is simply a wrapper around a compiled C function.
Which is why I considered it to be a valid test.  The effect of
interpretation by Foxpro was evidenced by the Delpi example, which ran
nearly twice as fast as Foxpro, and ten times as fast as the RPG equivalent.


> 2. I want to attract once again your attention to the fact that you trim
> *constant string* every time. Smart compiler will eliminate your entire
> loop and replace it with a single statement. Change number of repetitions
> from 500000 to 5000000. I will not be surprised if the timing will be
> exactly the same.

Ok, I changed the loop to 5,000,000.  It took ten times longer to run,
contrary to what you expected.  The string passed to the alltrim() function
is a variable - not a constant.  It holds 50 bytes, just like the RPG
variable.

> 3. I dare remind you that you constantly leave software out of the scope
of
> this discussion.
> You want to compare PowerPC speed to Pentium speed. But what you do
> actually compare is speed of RPG implementation in OS/400 environment on
> PowerPC to speed of FoxPro implementation in Windows environment on
> Pentium. Which is somewhat different thing, don't you think ?

The efficiency of code is in RPG's favor, not Foxpro's.  Yet Foxpro was more
than 5 times faster.  And Delphi was 10 times faster.  That's too much of a
difference to be explained by code efficiency.


> Try some other programming languages on OS/400 for a better perspective.
> Try C/C++ instead of RPG.
> Several years ago when RISC was first out I took some standard LinPack
> numerical benchmarks (they are all in C and with some massaging can be
> easily ported to OS/400) and ran them on PC and OS/400. Results were quite
> comparable.

May I dare remind you that you are constantly leaving hardware out of the
scope of this discussion?  Were you using a 170-2290?  What AS/400 and PC
were you comparing?  You are, in effect, contantly denying that the CPU on
the low-end 170 models is constrained by something.  Whatever the constraint
is, is aparently only known by IBM.

We did some language comparisons a month or so ago.  It was a string
handling exercise.  Following was the result.  I think the RPG examples in
these tests would have been faster if the numeric variable woulds have been
defined as integers, rather than zoned numerics.  Notice how I used integers
in my more recent tests.


===============  MI === RPG ===  C === Java
Right Adjust String:   1.3        2.6          1.5        18.7
Embedded spaces:  2.4        3.2          2.0        35.8
Code by: ========= leif ==  buck == phil === phil ===


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.