ed@iitmax.IIT.EDU (Ed Federmeyer) (04/24/89)
I don't really have much of an opportunity to use OS/2 or AmigaDOS, but I
couldn't help but wonder how different the two opperating systems are?
I don't understand why OS/2 uses 3 Mb of RAM (I think I read that somewhere) to be usefull, while with AmigaDOS you only need 256 Kb. What does OS/2 give
you that AmigaDOS doesn't? After all, they both multitask, have graphics
based interfaces, etc... Is it maybe because the 68000 assembly language
is more compact than 80286 or 80386?
Please E-mail an answer to this, unless you really think everyone else
would like to know... Heck it might make an interesting discussion...
Thanks
Ed Federmeyer
ed@iitmax.iit.edu <- Hard to get through to.
sysed@iitVax.bitnet <- Works everytime, so far!bmacintyre@watcgl.waterloo.edu (Blair MacIntyre) (04/27/89)
In article <2134@iitmax.IIT.EDU> ed@iitmax.IIT.EDU (Ed Federmeyer) writes: > >I don't really have much of an opportunity to use OS/2 or AmigaDOS, but I >couldn't help but wonder how different the two opperating systems are? Very different, actually. What I know of OS/2 is limited and based on discussions I have had with a friend that works for IBM ( and he looks so intelligent, too!:-) AmigaDOS (Exec, actually) gives you a nice, small light-weight OS. It has one paradigm for intertask communications (Send-Receive-Reply) which is (IMHO) more than sufficient and, indeed, the best method available so far. It is small and consistent (generally speaking) OS/2 gives you ... everything. Picture an OS designed by committee. Pick your favourite, perhaps extremely esoteric, OS primitive and there is a 99% chance it is in there somewhere! 1/2 :-) The standard processes are VERY heavy-weight, but they provide you with a variety of lightweigth threads, etc. The impression I get is that any of the popular, or unpopular, methods of communication are in there: SRR, monitors, rendevous, etc. It also has memory protection because ... it has Virtual Memory. That's about all I can dredge up from my feeble memory ... comments? Take all this with a half-ton grain of salt! >I don't understand why OS/2 uses 3 Mb of RAM (I think I read that somewhere) to be usefull, while with AmigaDOS you only need 256 Kb. What does OS/2 give >you that AmigaDOS doesn't? After all, they both multitask, have graphics >based interfaces, etc... Is it maybe because the 68000 assembly language >is more compact than 80286 or 80386? No, that's not it ... see above! It basically has more too it! Of course, as my friend put it (mostly jokingly :-) "It sells memory!!!!"
darin@nova.laic.uucp (Darin Johnson) (04/28/89)
In article <2134@iitmax.IIT.EDU> ed@iitmax.IIT.EDU (Ed Federmeyer) writes: >I don't understand why OS/2 uses 3 Mb of RAM (I think I read that somewhere) to be usefull, while with AmigaDOS you only need 256 Kb. What does OS/2 give >you that AmigaDOS doesn't? After all, they both multitask, have graphics >based interfaces, etc... Is it maybe because the 68000 assembly language >is more compact than 80286 or 80386? Oh ho! You think you can trip us up with this thinly veiled flame-war trap... Well it won't work this tim.. urk, arg... Ahhh! OS/2 could be made to work with smaller amount of memory, except that it has doesn't use shared libraries. This means that every program that does graphics links in everything except the low level kernel stuff. Also, OS/2 has to be somewhat compatible with MS-DOS (or they won't sell very well). If designed from scratch, I'm sure that the enormous amount of people who developed it could have come up with something decent. Heck, with 386's becoming so common, it would blow 386-based UNIXes out of the water if done right. Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) We now return you to your regularly scheduled program.
ejkst@cisunx.UUCP (Eric J. Kennedy) (04/28/89)
In article <2134@iitmax.IIT.EDU> ed@iitmax.IIT.EDU (Ed Federmeyer) writes: >I don't really have much of an opportunity to use OS/2 or AmigaDOS, but I >couldn't help but wonder how different the two opperating systems are? I was in a Computerland the other day, and I tried to use a model 50 running OS/2. It booted, and the first thing I typed *Crashed* the machine. I know, OS/2 isn't supposed to crash. But it did. First time I ever touched OS/2, too. I'll stick with my Amiga. I've crashed PC's, Amigas, Ataris, Macintoshes, etc., but I don't recall something ever crashing quite so quickly. -- Eric Kennedy ejkst@cisunx.UUCP
griff@intelob.intel.com (Richard Griffith) (04/28/89)
In article <9412@watcgl.waterloo.edu> bmacintyre@watcgl.waterloo.edu (Blair MacIntyre) writes: > No, that's not it ... see above! > > It basically has more too it! Of course, as my friend put it (mostly > jokingly :-) "It sells memory!!!!" ^^^^^^^ I wouldn't be too sure about "joking" here.... It seems that `round about the time OS/2 was supposed to be delivered, MicroSoft had completed the OS, handed it off to IBM for their "Seal of Approval" - The OS ran, was relatively compact, quite nice. IBM said - Rewrite it, it isn't structured. As you and I both know, the one thing in software that is most difficult to write structured is an OS, not impossible, but difficult. And it tends to grow. ALOT! Now I ask you - What does IBM sell? Do they sell software? or hardware? Obviously the latter (in the PC market). So it is not quite the joke - IBM, together with MicroSoft is hoodwinking all those people who sank their business bucks into the PC into thinking they absolutely HAVE to buy 4 megs of memory to run "the new standard for Operating Systems" - I have to hand it to them - it's quite a scam. Now - for us Amigaphiles to cut into their pie, all that is really needed is to show the business people the following: 1) I (Putting on my Businessperson hat) can translate *all* my precious data to a format that Amiga can use. Documents, data bases, and (Most importantly, since this is how my "Business" keeps track of how to pay me :-) my Spreadsheets. 2) The Operating system and Filing system are solid and robust. 3) The I/O routines are *fast*, supporting 5 1/4" (being able to read "IBM format" as an option), 3 1/2", HD of every size, and Tapes. CD read/write is a plus. 4) My secretary can easily use any software I buy. (Classes are OK) 5) Last, but not least, It has to be CHEAP! Cheaper than upgrading to OS/2. (That's not so hard, remember - we're not talking just memory here - OS/2's Presentation Manager *requires* VGA graphics have you priced a Multisync monitor lately??) (Whew! Sorry about the long post, but like many Amiga lovers, any mention of the Stupidity of upgrading any PC to OS/2 drives me into the "Will you *LOOK* at what your doing, you idiot?!?!?", you know, the kind of reaction you have when someone sticks a screwdriver into a big power panel that's still turned on....:-) OS/2 - Half an Operating System for TWICE the price! - griff -- * Richard E. Griffith * Cyrus Hammerhand * * "griff" * Household of the Golden Wolf * * BiiN, Hillsboro Ore. * Dragons' Mist * * UUCP: ...[!uunet]!tektronix!biin!griff * An Tir * ************************************************************************** * These are MY opinions, if BiiN wanted them, They'd pay for `em! *
richard@gryphon.COM (Richard Sexton) (04/28/89)
Oh good. I was afraid nobody was going to post an operating systems comparison/flame war without setting the Followup-to: field this year. I'd almost lost my faith in human nature. What will happen next. Two reasoned replies will follow, and then sombody who feels their ox has been gored will flame away causing 80 to 100 flames to be posted in a discussion that will last for 7 weeks, but will not completely die down for 12 weeks. Take it to comp.sys.misc. Take it to alt.flame, take to junk. Hell, take it OUSTIDE and drown it. And note that the appropriate use of Followup-to: fields set correctly in the header works wonders. Hrrrmphf. -- "My latest 'problem', btw, is that I'm working out an opportunity to get laid with some girl over the net." - Ted Kaldis richard@gryphon.COM decwrl!gryphon!richard gryphon!richard@elroy.jpl.NASA.GOV
cmcmanis%pepper@Sun.COM (Chuck McManis) (04/29/89)
In article <2134@iitmax.IIT.EDU> ed@iitmax.IIT.EDU (Ed Federmeyer) writes: > I don't really have much of an opportunity to use OS/2 or AmigaDOS, but I > couldn't help but wonder how different the two opperating systems are? About as different as you'd expect given the design criteria and the hardware. The similarities arise from the fact that when you ask the same question, generally you get a similar answer. > I don't understand why OS/2 uses 3 Mb of RAM (I think I read that > somewhere) to be usefull, while with AmigaDOS you only need 256 Kb. To correct your thinking, the recommendation is that if you are using Extended Addition OS/2 with Presentation Manager you need 6Mb. And on the Amiga you only need 256K of RAM, but you put the O/S mostly in 256K of ROM. And that is/was awfully tight. You really want 1Mb of RAM (still with the 256K of ROM) to be comfortable. > What does OS/2 give you that AmigaDOS doesn't? After all, they both > multitask, have graphics based interfaces, etc... Is it maybe because > the 68000 assembly language is more compact than 80286 or 80386? Good question, bad answer. For one, OS/2 gives you a full MS-DOS emulator. Sure, you can buy one for the Amiga but it makes running Amiga programs at the same time impossible. That can take a meg right there. Also OS/2 offers interprocess memory protection which the Amiga doesn't (no MMU on the 68000 based models) and that certainly makes the Kernel a bit more complicated. Also OS/2 is under a lot of time pressure and written nearly entirely in C rather than assembler. The combination has the same effect it has on UNIX (eg lots of code expansion). The compactness question never enters into the picture. >Please E-mail an answer to this, unless you really think everyone else >would like to know... Heck it might make an interesting discussion... Actually, it could make for a boring flame fest. I've tried to get out the facts early to prevent same, but since there are already a boatload of messages in comp.sys.amiga I'm probably too late. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "A most excellent barbarian ... Genghis Kahn!"
griffith@hplchm.HP.COM (Jeff Griffith) (04/29/89)
I've recently started some serious examinations of OS/2 at work, and AmigaDOS at home. The two systems are quite different. Amiga does provides only two forms of process control; you can spawn a new TASK (which I've gotten to work yet), or you can EXEC a new process (via the equivalent of Un*x "system()"). As for IPC, AmigaDOS provides process mailboxes, semaphores, and signals; shared memory is possible (does AmigaDOS implement protected memory?). Also, the Amiga "Intuition" provides some of the basic windowing features of OS/2 Presentation Manager. On the other hand, OS/2 combines the RMX notions of tasks (in the form of threads with the child thread either sharing the parent's memory or having its own) with the Unix notions of processes and IPC; quite well done it appears. Personally, I think there is a good match of price/performance between these two; last time I looked (and I could be wrong by now), a ready-to-run OS/2 system cost about twice the price of a ready to run Amiga; but you get twice the system from the OS/2 box. Personally, I don't need the extra horsepower just yet. Jeff Griffith
bcw@rti.UUCP (Bruce Wright) (04/29/89)
In article <2134@iitmax.IIT.EDU>, ed@iitmax.IIT.EDU (Ed Federmeyer) writes: > > I don't really have much of an opportunity to use OS/2 or AmigaDOS, but I > couldn't help but wonder how different the two opperating systems are? > > I don't understand why OS/2 uses 3 Mb of RAM (I think I read that somewhere) to be usefull, while with AmigaDOS you only need 256 Kb. What does OS/2 give > you that AmigaDOS doesn't? After all, they both multitask, have graphics > based interfaces, etc... Is it maybe because the 68000 assembly language > is more compact than 80286 or 80386? It really isn't any mystery why OS/2 is so enormous. Oversimplifying outrageously, the reasons are: o The segmented 80*86 chip architecture o The O/S designers at Microsoft. The problem with the 80286 chip in particular is that because it is a segmented architecture, and because paging is difficult to impossible, it turns out that it is inconvenient to deal with memory except in rather large chunks. This means that when a segment is required, the entire segment must be loaded; if you have a LOT of memory this may not be very bad, but it IS very memory intensive. The 68000 does not have this architectural problem (nor does the 80386 running in native mode, but even allowing for that the 80386 even in native mode looks ugly beside the more modern 68k chips). The problem with the O/S designers at Microsoft is that they had a tendency to require that everything be preallocated - there is rather little use of things like a "pool" or "free memory" area compared to many other operating systems (it does exist, it just isn't used to the extent that it is in many systems). Part of this may be a desire to ensure that you don't run out (the effects of this can be mysterious even to experienced users - imagine the consternation of a secretary when the PC runs out of something as esoteric as "pool space"). If you don't require the DOS compatibility box the size of the machine required to run OS/2 goes down quite a bit - that little convenience costs you quite a bit of *PERMANENTLY ALLOCATED* memory. Unfortunately because of the existence of abominations like Sidekick and other hostile DOS applications, there is not much that Microsoft can do about that. Unfortunately all these things work together and enhance each other's bad points to create an operating system which uses much more memory than one would normally think would be necessary. By the way, I am in NO WAY surprised at the amount of memory required to run OS/2 EFFICIENTLY - many multasking operating systems with window environments and complex software ARE able to use a LOT of memory (just look at VMS ...) but most of them don't degrade as DRASTICALLY as OS/2 does when there isn't 4MB of memory available. I AM surprised at how BADLY and QUICKLY it degrades as it runs out (usually it's more of a slow degradation rather than a brick wall). Anyway, I've probably annoyed enough people this evening. Bruce C. Wright
schanck@harmonica.cis.ohio-state.edu (Christopher Schanck) (04/29/89)
In article <101907@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >Also OS/2 is under a lot of time pressure and written nearly entirely in >C rather than assembler. The combination has the same effect it has on >UNIX (eg lots of code expansion). The compactness question never enters >into the picture. How does the "written nearly entirely in C" statement jibe with an earlier post (forget which) which mentioned OS/2 containing ~100,000 lines of assembler? It does make sense according to a rumor I heard: one of the reasons it took so long to get done was that the Microsoft guys had to teach the IBMers to use C -- everybody knows how fond of assembler IBM is ;-) Chris -=- "Life is pain, Highness. Anyone who says otherwise is selling something." --- "The Princess Bride" Christopher Schanck (schanck@cis.ohio-state.edu)
karl@sugar.hackercorp.com (Karl Lehenbauer) (04/29/89)
In article <521@laic.UUCP>, darin@nova.laic.uucp (Darin Johnson) writes: > Oh ho! You think you can trip us up with this thinly veiled > flame-war trap... Well it won't work this tim.. urk, arg... Ahhh! ... > ...If designed from scratch, I'm sure that the enormous > amount of people who developed it could have come up with something > decent. Heck, with 386's becoming so common, it would blow 386-based > UNIXes out of the water if done right. Now, who's trying to start another flame war?? -- -- uunet!sugar!karl | "Nobody hipped me to that, dude." -- Pee Wee -- Usenet BBS (713) 438-5018
elg@killer.Dallas.TX.US (Eric Green) (04/29/89)
in article <GRIFF.89Apr28084613@intelob.intel.com>, griff@intelob.intel.com (Richard Griffith) says: > 5) Last, but not least, It has to be CHEAP! Cheaper than upgrading > to OS/2. (That's not so hard, remember - we're not talking just > memory here - OS/2's Presentation Manager *requires* VGA graphics > have you priced a Multisync monitor lately??) As a matter of fact, I have. You can get a VGA monitor for less than $375 now. I've seen multisync monitors for as low as $425, and, in fact, am probably getting one so that I can use it with the new Amiga chipset whenever it comes out. OS/2's problem is that it requires as much memory and disk space as Unix, but without the portability advantages..... yet there's still fools who are converting their programs for OS/2. For example, I hear that the Autocad people are going to put out all future updates of Autocad for OS/2, not for MS-DOS..... -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | \X/ Newsflash: DP director fired for buying IBM! |
leonard@bucket.UUCP (Leonard Erickson) (04/30/89)
I don't know if it is true or not, but I've heard that one of the reasons for the size of OS/2 is the DOS compatibility box. It isn't easy making a real mode program run in protected mode! Another reason may be that the IBM machines have to do a lot of stuff in software that the Amiga hands off to hardware. No blitter chips for example... -- Leonard Erickson ...!tektronix!reed!percival!bucket!leonard CIS: [70465,203] "I'm all in favor of keeping dangerous weapons out of the hands of fools. Let's start with typewriters." -- Solomon Short
peter@sugar.hackercorp.com (Peter da Silva) (04/30/89)
In article <570001@hplchm.HP.COM>, griffith@hplchm.HP.COM (Jeff Griffith) writes: > The two systems are quite different. Amiga does provides only two forms > of process control; you can spawn a new TASK (which I've gotten to work yet), > or you can EXEC a new process (via the equivalent of Un*x "system()"). The Amiga has three kinds of tasks: TASKS, PROCESSES (tasks plus a process structure so you can call DOS), and CLI PROCESSES (processes plus an attached terminal device). OS/2 has two: threads (like tasks), and processes (like CLI processes). There's no concept in OS/2 of a process that's not associated with a user-interface. If you want to write a daemon it has to be a driver. > On the other hand, OS/2 combines the RMX notions of tasks (in the form of > threads with the child thread either sharing the parent's memory or having its > own) with the Unix notions of processes and IPC; quite well done it appears. ALL Amiga processes are effectively threads, with a lower overhead than OS/2. > Personally, I think there is a good match of price/performance between these > two; last time I looked (and I could be wrong by now), a ready-to-run OS/2 > system cost about twice the price of a ready to run Amiga If you can get OS/2 running on a $1600 PC clone, I'd like to know. The RAM you need to run OS/2 presentation manager will cost you more than that. And that's ignoring the cost of OS/2 itself. > but you get twice the system from the OS/2 box. Since you still can't get the OS/2 box, that'd be kind of hard. > Personally, I don't need the extra horsepower just yet. Given the performance of what OS/2 we've seen so far, on faster machines than the Amiga, you'd do better getting a 2620. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
mdg@macs.UUCP (Mark Griffith) (05/01/89)
In article <GRIFF.89Apr28084613@intelob.intel.com>, griff@intelob.intel.com (Richard Griffith) writes: > > (Whew! Sorry about the long post, but like many Amiga lovers, any mention > of the Stupidity of upgrading any PC to OS/2 drives me into the "Will you > *LOOK* at what your doing, you idiot?!?!?", you know, the kind of reaction > you have when someone sticks a screwdriver into a big power panel that's > still turned on....:-) > > OS/2 - Half an Operating System for TWICE the price! > Gee.....we folks that have been running OS-9 on microcomputers for some six or seven years now really get a kick out of the "new kids on the block" boasting about the abilities of their systems. In light of the previous posting here concerning OS/2 and megabytes of memory, Bill Gates was quoted as saying something like you MUST have at least 4 Meg to multitask. I guess he never saw a 64K 6809 machine running OS-9 Level I back in '83 when Microsoft was getting started (ir was it earlier than that??) I guess we'll just have to see what happens when OS-9 is released for the 80386 (maybe) or the MacIntosh. /\/\ark UUCP: mdg@macs BITNET: GRIFFITH@STETSON
w-glenns@microsoft.UUCP (Glenn Steffler) (05/02/89)
In article <2134@iitmax.IIT.EDU> ed@iitmax.IIT.EDU (Ed Federmeyer) writes: > >I don't really have much of an opportunity to use OS/2 or AmigaDOS, but I >couldn't help but wonder how different the two opperating systems are? These operating systems are as different in concept as I am to you. Meaning, both OS's provide the same features, and abilities, yet perform much different tasks. OS/2 is a business oriented OS, with extensive network capabilities, in addition to a rich and quite overwhelming array of multitasking primatives. OS/2 has memory, and resource protection, vital for multiple computer, or multiple user environments, which the Amiga OS was never designed to provide. >I don't understand why OS/2 uses 3 Mb of RAM (I think I read that somewhere) to be usefull, while with AmigaDOS you only need 256 Kb. What does OS/2 give >you that AmigaDOS doesn't? First, a 256KB Amiga is only slightly more usefull than my old (only 6 years) C=64; which "got by" on 64k quite nicely, FOR THE TASKS IT WAS MEANT TO PERFORM! My word processor KindWords (ugh!) or DPaintI/II/III require MUCH more than 256k to even run. More intelligent OS's like Windows (r) load only those sections of a programs code from disk when the program is initially executed. If a dialog box is chosen from a menu item, it's code may not be in memory, and if so, would be loaded from disk, possibly replacing another segment of code from memory. In this way, VERY large programs, like MicroSoft Excell (r), can be usefull in less memory than the program takes up on disk. OS/2 requires 3MB to run effectively due to many factors, including network facilities, more elaborate resource, and memory management, and that OS/2 was written for an 80286, and not an 80386 based machine (A BIG DIFFERENCE!). > After all, they both multitask, have graphics >based interfaces, etc... Is it maybe because the 68000 assembly language >is more compact than 80286 or 80386? In fact m'boy, it's the other way around. Most often used instructions are one or two bytes, and are streamlined on the 80x86 (x=2,3). The C compilers for OS/2 and Windows et all are very efficient, having been around for many more years, the code produced is more often than not (far pointers excluded) as fast and compact as pure assembly produced "from scratch". I LOVE the 68000 assembly language, having become good friends over the last couple of years, and prefer it over 80x86 any day. That still does not mean it's BETTER...:-) >Heck it might make an interesting discussion... Interesting or not, I place my PERSONAL OPINIONS against the bandwidth of the net. > Thanks > Ed Federmeyer > ed@iitmax.iit.edu <- Hard to get through to. > sysed@iitVax.bitnet <- Works everytime, so far! Thankyou for listening. B'b'b'b'b'b buba bububa buy now! --- w-glenns@microsoft.UUCP (Glenn Steffler) THE OPINIONS EXPRESSED HEREIN ARE COMPLETELY MY OWN, AND NOT OF MY EMPLOYER!
jesup@cbmvax.UUCP (Randell Jesup) (05/02/89)
In article <5625@microsoft.UUCP> w-glenns@microsoft.UUCP (Glenn Steffler) writes: >More intelligent OS's like Windows (r) load only those sections of a programs >code from disk when the program is initially executed. If a dialog box is >chosen from a menu item, it's code may not be in memory, and if so, would >be loaded from disk, possibly replacing another segment of code from memory. >In this way, VERY large programs, like MicroSoft Excell (r), can be usefull >in less memory than the program takes up on disk. The exact same capability exists in AmigaDos: overlays. They aren't used a lot (it's (a little) extra work), but they are there and work fine. I've been told that some versions of DPaint use them. They not only allow a flat overlay structure, but a tree structure to overlays. All automatic, merely specify the tree structure in your alink/blink with file, and add lib:ovs.o. Another way of getting the same results is to use loaded libraries. They even stick around until memory gets tight, and don't require reloading normally. >> After all, they both multitask, have graphics >>based interfaces, etc... Is it maybe because the 68000 assembly language >>is more compact than 80286 or 80386? > >In fact m'boy, it's the other way around. Most often used instructions are >one or two bytes, and are streamlined on the 80x86 (x=2,3). The C compilers >for OS/2 and Windows et all are very efficient, having been around for many >more years, the code produced is more often than not (far pointers excluded) >as fast and compact as pure assembly produced "from scratch". Well, compact and fast are often traded off against each other in processor design: witness RISC. The later generation CPUs, like 030/386, are well-optimized for common instructions - the majority of 030 instructions take 2 cycles or so. 68000 has no 1-byte instructions (which are somewhat holdovers from 8008/8080), but most common instructions are 2 bytes, unless an addressing mode or constant requires more. As to as good as hand-coded output from compilers: hah. Most C compilers on the PCclones either don't have global optimizers, or haven't had them for much longer than the amiga (though they MS C has had one longer). Even global-optimizers do not produce code as well as an expert human can. Close, sometimes. As good as, very rarely, mostly for trivial routines. I would think the bizarre register setup and restrictions would make it even worse on an 80x86, though I could be wrong - there could be too many unusual possibilities for a human to deal with. You'll note I restricted this to comp.sys.amiga, to forstall further xposted arguements. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
dougp@sbphy.ucsb.edu (05/02/89)
In article <6728@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes... > The exact same capability exists in AmigaDos: overlays. They aren't ^^^^^ Not quite. > Another way of getting the same results is to use loaded libraries. ^^^^^^^^^^^^^^^^ This is closer, but still different. I unfortunately have to program in windows at work. Windows allows segments of code to be loaded when functions in that segment is called, in that much it is like overlays. Unlike overlays, this does not necessarily force out another block of code. This code, like unused libraries on the Amiga only gets kicked out when the system is low on memory (all too often in windows). So a program in windows may if there is sufficient memory, be entirely loaded in memory, or it may act like an overlaed program if memory is tight. To do this, windows takes advantage of the nasty segmented architechture which allows them to move code arround in memory while the program is running by only messing with a few segment variables. The tradeoff is that code and data segments are limited to 64K and the CPU is constantly wasting cycles shuffling the memory arround. I believe that something similar to what windows does could be done using LoadSegment, but this would be complicated, and I don't see how segments could be discarded when another program was attempting to get more memory. This is the kind of thing that might be good to add in version 2 of the OS, but I hope it can be done without the compromises in windows. >Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup Douglas Peale
daveh@cbmvax.UUCP (Dave Haynie) (05/02/89)
in article <6728@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) says: > Keywords: Operating Systems, Religion WRT computers > In article <5625@microsoft.UUCP> w-glenns@microsoft.UUCP (Glenn Steffler) writes: >>More intelligent OS's like Windows (r) load only those sections of a programs >>code from disk when the program is initially executed... > The exact same capability exists in AmigaDos: overlays. They aren't > used a lot (it's (a little) extra work), but they are there and work fine. Which points out a fundamental difference between the machine environments: most Amigas have enough memory to fit everything in, even several programs' worth, with space to spare. Add ons to MS-DOS, like Windows, are trying to squeeze too much into too little space. Kinda like GEOS on the C64. Overlays are a primitive solution to the memory problem; they've been around since CP/M, and they work, but require extra effort on the part of the programmer, and aren't really efficient. Shared libraries and virtual memory are more sophisticated approaches to the problem. OS/2 and UNIX have virtual memory; I predict Amiga's with MMU's will have it before the end of the year. -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
papa@pollux.usc.edu (Marco Papa) (05/02/89)
In article <6730@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >Shared libraries and virtual memory are more >sophisticated approaches to the problem. OS/2 and UNIX have virtual memory; ^^^^^^^^^^^^^^ >I predict Amiga's with MMU's will have it before the end of the year. Do you mean 1.4 will support virtual memory and will show up by year's end? This would be just great! This is the FIRST time I've heard anything like this mentioned (not evn on BIX closed conf. I heard it). No more GURUs if you have an A2620 or A2630. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
wtm@neoucom.UUCP (Bill Mayhew) (05/02/89)
Having something die in the compatibility box is a good way to send os/2 into an unrecoverable lock-up that requires flipping that big red switch (which is so conviently mounted on the front of the model 80 sitting hrere). It really gets annoying to have to flip that switch all the time; I wish they'd have installed a reset button. There are a lot of times that the ctrl-alt-del doesn't restore sanity. Since we got our Amigas back in late 1985, I've only had the machine need a power-clyle to restore sensibility one time; all other times ctrl-A-A was enough. The problem with the current version of os/2 is that the 80286 is the target processor. Switching between the procteted mode and the virtual 80286 mode is a study in boroque programming. The virtual machine mode of the 80386 is clean, and it works. Its too bad that IBM's corporate-think insisted that os/2 had to appear on the 80286 and had to have msdos compatibility. There are a quite a few 808386-only operating systems (Windows 386, for one) that not only permit a virtual msdos session, but also support many at once. By the way, Windows 386 will run with only 640 K of RAM, but it is about as exciting as a 512 K Amiga. The current version of os/2 for the 80286 environment are sort of of like the Macintosh multifinder running on the Mac II with that ersatz simulated MMU. When/if Apple comes out with their real multitasking system later this year, you'll also have to stick in a real MMU too. It'll be interesting to see what happens with the Mac crowd when they get a real o/s and can ditch INITs and desk accessories. Bill wtm@impulse.UUCP
bmacintyre@watcgl.waterloo.edu (Blair MacIntyre) (05/02/89)
In article <16952@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >In article <6730@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >>Shared libraries and virtual memory are more >>sophisticated approaches to the problem. OS/2 and UNIX have virtual memory; > ^^^^^^^^^^^^^^ >>I predict Amiga's with MMU's will have it before the end of the year. > >Do you mean 1.4 will support virtual memory and will show up by year's end? >This would be just great! This is the FIRST time I've heard anything like this >mentioned (not evn on BIX closed conf. I heard it). No more GURUs if you have >an A2620 or A2630. Hmmm ... I keep saying to my friends "I won't buy another Amiga/computer until it has virtual memory, memory protection, etc" ... does this mean I may be buying another computer before the end of the year?!?! I hope so. I like my 1000, but life would be better with an OS that I wouldn't have to reboot every time a program hangs or goes beserk! I hope I hope I hope ... :-) Blair -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-///-= = Blair MacIntyre, bmacintyre@watcgl.{waterloo.edu, UWaterloo.ca} \\\/// = = now appearing at the Computer Graphics Lab, U of Waterloo! \XX/ = = "Don't be mean ... remember, no matter where you go, there you are." BBanzai=
daveh@cbmvax.UUCP (Dave Haynie) (05/03/89)
in article <16952@usc.edu>, papa@pollux.usc.edu (Marco Papa) says: > In article <6730@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >>Shared libraries and virtual memory are more >>sophisticated approaches to the problem. OS/2 and UNIX have virtual memory; >>I predict Amiga's with MMU's will have it before the end of the year. > Do you mean 1.4 will support virtual memory and will show up by year's end? > This would be just great! This is the FIRST time I've heard anything like this > mentioned (not evn on BIX closed conf. I heard it). No more GURUs if you have > an A2620 or A2630. No, that's not to imply that 1.4 will have built-in virtual memory, or that 1.4 will be out by the end of the year. I'm just predicting, based on what I know about MMU's, the Amiga OS, and all, that a virtual memory manager will be available in some form by year's end. Someone's already done one for the Mac, and it didn't require an OS revision. Similarly, I believe such a memory manager would work under the current Amiga OS. Virtual memory doesn't imply protected memory, however, and in fact, while I think I know how a virtual memory manager would work, I'm not sure it would be feasible to add-on memory protection -- that may have to be part of a new OS release to work correctly. Though I do know of people who've played with the idea.... > -- Marco Papa 'Doc' > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu > "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
elg@killer.Dallas.TX.US (Eric Green) (05/03/89)
in article <16952@usc.edu>, papa@pollux.usc.edu (Marco Papa) says: > In article <6730@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >>Shared libraries and virtual memory are more >>sophisticated approaches to the problem. OS/2 and UNIX have virtual memory; > ^^^^^^^^^^^^^^ >>I predict Amiga's with MMU's will have it before the end of the year. > Do you mean 1.4 will support virtual memory and will show up by year's end? > This would be just great! This is the FIRST time I've heard anything like this > mentioned (not evn on BIX closed conf. I heard it). No more GURUs if you have > an A2620 or A2630. Sorry Marco. Virtual memory is no problem. Process protection (GURU-busting) is. AmigaDOS assumes one big huge shared memory address space with multiple cooperating programs occupying it. Process protection thus must be on a per-block basis, which the MMU on the 2620 will NOT do if I recall my Motorola MMUs correctly. Virtual memory, on the other hand, is a piece of cake by comparison. Just map in the CHIP and ROMs, map in your page faulter (which runs the hard disk handler in "real" mode), and presto -- instant multi-megabyte FAST. Or not so presto... there's some problems involved in getting your pages to and fro from the hard drive. But you get the picture. There's no major OS rewrite or major hardware modification involved, just a bit of (admittedly tricky) software to control the hardware already there, in a way totally transparent to applications programs (when they request FAST, they have no idea if it's "really" memory, or not). So if your idea of heaven is to have a 10 megabyte RAD: device, and keep Excellence, X-WIndows, Superbase, and a half dozen other programs all running at the same time with no fear of running out of memory, you'll love what's coming. On the other hand, if your idea of virtual memory includes process protection, you're just plain out of luck. -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | // Join the Church of HAL, in worship of all computers with | |\X/ three-character names (e.g. IBM and DEC). White lab coats optional. |
papa@pollux.usc.edu (Marco Papa) (05/03/89)
In article <7988@killer.Dallas.TX.US> elg@killer.Dallas.TX.US (Eric Green) writes: |in article <16952@usc.edu|, papa@pollux.usc.edu (Marco Papa) says: || In article <6730@cbmvax.UUCP| daveh@cbmvax.UUCP (Dave Haynie) writes: |||I predict Amiga's with MMU's will have it before the end of the year. || Do you mean 1.4 will support virtual memory and will show up by year's end? || No more GURUs if you have an A2620 or A2630. | |Sorry Marco. Virtual memory is no problem. Process protection |(GURU-busting) is. |So if your idea of heaven is to have a 10 megabyte RAD: device, and |keep Excellence, X-WIndows, Superbase, and a half dozen other programs |all running at the same time with no fear of running out of memory, |you'll love what's coming. On the other hand, if your idea of virtual |memory includes process protection, you're just plain out of luck. For 1989, I'll settle for heaven #1, and pray for "Protected AmigaDOS" (heaven #2) for 1990. Should I guess that SetCPU 2.0 will do "virtual memory", Dave? [Have you ever noticed the time Dave makes his postings? 5AM !:-)] -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
griff@intelob.intel.com (Richard Griffith) (05/03/89)
In article <7953@killer.Dallas.TX.US> elg@killer.Dallas.TX.US (Eric Green) writes: >OS/2's problem is that it requires as much memory and disk space as >Unix, but without the portability advantages..... yet there's still >fools who are converting their programs for OS/2. For example, I hear >that the Autocad people are going to put out all future updates of >Autocad for OS/2, not for MS-DOS..... I wonder how much it would cost to get them to seriously consider an Amiga for Autocad ---? (No job's too tough, if the MONEY'$ enough!) - griff -- * Richard E. Griffith * Cyrus Hammerhand * * "griff" * Household of the Golden Wolf * * BiiN, Hillsboro Ore. * Dragons' Mist * * UUCP: ...[!uunet]!tektronix!biin!griff * An Tir * ************************************************************************** * These are MY opinions, if BiiN wanted them, They'd pay for `em! *
les@unicads.UUCP (Les Milash) (05/03/89)
In article <1610@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: >Having something die [...] It really gets annoying to have to flip >that switch all the time. Since we got our Amigas back in late 1985, I've >only had the machine need a power-clyle to restore sensibility one >time; all other times ctrl-A-A was enough. My software must be more macho then yours; I have to flush my Amiga hourly. (of course I'm developing software in C--bummer if it's only on the ramdisk). (I even read an article by some pro sw developer who said he'd compile&link on one amiga, download code to a test amiga, so he could be working while the test amiga reboots.) [this should not be construed to be a complaint, just a fact. to me an amiga is the volks-personal-computers. no wetbar or tv, but it's got power windows fer shure! i mean, anybody who hasn't lived with a task- per-window just doesn't know what they're missing. just like this Sun, except scrolls faster (well maybe that's not the Only difference) ]
jesup@cbmvax.UUCP (Randell Jesup) (05/04/89)
In article <7988@killer.Dallas.TX.US> elg@killer.Dallas.TX.US (Eric Green) writes: >in article <16952@usc.edu>, papa@pollux.usc.edu (Marco Papa) says: >> Do you mean 1.4 will support virtual memory and will show up by year's end? > >Sorry Marco. Virtual memory is no problem. Process protection >(GURU-busting) is. AmigaDOS assumes one big huge shared memory address >space with multiple cooperating programs occupying it. Process >protection thus must be on a per-block basis, which the MMU on the >2620 will NOT do if I recall my Motorola MMUs correctly. Virtual >memory, on the other hand, is a piece of cake by comparison. Just map >in the CHIP and ROMs, map in your page faulter (which runs the hard >disk handler in "real" mode), and presto -- instant multi-megabyte >FAST. Or not so presto... there's some problems involved in getting >your pages to and fro from the hard drive. But you get the picture. >There's no major OS rewrite or major hardware modification involved, >just a bit of (admittedly tricky) software to control the hardware >already there, in a way totally transparent to applications programs >(when they request FAST, they have no idea if it's "really" memory, or >not). Actually, it's tougher than that. Forbid()/Permit() locking is no longer sufficient if you need to take a page fault in the middle of it. Let's not talk about Disable/Enable. On the other hand, non-transparent VM is easy (where the program has to ask for it explicitly.) You just make sure you don't access VM pages during Forbid/Disable. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
griff@intelob.intel.com (Richard Griffith) (05/04/89)
In article <5625@microsoft.UUCP> w-glenns@microsoft.UUCP (Glenn Steffler) writes: Long posting - [stuff deleted] >These operating systems are as different in concept as I am to you. Meaning, >both OS's provide the same features, and abilities, yet perform much >different tasks. Yes? - Maybe. The only real difference I can immediately see, is that OS/2 is saddled with the need of keeping a huge ball-and-chain wrapped around it's foot. Namely that of backward compatibility with MeSsy-DOS. Trash that little problem, and you guys might have come with with something worth the price of an upgrade...:-) >>I don't understand why OS/2 uses 3 Mb of RAM (I think I read that somewhere) to be usefull, while with AmigaDOS you only need 256 Kb. What does OS/2 give >>you that AmigaDOS doesn't? MS-DOS compatiblity from the company that supports it in the first place. True VMM. Yep, AmigaDOS doesn't have that. Of course, with AmigaDOS, if I have 8 megs in my machine - I can use it all. With much smaller code - you see, the 68xxx's don't have to mess with segment-registers... (I know- the `386 doesn't need to anyway - does OS/2 use linear mode? Doesn't that cut down the amount of addressable memory by the size of the segment register?) >First, a 256KB Amiga is only slightly more usefull than my old (only 6 years) >C=64; which "got by" on 64k quite nicely, FOR THE TASKS IT WAS MEANT TO >PERFORM! My word processor KindWords (ugh!) or DPaintI/II/III require MUCH >more than 256k to even run. You sir, are obviously not using an Amiga. I, too, owned a C=64. Nice machine. Quite useful for "THE TASKS IT WAS MEANT TO PERFORM" - Since you brought up the point - I submit that the MS-DOS machines are superior to any other machine FOR THE TASK IT WAS MEANT TO PERFORM. Word processing. That's it. The IBM PC was meant to be a replacement for the IBM Selectric(r) typewriter. Also, don't start trying to compare products - or I'll start mentioning things like MS-Windows. :-) >More intelligent OS's like Windows (r) load only those sections of a programs ^^^^^^^ You've GOT to be Kidding. Aren't you? Everyone knows Windows has some severe problems... If you want to turn someone off of using anykind of graphical user interface - hand them windows... Most of the people I know who have used "Windows" have the kind of attitude that says "Graphical user interface? Who needs it? They're slow, clunky and ugly, why anybody would use a mouse is beyond me.." While those who have used anything else (Mac, Atari, Sun, or, dare I say it, Amiga!) wouldn't trade their GUI for anything! Windows is not what I would call any kind of an OS.... As for slow - well, there was a post here from Rob Peck, seems someone took Windows and compared it (running on a Compaq `386/25 no less!) to AmigaDOS...using a function that is used several hundred times a day - Push window to back and Pull window to front. Guess what? the 7.14 Mhz Amiga BEAT the Pride-of-the-DOS world. Don't try to toot Windows' Horn, it barely qualifies as a party favor. >In this way, VERY large programs, like MicroSoft Excell (r), can be usefull >in less memory than the program takes up on disk. (try overlays in AmigaDOS - same thing. Not usually used, because we don't have to be backwardly compatible with a 640k limit :-) >OS/2 requires 3MB to run effectively due to many factors, including >network facilities, more elaborate resource, and memory management, and >that OS/2 was written for an 80286, and not an 80386 based machine >(A BIG DIFFERENCE!). Yep - sells lots of Hardware - Hey- with all that Highly-vaunted "I only load what I NEED"-type design, why don't you not load the "network facilities, more elaborate resource and memory management" stuff until you need it - or wouldn't IBM be abel to sell as much H/W? >> Thanks >> Ed Federmeyer >> ed@iitmax.iit.edu <- Hard to get through to. >> sysed@iitVax.bitnet <- Works everytime, so far! >Thankyou for listening. B'b'b'b'b'b buba bububa buy now! >--- >w-glenns@microsoft.UUCP (Glenn Steffler) >THE OPINIONS EXPRESSED HEREIN ARE COMPLETELY MY OWN, AND NOT OF MY EMPLOYER! - griff Sorry for the length and small flame-fest, I just hate to see someone who obviously hasn't gone beyond their own propaganda. (Of course, *I never* do that :-) :-) :-)) -- * Richard E. Griffith * Cyrus Hammerhand * * "griff" * Household of the Golden Wolf * * BiiN, Hillsboro Ore. * Dragons' Mist * * UUCP: ...[!uunet]!tektronix!biin!griff * An Tir * ************************************************************************** * These are MY opinions, if BiiN wanted them, They'd pay for `em! *
hummel@m.cs.uiuc.edu (05/04/89)
To set aside the question of who was there first, I think a far more relevant
and valuable statement (in a marketing sense) is this:
With the Amiga line, Commodore has the largest installed base of
multitasking personal computers in the world.
I don't know how many IBM minis and mainframes are out there, but it
might even be fair to generalize the statement to encompass ALL
computers, not just personal computers.
< Lionel
----------
Lionel Hummel 404 W. High St. #6, Urbana, IL 61801
University of Illinois, Urbana-Champaign [H] (217)344-5303 [W] (217)333-7408
hummel@cs.uiuc.edu {pur-ee,uunet}!uiucdcs!hummel BIX: lhummel
"Thank you, BIX, for flat rate billing."mph@behemoth.phx.mcd.mot.com (Mark Huth) (05/05/89)
In article <7988@killer.Dallas.TX.US> elg@killer.Dallas.TX.US (Eric Green) writes: > ... (Stuff about virtural memory not being the same as process protection)... >So if your idea of heaven is to have a 10 megabyte RAD: device, and >keep Excellence, X-WIndows, Superbase, and a half dozen other programs >all running at the same time with no fear of running out of memory, >you'll love what's coming. On the other hand, if your idea of virtual >memory includes process protection, you're just plain out of luck. > Well, I guess I might as well wade into this MMU discussion. The 68851 MMU used on the 2620 (and a subset of which is contained on the 68030 - mostly fewer Address Translation Caches) provides several different functions. The functions provided are logical address to physical address translation, segment/page write protection, and privilege ring access protection. The address translation function is what is needed to support virtual memory systems. Using the 2620 hardware, virtual memory could probably be grafted onto AmigaDOS quicly and transparently. About all it would require is a mapper running in the Buss Error Exception Handler, and a hook to turn on the MMU with an initial page table. The OS and applications could all continue to reside in one large virtual memory space, giving the Amiga a virtual memory about the size of the hard drive. Actually, the memory space could be the entire 4GB 68020 space, but you could only use as much as would fit on the paging device at any one time. This wouldn't provide any protection, but it's relatively simple to add the an existing system. It could be done without the source to the base OS. It is possible to get some real protection using the page descriptors. The page tables allow rather arbitrary mappings of memory, so it is possible to fix areas of memory to not be visible from user space. In fact, the PMMU has three root pointers that allow separate translation trees for user, supervisor, and dma operations. A rapid context switch is supported by simply changing the user root pointer when a new process is dispatched. Other users' physical memory may simply be not appear in the translation tables. Additionally, user data space and program space are separated, making it a simple matter to protect code space from the user. There is also a write protect bit in each of the segment or page descriptors, allowing read only access to certain areas of memory. While relatively straight forward, the above protection would require considerable modifications to some of the OS routines. Most notable, the memory management routines would need to change to allocate the proper page table entries as well as the physical memory. Also, it would be necessary to change the calling sequence to system functions and libraries to use a trap mechanism in order to get to supervisor mode. To add protection would require source code to the OS. An additional level of protection can be implemented using the PMMU. This is a ring protection scheme similar to the one found in Multics. There are read and right access level registers for each page, and the high-order bits of the address are used to determine the access level requested. There is aregister in the PMMU for the current task access level. This all works to provide rings of protection in the user space. To implement this sort of protection scheme would require a rewrite of many portions of the system, possibly including linkers and loaders, as the access information is encoded in the addresses. This type of protection is not normally needed in single user systems, but is nice when the question of shared data is involved. In summary, virtural memory in say a month, protection in 6 months to a year, and anything more, well, why bother. Note that protection will eliminate the source of many gurus, but may not allow the resource recovery that is needed to effectively kill an errant task. That would require that the OS have the necessary tracking mechanisms built into it, and I'm not sure that AmigaDOS does enough in this area. By the way, the above is a very brief summary of the 68851. It's a very complex chip - microprocessor-like complexity. I've read the manual a few times and still don't understand all of its subtleties. Mark Huth
mph@behemoth.phx.mcd.mot.com (Mark Huth) (05/05/89)
In article <6758@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >... stuff about VM/protection - VM not too hard... > Actually, it's tougher than that. Forbid()/Permit() locking is no >longer sufficient if you need to take a page fault in the middle of it. >Let's not talk about Disable/Enable. Well, I don't really see a problem with Forbid/Permit. If I recall correctly, Forbid forbids task switching. VM doesn't get in the way of this, but the processor does get kinda' bored waiting for the page to swap into physical memory. Of course, the use of VM makes execution times much less predictable. If there is an upper bound on the time forbid is allowed, then the VM system taking a page fault may violate that constraint. Disable is another game all together. If disable only affects the software interrupt to a particular task/process (that is, if we're talking virtual interrupts) then VM makes no difference. If on the other hand, we're talking about raising the interrupt level mask to 7 in the SR, that's a completely different story. Normally, code which must disable critical interrupts in a VM system will run untranslated, or have its physical pages locked in memory so as to bound the disable time. This is what drivers and other pieces of trusted software are for. Basically, virtual memory systems are transparent to the virtual machine user. Those who use the physical machine gotta' take a little more care. Mark Huth
t-stephp@microsoft.UUCP (Stephen Poole) (05/07/89)
In article <GRIFF.89May3172946@intelob.intel.com> griff@intelob.intel.com (Richard Griffith) writes: >In article <5625@microsoft.UUCP> w-glenns@microsoft.UUCP (Glenn Steffler) writes: >>>I don't understand why OS/2 uses 3 Mb of RAM (I think I read that somewhere) to be usefull, while with AmigaDOS you only need 256 Kb. What does OS/2 give >>>you that AmigaDOS doesn't? > > MS-DOS compatiblity from the company that supports it in the first place. >True VMM. Yep, AmigaDOS doesn't have that. Of course, with AmigaDOS, if >I have 8 megs in my machine - I can use it all. With much smaller code - >you see, the 68xxx's don't have to mess with segment-registers... (I know- >the `386 doesn't need to anyway - does OS/2 use linear mode? Doesn't that >cut down the amount of addressable memory by the size of the segment register?) Version 1.1 of OS/2 does not use flat addressing, since as Glenn pointed out it is written for the 80286. I wouldn't discount the importance of virtual memory as easily as do you. It seems that one of the primary reasons you dislike OS/2 (and I do have to wonder if you've ever used for more than a few minutes) is because of the amount of memory it requires. You may be able to use all 8M on your Amiga, but you had to purchase it, didn't you? On my OS/2 box I can have 4M and use it like 16M. That's a good bit more valuable than being limited to 8M AND having to pay for it. >>First, a 256KB Amiga is only slightly more usefull than my old (only 6 years) >>C=64; which "got by" on 64k quite nicely, FOR THE TASKS IT WAS MEANT TO >>PERFORM! My word processor KindWords (ugh!) or DPaintI/II/III require MUCH >>more than 256k to even run. > >You sir, are obviously not using an Amiga. I, too, owned a C=64. Nice Sounds like an Amiga to me. It's been a while, but I used to use the Amiga quite a bit. A 512K machine didn't do a whole lot, considering that the OS ate half of it. Now that the OS is in ROM I suppose it's not such a great concern, but the point remains a valid one. > >>More intelligent OS's like Windows (r) load only those sections of a programs > ^^^^^^^ You've GOT to be Kidding. Aren't you? >Everyone knows Windows has some severe problems... If you want to turn someone [Comments about Windows GUI vs all others deleted] I am certainly no big Windows fan and am not defending it. You, however, completely missed the point. Windows is a more intelligent OS in that it demand loads code and resources. In terms of memory management in general it certainly qualifies as a second-generation PC operating system, regardless of other problems it may have. Overlays on the Amiga are a laughable substitute for VM or demand loading. >>OS/2 requires 3MB to run effectively due to many factors, including >>network facilities, more elaborate resource, and memory management, and >>that OS/2 was written for an 80286, and not an 80386 based machine >>(A BIG DIFFERENCE!). > >Yep - sells lots of Hardware - Hey- with all that Highly-vaunted "I only >load what I NEED"-type design, why don't you not load the "network facilities, >more elaborate resource and memory management" stuff until you need it - >or wouldn't IBM be abel to sell as much H/W? That's a ridiculous question. What do you expect the operating system to do, page in the disk drivers from virtual memory when it needs to access the disk? Kind of a chicken and egg situation, eh? Drivers and the OS/2 kernel are bootstrapped and remain resident for obvious reasons. The dynamic linking capabilities of OS/2, however, allow chunks of code to be shared between applications with no duplication in memory. DynLink libraries are one of the major advantages of OS/2 over more primitive PC operating systems (meaning PC in the generic sense). As everyone is aware, there is a significant amount of overhead associated with an OS with advanced networking and memory management capabilities, but that megabyte or two of overhead most assuredly leads to far more efficient memory utilization and connectivity. > Sorry for the length and small flame-fest, I just hate to see someone >who obviously hasn't gone beyond their own propaganda. (Of course, *I >never* do that :-) :-) :-)) I have been using OS/2 for about nine months now, and can honestly say that it is a tremendous pleasure to use. Until I tried it for myself I was a member of the sheeplike crowd of folks who had not used it and believed all the negative comments the reviewers constantly made. The productivity gains I have realized have been amazing. I totally dig having email running all the time and checking for new messages, having two compilations running, having my machine set up as a network server (a piece of cake, and something that can be done at any time without even rebooting), all while I'm using Word or a telecommunications program and formatting a floppy. And that's on a 4.6M machine WITH the DOS box enabled. That strikes me as being pretty good resource management. >* Richard E. Griffith * Cyrus Hammerhand * >* "griff" * Household of the Golden Wolf * >* BiiN, Hillsboro Ore. * Dragons' Mist * >* UUCP: ...[!uunet]!tektronix!biin!griff * An Tir * >************************************************************************** >* These are MY opinions, if BiiN wanted them, They'd pay for `em! * -- -- Stephen D. Poole -- t-stephp@microsoft.UUCP -- Mac II Fanatic -- -- -- -- I'm just an Oregon Tech Software Engineering co-op at Micro- -- -- soft. Believe me, nobody here pays attention to my opinions! --
mp1u+@andrew.cmu.edu (Michael Portuesi) (05/08/89)
t-stephp@microsoft.UUCP (Stephen Poole) writes: > Sounds like an Amiga to me. It's been a while, but I used to use the > Amiga quite a bit. A 512K machine didn't do a whole lot, considering that > the OS ate half of it. Now that the OS is in ROM I suppose it's not such > a great concern, but the point remains a valid one. It never made a difference whether the OS was in ROM or not. The A1000 contained an extra 256K of RAM for the express purpose of holding the Kickstart ROM image. Back in the dark ages when my A1000 had only 512K, I remember having about 410K free when the machine booted up. > I am certainly no big Windows fan and am not defending it. You, however, > completely missed the point. Windows is a more intelligent OS in that it > demand loads code and resources. So does the Amiga. > In terms of memory management in general > it certainly qualifies as a second-generation PC operating system, > regardless of other problems it may have. Overlays on the Amiga are a > laughable substitute for VM or demand loading. The Amiga already has demand loading, and from the discussion going by on this newsgroup it seems that VM will be here soon. > kernel are bootstrapped and remain resident for obvious reasons. The dynamic > linking capabilities of OS/2, however, allow chunks of code to be shared > between applications with no duplication in memory. The dynamic libraries on the Amiga do exactly that. Furthermore, any re-entrant program can be made resident and invoked concurrently multiple times with no duplication in memory. > I have been using OS/2 for about nine months now, and can honestly say > that it is a tremendous pleasure to use. Until I tried it for myself > I was a member of the sheeplike crowd of folks who had not used it and > believed all the negative comments the reviewers constantly made. I don't believe all the negative publicity about OS/2 either, but it is apparent that you know less about the Amiga OS than you claim to know. > I totally dig > having email running all the time and checking for new messages, having > two compilations running, having my machine set up as a network server > (a piece of cake, and something that can be done at any time without > even rebooting), all while I'm using Word or a telecommunications > program and formatting a floppy. And that's on a 4.6M machine WITH > the DOS box enabled. That strikes me as being pretty good resource > management. > -- Stephen D. Poole -- t-stephp@microsoft.UUCP -- Mac II Fanatic -- Sounds like you've been using a Macintosh for too long. -- Michael Portuesi * Information Technology Center * Carnegie Mellon University INTERNET: mp1u+@andrew.cmu.edu * BITNET: mp1u+@andrew UUCP: ...harvard!andrew.cmu.edu!mp1u+ MAIL: Carnegie Mellon University, P.O. Box 259, Pittsburgh, PA 15213
dennison@rex.cs.tulane.edu (Theodore Dennison) (05/08/89)
In article <17840@cisunx.UUCP> ejkst@unix.cis.pittsburgh.edu (Eric J. Kennedy) writes: >I was in a Computerland the other day, and I tried to use a model 50 >running OS/2. It booted, and the first thing I typed *Crashed* the >machine. I know, OS/2 isn't supposed to crash. But it did. >First time I ever touched OS/2, too. I'll stick with my Amiga. > >I've crashed PC's, Amigas, Ataris, Macintoshes, etc., but I don't recall >something ever crashing quite so quickly. IBM had a big PS2 demo here at TULANE about a month ago and I went to see what all the fuss was about. They had several displays set up. They had a stereo MIDI display with a 20 hooked up to a keyboard. No bad, but the 20's are realy just toys. A little farther over I saw a very impressive looking presentation using touch sensitive screens and impressive graphics. I tried to see what kind of PS2 was generating this impressive display, but it was not out. I traced some wire under a table, and found it hidden away. It was not a PS2 at all! It was some kind of dedicated hardware they had brought with them that seemed to be made for this one purpose. A little over from this they had some IBM bigwig explaining how his company solved some stupid little hardware problem ad nausemum (and calling it a "revolution" every 4 sentences, to try to keep the audience awake). I found a PS2/50 and told the salesman, "Impress me!" He opened one window, then tried to open another one, and the machine froze. He said, "Damn, I fragmented memory again!" and rebooted the machine! It had just been turned on when this happened! Their PS2/70 seemed to work allright, and even had some fairly neat packages with it. Of course their WP package did not support color, but you can't have everything, can you? (Sarcasm) The graphics display seemed ok, but the speed a requester was erased from the screen was actualy slow enough to watch. The only computer they had that could physicaly compete with my Amiga 1000 (which I have had for 3 1/2 years) was their top of the line 70 (the 80's are not AVAILABLE to students). These cost, at the student discount, $4,400 Considering I could buy a top of the line Amiga for $2000 with everything the IBM has, with NO discount, apparently IBM feels that their corporate logo is worth at least $2,200, and thousands more to business people. That's a lot of dough for three little letters! T.E.D.
peter@sugar.hackercorp.com (Peter da Silva) (05/08/89)
In article <5664@microsoft.UUCP>, t-stephp@microsoft.UUCP (Stephen Poole) writes: > On my OS/2 box I can have 4M and use it like 16M. That's a good bit more > valuable than being limited to 8M AND having to pay for it. For the price difference between the Amiga and the OS/2-capable box you can buy 4 extra megs of RAM, and have enough change left for a down payment on a Hyundai Excel. Besides, the Amiga is a real-time system. That's a capability you can't get for OS/2 (or any VM system I know of) for any price. > Sounds like an Amiga to me. It's been a while, but I used to use the > Amiga quite a bit. A 512K machine didn't do a whole lot, considering that > the OS ate half of it. The OS never ate half of *my* 512K. It got loaded into the same address space as the ROMs, which has nothing to do with the 512K CHIP RAM. > Now that the OS is in ROM I suppose it's not such > I am certainly no big Windows fan and am not defending it. You, however, > completely missed the point. Windows is a more intelligent OS in that it > demand loads code and resources. It also demands that you rewrite your application from scratch in an even more contorted way than the Macintosh does. Besides, I can demand-load code and resources on my Amiga. It's called using libraries and overlays, which puts some overhead on the programmer... but nothing like the demands Windows makes. > As everyone is aware, there > is a significant amount of overhead associated with an OS with advanced > networking and memory management capabilities, but that megabyte or two > of overhead most assuredly leads to far more efficient memory utilization > and connectivity. Why does that stuff need an extra megabyte or two? UNIX does a hell of a lot more than OS/2, and isn't anywhere near that big. > The > productivity gains I have realized have been amazing. I totally dig > having email running all the time and checking for new messages, having > two compilations running, having my machine set up as a network server > (a piece of cake, and something that can be done at any time without > even rebooting), all while I'm using Word or a telecommunications > program and formatting a floppy. And that's on a 4.6M machine WITH > the DOS box enabled. That strikes me as being pretty good resource > management. Wow. I can do all that on a 1 Meg machine running a 4-year-old version of Xenix. I used to do all that on a 512K machine running an 8-year-old version of UNIX. Yep, OS/2 is a real step forwards. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
SCHAFER@RICE.BITNET (Richard A. Schafer) (05/08/89)
In article <5664@microsoft.UUCP>, t-stephp@microsoft.UUCP (Stephen Poole) says: >I have been using OS/2 for about nine months now, and can honestly say >that it is a tremendous pleasure to use. Until I tried it for myself >I was a member of the sheeplike crowd of folks who had not used it and >believed all the negative comments the reviewers constantly made. The >productivity gains I have realized have been amazing. I totally dig >having email running all the time and checking for new messages, having >two compilations running, having my machine set up as a network server >(a piece of cake, and something that can be done at any time without >even rebooting), all while I'm using Word or a telecommunications >program and formatting a floppy. And that's on a 4.6M machine WITH >the DOS box enabled. That strikes me as being pretty good resource >management. What communications program are you using? I've just started working with OS/2 (SE 1.1) and I'm looking for a communications program. (Yes, I know I could spend the money and upgrade to Extended Edition, and with the 50% educational discount, I just might do that, but I'm trying to look at other options, too.) Do you know any good source of public domain/shareware programs for OS/2, or is it too early for things like that? ------- Richard A. Schafer Manager, Systems Support
griff@intelob.intel.com (Richard Griffith) (05/08/89)
In article <5664@microsoft.UUCP> t-stephp@microsoft.UUCP (Stephen Poole) writes: >>In article <5625@microsoft.UUCP> w-glenns@microsoft.UUCP (Glenn Steffler) writes: [ lots of stuff deleted...] >Version 1.1 of OS/2 does not use flat addressing, since as Glenn pointed out >it is written for the 80286. I wouldn't discount the importance of virtual >memory as easily as do you. It seems that one of the primary reasons you >dislike OS/2 (and I do have to wonder if you've ever used for more than a >few minutes) is because of the amount of memory it requires. You may be >able to use all 8M on your Amiga, but you had to purchase it, didn't you? All true (BTW - I don't discount the validity of VMM - It *is* nice when you have it... I meant it sincerely when I said that those were two *valid* reasons to choose OS/2...) The point you missed here was if I buy 8M I can honestly *use* (what is it? 7.5M)...not 4... and I don't *need* 4M just to boot my machine or use multitasking... (As a matter of fact, I have 3M :-) >On my OS/2 box I can have 4M and use it like 16M. That's a good bit more >valuable than being limited to 8M AND having to pay for it. Doesn't swapping give you a problem? [stuff deleted - really, I'm trying to shorten this thing....] >>You sir, are obviously not using an Amiga. I, too, owned a C=64. Nice >Sounds like an Amiga to me. It's been a while, but I used to use the >Amiga quite a bit. A 512K machine didn't do a whole lot, considering that >the OS ate half of it. Now that the OS is in ROM I suppose it's not such >a great concern, but the point remains a valid one. NO - equating an Amiga to a C=64 is like equating an IBM PC/AT with a Meg of memory, EGA, Stereo Sound card and OS/2 to a vanilla IBM/PC XT - nowhere near the same. (unless you count "upward compatibility" which the C=64 and Amiga don't have...) >>>More intelligent OS's like Windows (r) load only those sections of a programs >regardless of other problems it may have. Overlays on the Amiga are a >laughable substitute for VM or demand loading. Well, :-^ you might have a point here. - however, someone running a new version of Windows on a 25 Mhz `386 still can't match the 7mhz Amy in speed of graphics, at least as far as functions like window-to-front and window-to-back... you can ask R. Peck on that one.... >>Yep - sells lots of Hardware - Hey- with all that Highly-vaunted "I only >>load what I NEED"-type design, why don't you not load the "network facilities, >>more elaborate resource and memory management" stuff until you need it - >>or wouldn't IBM be abel to sell as much H/W? >That's a ridiculous question. What do you expect the operating system to Not really - why does the OS absolutely *have* to load all this stuff - I've seen many PC users you don't have a network, don't want one, can't use it- why force them to use the code?? - why not allow that segment to be dynamically configurable? I'm sure that there is more segments like this that could effectively be removed, due to not being neccessary... >do, page in the disk drivers from virtual memory when it needs to access >the disk? Kind of a chicken and egg situation, eh? Drivers and the OS/2 >kernel are bootstrapped and remain resident for obvious reasons. The dynamic - of course...I'm really not quite *that* dense :-) >I have been using OS/2 for about nine months now, and can honestly say >that it is a tremendous pleasure to use. Until I tried it for myself >I was a member of the sheeplike crowd of folks who had not used it and >believed all the negative comments the reviewers constantly made. The >productivity gains I have realized have been amazing. I totally dig >having email running all the time and checking for new messages, having >two compilations running, having my machine set up as a network server >(a piece of cake, and something that can be done at any time without >even rebooting), all while I'm using Word or a telecommunications >program and formatting a floppy. And that's on a 4.6M machine WITH >the DOS box enabled. That strikes me as being pretty good resource >management. Sounds good - how long do you wait for code swapping-? (just curious, I have no idea) - I admit I have doubts about the real need for VMM - yes, it's useful - no doubt, but - consider: if I have an OS that can span several Megs of memory and can multitask efficiently within that space - I can swap between programs with almost no delay (save screen refresh!) there's no delay in "just a minute! I gotta get that page") And there will *always* be some kind of a delay... even if a small one. >-- Stephen D. Poole -- t-stephp@microsoft.UUCP -- Mac II Fanatic -- >-- -- >-- I'm just an Oregon Tech Software Engineering co-op at Micro- -- >-- soft. Believe me, nobody here pays attention to my opinions! -- - griff -- * Richard E. Griffith * Cyrus Hammerhand * * "griff" * Household of the Golden Wolf * * BiiN, Hillsboro Ore. * Dragons' Mist * * UUCP: ...[!uunet]!tektronix!biin!griff * An Tir * ************************************************************************** * These are MY opinions, if BiiN wanted them, They'd pay for `em! *
daveh@cbmvax.UUCP (Dave Haynie) (05/09/89)
in article <5664@microsoft.UUCP>, t-stephp@microsoft.UUCP (Stephen Poole) says: > Xref: cbmvax comp.sys.ibm.pc:32990 comp.sys.amiga:36021 > I am certainly no big Windows fan and am not defending it. You, however, > completely missed the point. Windows is a more intelligent OS in that it > demand loads code and resources. In terms of memory management in general > it certainly qualifies as a second-generation PC operating system, > regardless of other problems it may have. Overlays on the Amiga are a > laughable substitute for VM or demand loading. Amiga shared libraries, fonts, and device drivers are all demand-loaded. Any more sophisticated form of demand loading should be, IMHO, based on a hardware driven virtual memory manager. If you haven't isolated the things that are to be loaded on demand, you're going to be pretty inefficient it would seem. And without any obvious indication of useage, such as in an Amiga device or font, or a VM manager's page count tags, the system isn't going to know enough to unload stuff that hasn't been recently used, at least not without some serious software overhead. Of course, I have yet to hear complaints about OS/2 being too fast... > That's a ridiculous question. What do you expect the operating system to > do, page in the disk drivers from virtual memory when it needs to access > the disk? Kind of a chicken and egg situation, eh? Drivers and the OS/2 > kernel are bootstrapped and remain resident for obvious reasons. You certainly need to have the driver you're booting the system from around before you boot the system. But obviously, any driver that gets loaded from that boot volume need only be loaded when that driver is actually accessed. The Amiga system has demand loaded device drivers -- are you sure OS/2 doesn't? Sounds pretty primitive if it doesn't. Next thing you're going to be letting me that an OS/2 machine has to be put though some expert-level configuration process to add or possibly even remove a device or memory board. > The dynamic linking capabilities of OS/2, however, allow chunks of code to > be shared between applications with no duplication in memory. DynLink > libraries are one of the major advantages of OS/2 over more primitive PC > operating systems (meaning PC in the generic sense). Of course they are. We know. We've had demand-loaded shared libraries since the Amiga OS first was released in 1985. It's a great idea. > I have been using OS/2 for about nine months now, and can honestly say > that it is a tremendous pleasure to use. That's really the bottom line. If you like it, you'll use it, tell your friends, and the thing may be successful. With IBM behind, it might be anyway. > I totally dig having email running all the time and checking for new > messages, having two compilations running, having my machine set up as a > network server (a piece of cake, and something that can be done at any time > without even rebooting), all while I'm using Word or a telecommunications > program and formatting a floppy. And that's on a 4.6M machine WITH > the DOS box enabled. That strikes me as being pretty good resource > management. It's a good thing that IBM-world folks, or at least some of 'em, are going to start seeing what a real multitasking OS can do for them. We Amigaoids have been shouting this for years, and the typical reaction from a PClone user was, "I won't ever need multitasking, all I want is a few pop-up programs/DAs/ whateveryacallems". I've had several terminal programs, several compilations, a text editor or two, floppy formats, the usual 5 or 10 utility things that run in the background, all running on my Amiga, all at once for a long, long time. Only with about 1/2 that memory... > -- Stephen D. Poole -- t-stephp@microsoft.UUCP -- Mac II Fanatic -- -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
elg@killer.Dallas.TX.US (Eric Green) (05/09/89)
in article <5664@microsoft.UUCP>, t-stephp@microsoft.UUCP (Stephen Poole) says: > I am certainly no big Windows fan and am not defending it. You, however, > completely missed the point. Windows is a more intelligent OS in that it > demand loads code and resources. In terms of memory management in general > it certainly qualifies as a second-generation PC operating system, > regardless of other problems it may have. Overlays on the Amiga are a > laughable substitute for VM or demand loading. From the Manx "C" documentation: " +O[_I_] option: The linker now handles segmentation (overlay) using this option. THe executable code in the object modules that follow will be placed in code sgement _i_. If _i_ is not specified, use the first empty segment number. If the segment already exists, append the code to its end. When segments are used, the linker generates a reference to the symbol .segload which is defined in a library module, _segload.o_. This module MUST be in the root segment for the program to function properly. The module is also available directly in the _lib_ directory. "Segments are loaded into memory as needed and remain in memory until explicitly removed by the program. The program does this by calling the _freeseg()_ routine with the address of a function which is in the segment to be unloaded. "For more information, see the new Code Segmentation section of the Technical Information Chaptor." So, Mr. Microsloth, does this sound a lot like what Windows is doing? I don't know if AmigaDOS itself supports segmentation of this sort, but Manx "C" certainly does, and for quite a while Manx was the choice of the developer community (until Lattice came out with 5.0... I don't know if 5.0 has a similar functionality, not having used Lattice). Amiga programmers haven't generally used this capability, probably because most Amiga programs run quite well in 1 meg of RAM (the Amiga has not yet spawned the mega-program, although Excellence and its ilk are coming close). In any event, all that's required for this kind of thing is an OS that allocates all data structures and programs dynamically, the OS doesn't necessarily have to directly support it. -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | // Join the Church of HAL, and worship at the altar of all computers | |\X/ with three-letter names (e.g. IBM and DEC). White lab coats optional.|
jesup@cbmvax.UUCP (Randell Jesup) (05/09/89)
In article <10848@behemoth.phx.mcd.mot.com> mph@behemoth.UUCP (Mark Huth) writes: >In summary, virtural memory in say a month, protection in 6 months to >a year, and anything more, well, why bother. Note that protection >will eliminate the source of many gurus, but may not allow the resource >recovery that is needed to effectively kill an errant task. That >would require that the OS have the necessary tracking mechanisms built >into it, and I'm not sure that AmigaDOS does enough in this area. One problem with VM: Forbid()/Permit() and Disable()/Enable(). If you allow another task to run when a Forbidden task takes a page fault, then the Forbid() is broken. This is compounded by the fact that many (more likely all) HD's use tasks for their drivers, and thus the forbid MUST be broken in order to page. Disable is, of course, worse. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
limonce@pilot.njin.net (Tom Limoncelli) (05/09/89)
In article <6793@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > The Amiga system has demand loaded device drivers--are you sure OS/2 doesn't? > Sounds pretty primitive if it doesn't. Next thing you're going to be letting > me that an OS/2 machine has to be put though some expert-level configuration > process to add or possibly even remove a device or memory board. [much deleted] Actually, OS/half builds a directed graph (remember your graph theory from undergrad?) of each resource on the system being a node, and the edges are pointers to which resource requested to use which resource. It then does some graph theory algorithms and determines if a node is unreachable; and therefore should be unloaded. Don't believe me? Read Inside OS/2. ...and people wonder why it uses so much memory. Ha! I sort of thought that keeping counts with 16-bit integers would have worked a bit better myself. >Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy > Amiga -- It's not just a job, it's an obsession -- Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net Drew University -- Box 1060, Madison, NJ -- 201-408-5389 Standard Disclaimer: I am not the mouth-piece of Drew University
Ralf.Brown@B.GP.CS.CMU.EDU (05/09/89)
In article <GRIFF.89May8122351@intelob.intel.com>, griff@intelob.intel.com (Richard Griffith) writes: } Well, :-^ you might have a point here. - however, someone running a }new version of Windows on a 25 Mhz `386 still can't match the 7mhz Amy }in speed of graphics, at least as far as functions like window-to-front }and window-to-back... you can ask R. Peck on that one.... Not too surprising, considering the specialized graphics-handling hardware in the Amiga. The 386 has to do all the work itself, usually through a 20 or so wait-state bottleneck at the video board.... (My 10 MHz 286 experiences an average of nine wait states, since the video memory is only available every 1.1 microseconds) -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/31 Disclaimer? I claimed something? You cannot achieve the impossible without attempting the absurd.
dale@boing.UUCP (Dale Luck) (05/09/89)
In article <6793@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > >Amiga shared libraries, fonts, and device drivers are all demand-loaded. Any >more sophisticated form of demand loading should be, IMHO, based on a hardware >driven virtual memory manager. If you haven't isolated the things that are >to be loaded on demand, you're going to be pretty inefficient it would seem. >And without any obvious indication of useage, such as in an Amiga device or >font, or a VM manager's page count tags, the system isn't going to know enough >to unload stuff that hasn't been recently used, at least not without some >serious software overhead. > I think we could granularize the demand loading a bit further. When a demand loaded library is opened it presently loads all the functions. We could instead just load stubs that would then load individual functions as they are actually used. I think this would save alot on memory since many functions are not even used in these libraries. In the instance of the ieee transcendental library, they most used function is sqrt, the hyperbolic cosines just are not used that often. ;+) I'm sure this is true for most demand loaded libraries. -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
les@unicads.UUCP (Les Milash) (05/10/89)
In article <746@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >In article <6793@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >>Amiga shared libraries, fonts, and device drivers are all demand-loaded. Any >>more sophisticated form of demand loading should be, IMHO, based on a hardware >>driven virtual memory manager. > >I think we could granularize the demand loading a bit further. When a >demand loaded library is opened it presently loads all the functions. >We could instead just load stubs that would then load individual >functions as they are actually used. I humbly agree with Dale Luck's Humble Opinion.
alex@mks.UUCP (Alex White) (05/10/89)
In article <5625@microsoft.UUCP> w-glenns@microsoft.UUCP (Glenn Steffler) writes: >OS/2 is a business oriented OS, with extensive network capabilities, in >addition to a rich and quite overwhelming array of multitasking >primatives. OS/2 has memory, and resource protection, vital for multiple Overwhelming array of multitasking primitives? You've got to be kidding. You're right -- it has more than are ever likely to be needed, but it doesn't have standard simple ones like fork(). It doesn't have very good ways to inherit things like signals. The session manager interface is undocumented. [When I asked microsoft it was pointed out to me that you'd only want it for shells, and they provide 3 different shells, and shells are not application programs.]
bmacintyre@watcgl.waterloo.edu (Blair MacIntyre) (05/10/89)
In article <917@mks.UUCP> alex@mks.UUCP (Alex White) writes: >In article <5625@microsoft.UUCP> w-glenns@microsoft.UUCP (Glenn Steffler) writes: >>OS/2 is a business oriented OS, with extensive network capabilities, in >>addition to a rich and quite overwhelming array of multitasking >>primatives. OS/2 has memory, and resource protection, vital for multiple >Overwhelming array of multitasking primitives? >You've got to be kidding. >You're right -- it has more than are ever likely to be needed, but >it doesn't have standard simple ones like fork(). I hate to disappoint you, but fork() is not what most people would consider a "standard multitasking primitive". It is a Unix'ism designed to get over the fact that Unix didn't have any Standard_Multitasking_ Primitives. Considering how old it is, the things that most people would consider standard were still being argued about long after Unix was developed. Standard? SRR, Monitors, Semaphores, maybe pipes (naaa), etc. ... Fork()???? Nope. >It doesn't have very good ways to inherit things like signals. Inherit? Sounds like you're getting back to fork ... but, yes that would be needed for things like process groups I suppose. #define standard (I_LIKE_IT) Blair -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-///-= = Blair MacIntyre, bmacintyre@watcgl.{waterloo.edu, UWaterloo.ca} \\\/// = = now appearing at the Computer Graphics Lab, U of Waterloo! \XX/ = = "Don't be mean ... remember, no matter where you go, there you are." BBanzai=
t-stephp@microsoft.UUCP (Stephen Poole) (05/10/89)
In article <GRIFF.89May8122351@intelob.intel.com> griff@intelob.intel.com (Richard Griffith) writes: > >In article <5664@microsoft.UUCP> t-stephp@microsoft.UUCP (Stephen Poole) writes: >>On my OS/2 box I can have 4M and use it like 16M. That's a good bit more >>valuable than being limited to 8M AND having to pay for it. > Doesn't swapping give you a problem? It doesn't as long as there is a reasonable amount of space on a hard drive for the swapper file. The system is quite configurable as far as VM goes. Of course, the faster the driver the faster the swap. > Well, :-^ you might have a point here. - however, someone running a >new version of Windows on a 25 Mhz `386 still can't match the 7mhz Amy >in speed of graphics, at least as far as functions like window-to-front >and window-to-back... you can ask R. Peck on that one.... Oh, I know about the graphics speed! That's what I enjoy the most about using the Amiga. >>>more elaborate resource and memory management" stuff until you need it - >>>or wouldn't IBM be abel to sell as much H/W? >>That's a ridiculous question. What do you expect the operating system to > Not really - why does the OS absolutely *have* to load all this stuff - >I've seen many PC users you don't have a network, don't want one, can't >use it- why force them to use the code?? - why not allow that segment to >be dynamically configurable? I'm sure that there is more segments like >this that could effectively be removed, due to not being neccessary... There's no NEED to load the network drivers, actually. I guess it's just that OS/2 networking is so much more pleasant than DOS networking that it becomes second nature. I actually did try yanking everything I could from my machine (shutting down the DOS box, not loading network drivers, no PM) and booted with 2M of memory. It was slower to be sure, considering the increased application swapping, but was still usable. Networking under OS/2 is awfully convenient, though. >Sounds good - how long do you wait for code swapping-? (just curious, >I have no idea) - I admit I have doubts about the real need for VMM - >yes, it's useful - no doubt, but - consider: if I have an OS that can >span several Megs of memory and can multitask efficiently within that >space - I can swap between programs with almost no delay (save screen >refresh!) there's no delay in "just a minute! I gotta get that page") >And there will *always* be some kind of a delay... even if a small one. Swapping - as described above. In my normal use I don't ever hit the wall. When I do it's because I was playing with memory allocation and intentionally forcing a thrashing situation. With that said, let me mention that I received via email comments from quite a few Amiga fans (and several of them quite rude) who showered me with a variety of information. Some if it was pretty contradictory, so I'm not sure what to think about it now. A couple of folks mentioned that the Amiga DOES have dynamic linking capability and demand loading and that what I described can be easily done on a 512k Amiga. (Everyone DID tell me that the OS was never taking up user RAM, so expect that is true (though I then wonder why people only have 400K or so free after booting)). Regardless of how slick a job of integrating multitasking into the Amiga OS Commodore has done, none of the Amiga users I have ever known were able to run more than a few programs at once in 512K, and only one if it happened to be a graphics-intensive program. I do happen to like the Amiga, and evidently a number of people thought I was out to destroy their only reason for living, but I still haven't seen it do what OS/2 does for me. >* Richard E. Griffith * Cyrus Hammerhand * -- -- Stephen D. Poole -- t-stephp@microsoft.UUCP -- Mac II Fanatic -- -- -- -- I'm just an Oregon Tech Software Engineering co-op at Micro- -- -- soft. Believe me, nobody here pays attention to my opinions! --
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (05/10/89)
In article <6796@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: > One problem with VM: Forbid()/Permit() and Disable()/Enable(). >If you allow another task to run when a Forbidden task takes a page fault, >then the Forbid() is broken. This is compounded by the fact that many >(more likely all) HD's use tasks for their drivers, and thus the forbid >MUST be broken in order to page. Disable is, of course, worse. > Then establish the following rule by fiat: "If you take a page fault while Forbid()den or Disable()d, you crash." The only reason Forbid() and Disable() exist is to arbitrate the use of shared data areas (am I forgetting something?). We should start encouraging the use of semaphores for this purpose. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
orn@rsp.is (Orn E. Hansen) (05/11/89)
In article <5664@microsoft.UUCP>, t-stephp@microsoft.UUCP (Stephen Poole) says: >I have been using OS/2 for about nine months now, and can honestly say >that it is a tremendous pleasure to use. Until I tried it for myself >I was a member of the sheeplike crowd of folks who had not used it and >believed all the negative comments the reviewers constantly made. The >productivity gains I have realized have been amazing. I totally dig >having email running all the time and checking for new messages, having >two compilations running, having my machine set up as a network server >(a piece of cake, and something that can be done at any time without >even rebooting), all while I'm using Word or a telecommunications >program and formatting a floppy. And that's on a 4.6M machine WITH >the DOS box enabled. That strikes me as being pretty good resource >management. WOW! How'd'ya'do'that? Currently I've got PS/2 Model 80/111 with 4Mb of memory installed running OS/2 EE 1.1 and francly mydear, It's a real horror! If I turn on my communications manager and start an emulation, it can hardly emulate 4800 bps let alone doing all that you mention! I turn on compilation, start formatting a floppy, start up the communications manager and start loading the telecomunications software (for pm) and go take a brake! What TURBINE are you using? In article <1034SCHAFER@RICE>, SCHAFER@RICE.BITNET (Richard A. Schafer) writes: > What communications program are you using? I've just started > working with OS/2 (SE 1.1) and I'm looking for a communications > program. (Yes, I know I could spend the money and upgrade to > Extended Edition, and with the 50% educational discount, I just > might do that, but I'm trying to look at other options, too.) > > Do you know any good source of public domain/shareware programs for > OS/2, or is it too early for things like that? I'd suggest you use the DOS part of your machine for that sort of thing because all communications packages I've seen for OS/2 are horrible. Well maybe not if you don't mind emulating at 2400 or 4800 bps. If you wanted to use an emulation within PM, you probably wouldn't mind. The communications manager for OS/2 comes with a VT100 emulator (7 bit version), if you can't use that (I can't) I know of ANSI X3.64 emulator for it. ---------------------------------------------------------------------------- Orn Hansen UUCP: ...!mcvax!hafro!krafla!rispa2!orn Internet: orn@rsp.is ---------------------------------------------------------------------------- My desktop calculator's performance is still unsatisfactory.
griff@intelob.intel.com (Richard Griffith) (05/11/89)
In article <5681@microsoft.UUCP> t-stephp@microsoft.UUCP (Stephen Poole) writes: >In article <GRIFF.89May8122351@intelob.intel.com> griff@intelob.intel.com (Richard Griffith) writes: >> >>In article <5664@microsoft.UUCP> t-stephp@microsoft.UUCP (Stephen Poole) writes: >>>On my OS/2 box I can have 4M and use it like 16M. That's a good bit more >>>valuable than being limited to 8M AND having to pay for it. >> Doesn't swapping give you a problem? >It doesn't as long as there is a reasonable amount of space on a hard >drive for the swapper file. The system is quite configurable as far as >VM goes. Of course, the faster the driver the faster the swap. Yes - but I don't HAVE to have a hard drive- this brings me back to the point - What, pray tell does IBM Sell? - in a word - Hardware. And MS- bless their groveling, greedy, little hearts won't even CONSIDER releasing a product for the PC's that IBM won't endorse. Especially the OS! - Again - If you're gonna run with OS/2 the amount of MINIMUM hardware is far and again more than what you need for AmigaDOS. Lord, if I have to buy as much hardware as OS/2 would require - I sure as he** wouldn't buy OS/2 - I'd buy UNIX - and it would *still use less space* than OS/2!!!! IBM and MS are cashing in on the collective ignorance of most of the MIS directors out there that have made their positions on the (unfortunate) axiom "Nobody ever got fired for buying IBM"... Maybe it's about time. I've got a few stories about IBM users that would make you think twice about the "technical knowledge" of most of them... All IBM and MS have to do is convince them they *REQUIRE* 4 megs of memory, 40 meg harddisk, VGA card, Multisync monitor, etc.... for each machine. IBM-users are proudly waving their "6 million (or is it 8 now?)" installed systems digits. Ok, but that's not IBM - that's MS-DOS... and I'll bet a goodly portion (what - 50%, more?) are using XT clones running (maybe) 2.11. Now IBM and MS are trying to convince this huge base of people to spend upwards of $4,000 PER MACHINE to upgrade to OS/2. I'm sorry, but this sounds like an evangalist telling me that money is evil and I should give him all my money. :-) For most businesses, upgrading to OS/2 would mean a MAJOR expenditure... figure the average office has what - a dozen or so PC's? - of those probably 75% are XT's... *you* do the math... >Oh, I know about the graphics speed! That's what I enjoy the most about >using the Amiga. good - I'm glad it's good for something :-) :-) >There's no NEED to load the network drivers, actually. I guess it's >just that OS/2 networking is so much more pleasant than DOS networking >that it becomes second nature. I actually did try yanking everything unless you are running one or two machines - which most private people are doing... >Swapping - as described above. In my normal use I don't ever hit the >wall. When I do it's because I was playing with memory allocation and >intentionally forcing a thrashing situation. I'll bet that my swap to another program is several times faster than yours (Don't bet me - you'll lose. *You* have to go the disk, I don't) >With that said, let me mention that I received via email comments >from quite a few Amiga fans (and several of them quite rude) who ^^^^^^^^^^ No doubt, and I'll apologize for any rudness I might have displayed, but remember, we're dealing with what is effectively religon here.... the best computer in the world is: *The One I Bought*, whoever I is...:-) >of folks mentioned that the Amiga DOES have dynamic linking capability >and demand loading and that what I described can be easily done on >a 512k Amiga. (Everyone DID tell me that the OS was never taking up Yep - please note: 512k is a minimum Hardware.... check that against what I said above... I can buy TWO COMPLETE Amiga systems for the cost of upgrading ONE EXISTING PC. I can be twice as "productive..."... >user RAM, so expect that is true (though I then wonder why people >only have 400K or so free after booting)). Regardless of how slick ^^^^ 112k for the OS - Damn sight better than 4000k :-) >a job of integrating multitasking into the Amiga OS Commodore has >done, none of the Amiga users I have ever known were able to run more >than a few programs at once in 512K, and only one if it happened to whadda mean? - I know one individual that runs 8 different utilities while he is editing... is that enough - That's a load more than your average MESSY_Dos machine...:-) >be a graphics-intensive program. I do happen to like the Amiga, and >evidently a number of people thought I was out to destroy their only >reason for living, but I still haven't seen it do what OS/2 does >for me. (see above....) >-- Stephen D. Poole -- t-stephp@microsoft.UUCP -- Mac II Fanatic -- - griff -- * Richard E. Griffith * Cyrus Hammerhand * * "griff" * Household of the Golden Wolf * * BiiN, Hillsboro Ore. * Dragons' Mist * * UUCP: ...[!uunet]!tektronix!biin!griff * An Tir * ************************************************************************** * These are MY opinions, if BiiN wanted them, They'd pay for `em! *
elg@killer.Dallas.TX.US (Eric Green) (05/11/89)
in article <11609@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) says: > In article <6796@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >> One problem with VM: Forbid()/Permit() and Disable()/Enable(). >>If you allow another task to run when a Forbidden task takes a page fault, >>then the Forbid() is broken. This is compounded by the fact that There are those of us who would say "So what?". Forbid/Permit, in my experience, are most often used when grabbing a system resource. Breaking it only hurts if you access one of those resources. Since the only program accessing the SCSI resources is the HD driver, breaking it thus isn't much of a problem. On the other hand, there are some programs which use Forbid/Permit around timing-critical code, e.g. a program which twiddles the printer port to do weird and wonderful things such as a 1541-style bus. I can see where there'd be a problem there, alas... >> Disable is, of course, worse. Understatement of the year ;-). > Then establish the following rule by fiat: > > "If you take a page fault while Forbid()den or Disable()d, you > crash." Sorry, Leo, that breaks the First Commandment: "Thou Shalt Not Break Existing Programs." I sort of like the solution that Dave Haynie suggested -- adding a flag to the task structure that says, "You can put me into virtual memory." This info would have to be put where it could be accessed by e.g. AllocMem. If this flag is not set, the program's pages are locked into "real" memory. This would require MAJOR hacking to AllocMem, basically adding the resource tracking that everybody so clamors for (if you get eight AllocMem calls for 8-byte structures for task X, you don't want to allocate 8 pages!), plus some hacking of hacking of the task switcher (boy, I'm glad y'all said "Don't mess with the Process structure!" because adding another flag to the Task structure will make the offsets wrong for existing programs accessing the Process structure). By the way, that's not a violation of the First Commandment, since CATS has been saying for the past couple of years that the Process structure will probably change.... -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | // Join the Church of HAL, and worship at the altar of all computers | |\X/ with three-letter names (e.g. IBM and DEC). White lab coats optional.|
alex@mks.UUCP (Alex White) (05/12/89)
In article <9616@watcgl.waterloo.edu> bmacintyre@watcgl.waterloo.edu (Blair MacIntyre) writes: >In article <917@mks.UUCP> alex@mks.UUCP (Alex White) writes: >>In article <5625@microsoft.UUCP> w-glenns@microsoft.UUCP (Glenn Steffler) writes: >>>OS/2 is a business oriented OS, with extensive network capabilities, in >>>addition to a rich and quite overwhelming array of multitasking >>>primatives. OS/2 has memory, and resource protection, vital for multiple >>Overwhelming array of multitasking primitives? >>You've got to be kidding. >>You're right -- it has more than are ever likely to be needed, but >>it doesn't have standard simple ones like fork(). > >I hate to disappoint you, but fork() is not what most people would >consider a "standard multitasking primitive". It is a Unix'ism designed Great. Ok, how do I do it without fork? DosExecPgm has a lot of options, but it doesn't have an array of open file descriptors to pass to the child. You have to go to grotesque contortions of dup'ing and moving file descriptors around, setting close- on-exec bits in order to set the child's file descriptors up the way you want. (You CAN however do it) It doesn't have an array of signal settings to set up default signals for the child. (You CAN'T do this properly) Sure this kind of stuff isn't used very often in strict application programs, but how do you reasonably join things together with pipes? Without fork, it is NOT possible to implement say the standard unix shell because of () [subshells using the environment of the parent shell]. I've cobbled together a fork(), but its hardly the same doing it at the user level as if the kernel did it. You can't even pass args in the unix argc, argv method! Sure, DosExecPgm actually has a real argv formatted just like unix's argv -- unfortunately DosStartSession doesn't. Since cmd.exe appears to always use DosStartSession, all args are passed as argv[1], so on the off chance that you might sometime want a program called from cmd.exe, you have to have all that cruft to parse your own args... By the way, on a slightly different topic, did you know you can't delete or rename a file that is being executed out of? You can rename the directory first however, then it works... Talk about bad implementations...
bcw@rti.UUCP (Bruce Wright) (05/12/89)
In article <6793@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: > Of course, I have yet to hear complaints about OS/2 being too fast... I have *NEVER* heard anyone complain because their {machine, operating system} was too fast! (buggy code in process control systems excepted). Even the people using the Cray think it's a pretty good machine but needs to be a bit faster ... Bruce C. Wright
coy@ssc-vax.UUCP (Stephen B Coy) (05/13/89)
In article <5664@microsoft.UUCP>, t-stephp@microsoft.UUCP (Stephen Poole) writes: > As everyone is aware, there > is a significant amount of overhead associated with an OS with advanced > networking and memory management capabilities, but that megabyte or two > of overhead most assuredly leads to far more efficient memory utilization > and connectivity. What about CPU overhead. Recently I checked out the April issue of MIPS magazine. In it they review a few 25Mhz 386 machines. In doing their benchmarks they test the systems running 3 different OS's; DOS, Xenix, and OS/2. Looking at the benchmark results I get the impression that system performance under OS/2 is about 40% less than under DOS. How good can resource management be if it consumes 40% of the CPU? This isn't intended as an OS/2 flame. I don't know enough about OS/2 to flame it. But the numbers presented by MIPS make OS/2 look horrible. What's the truth? > -- Stephen D. Poole -- t-stephp@microsoft.UUCP -- Mac II Fanatic -- > -- -- > -- I'm just an Oregon Tech Software Engineering co-op at Micro- -- > -- soft. Believe me, nobody here pays attention to my opinions! -- Stephen Coy uw-beaver!ssc-vax!coy Bush knew.
doug@xdos.UUCP (Doug Merritt) (05/13/89)
In article <2948@rti.UUCP> bcw@rti.UUCP (Bruce Wright) writes: > >I have *NEVER* heard anyone complain because their {machine, operating >system} was too fast! Naturally. Although in a different area it happens: I read a paper some years ago discussing problems with an experimental user interface that was too fast...they had hot special purpose hardware, and found that when the display changed it often happened too fast to notice, leaving users confused, and taking several seconds to re-orient. At the time I said, "wish we had problems like that!" (I was using 9600 baud vt220's on Intel 310's: 286 with 4-6 users running Xenix, blech). Since then I've experienced this problem frequently, with Blitz on the Amiga, and various software on Suns. It actually is helpful to have some finite-time transition to help cue the perceptual system to the fact that a change occurred. This is one of the charms of wicon. This is going to be more and more of an issue in user interfaces in the years to come; y'all be sure to keep it in mind when writing software! Doug -- Doug Merritt {pyramid,apple}!xdos!doug doug@xdos.com Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary "Of course, I'm no rocket scientist" -- Randell Jesup, Capt. Boinger Corps
bobmon@iuvax.cs.indiana.edu (RAMontante) (05/13/89)
coy@ssc-vax.UUCP (Stephen B Coy) <2649@ssc-vax.UUCP> : [MIPS tests 25MHz '386 boxes. In...] -doing their benchmarks they test the systems running 3 different -OS's; DOS, Xenix, and OS/2. Looking at the benchmark results I get -the impression that system performance under OS/2 is about 40% less -than under DOS. How good can resource management be if it consumes -40% of the CPU? 40% sounds a bit high, but the contrast to MSDOS isn't really fair. MSDOS doesn't have to do *any* resource management, in the sense that it needn't keep track of which process has a resource (since there's only one process at any time). On the other hand, every TSR has to do its own management in terms of checking whether it's safe to do disk I/O or whatever. The amount of CPU spent in overhead is also a function of system load. It's possible for one OS to be extremely good with a few processes but degrade badly as it overloads, while another OS can be a bit worse at low loads but stay pretty much the same until its memory chips begin to smoke.
bcw@rti.UUCP (Bruce Wright) (05/13/89)
In article <2649@ssc-vax.UUCP>, coy@ssc-vax.UUCP (Stephen B Coy) writes: > What about CPU overhead. Recently I checked out the April issue of > MIPS magazine. In it they review a few 25Mhz 386 machines. In > doing their benchmarks they test the systems running 3 different > OS's; DOS, Xenix, and OS/2. Looking at the benchmark results I get > the impression that system performance under OS/2 is about 40% less > than under DOS. I haven't seen the MIPS issue that you refer to, and I haven't done any benchmarks on OS/2, but there are a few things you have to be very careful about when you read "benchmark" articles from the general press: 1) In comparing a multitasking and a singletasking operating system, it is not fair to compare the multitasking system running several {jobs, tasks, processes depending on the OS terminology} unless the tasks are completely heterogeneous. For example, a mix consisting of the classical CPU-bound "soak" job, a database disk thrasher, and a terminal I/O bound text editor. If you have several tasks competing for the same resource it isn't really very surprising that they can't get that resource to do more than one task can get it to do! This is especially true of disk drives, where moving the disk arm can cause a BIG time penalty and make two task doing disk I/O more than twice as slow as one. This point seems to elude many of the people who write "benchmark" articles for the popular press. 2) In general, you should not expect that the multitasking system will run equally fast as the single tasking system given the same amount of memory. IF the single tasking system (or the application) can do things like increase its disk cache or otherwise take advantage of the larger amount of memory, the single tasking system will win. (on the other hand, MS-DOS is really not all that intelligent about taking advantage of memory to increase speed - though some programs that run under it are). 3) What you are buying with multitasking is the ability to use several resources at once (like run a compile in the background while you edit a file in the foreground) and (possibly, depending on your application) an ability to have several tasks waiting for various events. All this does take memory, and some CPU time. The hope is that by allowing different processes to complement their use of resources that more total work can get done; but you can almost always set up pathological cases. 4) If they are comparing OS/2 using the Presentation Manager then I expect it would be slower ... without significant hardware assists it's hard for a graphics based system to compete with a text based system. 5) It is quite possible for a benchmark to home in on a particular bottleneck on the system and make the system look much worse than it would look in a real environment. Many of the authors of the benchmark "results" that you see in magazines don't seem to have a very good grasp of this. Having said all this I must admit that my experience with OS/2 is limited; a couple of us played around with it for a couple of days a while back to get a feel for whether it would be useful for some projects we were thinking about. My impression at the time (this was before the Presentation Manager) was that it was not unreasonably slow - 40% sounds awfully high, well within human perceptual ability to detect for functions which take any amount of time. This was not on any super machine, something like a 12MHz '286, and for the most part it didn't feel that different from MS-DOS in terms of its general throughput and responsiveness. Some things were perhaps a bit slower, and others perhaps a bit faster, but subjectively a 40% slowdown sounds unreasonable. We rejected it for other reasons - primarily because the complexity of the system service interface did not justify the benefits for our application (which was pretty special-purpose). Looking at this I realize it's longer than I intended - sorry about that. Maybe someone who has done more scientific benchmarking on the system can address the specific questions about the actual speed of OS/2. Bruce C. Wright
jack@csccat.UUCP (Jack Hudler) (05/13/89)
In article <925@mks.UUCP> alex@mks.UUCP (Alex White) writes: >In article <9616@watcgl.waterloo.edu> bmacintyre@watcgl.waterloo.edu (Blair MacIntyre) writes: >>In article <917@mks.UUCP> alex@mks.UUCP (Alex White) writes: >>>In article <5625@microsoft.UUCP> w-glenns@microsoft.UUCP (Glenn Steffler) writes: >>>>OS/2 is a business oriented OS, with extensive network capabilities, in >>>>addition to a rich and quite overwhelming array of multitasking >>>>primatives. OS/2 has memory, and resource protection, vital for multiple >>>Overwhelming array of multitasking primitives? >>>You've got to be kidding. >>>You're right -- it has more than are ever likely to be needed, but >>>it doesn't have standard simple ones like fork(). >> >>I hate to disappoint you, but fork() is not what most people would >>consider a "standard multitasking primitive". It is a Unix'ism designed > >Great. >Ok, how do I do it without fork? >DosExecPgm has a lot of options, but it doesn't have an array of >open file descriptors to pass to the child. You have to go to grotesque >contortions of dup'ing and moving file descriptors around, setting close- >on-exec bits in order to set the child's file descriptors up the way you >want. (You CAN however do it) >It doesn't have an array of signal settings to set up default signals >for the child. (You CAN'T do this properly) Perhaps you need to redefine your concept of multitasking? The implementation of multi-tasking under OS/2 is the 'thread', it very powerful, provided you alter your concept. Our PM app uses threads, and I must say it was more difficult to implement our app using 'fork', however it does work using this primitive form of multitasking. Jack -- Classic Quotes from STNG: "Pen Pals" Picard: Her society is aware .. that there is intersteller life? Data: No Sir. Picard: Oooops..
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (05/14/89)
: 2) In general, you should not expect that the multitasking system will
: run equally fast as the single tasking system given the same amount
: of memory. IF the single tasking system (or the application) can
: do things like increase its disk cache or otherwise take advantage
: of the larger amount of memory, the single tasking system will win.
: (on the other hand, MS-DOS is really not all that intelligent about
: taking advantage of memory to increase speed - though some programs
: that run under it are).
This above is a different issue alltogether and not related to
multi-tasking / single-tasking at all. Since when can't a task in a
multi-tasking system tell the system (if the system supports it) that it
wants a cache to be arranged differently? The point is that this is a
function of whether the OS has the capability, not if the OS is multi-tasking.
you might be talking about this fact: In a single-tasking system
people can generally write programs which bypass the OS. This is not
considered a good thing, by the way.
: 3) What you are buying with multitasking is the ability to use several
: resources at once (like run a compile in the background while you
: edit a file in the foreground) and (possibly, depending on your
: application) an ability to have several tasks waiting for various
: events. All this does take memory, and some CPU time. The hope is
: that by allowing different processes to complement their use of
: resources that more total work can get done; but you can almost
: always set up pathological cases.
I would put it slightly differently. Multitasking gives the computer
the capability to fully utilize all its resources. Coupled with DMA and other
hardware assist mechanisms, one can usually run all the resources
simultaniously at 100% efficieny. For example, you could run a disk bound
program and a CPU bound program simultaniously and they would both run at
FULL speed. In effect, twice as fast as a single tasking system could ever
possibly do it.
And here, I should mention that the term 'resource' as used by
Bruce and I here refers to anything modular: Disk IO, terminal IO, one or
independant program, memory, etc... For example, running a text editor and
a CPU bound program still results in nearly 100% efficiency for both because
the CPU bound program will still get 95% of the CPU and the user will still
see relatively quick response to typing in the editor.
Whereas, in a single tasking system you could run only one program,
say the editor, and 95% of the CPU would be wasted. Or run only the CPU
bound program and you have to wait for it to finish before you can startup
the editor.
Three way example: You are running three tasks. (1) CPU bound program,
(2) DISK bound program, (3) text editor. All three will run at nearly 100%
efficiency.... how close you get depends on other factors such as DMA, etc...
on *real* UNIX machines the above scheme would run at essentially 100%
efficiency (each task would run as fast as if it were the only task in the
system).
Other examples don't really count. Running two CPU bound programs
results in each going at half speed... the same as for a single tasking
system. Running two disk bound programs is quite different... for instance,
if you have 20MB of disk cache you could quite conceviably run the disk
bound programs nearly at full speed (or they become CPU bound programs).
On the Amiga, running two disk bound programs will run at a little less
than half speed... it depends on the DMA capabilities and the manner of
access by the programs.
: 5) It is quite possible for a benchmark to home in on a particular
: bottleneck on the system and make the system look much worse than
: it would look in a real environment. Many of the authors of the
: benchmark "results" that you see in magazines don't seem to have
: a very good grasp of this.
Yes, absolutely. For instance, a sequent might have 12 processors
but most benchmarks use only one. Never mind the fact that it takes 20
compiles running simultaniously to bring the load average on the machine to
1.00!
> Bruce C. Wright
-Mattallbery@ncoast.ORG (Brandon S. Allbery) (05/15/89)
As quoted from <May.9.01.13.32.1989.2481@pilot.njin.net> by limonce@pilot.njin.net (Tom Limoncelli): +--------------- | In article <6793@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: | > The Amiga system has demand loaded device drivers--are you sure OS/2 doesn't? | > Sounds pretty primitive if it doesn't. Next thing you're going to be letting | > me that an OS/2 machine has to be put though some expert-level configuration | > process to add or possibly even remove a device or memory board. | [much deleted] | | Actually, OS/half builds a directed graph (remember your graph theory | from undergrad?) of each resource on the system being a node, and the | edges are pointers to which resource requested to use which resource. | It then does some graph theory algorithms and determines if a node is | unreachable; and therefore should be unloaded. +--------------- AAAAAGH!!!!! So even if you don't use the d*mned LAN Manager, you have to have enough memory to load it, along with everything else on the system? +--------------- | Don't believe me? Read Inside OS/2. ...and people wonder why it uses | so much memory. Ha! I sort of thought that keeping counts with | 16-bit integers would have worked a bit better myself. +--------------- But you still have to load everything first... or load each, one at a time, and keep an array of references somewhere, then use that array to load the desired modules *again*... bogus, s-l-o-w! Funny, the 7300 had runtime-loadable device drivers and ran fine in 2MB of memory. It even supported virtual memory. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
daveh@cbmvax.UUCP (Dave Haynie) (05/16/89)
in article <2948@rti.UUCP>, bcw@rti.UUCP (Bruce Wright) says: > Summary: Can a machine *REALLY* be too fast?! > Xref: cbmvax comp.sys.ibm.pc:33258 comp.sys.amiga:36309 > In article <6793@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: >> Of course, I have yet to hear complaints about OS/2 being too fast... > I have *NEVER* heard anyone complain because their {machine, operating > system} was too fast! (buggy code in process control systems excepted). > Even the people using the Cray think it's a pretty good machine but > needs to be a bit faster ... Well, my 68030 Amiga with memory resident C Compilers was getting so fast at compiling C code, I didn't have time to do anything while I ran the compiler. Not necessarily something everyone's going to mind, I'm sure, but I just program for fun, and really like to think I can go get a beer without wasting any useful time. For the moment, I've solved this problem by switching to the C++ compiler, which should last me until a faster C++ comes out, or the 68040... > Bruce C. Wright -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
coy@ssc-vax.UUCP (Stephen B Coy) (05/16/89)
In article <20694@iuvax.cs.indiana.edu>, bobmon@iuvax.cs.indiana.edu (RAMontante) writes: > coy@ssc-vax.UUCP (Stephen B Coy) <2649@ssc-vax.UUCP> : > [MIPS tests 25MHz '386 boxes. In...] > -doing their benchmarks they test the systems running 3 different > -OS's; DOS, Xenix, and OS/2. Looking at the benchmark results I get > -the impression that system performance under OS/2 is about 40% less > -than under DOS. How good can resource management be if it consumes > -40% of the CPU? > > 40% sounds a bit high, OK. Here's the numbers I was referring to: The benchmark program is the current version of dhrystones. The benchmark was run both with and without register varaibles. Only one DOS timing is given since the numbers were the same for both cases. Under OS/2 the 1st number is without register variables, the 2nd is with. All the systems are 25Mhz 386's. system DOS OS/2 ACER 1100/25 11970 5925 6153 ALR FlexCache 25 286 12281 6486 6760 Compac Deskpro 386/25 11203 5783 6000 DEL System 325 11671 6000 6153 Everex Step 386/25 12445 6666 6956 IBM PS/2 Model 70A21 11745 6486 6760 Well, the way I count it the overhead is from 42.4% to 50.5%. > but the contrast to MSDOS isn't really fair. MSDOS > doesn't have to do *any* resource management, in the sense that it needn't > keep track of which process has a resource (since there's only one process > at any time). On the other hand, every TSR has to do its own management > in terms of checking whether it's safe to do disk I/O or whatever. Sorry, I didn't make myself clear. I know that MS-DOS is doing absolutely nothing. Therefore I looked at the DOS numbers as being the absolute best you could get out of the system ie the bare-bones, down-to-the-metal raw cpu power available. Then, looking at the OS/2 numbers, I saw that up to half of that cpu power was lost to system overhead. And I thought that stunk. > The amount of CPU spent in overhead is also a function of system load. > It's possible for one OS to be extremely good with a few processes but > degrade badly as it overloads, while another OS can be a bit worse at low > loads but stay pretty much the same until its memory chips begin to smoke. But an OS that starts with 40% to 50%?!? Unless you think that the good folks at MIPS magazine were generating Mandelbrot images in the background while running the benchmarks. :-) Stephen Coy uw-beaver!ssc-vax!coy
coy@ssc-vax.UUCP (Stephen B Coy) (05/16/89)
In article <2954@rti.UUCP>, bcw@rti.UUCP (Bruce Wright) writes: > I haven't seen the MIPS issue that you refer to, and I haven't done any > benchmarks on OS/2, but there are a few things you have to be very > careful about when you read "benchmark" articles from the general press: > > 1) In comparing a multitasking and a singletasking operating system, > it is not fair to compare the multitasking system running several > {jobs, tasks, processes depending on the OS terminology} unless > the tasks are completely heterogeneous. True. The benchmark I was refering to was dhrystones. The actual numbers I have posted in my previous article. I understand that even "at rest" a multitasking OS usually has at least a handful of processes active. Fine. But when this system overhead eats up 40 to 50% of a 25Mhz 386 I start to have questions. re "general press" the people at MIPS magazine seem to have their heads on straight. I've been told that their benchmarking suite was discussed in some detail in their February issue. > 2) In general, you should not expect that the multitasking system will > run equally fast as the single tasking system given the same amount > of memory. The systems benchmarked were all "fully loaded" and as such had plenty of memory to run the dhrystones benchmark with megs to spare. > 3) What you are buying with multitasking is the ability to use several > resources at once (like run a compile in the background while you > edit a file in the foreground) and (possibly, depending on your > application) an ability to have several tasks waiting for various > events. All this does take memory, and some CPU time. The hope is > that by allowing different processes to complement their use of > resources that more total work can get done; but you can almost > always set up pathological cases. I understand the benefits of multi-tasking. My Amiga has been cranking along just fine since Oct '85, multi-tasking all the way. Running the Dhrystones benchmark on an empty machine is not a pathological case by a long shot. Although the MIPS benchmarks sure make running it under OS/2 seem like a pathetic case. (Cheap shot, I know. Sorry :-) > 4) If they are comparing OS/2 using the Presentation Manager then I > expect it would be slower ... without significant hardware assists > it's hard for a graphics based system to compete with a text based > system. Dhrystones is not I/O dependent. Next. > 5) It is quite possible for a benchmark to home in on a particular > bottleneck on the system and make the system look much worse than > it would look in a real environment. Many of the authors of the > benchmark "results" that you see in magazines don't seem to have > a very good grasp of this. Ok, so what is it about OS/2 that causes it to slow down dhrystones so much? Hint: the actual number of cycles executed by dhrystones under each OS is about the same depending on compiler variations. The "bottleneck" is not the benchmark picking on the system but the system being too fat. > Maybe someone who has done more scientific benchmarking on the system can > address the specific questions about the actual speed of OS/2. > > Bruce C. Wright I'm sorry if this came off as a flame but the tone of your response implied that I was too ignorant to know what I was talking about and this offended me a touch. I too would like to see some other comparisons done. If anyone has any, please post. Stephen Coy uw-beaver!ssc-vax!coy
les@unicads.UUCP (Les Milash) (05/16/89)
In article <6876@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >Well, my 68030 Amiga with memory resident C Compilers was getting so >fast, I didn't have time to[...] >a beer without wasting any useful time. For the moment, I've solved this >problem by [...], which should last me until the 68040. if this is a widespread problem, i'm fairly sure i could whip up a "application decellerator" that'd fit between the 68xxx and its socket. it'd draw a wee bit of 5v, and it'd have a trim-pot to adjust the doodoo cycle, so you could make your machine arbitrarily slow. on most machines you can do this in software. in fact i've got some rays you could trace for me... i'm trying to animate a ray-traced grand-canyon fly-thru with kajya-style diffuse reflections. let's see, 4000000 polygons times 12800 rays times 16 for antialiasing times 30 frames a second times 60 seconds a minute... yeah that should do it. i'll mail you a few floppies and...
ellisond@gtephx.UUCP (Dell Ellison) (05/17/89)
In article <2948@rti.UUCP>, bcw@rti.UUCP (Bruce Wright) writes: > In article <6793@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: > > Of course, I have yet to hear complaints about OS/2 being too fast... > > I have *NEVER* heard anyone complain because their {machine, operating > system} was too fast! (buggy code in process control systems excepted). > Even the people using the Cray think it's a pretty good machine but > needs to be a bit faster ... Bruce, I am sure that Dave wrote that with a little bit of sarcasm with the intention of meaning that OS/2 was not terribly fast.
bcw@rti.UUCP (Bruce Wright) (05/17/89)
In article <2656@ssc-vax.UUCP>, coy@ssc-vax.UUCP (Stephen B Coy) writes: > I'm sorry if this came off as a flame but the tone of your response > implied that I was too ignorant to know what I was talking about and > this offended me a touch. The posting wasn't intended to imply anything particular ... as I said, I haven't seen the article and had no idea what's in it (your later postings have helped somewhat). Sometimes I have seen benchmark articles in magazines which were stated with *extreme* confidence by their authors who obviously didn't understand what it was that they were measuring - sometimes this may not be obvious to someone who reads the article but is not familiar with the specific product. If OS/2 is *really* taking 40% of the CPU away from a pure compute-bound process on an otherwise idle machine then something is wrong -- I don't know of *ANY* multitasking system that is *THAT* bad. I suspect that there is some hidden variable (such as a call to a clock timer or some- thing) that is causing the difference - do you have the source to the actual benchmark that they ran? I have heard of such "innocuous" system calls really messing up benchmarks in funny ways that are not always easy to understand or predict. Please don't be offended by my previous posting - it wasn't meant to be trying to imply anything particular about you or anybody else. It was written with very little information about the specific case you brought up. My only point was that when trying to get quantitative data from the popular press you need to have several pounds of salt available. Bruce C. Wright
alex@mks.UUCP (Alex White) (05/18/89)
In article <2762@csccat.UUCP> jack@csccat.UUCP (Jack Hudler) writes: > Perhaps you need to redefine your concept of multitasking? > The implementation of multi-tasking under OS/2 is the > 'thread', it very powerful, provided you alter your concept. > Our PM app uses threads, and I must say it was more difficult > to implement our app using 'fork', however > it does work using this primitive form of multitasking. I have to agree with you, for a standard application, threads may well be more useful. However, for your average system program (e.g. shell, editor) fork/exec is more useful. And somehow, it seems that there are far more of these system type programs around than pure applications. Virtually every application wants to allow escapes to shells, or filter your data thru arbitrary programs.
daveh@cbmvax.UUCP (Dave Haynie) (05/18/89)
in article <2656@ssc-vax.UUCP>, coy@ssc-vax.UUCP (Stephen B Coy) says: > Xref: cbmvax comp.sys.ibm.pc:33486 comp.sys.amiga:36543 > The systems benchmarked were all "fully loaded" and as such had > plenty of memory to run the dhrystones benchmark with megs to spare. I think part of the reason they get much better results with Dhrystone on the MS-DOS vs. OS/2 systems may be nothing more than caching effects. Most of those high-end 25Mhz and 33MHz 80386 systems have between 16k and 64k of external cache. Here on my Amiga, Dhrystone 2.1 comes out at around 20k, certainly most if not all of which would fit in the cache of these machines. Add OS/2, and if, during the course of any Dhrystone run, you get a context switch, I'll bet you end up dumping cache on the switch (UNIX would have to as well, AmigaOS wouldn't) and greatly slowing the system. While the test does show the absolute maximum speed each machine can do with a Dhrystone, it's not very telling in real life situations. I haven't seen MIPS mention cache effects in detail on their benchmark explanations, but they otherwise seem to handle them pretty well. This is also a good explanation as to why their best MS-DOS machines run faster Dhrystones than anything short of a good RISC system, but fast '030 machines do better under UNIX than the same fast '386 machines under UNIX. > I too would like to see some other comparisons done. If anyone has > any, please post. I'm seeing around 7000 Dhrystones on an A2630 equipped A2000 and the best set of Lattice 5.02 compiler switches. With a fat external cache at the same speed, this might come close to being doubled. > Stephen Coy > uw-beaver!ssc-vax!coy -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
hubey@pilot.njin.net (Hubey) (05/18/89)
In article <6910@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > I'm seeing around 7000 Dhrystones on an A2630 equipped A2000 and the best > set of Lattice 5.02 compiler switches. With a fat external cache at the > same speed, this might come close to being doubled. > Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" In the last issue of Sentry (I don't have it with me), the GVP board with a MC68030 and MC 68882 running at 33 MHz (I think) says that the A2000 gets over 11,000 Dhrystones. Is that good ?? :-). I think in the same issue the Sun 3/80 registers around 11,000..... -- hubey@OSultrix.montclair.edu hubey@pilot.njin.net hubey@apollo.montclair.edu VOICE: 201-893-5269 ...!rutgers!njin!hubey
john@jwt.UUCP (John Temples) (05/18/89)
In article <2655@ssc-vax.UUCP> coy@ssc-vax.UUCP (Stephen B Coy) writes: > [ about MIPS benchmarks of 386 boxes ] >In article <20694@iuvax.cs.indiana.edu>, bobmon@iuvax.cs.indiana.edu (RAMontante) writes: >> [ contrasting OS/2 to DOS benchmarks isn't fair ] While I agree that comparing OS/2 to DOS benchmarks isn't really fair, what I found far more interesting in the MIPS articles was the comparison between Unix and OS/2. In the single-tasking benchmarks (e.g. Dhrystone) Unix was some 20% faster than OS/2. This difference might very well be attributed to Unix running 32-bit code versus OS/2's 16-bit code; I don't know. But in the multitasking benchmarks, Unix consistently had a 3 to 1 performance edge over OS/2. It sounds like OS/2 has a long way to go compete with Unix in performance. -- John Temples - UUCP: {uiucuxc,hoptoad,petsd}!peora!rtmvax!bilver!jwt!john
wtm@neoucom.UUCP (Bill Mayhew) (05/18/89)
The dhrystone benchmark normally doesn't make calls to hardware-specific devices, as dhrystone is supposed to compile and run on virtually any machine. A 2:1 difference in the dhrystone/sec between msdos and os/2 is suspicious. One might want to inquire about what compilers were used to generate the code run in the mips magazine test. I have seen close to 2:1 differences between Microsoft Optimizing C 5.0 and the Green Hills or Phar-Lap compilers for msdos. The former was emitting 16 bit code, while the latter two were emitting 80386 code. To the best of my knowledge, the C compiler included with os/2 developemnt system generates only 16 bit code. How this applies to the Amiga, I'm not sure... Bill wtm@impulse.UUCP
darin@nova.laic.uucp (Darin Johnson) (05/19/89)
>I have to agree with you, for a standard application, threads may well >be more useful. >However, for your average system program (e.g. shell, editor) >fork/exec is more useful. But very few OS'es have fork() and get along just nicely. Most UNIX gurus will readily admit that roughly 90% of fork()'s are followed immediately by exec(). This is the reason for vfork() and fexec(). For a lot of OS'es there is a single call that does this sort of thing, let's call it spawn(). It usually takes the name of a program, and possibly an input and output stream. This type of call can be made to work on nearly any multitasking system, even if fork() is not available. This command works great for editors and mailers when you want to create a "subshell" without leaving the application. Many non-unix shells use a similar method to run commands in the background (many don't bother with a new process for each command). And if you have a huge application that wants to spawn a tiny program, this is more efficient than fork (except for intelligent fork()s that use copy on modify). The nice thing is that this type of call can be built on top of other multitasking primitives. If you need the primitive calls they are there, but for the general case you don't have to do all the hard work yourself. I would say spawn() is more useful than fork/exec, at least more widely used. (I like UNIX, but you have to admit that its method of process creation is pretty unique) Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) We now return you to your regularly scheduled program.
daveh@cbmvax.UUCP (Dave Haynie) (05/19/89)
in article <May.17.21.33.39.1989.14040@pilot.njin.net>, hubey@pilot.njin.net (Hubey) says: > Xref: cbmvax comp.sys.ibm.pc:33552 comp.sys.amiga:36645 > In article <6910@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >> I'm seeing around 7000 Dhrystones on an A2630 equipped A2000 ... > In the last issue of Sentry (I don't have it with me), the GVP board > with a MC68030 and MC 68882 running at 33 MHz (I think) says that > the A2000 gets over 11,000 Dhrystones. Is that good ?? :-). 11k-12k Dhrystones/sec. is what I'd expect under Lattice V5.02, a 33MHz '030, and a decent 32 bit memory system supporting with burst cache line fill. > I think in the same issue the Sun 3/80 registers around 11,000..... I'd be really surprised to see the Sun 3/80 do that well. It's '030 based, and probably has memory system more closely matched to it's CPU speed than the GVP or Commodore boards. And possibly a better compiler. But it's only running a 20MHz. Though if it had around 32k of static cache, maybe.... > > hubey@OSultrix.montclair.edu hubey@pilot.njin.net > hubey@apollo.montclair.edu VOICE: 201-893-5269 > ...!rutgers!njin!hubey -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
ugdill@cs.Buffalo.EDU (Peter Dill) (05/19/89)
In article <6918@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > >11k-12k Dhrystones/sec. is what I'd expect under Lattice V5.02, a 33MHz '030, >and a decent 32 bit memory system supporting with burst cache line fill. > >> I think in the same issue the Sun 3/80 registers around 11,000..... > >I'd be really surprised to see the Sun 3/80 do that well. It's '030 based, >and probably has memory system more closely matched to it's CPU speed than >the GVP or Commodore boards. >Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" I know that there is nothing that you can do about this, BUT under the heading of wishful thinking... if Commodore released a configuration of the 2000 with the 2630 (like the Amiga 2530?) at 33Mhz they could get the cover of Byte. Plus every time in the future they do a "PC priced workstations"/ "Workstation priced PCs" piece the machine would get a mention in the rundown along with a price/preformance comparsion (like the next does). Lots of free publicity and you'd get the satisfaction of know that Byte was being YOUR dupes for a change. Peter Dill ugdill@sunybcs | In /// | "As a rule of course, we just ugdill@joey.cs.buffalo.edu | /// |don't care. " v114nj32@ubvms.cc.buffalo.edu | /// |- _Logical Design of Digital ..!rutgers!sunybcs!ugdill |\\\/// We | Circuits_ | \XX/Trust| C.M.Reeves --------------------------------------------------------------------------------
rodney@pyr.gatech.EDU (Rodney Ricks) (05/19/89)
In article <6918@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <May.17.21.33.39.1989.14040@pilot.njin.net>, hubey@pilot.njin.net (Hubey) says: >> I think in the same issue the Sun 3/80 registers around 11,000..... No, not quite. I have the issue in question in front of me. The prices, Dhrystone ratings, clock speeds and RAM amounts follow; quoted, of course, without permission. Computer Price Dhrystones CPU/MHz RAM Megs Sun 3/80 $12,595 5,154 68030/20 MHz 4 Meg of RAM Compaq 386/20 21,421 5,705 80386/20 MHz 8 Meg of RAM Apollo DN3500 19,750 7,075 68030/25 MHz 8 Meg of RAM Sun 3/470 40,900 11,748 68030/33 MHz 8 Meg of RAM Amiga 2000 5,600 7,273 68030/25 MHz 5 Meg of RAM with Impact ????? >11,000 68030/32 MHz Crystal 5 Meg of RAM A3001-4MB RAM, 40 Meg Quantum HD Note that the 11,000 Dhrystones/sec Sun system is the $40,900 Sun 3/470, not the Sun 3/80. Also note that the 11,000 Dhrystones/sec timing was not included in the chart in the article, as it was done by driving the 25 MHz 68030 way beyond the rated speed by using a 32 MHz crystal, causing overheating. There is also a good review of the A-MAX MacIntosh Emulator in the same issue of the Sentry. >> hubey@OSultrix.montclair.edu hubey@pilot.njin.net >> hubey@apollo.montclair.edu VOICE: 201-893-5269 >> ...!rutgers!njin!hubey >-- >Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy > Amiga -- It's not just a job, it's an obsession
faerber@iraul1.ira.uka.de (Hans-Juergen Faerber) (05/19/89)
###########################################
I am posting this for a friend who has no
possibility to post news.
Please refer to his email address.
###########################################
Hi folks,
I want to say something to the OS/2 discussion
on the net.
1. about benchmarks
I ran the dhampstone benchmark posted to the net last year
on different computers in our institute.
The benchmark was written by Jack Purdum in 1985.
I ran it 100 times, screen output to /dev/nul or NUL:.
Here are the results:
MicroVax II (Ultrix) 806 sec.
PCS Cadmus (System V)
68020 20 MHz 267 sec.
Sun 4 (SUN OS)
10 MIPS Risc 56 sec.
IBM-AT 03 (PC-DOS 3.2)
80286 8 MHz 1 Wait 32 MB HD 537 sec.
IBM PS/2-70 A21 (PC-DOS 4.0)
80386 25 MHz cache 115 MB HD 156 sec.
IBM PS/2-70 A21 (MS-OS/2 1.1) 168 sec.
The PC programs were compiled with Microsoft C 5.1 using
options -Ms -FPi87 -Oalt.
As you can see the overhead for OS/2 is about 8%.
(Who got the 40% and why ???????)
(For all of you who didn't receive the source from the net:
The dhampstone benchmark uses character, int, long,
float, and file-I/O.
If you are interested in the source, please send me a mail,
I will send you the source back. )
2. about UNIX
From the above you can see, we use many different UN*X
machines.
The problem with UN*X is the response time. It is a multi-user
operating system, that causes waiting for mouse operations or
for echoing typed characters on heavy load.
Sometimes you have to wait for the mouse even if you are the only
user actually logged in.
This is because UN*X wants to give every process in the system
(e.g. printer spooler, network daemon, background compile,...)
the same part of CPU time as the foreground dialog process.
OS/2 does it better in using a "very good" (my opinion) priority scheme.
Also screen group switching in OS/2 is far better than layered shell
in UN*X.
3. about multitasking and fork()/exec()
fork() under UN*X is behind the concepts of threads in OS/2, because
it needs duplication of assigned memory space.
fork() is normally used for two purposes:
- setting up a process for doing some tasks in parallel
This can be done by threads in a more efficient and clearer way.
- running an other program (like the shell)
In UN*X it needs first duplication using fork() and then
overlaying the process using exec().
In OS/2 you can do the same using only spawn() in C
or DosExecPgm().
I know, I know, you are not able to port UN*X software easy to OS/2.
But as far as I know, OS/2 was not designed to be a replacement
for UN*X, it should be the PC operating system for today.
My only experience about OS/2 is an internal revision by Microsoft.
This revision is dated March 88.
IBM is not able to sell OS/2 1.1 with the Presentation Manager in Germany.
They announced for June 89.
Perhaps in two months I have more expirience.
Any comments are welcome.
Birger
/***********************************************************************/
/* Birger Kraegelin */
/* Fraunhofer Institut fuer Tel: 0721/6091-454 */
/* Informations- und */
/* Datenverarbeitung (IITB) email: krg@iitb.fhg.de */
/* Fraunhoferstr. 1 */
/* D-7500 Karlsruhe 1 or ...!uunet!unido!iitb.fhg.de!krg */
/* West Germany */
/***********************************************************************/daveh@cbmvax.UUCP (Dave Haynie) (05/19/89)
in article <8268@pyr.gatech.EDU>, rodney@pyr.gatech.EDU (Rodney Ricks) says: > Keywords: Sun Dhrystones GVP 68030 A-MAX MacIntosh Emulator > In article <6918@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >>in article <May.17.21.33.39.1989.14040@pilot.njin.net>, hubey@pilot.njin.net (Hubey) says: >>> I think in the same issue the Sun 3/80 registers around 11,000..... Hey, wait a minute! You make it look like I was claiming 11k Dhrys for the 3/80. I was actually refuting that, pointing out that a 3/80 is actually a 20Mhz machine, and 11k Dhrys is more on the order of a decent 33MHz machine's performance. > Sun 3/80 $12,595 5,154 68030/20 MHz 4 Meg of RAM > Sun 3/470 40,900 11,748 68030/33 MHz 8 Meg of RAM I guess I was right. -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
nuharlic@ndsuvax.UUCP (Ryan Harlicker) (05/20/89)
Hello all,
I am currently writting a assembler in Modula-2 using the Benchmark Modula-2
package. I am having problems with system error #3 bad address error. What is
this? The program compiles and links correctly, I can run it from the editor,
but when I try to run it from the cli my machine crashes. Very annoying!
All help appreciated.
Ryan Harlicker
hubey@pilot.njin.net (Hubey) (05/20/89)
> > > Sun 3/80 $12,595 5,154 68030/20 MHz 4 Meg of RAM > > Sun 3/470 40,900 11,748 68030/33 MHz 8 Meg of RAM > > I guess I was right. > > -- > Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy > Amiga -- It's not just a job, it's an obsession I guess I should have been looking at the page when I wrote the original INCORRECT information!!! The figures above obviously are the ACCURATE ones. Sorry !! mark -- hubey@OSultrix.montclair.edu hubey@pilot.njin.net hubey@apollo.montclair.edu VOICE: 201-893-5269 ...!rutgers!njin!hubey
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (05/20/89)
:2. about UNIX : : From the above you can see, we use many different UN*X : machines. : : The problem with UN*X is the response time. It is a multi-user : operating system, that causes waiting for mouse operations or : for echoing typed characters on heavy load. : Sometimes you have to wait for the mouse even if you are the only : user actually logged in. : This is because UN*X wants to give every process in the system : (e.g. printer spooler, network daemon, background compile,...) : the same part of CPU time as the foreground dialog process. This is a common misconception due to SUN's really bad software implementation for its mouse. A uVax, for example, does it in hardware. You are right about real-time response, but the mouse is not a good example. Even so, lack of resources on whatever machines you are used to will make for bad comparisons. It really is unfair to compare mouse response on, say, a 4MB diskless SUN which pages over ethernet vs a standalone microcomputer. Reality check: having local disk on a UNIX workstation makes a big difference. Having enough memory on a UNIX workstation makes a big difference when starting up processes as well. Example: I often use a 12MB diskless SUN 3/60 which pages over the ethernet and the mouse almost never freezes (and this is with the really bad sun mouse drivers!)... the response can be jerky at times (say, your running two XTrek's), but otherwise no big problems. (oh yah, this is running X11-R3). :3. about multitasking and fork()/exec() : : fork() under UN*X is behind the concepts of threads in OS/2, because : it needs duplication of assigned memory space. : fork() is normally used for two purposes: : : - setting up a process for doing some tasks in parallel : This can be done by threads in a more efficient and clearer way. : : - running an other program (like the shell) : In UN*X it needs first duplication using fork() and then : overlaying the process using exec(). : In OS/2 you can do the same using only spawn() in C : or DosExecPgm(). Normally one uses vfork() for the second case, and frankly having to make two systems calls instead of one is 0 trouble considering that you can always write a 3 or 4 line spawn() function that simply does a vfork/exec or even just a popen(). :Any comments are welcome. : :Birger :-) -Matt
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (05/21/89)
:But very few OS'es have fork() and get along just nicely. Most UNIX :gurus will readily admit that roughly 90% of fork()'s are followed :immediately by exec(). This is the reason for vfork() and fexec(). : :For a lot of OS'es there is a single call that does this sort of :thing, let's call it spawn(). It usually takes the name of a program, :... :yourself. I would say spawn() is more useful than fork/exec, at least :more widely used. (I like UNIX, but you have to admit that its method :of process creation is pretty unique) : :Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) : We now return you to your regularly scheduled program. More widely used != more useful. There was another thing you mentioned about large programs wanting to 'spawn' small programs... you missed your own remarks about vfork() for vfork() does not duplicate the address space and thus has the same overhead no matter how large the program calling vfork() is. Believe me, that 10% is important. It makes life easy for an incredible range of applications. The simple fact that spawn() is a subset of [v]fork/exec means that spawn is NOT more useful. For example, [v]fork/exec allows one to taylor how the soon-to-be-exec'd process will be setup in terms of stdin, stdout, stderr, ALL the file descriptors in fact. How does one do this with spawn()? add more arguments to the call? force the user to setup stdin, out, etc... do the spawn(), and then fix his stdin, etc.. back to what it was before? And that is just one example... -Matt
allbery@ncoast.ORG (Brandon S. Allbery) (05/22/89)
As quoted from <2656@ssc-vax.UUCP> by coy@ssc-vax.UUCP (Stephen B Coy): +--------------- | processes active. Fine. But when this system overhead eats up 40 | to 50% of a 25Mhz 386 I start to have questions. +--------------- (1) Was the OS/2 system running the LAN Manager? Or the SQL server? For that matter, PM *could* affect the total *if it continues to eat cycles while the benchmark is running*. (Windows/286 does, so I don't expect PM to be any different. I/O has nothing to do with it, except insofar as PM would be scanning for a "window-switch" command or etc.) (2) Someone should run the same benchmark under PC-MOS, 386 Unix, Concurrent DOS XM, and any other multi-tasking system they can come up with and compare *those* to OS/2's numbers. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
jxh@cup.portal.com (Jim - Hickstein) (05/25/89)
Ahem. I have been using OS/2 for some months, now, dabbling with PM until I get the go-ahead to actually write our application, and I have these observations about the discussion in hand: 1. OS/2 threads (and perhaps those elsewhere) are distinct from processes in that processes own resources, notably segment descriptors, while a thread is simply the unit of scheduler activity. The result is that threads within a given process must be mutually trustworthy, that is they must not stumble and expect that the operating system will protect the other threads from their mistakes. For that reason, I have sympathy with alex@mks (I have your beta version: good work!) who laments that fork() does not quite exist for OS/2 processes. In keeping with the kitchen-sink philosophy that seems to prevail, perhaps fork() could be added to all the other primitives already there. To echo a previous sentiment: I like having options. 1A. However, I would point out that, under OS/2, fork() cannot be made quite as inexpensive as Kaare Christian rightly pointed out, because most of what is copied for the child is, typically, a single code and single data segment; lacking pages (so far: when did you guys say OS/3 was due?) it must copy an ENTIRE segment for each (could be quite small, but the linker tries hard to fill them up to conserve selectors). This is probably going to be at least 100KB copy on fork(). Given the sizes of things generally under OS/2, this doesn't seem large, but for such an important function as process creation, it adds up. 2. Whatever other things came before (Amiga, OS9, you name it), I like OS/2, chiefly because it is AN OPERATING SYSTEM. I have been swearing at MS-DOS for TEN years (remember SCP 86-DOS from Seattle Computer Products? I had serial number 12. Pay attention!) having come from a mainframe background before that. Indeed, I have been swearing at 8-bit microcomputers for longer than that, wishing someone would sell a Cyber on a chip so we could get some work done. Now, with the advent of devices that might give a Cyber 74 a run for its money (25 YEARS LATER!), I'm stuck with a PC on my desk which (like all its bretheren) is I/O choked. *sigh* I guess there's no pleasing some people. Anyway. At least the software is beginning to catch up with ideas that have been around for DECADES. Given that OS/2 is hot off the press, I expect that it will mature rapidly and nicely. It is important for Microsoft to keep an eye on this forum, among others, but we should be guiding its development, not throwing rocks at the developers. -Jim Hickstein OS/2 PMSDK Masochists Group :-) VSAT Systems, Inc. San Jose, CA jxh@cup.portal.com ...!sun!portal!cup.portal.com!jxh
iddos@TAURUS.BITNET (06/04/89)
In article <May.17.21.33.39.1989.14040@pilot.njin.net> hubey@pilot.njin.net (Hub >In the last issue of Sentry (I don't have it with me), the GVP board >with a MC68030 and MC 68882 running at 33 MHz (I think) says that >the A2000 gets over 11,000 Dhrystones. Is that good ?? :-). >I think in the same issue the Sun 3/80 registers around 11,000..... In Sentry the Sun 3/80 is quoted as doing 5,150. It is the Sun 3/470 with a $40,900 price tag that does 11,748. The GVP board reaches that with a 32MHz crystal - but is supplied with a 25MHz one. Using a 32MHz crystal caused the CPU to heat up. BTW, the most astonishing fact in this review was that a Compaq 386/20 with a 80386/20NHz + 80387 (does 5,705) costs --$21,421--. Note the <1> (one) dollar. "Err, sorry sir, that was 21,420 plus, lets see, umm, ONE DOLLAR". Ido (The Id) Amin iddos@math.tau.acc.IL.BITNET - or simply iddos@taurus.BITNET
sparks@corpane.UUCP (John Sparks) (06/05/89)
In article <1025@taurus.BITNET> iddos%MATH.Tau.Ac.IL@CUNYVM.CUNY.EDU (Iddo Ilan) writes: >BTW, the most astonishing fact in this review was that a Compaq 386/20 >with a 80386/20NHz + 80387 (does 5,705) costs --$21,421--. >Note the <1> (one) dollar. "Err, sorry sir, that was 21,420 plus, >lets see, umm, ONE DOLLAR". > No way! 21 grand for a 20 mhz '386? Ha! I am sitting here using a Compaq 386/20. We paid around $5,000 for it with co-processor and many other options included. You'd have to really spiff things up to get it to $21,421. Like several 300 meg SCSI drives, 20 inch monitor with a super-duper-hi-res graphics adaptor, oodles of memory, Chrome bumpers, Velour seats and 5 speed transmission... and still have money to spare. You can get a base 386/20 for around $2,000 if you shop right. -- John Sparks | {rutgers|uunet}!ukma!corpane!sparks | D.I.S.K. 24hrs 1200bps [not for RHF] | sparks@corpane.UUCP | 502/968-5401 thru -5406 A virtuous life is its own punishment.