Jan,
At 4:50 PM +0000 9/4/03, olympus-digest wrote:
>Date: Wed, 3 Sep 2003 21:20:34 -0700
>From: Jan Steinman <Jan@xxxxxxxxxxxxxx>
>Subject: [OM] Re: Macs vs PCs; 16-bit apps (was Re: an Albert intervention)
>
> >From: Joe Gwinn <joegwinn@xxxxxxxxxxx>
> >
> >>What are 16 bit apps? Apple users have never had to deal with such things
> >>-- all Mac programs were always 32 bit.
> >
> >Yes and no. While the 68000 family of CPUs had 32-bit addressing from the
> >start, the memory busses were 16 bit, so moving a 32-bit word (address or
> >data) took two bus cycles. Many programs used 16-bit data items, to reduce
> >memory demand.
>
>I guess my point was that whether any given program used 16 bit quantities or
>32 bit quantities was completely transparent to the end user. The 80x86 of the
>day had a segmented architecture, which required messy mode changes between 16
>bit and 32 bit ops, but on the 680x0, 16/32 bit ops were completely regular --
>they just had to be on an even 16 bit boundary.
True. Actually, any 16-bit boundary would work, even or odd. Or by "even" did
you mean "exact"?
>There is no reason a so-called "16 bit" Mac app would not run on the 64 bit
>G5, correct?
Mostly true, although this is mostly a tribute to the quality of the 68040
emulator software that runs on PowerPC Macs. The PowerPC hardware cannot run
680x0 code directly, as the instruction sets are wildly different.
> >The arrival of universal hardware floating-point is changing this, as FP is
> >far easier on the programmers.
>
>But still relatively expensive, compared to integer math!
Not so much so any more. It's a matter of what market a processor is intended
to serve. If that market demands floating point, then the chip designers will
spend a larger part of the transistor budget of the FP arithmetic hardware, and
will achieve better relative performance.
> >I did have a lot of fun when computer salesmen from major vendors tried to
> >convince me that my code would run faster on their brand new 64-bit
> >computers, because such computers could "do twice as much work as a 32-bit
> >computer". I replied that the air traffic control code of interest here was
> >originally 16-bit code, and still was, whatever the word size of the new
> >platforms, so those new 64-bit words would only be 1/4 full.
>
>Ah, but have you checked out the G5 architecture white paper? It does
>extensive pipelining and branch prediction, and can work on multiple
>instructions at a time, even if the original programmer had no intention of
>multi-processing.
Not to be difficult, and the G5 is a wonderful computer, but I hardly ever read
such papers, because all such papers look and sound the same, and I couldn't
tell a good design from a bad design by reading such a paper anyway. Nor can
computer design engineers that write such papers tell the difference either,
unless they have a fairly precise idea of the exact kinds of programs the
computer will be expected to do well on and can run detailed trace-driven
simulations.
I only believe in benchmarks using the programs that I will use. Nothing else
matters.
>If your memory bandwidth is four times bigger, it should run even 16 bit
>programs approaching four times faster.
>
> >Actually, with modern computers, the memory system speed is more important
> >than the CPU speed.
>
>Exactly! And the new Mac G5 has a 128 bit memory bus that can hit 6.4
>gigabytes per second! That's nearly four times as fast as the nearest desktop
>competitor.
>
>I'm counting the days... it should be here by the end of next week...
So, the new machines will be four times faster than anything else on the
market? I would tend to doubt this. Or, rather, doubt that such an advantage
would long endure. Computer design is a leapfrog game. Good for us, but a bit
hard on the computer vendors.
That said, the G5 does sound hot. There is an Apple ad comparing the
dual-processor 2-GHz PowerMac G5 with the fastest Xeon and Pentium boxes
available. The ad I am quoting is on the inside front cover of the September
2003 issue of IEEE Spectrum, but I've seen it many other places. I bet the
data is at www.apple.com too.
Integer calculations (SPECint_rate2000): The PPC G5 equals a 3.06-GHz dual-CPU
Xeon, and is 1.6 times as fast as a single-CPU 3-GHz Pentium 4.
Floating-point calculations (SPECfp_rate2000): The PPC G5 is 1.5 times as fast
as a 3.06-GHz dual-CPU Xeon, and is 2.0 times as fast as a single-CPU 3-GHz
Pentium 4.
Right away, we see that a 2-GHz G5 has the same integer performance as a 3-GHz
Xeon, both with dual processors, so the G5 gets 1.5 times as much work done per
clock cycle. Last year, the ratio was closer to 2:1.
The reason that the floating point performance of the Xeon is so much worse
than its integer performance is simply a statement of intended market. The
Xeon spent less of its transistor budget on FP than the G5.
However, I would not buy a computer that came out a week ago. Too much risk of
design or manufacturing flaws. Better to wait until it's been on the market
for at least six months, with nine to twelve months being better, and the user
magazines have had a chance to test it, and people have posted their
experiences on the newsgroups.
>Obligatory Olympus content: I spent the money I was going to spend on an E-1
>on a dual G5 and Cinema Display instead. My five-year-old G4 was starting to
>feel a bit slow working on 1.5 GB drum scans... :-)
You're way ahead of me on this. Nothing I work on is anywhere near that large,
even a tenth that large. Nevermind.... I need to invent a reason why I need a
dual-CPU G5. Enabler!
Obligatory OM content. One advantage of continuing to use the same camera and
system for thirty years is that all the money one saves on cameras can be spent
on other toys. And digital cameras seem to need replacement every two or three
years, just like computers.
Joe Gwinn
< This message was delivered via the Olympus Mailing List >
< For questions, mailto:owner-olympus@xxxxxxxxxxxxxxx >
< Web Page: http://Zuiko.sls.bc.ca/swright/olympuslist.html >
|