|
Alexei, Thank you for your explanations. I am afraid that I may have added fuel to the fire with my suggestion that 'NoOps' might be added based on some theoretical componant in each model. You are certainly correct about MHZ. It is much the same as comparing the RPM of my brothers BMW 4Cyl to his friends Viper V10. The BMW kicks the Vipers A** on the tachometer but the Viper has more horsepower at 2000 RPM than the Bmer at 6K! As he says, 'not a fair fight', the Viper will pass anything but a Gas station. A simalair comparison can be made of my laptop with 300Mhz PII and a desktop I have with a PII300. Should be the same? Nope. The laptop has double the memory both run W2K. The Desktop machine has a string of FWSCSI drives in an array. THe laptop a single IDE drive. Likely the video card comparison isn't even either, but the desktop wins in every column. I hate working on big presentations on the laptop, they seem to be sleeping half the time. Where the rubber hits the road for me is where you compare two iSeries systems with identical processors running at similair Mhz but seeing nearly three to one CPW increases (ie 270-2250 and 2252). Yes Cache is a factor but other than that those machines support identical Disk and I/O configurations, including number of arms, speed of arms, speed of IOPS. Nonetheless I personally am NOT accusing IBM of cheating in any way. My comments were intended to SUPPORT different speed machines built with standardized componants. The suggestion of NoOps was just one way that seemed to be consistant with results seen 'at the track'. If IBM accomplishes the same thing by adjusting cache size, memory size, IOP throughput, or cooling fan speed for that matter, is of little consequence as I see it. In any case that is MY last word on the matter. - Larry Alexei Pytel wrote: > > OK, last try... > Last week I tried to show that "system performance" is a misunderstood > concept. > Now let's have a look at "CPU performance". CPU is not an isolated > component. It's complex entity in itself, which consists of lots of > circuitry inside, L1 cache inside, L2 cache outside, main storage outside, > interconnection between registers and caches of different level, between > caches and memory etc etc > Next, different code has different characteristics - locality of reference, > working set size, pipeline affinity etc etc. > Next. don't forget also that you do not write code in chip instruction set. > Before your source code becomes executable it is worked on by compiler and > translator. Modern RISC chips rely very heavily on compiler technology - > to fill pipeline, to schedule instructions etc etc. > > Raw chip Mhz rating tells you nothing - if it were, then 1Ghz Pentium would > be the king of processors once and for all - simpy because it has highest > clock rate. > > Next, do not think that CPU chip with a certain Mhz clock rate should work > with the same speed in all circumstances with any code - this is a wrong > assumption. > > Apache and Northstar are based on the same architecture, but they are > inherently different processors - they have different pipelines, different > instruction scheduling, different this, different that... > > What I am arguing against, is your sweeping statement, that 200Mhz chip > should run twice as fast as 100Mhz chip and if this does not happen, then > something dark is under way. > > Should your test run twice as fast on 200Mhz NorthStar then on 100Mhz > Apache ? - I don't know. Maybe yes, maybe not. > Your observations are interesting - it would be interesting to speculate > why this could happen. As a matter of fact, I offered you some suggestions > last week... > Nothing in your observations is an evidence of tampering with CPU. > > Alexei Pytel -- Larry Bolhuis | Cogito ergo mercari iSeries Arbor Solutions, Inc. | (616) 451-2500 | (I think, therefore I buy iSeries.) (616) 451-2571 -fax | lbolhuis@arbsol.com | #3 1951-2001 +--- | 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.