🚀 go-pugleaf

Alex Makarewycz writes
> Obviously some nexters' just aren't programmers!
>   
> 	Having a Ramdisk containing cc or tex would spare my harddisk the  
> torturous reading and writing it goes through when recompiling.  I can't  
> wait to get a copy!

If you have enough memory, frequently invoked programs are cached on more than  
one level already on the NeXT. If you don't have enough memory what are you  
doing with a ram disk ? (No, I refuse to make the virtual memory joke. It is  
quite good, but _very_ old).

Seriously, probably a point can be made for ram disks for certain specialized  
uses. Sun tempfs comes to mind. But transplanted Mac/PC programmers who are  
basing their judgements on their old experiences and lack of the understanding  
of the internals of UNIX and Mach are going to be disappointed.

BTW, AMIGA programmers have been able to keep programs resident without RAM  
disk for many years. Having an operating system (even if it is not quite as  
sophisticated as Mach/BSD 4.3) does help. Apple and Microsoft, take note !

	Carl Edman

Am I missing something here? What's to stop your RAM disks memory from
getting swapped to your swap disk? At which point you have achieved nada...

\n

In article <2A872788.9058@noiro.acs.uci.edu> cedman@golem.ps.uci.edu (Carl Edman) writes:
> Seriously, probably a point can be made for ram disks for certain specialized  
> uses. Sun tempfs comes to mind. But transplanted Mac/PC programmers who are  
> basing their judgements on their old experiences and lack of the understanding  
> of the internals of UNIX and Mach are going to be disappointed.

Exactly.

This doesn't really affect the RAM disk question, but
I'ld like to correct an error in my previous posting
about the sticky bit for executables.

Back in the old days when processes were swapped in & out
in their entirety, the text segment of sticky executables
would remain in the contiguous swap space to avoid seeking
all over the disk when starting the next invocation.

I incorrectly posted that the text segment remained in core.

So the sticky bit for executables probably is irrelevant
to demand paged virtual memory systems and is merely
a harmless historical oddity.

Thanks to eric@skatter.usask.ca (Eric Norum) for straightening
out my memories of a twisted past.

-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted

NoNoNoNoNo! (Warning: entering the ozone layer now)

This points up a problem with traditional computing environments. If you
think of memory as being either RAM, where your computer does its work,
and Disk, where your computer stores its work, you end up with this waste
of resources and loss of performance.

If you're going to keep executables in RAM, that's OK. But it's not OK to
copy that program from one place in RAM to another to execute it, which is
what a ramdisk does. A really good operating system would let you execute
the program in place. Of course, that means you must write re-entrant code
*always*.

While NeXT made some real improvements in usability, the next leap forward
needs to include RAM-resident program files that are re-entrant and execute
in place, running under a *real* realtime OS.

(You can take off your space suits now, but the preceding is no joke.)

Steve abell@netcom.com

In article <1992Aug10.221515.5435@nas.nasa.gov> makarewy@rft31.nas.nasa.gov  
(Alex Makarewycz) writes:
> Obviously some nexters' just aren't programmers!
>   
> 	Having a Ramdisk containing cc or tex would spare my harddisk the  
> torturous reading and writing it goes through when recompiling.  I can't  
> wait to get a copy!
> 
> -Alex Makarewycz

Well, this must be a serious effort!  I somehow can't beleive anyone that could  
program a device driver wouldn't understand how unix VM works, but I guess  
folks have blind spots!  

I'd be interested in how he plans to keep the ramdisk ram resident.  I suspect  
the os will be swapping it out as needed!

Folks, if you need to speed your machine up, ADD RAM.  Removing RAM from  
general use for a ramdisk, if it can work in any reasonable fashion at all,  
will otherwise slow the rest of the processes in your machine with the  
additional swapping you will need.

Jim

   There are occasions where largish files get written to disk and t
then read right back in again.  System builds, for example, write .o files
and then read them back.  (Does NeXT write intermediate files, too?)

   In such a case, a way to write data to a "file" that stays in memory
seems useful.  Normal cacheing doesn't accomplish it, since the files
get synced to disk pretty often.

   Of course, IF the "files" in memory contend for memory, they should be
swapped out, just like any other memory contender.  But if there is
lots of memory free, they would stay in memory and thus speed up system
building.

      In short, there should be a way to create memory resident files
which aren't synced to disk unless absolutely called for.

In article <rf3mxlc.abell@netcom.com> abell@netcom.com (Steven T. Abell) writes:
>NoNoNoNoNo! (Warning: entering the ozone layer now)
>
>This points up a problem with traditional computing environments. If you
>think of memory as being either RAM, where your computer does its work,
>and Disk, where your computer stores its work, you end up with this waste
>of resources and loss of performance.
>
>If you're going to keep executables in RAM, that's OK. But it's not OK to
>copy that program from one place in RAM to another to execute it, which is
>what a ramdisk does. A really good operating system would let you execute
>the program in place. Of course, that means you must write re-entrant code
>*always*.
>
>While NeXT made some real improvements in usability, the next leap forward
>needs to include RAM-resident program files that are re-entrant and execute
>in place, running under a *real* realtime OS.
>
>(You can take off your space suits now, but the preceding is no joke.)
>
>Steve abell@netcom.com

    Heh.  That is *exactly* what the Amiga's resident does.  Not quite in
    the backwater, eh?	The Amiga's resident will preload AND pre-relocate
    a program in memory.  The program is reentrant, you can run as many
    simultanious instances of it as you like, and startup is instantanious.

    But on the NeXT (or any UNIX machine), truely, the only place where you
    get a meaningful performance boost is if the OS caches the thing for
    you run-ready.  A NeXT ram disk is only a half step and as people have
    mentioned, it can get swapped... you still have to go through a load &
    process creation phase which involves a lot of work.

						    -Matt

--

    Matthew Dillon	    dillon@Overload.Berkeley.CA.US
    891 Regal Rd.	    uunet.uu.net!overload!dillon
    Berkeley, Ca. 94708     ham: KC6LVW (no mail drop)
    USA