seanf@sco.COM (Sean Fagan) (05/25/90)
In article <MEISSNER.90May23162522@curley.osf.org> meissner@osf.org (Michael Meissner) writes: >But this is all invisable at the user level. The new mode is in >kernel space. As long as you treat all pointers as 32-bit quanities, So a user can't do something like movl (0xabcddead),r0 since that specifies a 32-bit immediate (or "offset") address, which will not work on a 32016. >there is no problem unless you have an executable that has data >sections linked at addresses > 16M, or your program dynamically needs >more than 16M. Oh. So a user program *isn't* backwards compatible. Which is it? -- -----------------+ Sean Eric Fagan | "It's a pity the universe doesn't use [a] segmented seanf@sco.COM | architecture with a protected mode." uunet!sco!seanf | -- Rich Cook, _Wizard's Bane_ (408) 458-1422 | Any opinions expressed are my own, not my employers'.
peter@ficc.ferranti.com (Peter da Silva) (05/26/90)
In article <6363@scolex.sco.COM> seanf@sco.COM (Sean Fagan) writes: > In article <MEISSNER.90May23162522@curley.osf.org> meissner@osf.org (Michael Meissner) writes: > >But this is all invisable at the user level. The new mode is in > >kernel space. As long as you treat all pointers as 32-bit quanities, > So a user can't do something like > movl (0xabcddead),r0 You're usually a pretty cool dude, Sean. Why are you suddenly going into hair-splitting mode here? In practical terms, machines like the 68000 and the 32000 are compatible across the board. There's no compelling reason to use the new instructions, because you get nearly as good performance without them. Outside of the O/S itself, you really can't tell the difference. The 80x86 is a whole different ball of wax, because earlier processors are emulated rather than being a subset of the new one. Running old code instead of recompiling causes severe performance degradation. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.ferranti.com> 'U` Have you hugged your wolf today? <peter@sugar.hackercorp.com> @FIN Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.
bzs@world.std.com (Barry Shein) (05/26/90)
Re: Sun/386i
As I remember what a lot of folks who complained about the 386i as not
being "snappy" really meant was that the WINDOW SYSTEM seemed sluggish.
It's obvious why that affects people's impressions of the whole
machine.
The problem with the window stuff was that just about everything went
thru a layer to byte-swap as the 386 had a different byte-order than
the 68k (and SPARC for that matter.) Rather than change the upper
layers of the window system (#ifdef BYTESWAP) the swapping was
inserted down below. I assume that was a time to market decision (I'm
being coy, I don't "assume", I know for a fact...)
Overall I thought it was a pretty good machine, sort of a rolls-royce
of the 386 world. Pricey (tho not horribly so, $18K-ish fully
configured with 8MB, cache, 300MB, 1Kx1K color etc), but also loaded
with features.
The real problem with the machine was with people who had no
particular use for a '386 but just bought it as a variation on a
workstation, perhaps moving from a '286 thinking they were venturing
into safer territory. When they looked at the Sparcstation (or other
company's RISCs) several months later they wished they had bought one
of those.
If you didn't have a specific need for its ability to run DOS
applications and attach AT boards then the real value was lost on you.
For a 386, at the time, Sun's Unix was light years ahead of other 386
Unix systems. Particularly in networking.
A lot of them were sold, e.g., into Wall Street running the Quotron
real-time ticker system and replacing a half-dozen monitors on desks
with point and click windows. For applications like that little
price/performance arguments were irrelevant, they had a job to do and
this system did that job, quite well as I've heard it.
--
-Barry Shein
Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLDian@sibyl.eleceng.ua.OZ (Ian Dall) (05/27/90)
In article <3383@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>}So, you don't think that the Sun 386i is a workstation? Why not? >> >>My only (limited) play on a Sun 386i gave me the impression it wasn't >>very snappy. > >At least the one time I ran the Stanford benchmarks on a 386i and a >3/280, the 386i (25 MhZ, I think, same as the 3/280's '020), the integer >benchmarks were of competitive speed (at least until you turned on the >"global" optimizer, which Sun's 68K compiler has and Sun's 386 compiler >doesn't) Raises an interesting point. Mightn't the 386 lack of (many) registers limit the potential gains from a global optimiser? >So the CPUs didn't seem too far off, from that one test. Well, I have heard other people say the same (it benchmarks OK). I was commenting on how it (very subjectively) "felt". Someone has said that this was due to SunView being particularly slow. Be that as it may, one might expect that the manufacturers (Sun) would have put some effort into making their most visible piece of software reasonably efficient on the 386i if they wanted to sell many 386i's. >>Add to that supposedly user friendly system management >>stuff Sun added for the 386 version of SunOs and I don't think I will >>ever order one! > >The only thing that has to do with the 386 is that the 386 was stuck in >there to grab PC users, as was a lot of the SNAP/plug-n-pray/etc. stuff; >this doesn't mean that the x86 architecture was the direct cause of that >stuff. Fair point (that the x86 architecture is not to blame for the system administration cruft), but it still contributes to the feeling that this is an up jumped pc and not a serious machine. Sure, a 386 machine will blow away a Sun 1, 2 and be competitive with many Sun 3's on cpu benchmarks, but these are yesteryears workstations. I guess my definition (and the markets) of a workstation has changed with the times. In my case it has changed to always exclude the current x86 machine! I think it is the duty of every knowledgable person to give Adam whatsisname's hand a little nudge in the right direction when we can. If x86 machines had any significant *advantages* I might have a harder decision, but if things are much of a muchness I will got for elegance everytime. People that design elegantly deserve encouragement! -- Ian Dall life (n). A sexually transmitted disease which afflicts some people more severely than others.
) (05/27/90)
In article <BZS.90May25201518@world.std.com> bzs@world.std.com (Barry Shein) writes: >The problem with the window stuff was that just about everything went >thru a layer to byte-swap as the 386 had a different byte-order than >the 68k (and SPARC for that matter.) Not really. Only things which start out in big-endian bit order (fonts, icons, rasterfiles) get swapped, and they only get swapped once. In normal use very little time is spent in the byte/bit-swapping code. If you look at MIPS and memory bandwidth, a 386 class CPU driving a 1 Mb dumb frame buffer is pretty marginal. You have to tune the window system code very carefully to get snappy interactive performance, and this was never done for SunView on the 386i. -- David DiGiacomo, Sun Microsystems, Mt. View, CA david@eng.sun.com
mccalpin@vax1.acs.udel.EDU (John D Mccalpin) (05/27/90)
In article <136288@sun.Eng.Sun.COM> david@eng.sun.com (You'll feel good about yourself!) writes: >If you look at MIPS and memory bandwidth, a 386 class CPU driving a 1 Mb >dumb frame buffer is pretty marginal. You have to tune the window system >code very carefully to get snappy interactive performance, and this was >never done for SunView on the 386i. >-- >David DiGiacomo, Sun Microsystems, Mt. View, CA david@eng.sun.com Two related comments: (1) The NeXT machine is a pretty snappy UNIX(tm) box when running from a dumb terminal. Of course, its response at the console is well known as being less satisfying. I have not played much with the local 386i, but it is much quicker remotely than on the console. (2) My primary machine has a 20 MHz R-3000 CPU --- about 17 VAX MIPS. I can use up to 60% of the cpu cycles just by moving the mouse quickly back and forth between two windows! I certainly would not want to run that same software on a 3 MIPS cpu! -- John D. McCalpin mccalpin@vax1.udel.edu Assistant Professor mccalpin@delocn.udel.edu College of Marine Studies, U. Del. mccalpin@scri1.scri.fsu.edu
seanf@sco.COM (Sean Fagan) (05/28/90)
In article <C0P32J9@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <6363@scolex.sco.COM> seanf@sco.COM (Sean Fagan) writes: >> In article <MEISSNER.90May23162522@curley.osf.org> meissner@osf.org (Michael Meissner) writes: >> >But this is all invisable at the user level. The new mode is in >> >kernel space. As long as you treat all pointers as 32-bit quanities, >> So a user can't do something like >> movl (0xabcddead),r0 >You're usually a pretty cool dude, Sean. Thank you. 8-) >Why are you suddenly going into >hair-splitting mode here? In practical terms, machines like the 68000 and >the 32000 are compatible across the board. Practically, yes. And so are the 68ks. *However*: if I were writing an assembler for the 32532, and wanted to do it quickly, and not worry overmuch about memory overhead, I would do all addresses as 32-bit absolute (or 31-bit relative, whatever). The code thus generated would *not* run on a 32016, but *would* run in user mode on a '532. An incompatability caused by NS's original design. (Personally, I don't really think it's a problem. But since the goal of usenet is to split hairs, ... 8-)) >The 80x86 is a whole different ball of wax, because earlier processors >are emulated rather than being a subset of the new one. Running old code >instead of recompiling causes severe performance degradation. Hair-splitting time *again* 8-): the 80286 is not emulated on a '386. That is, the processor executs the instructions directly, and has a 16-bit mode on it's ALU (so I've been lead to believe. I think only intel knows for sure). Otherwise, a 32-bit add would be quicker than a 16-bit add, and it's not. (However, it *can* be argued that, if the 16-bit mode were not there, the 32-bit add *would* be faster. Depends on how the chip was designed.) And, of course, old code *can* run on the *86 processors. You don't have to recompile. You don't get the new features, that's true, but I really don't know of any processor that you *do* (other than, more address bits but that was more due to a limitation of the original processor [i.e., the 68k had 32-bit address registers, but only 24 of them mattered] than to a superiority in the method). -- -----------------+ Sean Eric Fagan | "It's a pity the universe doesn't use [a] segmented seanf@sco.COM | architecture with a protected mode." uunet!sco!seanf | -- Rich Cook, _Wizard's Bane_ (408) 458-1422 | Any opinions expressed are my own, not my employers'.
jesup@cbmvax.commodore.com (Randell Jesup) (05/28/90)
In article <6537@vax1.acs.udel.EDU> mccalpin@vax1.udel.edu (John D Mccalpin) writes: >(1) The NeXT machine is a pretty snappy UNIX(tm) box when running from > a dumb terminal. Of course, its response at the console is well known > as being less satisfying. ... >(2) My primary machine has a 20 MHz R-3000 CPU --- about 17 VAX MIPS. > I can use up to 60% of the cpu cycles just by moving the mouse > quickly back and forth between two windows! I certainly would not > want to run that same software on a 3 MIPS cpu! The motto of the programmers of the world: "Get us 5 more VUPS, and we'll eat them for breakfast and ask for more!" God, 60% of a 17 VUPS machine? I knew Unix window systems were mostly horrible hogs, but that's ridiculous. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
basti@orthogo.UUCP (Sebastian Wangnick) (05/29/90)
alvitar@xavax.com (Phillip Harbison) writes: >In article <21440@megaron.cs.arizona.edu> druschel@cs.arizona.edu (Peter >Druschel) writes: >> In article <634@sibyl.eleceng.ua.OZ> ian@sibyl.OZ (Ian Dall) writes: >> > Part of *my* definition of a workstation >> > is that it doesn't have a 80x86 as a cpu (only 1/2 :-). When at last we got OSF/Motif for our Apollo DN3500, I ported my application from our 386 to it as soon as possible. But alas, when I ran the application on my X-Terminal, the 386 was faster! Some benchmarking with the BYTE code from comp.sources.unix proved that indeed this 386-PC (33 MHz, 64KB RAM cache) outperformed the Apollo workstation: Dhrystones with registers [1/s]: 4250 5348 Arithmetic with int [s]: 12.1 3.0 Arithmetic with double [s]: 60 464 Filesystem read [KB/s] 173 327 Execl [s]: 4.4 1.3 Sort and other Unix utilities, 8 processes [s]: 50.3 10.5 Now, I have been praising workstations and damning PC's a long time. But this last bench, which approximates my daily requirements best, scattered my prejudices to pieces. Sebastian Wangnick (basti@orthogo.uucp)
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (05/29/90)
In article <639@sibyl.eleceng.ua.OZ> ian@sibyl.OZ (Ian Dall) writes: | If x86 machines had any | significant *advantages* I might have a harder decision, but if things | are much of a muchness I will got for elegance everytime. People that | design elegantly deserve encouragement! In the real world there is a major advantage: MS-DOS software can be run. And ecconomics cares not one whit for o/s elegance, there is a lot of good software for MS-DOS, and it cost s less than UNIX software (which may be hurting the growth of UNIX). And for people who want to develop in a reasonable environment and then have software that runs in MS-DOS where the unit sales are, this becomes highly important. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Stupidity, like virtue, is its own reward" -me
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (05/29/90)
In article <11876@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: | God, 60% of a 17 VUPS machine? I knew Unix window systems were mostly | horrible hogs, but that's ridiculous. On *any* unloaded system the window manager is going to use a lot of CPU. It doesn't reflect any inherent problem. The window system on the unix-pc is nicely responsive on an unloaded system, and it runs on a 68010, with barely a single MIP to its name. unix windows don't HAVE to take a lot of CPU. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Stupidity, like virtue, is its own reward" -me
rpeglar@csinc.UUCP (Rob Peglar) (05/29/90)
In article <6537@vax1.acs.udel.EDU>, mccalpin@vax1.acs.udel.EDU (John D Mccalpin) writes: > In article <136288@sun.Eng.Sun.COM> david@eng.sun.com (You'll feel good about yourself!) writes: > >If you look at MIPS and memory bandwidth, a 386 class CPU driving a 1 Mb > >dumb frame buffer is pretty marginal. You have to tune the window system > >code very carefully to get snappy interactive performance, and this was > >never done for SunView on the 386i. > >-- > >David DiGiacomo, Sun Microsystems, Mt. View, CA david@eng.sun.com > > Two related comments: > (1) The NeXT machine is a pretty snappy UNIX(tm) box when running from > a dumb terminal. Of course, its response at the console is well known > as being less satisfying. > I have not played much with the local 386i, but it is much quicker In a previous life, I used - it sat in my office - a Sun 386i/250. This machine had cache (I forget now, how much - 16KB, maybe?) and 8MB RAM. Used stand-alone, I found the windowing system (SunView) just fine, no problem, with the cg3 (again, I think) monitor. Today, I have access to a Sun 386i/150 - no cache. It is *very* slow with SunView. I cannot complain (much) with X11R4 on it. Even X11R3 is ok, from a "seat-of-the-pants" evaluation. Moral? The Sun386i, not unlike many other machines, comes in different flavors. Your mileage will vary. However, the apples-to-apples (well, at least fruit-to-fruit) comparison betweeen SunView and X11R4 on the same box is at least somewhat valid, IMHO. SunView and its ilk are rapidly moving up on the "pain-in-the-A" scale, compared to a public (kinda) windowing/protocol/behavior system like X. Submoral - if you really want SunView and snappy windowing, get a 386i/250. Forget the 386i/150. (n.b., discussion limited to 386i's, no comments on 4's or other boxes, please.) Rob -- Rob Peglar Comtrol Corp. 2675 Patton Rd., St. Paul MN 55113 A Control Systems Company (800) 926-6876 ...uunet!csinc!rpeglar
rcd@ico.isc.com (Dick Dunn) (05/30/90)
david@eng.sun.com writes: > If you look at MIPS and memory bandwidth, a 386 class CPU driving a 1 Mb > dumb frame buffer is pretty marginal. You have to tune the window system > code very carefully to get snappy interactive performance, and this was > never done for SunView on the 386i. The experience of the folks working on X at Interactive seems to be quite the opposite: If you've got a dumb frame buffer, the limiting factor is the video memory speed. This was certainly true for both the Sigma Laserview and the Cornerstone Video Controllers. I worked on the Corner- stone server. In tuning it, I quickly found that after the obvious stuff (a few days worth), what mattered was anything that would minimize the number of accesses to video memory. Remember that a dumb frame buffer is not just a hunk of memory; it's a hunk of *dual-ported* memory, and the bandwidth appetite of a high-res fast-refresh display is enormous (by the standards of such machines). Most of the memory's bandwidth goes into feeding the display; the CPU gets the leftovers. Given that, it's not too hard to drive it to capacity with a 386. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Simpler is better.
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (05/30/90)
In article <212@csinc.UUCP> rpeglar@csinc.UUCP (Rob Peglar) writes: | Submoral - if you really want SunView and snappy windowing, get a | 386i/250. Forget the 386i/150. (n.b., discussion limited to 386i's, | no comments on 4's or other boxes, please.) Sun announced a 486i last year, but we couldn't get delivery by year end. Has anyone actually seen the beast? -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Stupidity, like virtue, is its own reward" -me
lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) (05/31/90)
In article <768@orthogo.UUCP> basti@orthogo.UUCP (Sebastian Wangnick) writes: >Some benchmarking with the BYTE code from comp.sources.unix >proved that indeed this 386-PC (33 MHz, 64KB RAM cache) >outperformed the Apollo workstation: >Dhrystones with registers [1/s]: 4250 5348 >Arithmetic with int [s]: 12.1 3.0 >Arithmetic with double [s]: 60 464 >Filesystem read [KB/s] 173 327 >Execl [s]: 4.4 1.3 >Sort and other Unix utilities, > 8 processes [s]: 50.3 10.5 >Now, I have been praising workstations and damning PC's a long time. >But this last bench, which approximates my daily requirements best, >scattered my prejudices to pieces. You didn't say _which_ Apollo, or anything about its memory/cache/ disk/IO-load, so it's difficult to draw conclusions from your experience. From the Dhrystones, I'd guess it contains a 68020, which is older technology than the 386. Personally, I would be happy to describe ANY workstation containing a 386 (or 68020), as a workstation. And, of course, non-workstations containing 386s (or 68020s) aren't workstations. -- Don D.C.Lindsay Carnegie Mellon Computer Science
pa1@tdatirv.UUCP (Pat Alvarado) (05/31/90)
In article <2268@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: >In article <212@csinc.UUCP> rpeglar@csinc.UUCP (Rob Peglar) writes: > >| Submoral - if you really want SunView and snappy windowing, get a >| 386i/250. Forget the 386i/150. (n.b., discussion limited to 386i's, >| no comments on 4's or other boxes, please.) > > Sun announced a 486i last year, but we couldn't get delivery by year >end. Has anyone actually seen the beast? >-- >bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) > "Stupidity, like virtue, is its own reward" -me My understanding is that the 486i is actually an upgrade processor board to replace in a 386i. I don't believe that Sun intended to manufacture an actual workstation. Perhaps someone from Sun may comment on this. YYY Pat Alvarado YYY Teradata Corporation YYY Product Development v 12945 Jefferson Blvd. #2187 Y Y Los Angeles, Calif. 90066 YYY YYY Phone: (213) 302-6104 YYY YYY FAX: (213) 305-9746 YYY YYY E-Mail: tdat!pa1@suntzu.sun.com disclaimer: My comments do not reflect the philosophy or beliefs of Teradata Corp.
paul@taniwha.UUCP (Paul Campbell) (05/31/90)
In article <1990May30.041648.9063@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >number of accesses to video memory. Remember that a dumb frame buffer is >not just a hunk of memory; it's a hunk of *dual-ported* memory, and the >bandwidth appetite of a high-res fast-refresh display is enormous (by the >standards of such machines). Most of the memory's bandwidth goes into >feeding the display; the CPU gets the leftovers. Given that, it's not too >hard to drive it to capacity with a 386. It depends on the display design - remember on an AT class machine video designers are 'stingy' (ie they are in cut-throat price competition) and don't use VRAM (like for Mac and other high-end workstation displays), VRAMs steal about 2% of the bandwidth. Also lots of the PC systems have 16-bit buses, meaning you have to do twice as many bus cycles to get the same amount of work done .... Paul -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P Number of US citizens with 2 or more homes: 3 Million Number of US citizens with no home: 1 Million
david@eng.sun.com (6. Do you resent the efforts of others to tell you what to do?) (06/01/90)
In article <1990May30.041648.9063@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >david@eng.sun.com writes: >> If you look at MIPS and memory bandwidth, a 386 class CPU driving a 1 Mb >> dumb frame buffer is pretty marginal. You have to tune the window system >> code very carefully to get snappy interactive performance, and this was >> never done for SunView on the 386i. >The experience of the folks working on X at Interactive seems to be quite >the opposite: If you've got a dumb frame buffer, the limiting factor is >the video memory speed. That's because they're working with DRAM frame buffers on a slow PC bus. The Sun-386i in question has a well designed VRAM frame buffer on a fast bus. Under these conditions it's hard to write code which will allow the 386 to saturate the buffer buffer (especially when you want to write it in C and you don't have a very good C compiler). I should also have mentioned that SunView performance improved quite a bit from the initial 386i release ("4.0.0") to 4.0.1 to 4.0.2. >Remember that a dumb frame buffer is >not just a hunk of memory; it's a hunk of *dual-ported* memory... Ever hear of VRAMs? -- David DiGiacomo, Sun Microsystems, Mt. View, CA david@eng.sun.com
jon@hitachi.uucp (Jon Ryshpan) (06/13/90)
In article <2264@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: >In article <11876@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: > >| God, 60% of a 17 VUPS machine? I knew Unix window systems were mostly >| horrible hogs, but that's ridiculous. Here's a fragment of "ps -ef" on a compaq Deskpro-386/33 running Interactive Unix X-windows (X version 11.3) on a 640x480 VGA screen. In 9 hours of moderately busy operation the X server - Xvga - has used 6-1/2 minutes of CPU, about 1%. Performance is essentially instantaneous; infinite CPU power wouldn't produce visible improvement. Performance on a 20 mhz machine with an 800x600 screen is very OK, but isn't as fast as it could possibly be. $ ps -ef ... jon 10318 10317 24 09:56:01 vt03 6:36 Xvga :0 ... $ date Tue Jun 12 19:14:13 PDT 1990 Jonathan Ryshpan <...!uunet!hitachi!jon>
bitbug@vicom.com (James Buster) (06/14/90)
In article <2264@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: >In article <11876@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: > >| God, 60% of a 17 VUPS machine? I knew Unix window systems were mostly >| horrible hogs, but that's ridiculous. Much of the problem with the Sun 386i isn't the window system, it's the frame buffer and disk I/O. On CPU-bound programs it was reasonably competitive with the SPARC and Motorola machines, but the 386i was saddled with a very slow frame buffer and slow disks. This is just as good a way to guarantee the death of a machine as anything. Indeed, to be speculative about this, Sun had to make the 386i a slow machine in order to spur sales of SPARC-based machines. -- --------------------------------------------------------------------- James Buster (Domain) bitbug@vicom.com Mad Hacker Extraordinaire (UUCP) ...!ames!vsi1!bitbug ---------------------------------------------------------------------
dujihara@grapevine.EBay.Sun.COM (Daniel D. Ujihara ext. 33452) (06/14/90)
In article <1990Jun13.194117.16722@vicom.com>, bitbug@vicom.com (James Buster) writes: > Much of the problem with the Sun 386i isn't the window system, it's the frame > buffer and disk I/O. On CPU-bound programs it was reasonably competitive with > the SPARC and Motorola machines, but the 386i was saddled with a very slow > frame buffer and slow disks. This is just as good a way to guarantee the death > of a machine as anything. Indeed, to be speculative about this, Sun had to make > the 386i a slow machine in order to spur sales of SPARC-based machines. > -- James, I will have to take issue with your posting. The framebuffer on the 386i is reasonable, it is the window system that needed tuning. The window system on the 680X0 machines had years to be tuned. That window system was ported to the 386i and needed to be tuned all over again. All you have to do is look at an X implementation that is not biased toward the 680X0 byte order to see the difference. As for the disks, would you like to put an SMD controller or a IPI controller in a low cost machine? Wouldn't make it low cost would it? In any case, you seemed to like the 386i that you used at Sun well enough. Dare I say that you have a case of sour grapes considering where you are posting from now? Daniel D. Ujihara, Sun Microsystems Federal, dujihara@sun.COM Of course, my opinions are my own.
wayne@dsndata.uucp (Wayne Schlitt) (06/14/90)
> God, 60% of a 17 VUPS machine? I knew Unix window systems were mostly > horrible hogs, but that's ridiculous. things like windowing systems will tend to use up all available cpu cycles no matter how fast your computer is. when you move your mouse, you need to erase the old cursor, draw a new one, check to see if it has crossed a window boundary and such. the more cpu cycles you have the more often you can perform these things and the smoother your window system will appear. you can make a window system on a 10Mhz 68000 respond quick enough that no one really cares that it is skipping a lot of pixels when you are moving the puck quickly. there _is_ a limit to how much cpu a window system will use, but it takes a lot of horse power to redraw the cursor on _every_ pixel as you move the puck very quickly across the screen. sure, you could add code to limit how often you redraw the cursor, but what's the point? -wayne
rwallace@vax1.tcd.ie (07/16/90)
In article <770@orthogo.UUCP>, basti@orthogo.UUCP (Sebastian Wangnick) writes: > lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes: > > >>In article <768@orthogo.UUCP> basti@orthogo.UUCP (Sebastian Wangnick) writes: >>>Some benchmarking with the BYTE code from comp.sources.unix >>>proved that indeed this 386-PC (33 MHz, 64KB RAM cache) >>>outperformed the Apollo workstation: I suspect what you actually did was to prove your MS-DOS C compiler does better optimization than the Apollo C compiler. MS-DOS has some of the best optimizing C compilers in the world. Russell Wallace, Trinity College, Dublin rwallace@vax1.tcd.ie "To summarize the summary of the summary: people are a problem"