|
midrange.com
>> 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.
I am not constantly denying that CPU is constrained. I am constantly
denying your explicit or implicit statement that this is a malicious act of
evil IBM - that this is something that good guys PC manufacturers do not
do, and bad guys in IBM constantly do.
Of course, CPU IS contsrained - it is ALWAYS constrained by something - CPU
technology is so much ahead of memory technology, I/O technology, disk
drive technology. The problem is how to keep CPU busy, not how to make it
run faster.
I have seen somewhere results of investigation, that in normal desktop
workload CPU on PCs is waiting for memory accesses more than 95% of the
time. So it does not really matter, how fast CPU is. CPU is working in
short bursts. The speed of this burst is important for graphical rendering,
for some special-purpose applications, for your test, for games...
But in a real world memory bus throughput, I/O bandwidth etc are much more
important.
Just recently I got new PC with 4 times memory, 3 times CPU Mhz and 4 times
disk. One would expect that it will fly in comparison to an old one. Not
exactly - it's about 20%-30% faster for the things I normally do.
Although I have no doubts that test like yours will show that it just
screams.
But I am digressing...
What I was going to say is that CPU performance is constrained by a speed
of many other components in a system.
What you are saying is that IBM puts special fences to slow down CPU.
What I am saying is that IBM installs the same CPU chip in different models
with different componentry - cache, memory, bus... This different
componentry (which has diifferent cost!) will define an effective speed of
a particular model. Which is what you see in your results.
By the way, PC manufacturers also do this. The same Pentium chips are
installed in desktop models and high-end servers - which have larger cache,
separate and faster memory bus etc. And the same benchmark will run faster
on high-end servers, although Mhz rate is the same.
Your observations are correct - your conclusions are not.
Alexei Pytel
"Nathan M. Andelin"
<nathanma@haaga.com To: <MIDRANGE-L@midrange.com>
> cc:
Sent by: Subject: Re: How are CPU
Speed and Overall CPW
owner-midrange-l@mi Related?
drange.com
05/04/2001 01:43 PM
Please respond to
MIDRANGE-L
> 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
+---
+---
| 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 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.
