cs225ax@ux1.cso.uiuc.edu (02/08/90)
If the new IIgs is at 9Mhz with the 640x480 mode, it's a serious choice
for people who are considering going to a Mac. The 9Mhz 65C816 is as fast as
a ~20Mhz Mac, and the graphics would be better res-wise, worse color-wise,
and it would be a heck of a lot cheaper to go for the new IIgs than the
Mac or other computer.
I think a 6Mhz IIgs might be a bit slow, but a 9Mhz machine would be
quit a bit faster than any '286 machines I've seen, and faster than pre-ci
Mac IIs. That's assuming the rest of the gs can keep up with the 9Mhz. I
would think that this is a large step for the gs if you mix in the graphics.
I, personally, have been moved out of the "saving up for a Mac" syndrome
in anticipation of this new machine. If it only turns out to be a 6Mhz,
640x400 machine, a lot of third parties will be open to make some money on
speed-up devices. If there's a upgrade path (which I seem to doubt) I'd
buy the machine instantly, e.g. tomorrow (today, if it weren't past closing
time :-)
If Apple is supporting and upgrading the machine, IT'S NOT DEAD! Sheesh,
people should look at the real reality: the gs is selling, it's getting
better, there's no sign of it dying, and there are one hell of a lot of people
interested in the machine, e.g. Beagle Bros, Claris, Apple people on the net,
along with the dozens of responders to this subject alone!
Scott back there had a bit emotional but true response to everyone who
thinks the gs is dying: buy another computer and get out. It's your loss.
Ken.
_____________________________________________________________________________
{= InterNet =} ken-b@uiuc.edu {= Kenneth R. Brownfield =}
{= BITNET =} free0361@uiucvmd.bitnet {= University of Illinois, UC =}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ruzun@pro-sol.cts.com (Roger Uzun) (02/09/90)
In-Reply-To: message from cs225ax@ux1.cso.uiuc.edu
>>a 9 Mhz gs should be faster than any pre iici mac II
Well in my experience with the 65816 and the 68000, the 65816 is slightly
faster than a similar clocked 68000, that is an 8Mhz 65816 will perform,
in most applications slightly better than an 8Mhz 68000. BUT for some
applications the 68000 is MUCH faster. Lichty and Eyes in their
book on 65816 programming, indicate that an 8Mhz 65816 would be slower than an
8Mhz 68000 for an optimized sieve bench, which they concede is a good test
of processor performance. The 68020 in my experience performs at 3-4 times
the speed of a similar clocked 68000. The mac II at 15.2 Mhz or so, really
has the processing power of a 30-40 Mhz 65816. The mac iix uses a 68030, but
the system board is really not designed to take advantage of it. In my
experience with native 68030 based designs, the 68030 performs at about 1.5
times the level of the same clock speed 68020.
I do not see how anyone can think that a 9 Mhz 65816 machine can perform as
well as a 15 mhz 68020, it cannot. People who write apple // software are
often talented assembly language programmers, and most 680X0 stuff is in C, so
many people have an inflated idea of the chips capabilites, you apple guys are
lucky in one way, you have the benefit of a lot of effiecient and tightly
coded assembly language applications. But facts are facts, you need a lot
more than a 9 Mhz 65816 to equal a Mac II's processing power.
I use a 28 Mhz 68030 system 1 wait state burst mode enabled, here are some
C language benchmarks from this system,
sieve 100 iterations of the 1st 1900 primes - 1.9 secs
savage 25000 iterations - 2.0 secs
dhrystones - 12,500
whetstones - 2,000,000
-Rogerrnf@shumv1.uucp (Rick Fincher) (02/10/90)
In article <16475.apple.net@pro-sol> ruzun@pro-sol.cts.com (Roger Uzun) writes: >In-Reply-To: message from cs225ax@ux1.cso.uiuc.edu > stuff deleted >coded assembly language applications. But facts are facts, you need a lot >more than a 9 Mhz 65816 to equal a Mac II's processing power. >I use a 28 Mhz 68030 system 1 wait state burst mode enabled, here are some >C language benchmarks from this system, >sieve 100 iterations of the 1st 1900 primes - 1.9 secs >savage 25000 iterations - 2.0 secs >dhrystones - 12,500 >whetstones - 2,000,000 > >-Roger Roger, You are correct but you should also remember that the 68881/68882 helps a lot on the numeric stuff. Send me the C code for the above benchmarks and I'll run them with the FPE in my GS with a 7 mhz transwarp and post the results for comparison. As a very rough rule of thumb would you say a 65816 computes at about half the speed of a similarly clocked 68030? Rick Fincher rnf@shumv1.ncsu.edu
shankar@SRC.Honeywell.COM (Subash Shankar) (02/11/90)
In article <16475.apple.net@pro-sol> ruzun@pro-sol.cts.com (Roger Uzun) writes: >Well in my experience with the 65816 and the 68000, the 65816 is slightly >faster than a similar clocked 68000, that is an 8Mhz 65816 will perform, >in most applications slightly better than an 8Mhz 68000. I don't agree, since I think the difference is more significant for most non-number-crunching applications - maybe 2.5 times as fast or so. My 7 MHz TWGS runs circles around the 8 MHz 68000 in the Mac Plus when doing typical desktop junk, like opening and closing windows. The difference is even more significant if you consider the slow video memory and the fact that the TWGS uses cache. > BUT for some applications the 68000 is MUCH faster. True. Like number crunching. See below. >Lichty and Eyes in their >book on 65816 programming, indicate that an 8Mhz 65816 would be slower than an >8Mhz 68000 for an optimized sieve bench, But the sieve benchmark uses multiplication heavily, which is one of the things that the 65816 is worst at (I guess non-existence of a multiply opcode qualifies to be rated badly in multiplies). > ...which they concede is a good test of processor performance. Let them post on comp.arch and watch the flames! >I do not see how anyone can think that a 9 Mhz 65816 machine can perform as >well as a 15 mhz 68020, it cannot. Agreed. Just overenthusiastic 65XXX'ers here. --- Subash Shankar Honeywell Systems & Research Center MN65-2100 voice: (612) 782 7558 US Snail: 3660 Technology Dr., Minneapolis, MN 55418 shankar@src.honeywell.com srcsip!shankar
ruzun@pro-sol.cts.com (Roger Uzun) (02/12/90)
In-Reply-To: message from rnf@shumv1.uucp As a general rule I would say that the 65816 will compute at 1/4th to 1/3rd times the speed of the same clocked 68030. -Roger
gsnow@pro-freedom.cts.com (Gary Snow) (02/13/90)
In-Reply-To: message from ruzun@pro-sol.cts.com > As a general rule I would say that the 65816 will compute at 1/4th to 1/3rd > times the speed of the same clocked 68030. I would really be interested in what you base this on....... Gary _______________________________________________________________________________ UUCP: crash!pnet01!pro-freedom!gsnow | ProLine: gsnow@pro-freedom | Pro-Freedom: (206)253-9389 ARPANet: crash!pnet01!pro-freedom!gsnow@nosc.mil | Vancouver, Wa InterNet: gsnow@pro-freedom.cts.com | _______________________________________________________________________________
ruzun@pro-sol.cts.com (Roger Uzun) (02/14/90)
In-Reply-To: message from gsnow@pro-freedom.cts.com I base the 65816 running at 1/3 to 1/4 the speed of a similar clocked 68030 on ACTUAL BENCHMARKS. for example the following standard C benchmarks 1) Sieve 100 iterations of 1st 1900 primes as per byte mag = 2 secs 2) qsort from byte magazine = 4 secs 3) dhyrystone 1 = 12,500 dhrystones/sec 4) savage 25,000 iterations - 2 secs These are all on a 28 Mhz 68030 system. Compare to the 65816 values. -Roger
mmunz@pro-beagle.cts.com (Mark Munz) (02/16/90)
In-Reply-To: message from ruzun@pro-sol.cts.com When doing benchmarks, it is also VERY important to consider the C COMPILER.. Also, the 680x0 was designed to let higher level languages take better advantage of the CPU.. with say Link and Unlink commands. So, if you want to compare the 65816 with the 680x0, do it at the same level -- Assembly. An assembly comparison would be a much more accurate comparison. Mark Munz
lmb7421@ultb.isc.rit.edu (Les Barstow: Phoenix) (02/16/90)
I don't think we're being fair here - C compilers for the 68000 series are very well developed and ironed out for optimization. However, the GS C compilers have not yet been written for speed - I seem to remember a comparison done back when the GS came out, all code written in Assembly for both machines, and the GS did rather well... Comparing a 2.5 MHz GS to an 8MHz Mac, the GS actually won the Sieve race, came close in others, and managed to hold some ground on the rest... Remember, the average 65816 cycles/instruction is ~5, while the minimum cycles/instruction on a 68000 series is ~4 (and goes up steeply from there in increments of 2 or 4 cycles (can't remember which, just remember seing instructions which took over 20 cycles to execute)...) Don't under-estimate the power of the 65816 - even though it lacks some instructions (notably MUL and DIV) and some other features (multitudinous registers), but it is also more efficient and has some unique features of its own (direct page, fast increments, etc...) -- Les Barstow |RIT - A citadel of gleaming brick towering over a snowy swamp SunSinger |Money - That which pays the bills. A dream never remembered. Phoenix rising...+------------------------------------------------------------- LMB7421@ritvax.bitnet | lmb7421@ultb.isc.rit.edu |...rochester!rit!ultb!lmb7421
c60a-3hu@e260-1g.berkeley.edu (Calvin Cheng) (02/18/90)
In article <2228@ultb.isc.rit.edu> lmb7421@ultb.isc.rit.edu (Les Barstow: Phoenix) writes: >I don't think we're being fair here - C compilers for the 68000 series >are very well developed and ironed out for optimization. However, the >GS C compilers have not yet been written for speed - I seem to remember >a comparison done back when the GS came out, all code written in >Assembly for both machines, and the GS did rather well... Compilers are what u need to use for most software developments. It doesn't make sense to compare assembled programs because assem- blers are just not practical unless under demanding situations. One main reason why the Mac is slower than MS-DOS machines in benchmarks is because Mac compilers are less developed than MS-DOS compilers but it's a fact that everybody has to live with. The most important fact is we are not comparing the raw processors here. > >Comparing a 2.5 MHz GS to an 8MHz Mac, the GS actually won the Sieve >race, came close in others, and managed to hold some ground on the >rest... Remember, the average 65816 cycles/instruction is ~5, while the >minimum cycles/instruction on a 68000 series is ~4 (and goes up steeply >from there in increments of 2 or 4 cycles (can't remember which, just >remember seing instructions which took over 20 cycles to execute)...) 65816 takes 3 cycles to read a 16-bit word, the 68000/010 4 cycles and the 68020/030 3 cycles for a 32-bit long word. The 030 has a special burst fill mode that takes in 4 32-bit long words in 5 cycles! This is not implemented on the IIcx and SE/30 but on the IIci. On top of that, the 030 comes with data and code caches of 32 32-bit long words each. The overlapping of instruction execution is such that instructions can take *0 cycles* to execute. The 68040 is typically 3 to 4 times the speed of the 030 at the same clock rate. While people are still trying to confirm the presence of a 20Mhz 816 (and the IIGS has the 2.8Mhz one), the maximum clock rate for the 030 is now at 50Mhz. > >Don't under-estimate the power of the 65816 - even though it lacks some >instructions (notably MUL and DIV) and some other features >(multitudinous registers), but it is also more efficient and has some >unique features of its own (direct page, fast increments, etc...) > Neither the 680x0 nor the 658xx families are true RISC chips. It'll be interesting to watch for the next generation (68040 and 65832). A 68040 Mac (and NeXT) will probably make the debut by the end of the year. But for now the fast-increments is equivalent to the ADDQ and SUBQ on the 680x0 (with the choice of more data registers), the direct page, a bigger but more limited version of the 680x0's 8 data and 8 address registers. My Dhrystone timings on APW C and THINK C: APple IIGS w/o Transwarp 162/sec Apple IIGS w Transwarp 274/sec Mac Plus 854/sec Mac SE 1035/sec Mac SE/30 4300/sec Timings I didn't do: Apple IIe 60/sec Accorn Archimedes 5100/sec NeXT 5800/sec DEC Vax 11/780 mini 2100/sec Typical 25Mhz 386-clone 7000+/sec By the way, Sieve under THINK C on my SE/30 takes abt 3.9s for 100 iterations It takes about 56s under Orca/Pascal and almost 70 to 90s for APW C.
gwyn@smoke.BRL.MIL (Doug Gwyn) (02/18/90)
In article <2228@ultb.isc.rit.edu> lmb7421@ultb.isc.rit.edu (Les Barstow: Phoenix) writes: >I don't think we're being fair here - C compilers for the 68000 series >are very well developed and ironed out for optimization. However, the >GS C compilers have not yet been written for speed - I seem to remember >a comparison done back when the GS came out, all code written in >Assembly for both machines, and the GS did rather well... It doesn't much matter what is achievable in assembly language when one writes his applications in higher-level languages, as is generally recommended practice. ORCA/C does perform numerous optimizations if you ask it to (by default it doesn't perform any). The problem with the 65816 is that it doesn't have enough general-purpose registers to permit the degree of optimization that for instance the 68000 does. Its addressing modes are also not very orthogonal to the instruction set, which also reduces opportunity for optimization. Finally, it has very weak support for large programs due to the page-oriented architecture; this too forces inefficiencies. >Remember, the average 65816 cycles/instruction is ~5, ... And RISC architectures generally achieve more in a single cycle or two.
ruzun@pro-sol.cts.com (Roger Uzun) (02/18/90)
In-Reply-To: message from mmunz@pro-beagle.cts.com > Mark Munz suggests comparing the 65816 to the 680X0 using assembler > and not C compiler Well in ways this makes sense, but if you want to use C as a development environment, best check the system with a C compiler. if you want to develop in assembler, use assembly to benchmark the systems. Writing applications in C makes porting them to other systems easier. With a decent processor and a decent C compiler, the //gs would have a lot more support from developers, in my opinion. -Roger
ruzun@pro-sol.cts.com (Roger Uzun) (02/19/90)
In-Reply-To: message from c60a-3hu@e260-1g.berkeley.edu Interesting, looks like I way overestimated the relative performance of a 65816 vs a 68030. The Apple IIGS w/transwarp gets 274 drystones/sec My 28 Mhz 68030 w/ BURST and CACHE enabled, and an optimizing C compiler gets 12,500 drystones/sec/ ALso looks like 100 iterations of sieve, which take 2 seconds on my 28 Mhz 030 system, take 56 to 90 seconds on a //gs depending on compiler. Apple really needs to do something about the //gs performance under C. -R@oger