aberno@questor.wimsey.bc.ca (Anthony Berno) (10/21/90)
There has been a lot of talk about the relative performance of the Mac vs. the NeXT. I quite agree, having used both, it would seem on the surface that a high end MacII is faster. But consider this: While the Mac is using a relatively simple imaging model, (QuickDraw), the NeXT is using PostScript, which requires millions upon millions of floating point operations. Have you ever seen a Mac text window scroll WHILE you move the scrollbar? Even with QuickDraw, it would be much jerkier than on a Next. At any given time, the Mac is doing only one thing at a time, while the NeXT has daemons and other applications busy in the background. They are actually doing useful things. If a Mac tried to do so many things at once (which it can't really do anyway, not being a multitasking computer) it would be hopelessly bogged down. The only thing I don't get is why applications take so long to launch on the NeXT. Perhaps they are intrinsically bigger? As for everything else, give the poor cube a break! If a Mac ever tried to process all the things that were going on in a Next, ranging from display PostScript to the Window Server (notice how the WHOLE window moves when you drag it, not just the frame) it would be hopelessly slow. I would guess that the programmers at NeXT tried to make a compromise between nice features and a bogged down system. If you could run the Mac OS on a machine with the NeXT architecture, it would go so fast you would miss it if you bl did so much as blink. So don't complain about speed - if you want speed without the nicities, buy a Sun.
scott@NIC.GAC.EDU (10/21/90)
aberno@questor.wimsey.bc.ca (Anthony Berno) writes:
The only thing I don't get is why applications take so long to launch on
the NeXT. Perhaps they are intrinsically bigger?
This is because of the amount of run-time initialization required . . .
which I have a question about. Would it be possible to initialize and
then unload an app, like many lisps and emacs do, so that everything is
pre-initialized? I realize this would cause problems with shared
libraries and the like, but if there were some method of doing this on
a per-application basis. I don't think we necessarily need to actually
call the init methods of every class, but certain things probably could
be pre-initialized.
I just remembered something about 2.0. There's this method of linking called
scatter-loading (I think). What you do is take profiling data, and use that
to arrange the placement of functions within an executable. The idea is that
mutually dependant functions are located within the same page, while unused
functions (such as those for an Info Panel) go somewhere distant, like the
end of the TEXT segment. I'm sure there's a way of moving all the
initialization code to the front of the TEXT segment, so it gets loaded
right away, calls a bunch of functions which are in close proximity to
each other (reduces swapping), which means that app initializes faster.
This might be why they claim a 2x increase in launch speed for many apps.
scott hess
scott@gac.edu
Independent NeXT Developer (Stuart)
NeXT Campus Consultant (Not much, really)
GAC Undergrad (Horrid. Simply Horrid. I mean the work!)
<I still speak for nobody>kocks@jessica.stanford.edu (Peter Kocks) (10/23/90)
In article <87ocR1w163w@questor.wimsey.bc.ca> aberno@questor.wimsey.bc.ca (Anthony Berno) writes: >At any given time, the Mac is doing only one thing at a time, while the >NeXT has daemons and other applications busy in the background. They are >actually doing useful things. If a Mac tried to do so many things at once >(which it can't really do anyway, not being a multitasking computer) >it would be hopelessly bogged down. Umm... Not to pick bones, but actually this is not true. It is easy to write programs which run in the background on the Mac ( just call WaitNextEvent a few times). The problem is that if the program accidentally changes memory not in its domain, then you may have a crashed mac on you hands. >Window Server (notice how the WHOLE window moves when you drag it, not >just the frame) ... This is a neat feature, but is there a way to turn it off. I would much rather have the speed. --Peter Kocks kocks@jessica.Stanford.EDU
zippy@chaos.cs.brandeis.edu (Patrick Tufts) (10/24/90)
In article <87ocR1w163w@questor.wimsey.bc.ca> aberno@questor.wimsey.bc.ca (Anthony Berno) writes: There has been a lot of talk about the relative performance of the Mac vs. the NeXT. I quite agree, having used both, it would seem on the surface that a high end MacII is faster. But consider this: While the Mac is using a relatively simple imaging model, (QuickDraw), the NeXT is using PostScript, which requires millions upon millions of floating point operations. Have you ever seen a Mac text window scroll WHILE you move the scrollbar? Even with QuickDraw, it would be much jerkier than on a Next. [NeXT does many useful things at once. Mac doesn't.] [Mac OS on NeXT would be fast. If you want speed w/o niceties, buy a Sun] I'm sure no one will disagree that Display Postscript is a better imaging model than Quickdraw, but I'd rather have my machine bog down on _interesting_ problems. The NeXT has daemons running in the background doing 'useful' things. But aren't these tasks useful only because the NeXT needs them? What do the background tasks do that a Mac user would find useful? --Pat -- |\/\/\/|--------------------------------------------------------------------| | | "I WILL NOT HACK IN LISP proj: writing empire in a lisp-based | | (o)(o) / I WILL NOT HACK IN LISP TECO front end for a SQL | C _) I WILL NOT HACK IN LISP server implemented in APL | | ,___| I WILL NOT HACK IN LISP" | |___/----------------------------------------------------------------------| / \ / \ | brand | | X | |_______| | | | | \___|___| | | | | | | | | |_| |_| (__| |__)
slfields@uokmax.ecn.uoknor.edu (Scott L Fields) (10/24/90)
In article <ZIPPY.90Oct23212636@chaos.cs.brandeis.edu> zippy@chaos.cs.brandeis.edu (Patrick Tufts) writes: >The NeXT has daemons running in the background doing 'useful' things. >But aren't these tasks useful only because the NeXT needs them? What >do the background tasks do that a Mac user would find useful? I would find queing very useful on a mac. Their are things I find useful to run in the background but don't need on a Mac except where a Mac just doesn't do the job all that well unless yhou dedicate it to it. Examples: NFS server Network router Remote print server {granted these are vague points}
vehaag@crocus.uwaterloo.ca (Viktor Haag) (10/25/90)
In article <ZIPPY.90Oct23212636@chaos.cs.brandeis.edu> zippy@chaos.cs.brandeis.edu (Patrick Tufts) writes: >The NeXT has daemons running in the background doing 'useful' things. >But aren't these tasks useful only because the NeXT needs them? What >do the background tasks do that a Mac user would find useful? I am a neophyte to the NeXT world ( I don't own one, but want to own one, and likely will soon ) and I have a Mac currently so this thread here really interests me. From a >practical< standpoint, what differences would I notice as a Mac user switching to a NeXT (ie. something that my mother would notice as a 'neat' thing that she could never fo before while using my Mac)? If an answer to this question would be below the scope of this group, I would heartily appreciate a response by email. viktor@watdcs.UWaterloo.edu -- "We murder to dissect" Wordsworth
dd26+@andrew.cmu.edu (Douglas F. DeJulio) (10/26/90)
zippy@chaos.cs.brandeis.edu (Patrick Tufts) writes: > What do the background tasks do that a Mac user would find useful? Run batch jobs? Receive and process email and FTP sessions? Allow other people to log in and get work done on one machine?
dgb@unislc.uucp (Douglas Barrett) (10/29/90)
From article <9010201909.AA12905@mcs-server.gac.edu>, by scott@NIC.GAC.EDU: > aberno@questor.wimsey.bc.ca (Anthony Berno) writes: > The only thing I don't get is why applications take so long to launch on > the NeXT. Perhaps they are intrinsically bigger? > > This is because of the amount of run-time initialization required . . . > which I have a question about. Would it be possible to initialize and Well... no. A unix executable file consists of 2 things. text and directives. the text is of course the raw machine code. before text can run it needs addresses resolved. almost all modern cpus will accept a reletive addressing mode (ie no need to resolve *local* addresses), so only nonlocal addresses need be resolved. The amount of work here depends intirely on the archetecture. most use a vector for system calls, these require little address patching. Shared text and libraries are really quite fast (the memory is already allocated and initialized), there is just some region pointers to fix up.So the text really requires little effort (*usually*). the directives are a problem. they instruct the loader how to initialize static memory. this includes zeroing bss and doing the initialization. this takes some time, but not all that much (for most apps). auto memory and stack require no initialization. so the directives and resolution really are quite quick, and occur at an unpreempable priority. so why does it take so long to fire off a process on a UNIX system? the real problem is all of the os overhead. the process needs to fill out a proc slot. it needs its region table initialized to point to enough memory to get the process started. it needs a u. and if the file is not in memory just bringing it in takes time. and speaking of files, even after an app has started, it is *very* common for it to begin by doing io, even *opening* a file involves a lot of overhead and disc reads. thus even after a process has started it may lose several quanta doing disc io, which to the user looks like the process has not started. yes running a complicated os (compared to ie a Mac) is complicated. now once a process is unloaded its region table is no longer valid, the memory having been given to some other user. so there is no way to "unload" a process and keep it runable. the situation is not hopeless though. startup time can be reduced by firing off a daemon to keep as many resources as practical. for *many* apps this makes a lot of sense. if the process is idle for too long it will be paged out (or swapped on some systems). starting a swapped process is not much faster than starting a process from scratch. its region table is no longer valid, and it may have lost its buffers. but once an app is unloaded it must lose its memory. ------------------------------------------------------------------ Douglas Barrett I speak for myself Unix Systems Programmer Unisys SLC Utah