pascal@altitude.CAM.ORG (Pascal Gosselin) (03/28/90)
lih@cunixf.cc.columbia.edu (Andrew Lih) writes: >I saw the Mac IIfx running A/UX 2.0 just last week a day after its >announcement and got to sit in front of one for about a half hour and >played with it. When running MacX (with 1 session and the Motif >Window Manager) and two Mac OS programs (Swivel 3D, and another), it >was kind of sluggish. The X implementation (1.07) was slow, and I >found XNeXT to be much quicker. Many times, it would take a few >seconds for a menu to pop up on the root window. Of course, the NeXT >does not have the color that the Mac does. >I did not get to see the Mac IIfx running plain MacOS, but the A/UX >2.0 implementation seems to be much better than the old A/UX, but >performance was not as quick as I thought it would be... MacX does not give you a true feeling of the IIfx's power. You see, MacX running under AU/X (that is, ROOTLESS mode where X is running within MultiFinder windows with Multifinder running as an AU/X 2.0 process) will always be a bit slower than the dedicated X screen mode (ROOTED). The version of MacX that you saw was VERY EARLY BETA.... The Apple guy doing our demo told us that the next Beta release is 10times faster in Rootless mode! Please do not confuse the Multifinder process and AU/X programs. The ROOTED mode, I can assure you, is certainly faster than Display Postscript on a Next... Especially with the 8.24GC board, with it's off-screen drawing capabilites and 30Mhz Heater! -- +--------------------------------------------------------------------+ | Pascal Gosselin | Internet: pascal@altitude.CAM.ORG | | Computer Connection Inc. | (514) 674-1514 CIS: 72757,1570 | +--------------------------------------------------------------------+
hammersslammers1@oxy.edu (David J. Harr) (03/30/90)
Pascal Gosselin says: >Please do not confuse the MultiFinder process and A/UX programs. The ROOTED >mode, I can assure you, is certainly faster than Display Postscript on a >NeXT...30 MHz heater! FLAME ON! If it's one thing I hate, it's people who talk without knowing what they are talking about. FLAME OFF. In other words, it's a 25 MHz heater. ^^ (Sorry, Pascal, I just couldn't resist. 8 :-)). David
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (03/30/90)
I just remembered another "feature" about the Mac, which reminds me
why I intend never again to do software development on the Mac
platform. Like MS-DOS, the Mac operating system splits memory into
64K segment; no object may be larger than that. So, if you need a
100,000 character string, you have to split it into chunks.
Also, there's no memory mapping, so system memory management is done
by shuffling. The way they do this is by a bizarre system of double-
indirect pointers. Although this is OK for memory-tight systems, it's
a lot of work for the programmer to keep track and for large memory
systems this is slower than allocating enough memory for the
application to begin with and shuffling it to a larger chunk with a
single base register than making all those double-indirect references.
I guess this was all for CP/M compatibility. ;-)
_____ ____ ---+--- /-\ Mark Crispin Atheist & Proud
_|_|_ _|_ || ___|__ / / 6158 Lariat Loop NE R90/6 pilot
|_|_|_| /|\-++- |=====| / / Bainbridge Island, WA "Gaijin! Gaijin!"
--|-- | |||| |_____| / \ USA 98110-2098 "Gaijin ha doko ka?"
/|\ | |/\| _______ / \ +1 (206) 842-2385 "Niichan ha gaijin."
/ | \ | |__| / \ / \ mrc@CAC.Washington.EDU "Chigau. Gaijin ja nai.
kisha no kisha ga kisha de kisha-shita Omae ha gaijin darou."
sumomo mo momo, momo mo momo, momo ni mo iroiro aru "Iie, boku ha nihonjin."
uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru "Souka. Yappari gaijin!"mwilkins@jarthur.Claremont.EDU (Mark Wilkins) (03/30/90)
In article <6453@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: > >I just remembered another "feature" about the Mac, which reminds me >why I intend never again to do software development on the Mac >platform. Like MS-DOS, the Mac operating system splits memory into >64K segment; no object may be larger than that. So, if you need a >100,000 character string, you have to split it into chunks. > >Also, there's no memory mapping, so system memory management is done >by shuffling. [ stuff deleted ] Not to get into any sort of machine war or anything, but... Your comments on memory mapping are well taken. However, memory is NOT split into 64K segments. Only certain types of data ever had a size restriction. Furthermore, at this time there are no such size restrictions on any data type. The only restriction which still stands in practice is that relocatable code blocks must be less than 32K. However, since you can split your code into as many as you like, that's not a problem. Things have changed a lot in the Mac world over the past several years. You might consider giving it another look. In my opinion, features have been added and many things have gotten simpler at the same time. -- Mark Wilkins mwilkins@jarthur.claremont.edu DISCLAIMER: Read the Followup-to: line before flaming.
minich@a.cs.okstate.edu (MINICH ROBERT JOHN) (04/07/90)
From article <6453@blake.acs.washington.edu>, by mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin): > > I just remembered another "feature" about the Mac, which reminds me > why I intend never again to do software development on the Mac > platform. Like MS-DOS, the Mac operating system splits memory into > 64K segment; no object may be larger than that. So, if you need a > 100,000 character string, you have to split it into chunks. Well, either you haven't looked real close or you are just remembering something from someone who heard that it was said... There is no problem on the Mac with big chunks of data. That is what the Memory Manager is great at! Just ask for a chunk of arbitrary size, and if it can be provided, you've got it. What I think has gotten into your head somewhere is the limit on the size of single objects in the resource _file_ (32K) where other considerations are at work. This is not a real big prob IMHO, and I certainly prefer to have the Resource Manager rather than writing my own code to attempt something analagous. > Also, there's no memory mapping, so system memory management is done > by shuffling. The way they do this is by a bizarre system of double- > indirect pointers. Although this is OK for memory-tight systems, it's > a lot of work for the programmer to keep track and for large memory > systems this is slower than allocating enough memory for the > application to begin with and shuffling it to a larger chunk with a > single base register than making all those double-indirect references. Yes, the Mac's memory management does "shuffling" and uses double indirection, but the concept is very clean in use. And if you ask anyone who uses big apps regularly, you'll find that all computers are "memory-tight systems". :-) No, it's NOT a lot of work for programmers to keep track of things with handles. (IMHO, again.) Just make sure there is something on the end of a handle before you use it, and your fine. About the base register BS... if the Mac's memory was segmented by hardware into chunks, this _might_ be worthwhile, but it isn't. Now, if you mean you want a base register for a big chunk you get back from the memory manager to divy up yourself, that's fine and you can do that if you want. (Of course, some assembly required. :-) I think you'd do well to talk with someone who has actually written for the Mac about these "details" before you go to far in putting them down. There are definite limitations, but not at all the ones you describe. > I guess this was all for CP/M compatibility. ;-) naaaw, they did it for clone protection! :^) Robert Minich Oklahoma State University minich@a.cs.okstate.edu -- Robert Minich
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (04/10/90)
In article <5522@okstate.UUCP> minich@a.cs.okstate.edu (MINICH ROBERT JOHN) writes: > I think you'd do well to talk with someone who has actually written >for the Mac about these "details" before you go to far in putting them >down. There are definite limitations, but not at all the ones you >describe. One clarification: I *have* written for the Mac. I quit that job 2.5 years ago. So I've forgotten the exact gory details in 2.5 years. I must have gone to some effort to purge the details -- and MPW, and MPW C -- out of my mind. The fact still remains that the Mac was the *worst* programming environment I have ever dealt with. The best programming environment, by the way, was not the NeXT; it was Xerox Lisp machines for a graphic interface and DEC-20's for a TTY interface. Both of these, however, are dead systems. One detail I do remember is that object assignment via malloc() is very slow on the Mac. If you need to create lots of small objects (e.g. strings in a data structure) you are much better off creating a single large object and subdividing it yourself than individual small objects; the difference is seconds of real time. Of course, Mac programmers will tell you that you shouldn't use malloc(). No matter that you're porting a large library and merely want to put a Mac user interface on top of it; their answer is "you should rewrite it." The NeXT environment sometimes betrays this attitude too; fortunately it is generally possible to ignore it. Let me say this; I have nothing but admiration and respect for those individuals who develop software for the Mac. No one is calling you "stupid", or telling you you should migrate to the NeXT. There really is no comparison between the two machines. Some Mac users/programmers may well want to migrate to a NeXT, but they're the guys who wanted more out of a Mac than a Mac was going to deliver anyway. You won't see people migrating from a NeXT to a Mac; if NeXT goes under then SUN, IBM, DEC, etc. will be the beneficiaries. _____ ____ ---+--- /-\ Mark Crispin Atheist & Proud _|_|_ _|_ || ___|__ / / 6158 Lariat Loop NE R90/6 pilot |_|_|_| /|\-++- |=====| / / Bainbridge Island, WA "Gaijin! Gaijin!" --|-- | |||| |_____| / \ USA 98110-2098 "Gaijin ha doko ka?" /|\ | |/\| _______ / \ +1 (206) 842-2385 "Niichan ha gaijin." / | \ | |__| / \ / \ mrc@CAC.Washington.EDU "Chigau. Gaijin ja nai. kisha no kisha ga kisha de kisha-shita Omae ha gaijin darou." sumomo mo momo, momo mo momo, momo ni mo iroiro aru "Iie, boku ha nihonjin." uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru "Souka. Yappari gaijin!"