|
midrange.com
I can't understand your obsession with "artificial constraints".
It's much more complicated than that.
CPU (any CPU) is so much faster than memory, that however large is the
cache, CPU always has to waste cycles.
The only really "unbridled" case will be if cache entirely replaces memory.
Next, we were talking about L2 cache. L2 cache is still sufficiently slower
than CPU, so any L2 cache always constrains CPU.
To let CPU run at "unbridled" speed will be to expand L1 cache to the size
of memory - say 256MB.
In fact, using your logic, Intel does "artiicially bridle" it's chips,
because Pentium L1 cache is much smaller than PowerPC L1 cache. However,
you don't seem to complain about it.
Next, every application has different requirements in terms of cache. Some
applicatoins benefit more - what you discovered in your test. Some others
will not so easily benefit from it. Of course, if cache could be made the
size of memory (or in other words, memory could be made to run at CPU
speed), then any sort of applications will benefit. But this kind of
surpasses modern technology.
Also, you found a benchmark, which shows that your laptop is superior in
performance to iSeries. I totally agree - your laptop runs your test
faster. So what - do you spend hours and hours round o'clock to run this
test ?
I have my doubts. Try to run a banking system with a modest number of say 2
million accounts on your laptop - a dozen branches, couple of hundreds of
users, interest calculations, loan validation, credit risk etc. Why not -
it is so much faster than iSeries, it should be a breeze.
Again I have my doubts.
Any benchmark shows how well system A runs this particular benchmark. No
more, no less. Now if you can demonstrate that your real application is
sufficiently similar to a benchmark, then these results will tell you
something important. Otherwise, it can be real misleading. This is a
problem with any becnhmark.
For what it's worth...
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/02/2001 11:30 PM
Please respond to
MIDRANGE-L
> From: Jon.Paris@hal.it
> Nathan, while I doubt it will erase all of the time difference, the
> code in your example is not doing anything like the same thing.
Take a second look at the code, Jon. Both programs trim a <variable>
containing exactly 50 bytes (39 of which are blank), then assign the result
to another variable. alltrim() is equivalent to %trim(). Also consider
that Foxpro is an interpreted language, while the RPG code was
compiled with OPTIMIZE = *FULL.
> None of this matters worth a darn though because real programs
> don't simply wizz round in circles doing nothing.
The intent was not to test a mixed workload. Only to compare CPU
performance. Sure there are many other factors to consider, but I still
think CPU performance is "worth a darn". The test showed the Intel CPU to
have much higher throughput. Is that not the reason Intel servers are so
prevalent? I don't believe it's due to the merits of Windows. I believe
the AS/400 CPU is artificially bridled by limited cache. My simple logic
says take off the artificial constraint, and let the CPU do more work -
Particularly CPU intensive Web and client-server work. Instead of watch
"win-tel" take over the server market.
> From: Pat Barber <mboceanside@worldnet.att.net>
> Since the 400 is task interrupt driven, it attempts to service
> all tasks that it has been given in a reasonable amount of time.
> It does not have just one single task of run these 30 or so
> instructions and "then" go check to see how everybody else
> is doing. Every single job in the system gets a whack at the
> processor but that schedule is a fairly complicated process
> that requires time.
It might invalidate the test if OS/400 were doing more work than Windows
during the test, but I don't believe this to be the case. I still think
the
programs test CPU throughput with a sufficiently valid degree of accuracy.
Here's something more meaningful:
I recently sent the RPG source to another list participant who compiled and
ran the program on his 170-2385. The program ran 11 times faster. The
main
difference between his system and my 170-2290 is 4MB of L2 cache. That
really supports my hypothesis that a cache constraint artificially
restricts
the CPU. I actually don't know how much cache the 170-2290 has. That
information is not published. Part of that obfuscation I mentioned
earlier.
Nathan.
+---
| 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.
