jb10320@uxa.cso.uiuc.edu (Desdinova) (01/05/91)
In what will almost certainly be a futile attempt to end the counter-productive discussions downplaying $1.00 6502s to $1,000 RISC chips, I submit the following information. Two machines, pitted against each other. Apple IIgs, Transwarp (7MHz) 386 Clone, 33MHz The test- the Dhrystone, a program designed to test the ability of a machine to execute basic tasks (branches, comparisons, math). The results- IIgs 650 Dhrystones 386 10000 Dhrystones Now, this looks pretty bad, doesn't it? I mean, one can get a 386 machine for a little over twice the cost of a GS system, and look at the performance difference! But, remember one thing- the 386 has hardware multiply and divide- two of the most often executed instructions in the Dhrystone. This makes 2 * 2 on the 386 about 20-30 (roughly) times faster than the equivalent operation on a 65816 (measured in clock cycles). But the 386 only pulls a Dhrystone 13 times faster than the GS- when it should be getting upwards of 100 times that! (20 times faster math, 5 times faster clock). I'm sticking with my '816, thank you very much. For it's price and simplicity, it's a damned good chip. Give me a 25MHz '816 any day over a 33 MHz 386- sure, the '386 will still be faster at the basics, but then again, the rest of the PC/AT hardware design is VERY limiting for such a processor. Which is one reason why Windows is so bloody slow. A '386 inside of a PC box is, simply put, unimpressive. (The Unix box I'm using right now uses 6 '386s, and they crank! But they're still Intel-designed chips- ewewewew) Now we come to assembly vs. C. Someone who chooses to program in C because "it's easier to program in C" is full of it. Assembly language is EASY to program in, especially on machines line the '816 that were (sort of) designed to be programmed in assembly. With good enough macro libraries, there's almost no reason NOT to program in assembly. Sure you have to plan a little better (because you can be totally free-form), but you can also optimize the hell out of it. Now- C's not all bad. In fact, I'm releasing my TelCom program to show that REAL, USABLE applications can be written in C on the GS. GScii is another example of a program written in a HLL that performs well- and it will even better once a few choice routines are rewritten in assembly. And here we come to the heart of the matter- on the Apple II, people are still willing to write in assembly. In the rest of the world, programmers have become lazy. AutoCad for the IBM will soon stop supporting '286s entirely- becuase the program is too 'complex' to run at good speed. In actuality, the programmers are too lazy to write assembly code to speed up critical sections. Well, I've ragged in a national forum long enough. My point? Just that you get what you pay for, and considering everything, the GS is not that bad a deal. -- Jawaid Bazyar | Being is Mathematics Senior/Computer Engineering | Love is Chemistry jb10320@uxa.cso.uiuc.edu | Sex is Physics Apple II Forever! | Babies are engineering
rhyde@ucrmath.ucr.edu (randy hyde) (01/05/91)
>> Apple II GS 7Mhz 650 Dhrystones >> 386 33Mhz 10000 Dhrystones Did you write all this in "C"? Even I would expect a 7Mhz '816 to run a little faster than ~1/18th the speed of a 33 Mhz 386. If this is in "C", I'm sure the STRCMP and STRCPY functions were carefully crafted in assembly to optimize Dhrystone ratings, vs. ORCA/C where those routines were probably written in "C". If this is a legitimate measurement, I would suspect that ORCA/C is even worse than I thought it was or your code is blowing the cache on your transwarp and the '816 is running slower than 7 Mhz as a result. BTW, over in comp.sys.nsc.32k there's someone who used to work for National Semi who had a few comments about the Dhrystone Benchmark. Carefully crafting routines like STRCMP, STRCPY, and other in assembly he was able to get the chip to exceed 30,000 Dhrystones. Considering that it produces about 8,000 Dhyrstones @ 25 Mhz using GCC this is a rather impressive achivement (he did not, however, rewrite the entire program in assembly). I would like to see some reasonable benchmarks around here comparing a 1Mhz 6502 against a 4.77 Mhz 8088. Alas, I wouldn't even know if I could locate a 4.77 Mhz machine myself these days. Maybe there is one hidden around at UCR I could find. Only some real, substantial benchmarks will shut everyone up on these subject (or, at least, it will refocus the argument on the quality of the benchmark!). >> 2*2 on the 386 about 20-30 times faster... Not if you use ASL vs. SHL! Perhaps you should pick a better pair of numbers to multiply. I sure hope, if you're actually multiplying by a power of two, that your "C" compilers pick up on this and (on the 816) convert it to the appropriate shift instructions! >> Give me a 25Mhz '816 over a 33 Mhz '386 any day. Assuming zero wait states, I'd go along with this. Question is, will we ever really see such a beast? Better yet, give me a 65c832 or even a 65032 at 20-25Mhz. Alas, by the time such a chip exists, Intel will probably have given us 100 Mhz 586 or 686 chips. Of course, the big problem with all of these fast chips is "where are we going to get the high speed memory to go along with them?" >>>>>>> Now we come to assembly vs. C. Someone who chooses to program in C because "it's easier to program in C" is full of it. Assembly language is EASY to program in, especially on machines line the '816 that were (sort of) designed to be programmed in assembly. <<<<<<< >> full of it.. I couldn't agree more. Our wonderful University system and compiler vendors have grossly overstated the advantages of HLLs and "C" in particular. >> designed to be programmed in assembly. Yes and no. Certainly the '816 has a poor architecture for supporing HLLs and the original intent of the chip was for video games and controller applications. I don't think the designer (Bill Mensch), however, went out of his way to make it easy to write assembly code for the '816. Those M & X bits are a big source of trouble in complex programs. >>>>> And here we come to the heart of the matter- on the Apple II, people are still willing to write in assembly. In the rest of the world, programmers have become lazy. <<<<< True. Alas, Apple II people who are willing to writing in assembly are a dying breed. Long gone are the days that someone would learn assembly so they could get rich writing a video game for an Apple II. It's much easier to write in C on a PC, and the market is about 100 times larger, so guess what? They won't bother. It would be nice if there was a really good C for the GS that was reasonably compatible with PC C compilers so we could entice some of those people to port their stuff to the GS. >>>>>> My point? Just that you get what you pay for, and considering everything, the GS is not that bad a deal. <<<<<< If you're willing to accept the "limitations" of the GS, it is a good deal. Alas, most people don't need the need things the GS has to offer (good sound, built in networking, toolkit in ROM, etc.) They need a specific solution to a problem. Alas, except in the educational market, low end word processing and spreadsheet, and other small niches, the GS doesn't solve too many people's problems cost effectively. I would hate to have the GS as my only machine. I would also hate not to have a GS at all. >>>>> Well, I've ragged in a national forum long enough. <<<<< Hey, that's why I'm paying outrageous amounts of income taxes. Rag all you want, I'll pay more :-). *** Randy Hyde
jb10320@uxa.cso.uiuc.edu (Desdinova) (01/05/91)
In article <10904@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >>> Apple II GS 7Mhz 650 Dhrystones >>> 386 33Mhz 10000 Dhrystones > >Did you write all this in "C"? Even I would expect a 7Mhz '816 >to run a little faster than ~1/18th the speed of a 33 Mhz 386. >If this is in "C", I'm sure the STRCMP and STRCPY functions were >carefully crafted in assembly to optimize Dhrystone ratings, vs. >ORCA/C where those routines were probably written in "C". >If this is a legitimate measurement, I would suspect that ORCA/C >is even worse than I thought it was or your code is blowing the >cache on your transwarp and the '816 is running slower than 7 Mhz >as a result. Really? Wow. Okay, I'll check out the source, optimize STRCMP and STRCPY (after looking at the library, of course), and re-run it. If they can play games so can I. The 10000 number was quoted to me by a '386-owner I know. I didn't think about Orca being THAT bad (the test was with optimization on, whoopdedoo), but perhaps so. I'll experiment and see what I can come up with. >I would like to see some reasonable benchmarks around here comparing >a 1Mhz 6502 against a 4.77 Mhz 8088. Alas, I wouldn't even know if >I could locate a 4.77 Mhz machine myself these days. Maybe there is >one hidden around at UCR I could find. Only some real, substantial >benchmarks will shut everyone up on these subject (or, at least, it >will refocus the argument on the quality of the benchmark!). > >>> 2*2 on the 386 about 20-30 times faster... >Not if you use ASL vs. SHL! Perhaps you should pick a better pair of [..] That was a bad example. I meant to signify the concept of multiplication, for which the '386 has microcode and the '816 has "Integer Math Toolset". Integer Math is a sloth. The bottleneck is in there and the C library routines. Our Dhrystone tests came as a result of our desire to have a way to base comparisons of various souped-up IIgs's. >>> Give me a 25Mhz '816 over a 33 Mhz '386 any day. >Assuming zero wait states, I'd go along with this. Question is, will we >ever really see such a beast? Better yet, give me a 65c832 or even a >65032 at 20-25Mhz. Alas, by the time such a chip exists, Intel will >probably have given us 100 Mhz 586 or 686 chips. Of course, the big >problem with all of these fast chips is "where are we going to get the >high speed memory to go along with them?" Intel marketing has for a couple years now promised things they can't deliver (or deliver quite late). I suspect that 100MHz is a pipe dream and that there's really no sound engineering reason to strain the already creaking design of the 'x86 series further. Perhaps more support hardware on-chip, but not a lot more. >>> designed to be programmed in assembly. >Yes and no. Certainly the '816 has a poor architecture for supporing HLLs >and the original intent of the chip was for video games and controller >applications. I don't think the designer (Bill Mensch), however, went >out of his way to make it easy to write assembly code for the '816. >Those M & X bits are a big source of trouble in complex programs. True, but then I avoid them completely and use the macros SHORT and LONG. And I also avoid using them by doing such things as Bad Good -------- ------ short m lda location lda location and #$ff long m And sticking in 16-bit mode. Takes less time, actually, to do it WITHOUT switching in 8-bit mode. For doing I/O stuff, sure it can be a pain, but then GS/OS and the tools are provided so you don't have to fuss with it. It's funny you should mention video games as a target market- the new 16-bit Nintendo machine will use the '816. Ain't that nice? It'd be cool to run GS/OS thru my NES. What apple needs to do is make an NES compatible IIgs. They'd sell BILLIONS of the things. >True. Alas, Apple II people who are willing to writing in assembly are >a dying breed. I have to disagree with this. I program in assembly and I know many others who do (not exclusively of course- best language for the job), and I'm beginning to think RISC/HLL 'supported' CPUs are a divergence from where CS should be going. Long gone are the days that someone would learn assembly >so they could get rich writing a video game for an Apple II. It's >much easier to write in C on a PC, and the market is about 100 times >larger, so guess what? They won't bother. It would be nice if there was >a really good C for the GS that was reasonably compatible with PC C compilers >so we could entice some of those people to port their stuff to the GS. I'd prefer a Unix-compatible C compiler, but that's a personal preference. And, I really could care less that my GS doesn't have a million bad games ported to it. We get some of the best ones, simply because it's a hell of an effort that doesn't pay back well to program them. Re: Immortal, Rastan, Arkanoid, etc... >I would hate to have the GS as my only machine. >I would also hate not to have a GS at all. Beautiful. >*** Randy Hyde -- Jawaid Bazyar | Being is Mathematics Senior/Computer Engineering | Love is Chemistry jb10320@uxa.cso.uiuc.edu | Sex is Physics Apple II Forever! | Babies are engineering
rhyde@ucrmath.ucr.edu (randy hyde) (01/07/91)
>>> The new 16-bit Nintendo will use an '816...
They're already ahead of you! The current Nintendo uses an '816!
*** Randy Hydewjbaird@dahlia.uwaterloo.ca (Warren Baird) (01/07/91)
In article <1991Jan5.014646.26135@ux1.cso.uiuc.edu> jb10320@uxa.cso.uiuc.edu (Desdinova) writes: > >Now we come to assembly vs. C. Someone who chooses to program in C because >"it's easier to program in C" is full of it. Assembly language is EASY >to program in, especially on machines line the '816 that were (sort of) >designed to be programmed in assembly. With good enough macro libraries, >there's almost no reason NOT to program in assembly. Sure you have to plan >a little better (because you can be totally free-form), but you can also >optimize the hell out of it. I agree completely with your opinion of the relationship between 386 chips and the 816... However I don't agree with your discusion of C vs. assembly... Assembly may be _easy_ to program in (I haven't done much assembly, but from what I've seen this may be true), but it's non-portable... It's also a bit of a dead end in the real (read Unix) world... If I write a program for the Sun 3 that I used at work, and half or all of it is in assembly, I'm out of luck if I want to move it to any other Unix machine (probably even other 68020 based machines, but I don't know enough about 020 assembly to guarentee that...). It may work REALLY fast, but I've cut out a HUGE section of my possible user base, or I need to recode the assembly stuff for each possible architecture, something that would take thousands of extra person-hours. There is also the consideration of which is more useful in the job market... If I go to an interview for a computer job, and I tell the interviewer that I can't program C, but that I can program 65816 assembly... I'd probably not get the job... If I walk in and say that I can program in C, I think I'd have a FAR better chance at getting the job... C gives you all of the functionality and power of assembler, but it also provides the flexibility and portability of a HLL (more so than many HLLs, in fact...) I agree that for a job that is TOTALLY speed-dependant, assembly is a better choice... but for most "real-world" applications, I think that C with a GOOD optimizing compiler (and maybe a few essential routines in assembly...) is a far better solution. > >Now- C's not all bad. In fact, I'm releasing my TelCom program to show that >REAL, USABLE applications can be written in C on the GS. GScii is another >example of a program written in a HLL that performs well- and it will even >better once a few choice routines are rewritten in assembly. I'm interested in seeing Telcom... > >And here we come to the heart of the matter- on the Apple II, people are >still willing to write in assembly. In the rest of the world, programmers >have become lazy. AutoCad for the IBM will soon stop supporting '286s >entirely- becuase the program is too 'complex' to run at good speed. >In actuality, the programmers are too lazy to write assembly code to speed >up critical sections. I don't like IBM's being referred to as "the rest of the world..." There are a lot of IBM PC compatibles out there, but I believe that they have reached (or are near reaching) the peak of their power and usability... I think (and hope) that in the reasonable future, the X86 family's ugly architecture will catch up with it, and the IBM PC will (finally) die out... > >Well, I've ragged in a national forum long enough. Me too... > >My point? Just that you get what you pay for, and considering everything, >the GS is not that bad a deal. I agree TOTALLY with this point, but I'm begining to feel the pressure of Apple's lack of support... I'm actually starting to wish that I had bought an Amiga instead... I really like my GS, but it's being used now mainly as a terminal, a word processor, and as a games machine... An Amiga would be as effective for the first two, and has more software available for the last... > > >-- >Jawaid Bazyar | Being is Mathematics >Senior/Computer Engineering | Love is Chemistry >jb10320@uxa.cso.uiuc.edu | Sex is Physics > Apple II Forever! | Babies are engineering -- Warren Baird, 2A Co-op Math Computer Science, U(Waterloo) wjbaird@dahlia.uwaterloo.ca ...utzoo!watmath.uwaterloo.edu!dahlia!wjbaird An elephant is a mouse with an operating system...
ifar355@ccwf.cc.utexas.edu (David H. Huang) (01/07/91)
In article <10914@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >>>> The new 16-bit Nintendo will use an '816... > >They're already ahead of you! The current Nintendo uses an '816! >*** Randy Hyde Hmmm... I remember reading that it uses the 65c(?)02. -- David Huang | Internet: ifar355@ccwf.cc.utexas.edu | "My ganglion is stuck in UUCP: ...!ut-emx!ccwf.cc.utexas.edu!ifar355 | a piece of chewing gum!" America Online: DrWho29 |
sysadmin@pnet91.cts.com (Matthew Montano) (01/08/91)
ifar355@ccwf.cc.utexas.edu (David H. Huang) writes: >In article <10914@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >>>>> The new 16-bit Nintendo will use an '816... >> >>They're already ahead of you! The current Nintendo uses an '816! >>*** Randy Hyde > >Hmmm... I remember reading that it uses the 65c(?)02. > Do you think Nintendo with it's manufacturing prowess in simply units sold is going to be buying 65(c)02 chips from GTE, Western Design Centre or Rockwell? I have a very limited understanding of the manufacturing process of chips, and the legal ramifications of it all, but I'll place my bets that Nintendo is producing their own physically cusomtized version of the 6502.. Over 50 million Nintendo units in the US alone?.. Someone did their marketing right.. Matthew --- Email: sysadmin@pnet91.cts.com (most mailers won't barf on that..) My comments aren't even worth a disclaimer... pnet91 - 416-237-{1204|0308}. 2400bps only. 1200bps if you do hard breaks.
gwyn@smoke.brl.mil (Doug Gwyn) (01/11/91)
In article <10904@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >Now we come to assembly vs. C. Someone who chooses to program in C because >"it's easier to program in C" is full of it. Assembly language is EASY >to program in, especially on machines line the '816 that were (sort of) >designed to be programmed in assembly. But it truly is easier to develop reliable applications in C, particularly when they are massive. When you add transportability to the picture, the balance tips so far in the direction of C that assembly language simply is not justified for the production of generally useful applications that are potential candidates for porting to (or from) other platforms. Only for the single-machine-forever hobbyist would a substantial amount of use of assembly language be the most effective use of programmer time. >>> full of it.. >I couldn't agree more. Our wonderful University system and compiler vendors >have grossly overstated the advantages of HLLs and "C" in particular. Undoubtedly American universities are rife with incompetent instructors and vendors are self-serving; however, as a professional programmer with over 25 years of computing experience, who has used dozens of languages including many radically assembly languages on a large number of quite distinct architectures and operating systems, I must say (along with many other practicing professionals) that software development in C is far superior in almost every way to development in assembler. The only thing assembler has going for it is direct access to baroque machine-dependent instructions, such as IO port access opcodes, and occasional use when a bottleneck really demands hyperoptimization. (For the IIGS, this would for example include the "blit" aspect of updateing the graphics display.) Of course, when implementing an operating system or HLL run-time support system, a certain amount of assembler is normally required; however, the bulk of systems implementation is much better performed using a systems implementation language (notably C) than in assembler. >And here we come to the heart of the matter- on the Apple II, people are >still willing to write in assembly. In the rest of the world, programmers >have become lazy. It's not a matter of laziness, but of effective use of one's limited lifespan. When I can produce (AND MAINTAIN, an important point) dozens of applications for use on a wide variety of systems using a HLL in the same time that I could produce fewer, less maintainable applcations on a single platform, what would you think I ought to choose? There is no point in being macho.
joeq@pro-odyssey.cts.com (Joe Quilici) (01/12/91)
In-Reply-To: message from rhyde@ucrmath.ucr.edu
> They're already ahead of you! The current Nintendo uses an '816!
No it doesn't, the Nintendo is not a 16 bit machine, I believe it uses a
custom microprocessor.
----
ProLine: joeq@pro-odyssey
Internet: joeq@pro-odyssey.cts.com
UUCP: crash!pro-odyssey!joeq
ARPA: crash!pro-odyssey!joeq@nosc.milrmk@frog.UUCP (Rick Kelly) (01/23/91)
In article <6852@crash.cts.com> joeq@pro-odyssey.cts.com (Joe Quilici) writes: >In-Reply-To: message from rhyde@ucrmath.ucr.edu >> They're already ahead of you! The current Nintendo uses an '816! >No it doesn't, the Nintendo is not a 16 bit machine, I believe it uses a >custom microprocessor. Actually, the Nintendo uses a custom chip that executes 6502 instructions. There are an awful lot of arcade machines out there using the 6502. Rick Kelly rmk@frog.UUCP rmk@rmkhome.UUCP frog!rmkhome!rmk
kreme@isis.cs.du.edu (Fred Zeats IV) (01/28/91)
In article <22977@frog.UUCP> rmk@frog.UUCP (Rick Kelly) writes: >In article <6852@crash.cts.com> joeq@pro-odyssey.cts.com (Joe Quilici) writes: >>In-Reply-To: message from rhyde@ucrmath.ucr.edu > >>> They're already ahead of you! The current Nintendo uses an '816! > >>No it doesn't, the Nintendo is not a 16 bit machine, I believe it uses a >>custom microprocessor. HOWEVER, I do believe that the new nintendo (Famico, whatever) which is rumored to be ready for release 3rd quarter of '91 [to coincide with SMB IV] uses a 68C816. -- | kreme@nyx.cs.du.edu |Growing up leads to growing old, and then to dying, and| |---------------------|dying to me don't sound like all that much fun. | | I said, I TRIPPED! - Opus |