NJ_GOKEMEIJE@FANDM.BITNET (06/19/91)
From: IN%"melling@cs.psu.edu" "Michael D Mellinger" 18-JUN-1991 17:06:49.23 >In article <1991Jun17.172930.13518@cunixf.cc.columbia.edu> > es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: > > >Memory is cheap, but Mathematica can use more than 9MB of RAM. Get a > >computer with virtual memory. > > > >-Mike > > And wait for it to page in and out? When memory is > $60/meg? What's the point? So get 18MB if you need that much. The > time it saves you (if you need it) makes it more than worth the > cost. > >The problem is you don't know how much you will need. People run some >pretty large Mathematica jobs.I'm willing to bet there are times >when 32MB of RAM is not enough. Besides, if a job is running for >hours you don't want to find out half way through that it ran out of >memory. Let it page to disk. If you are using the machine for >something else the CPU will be given to another task while the system >is paging. >-Mike OK, I understand, the A3000 is not too bad, especially if you could get a 68040 card for it. I heard there was a german company who has a Virtual Memory Handler for their harddrive. Can it be run on a standard A3000? (without their harddrive?) Is it save? Could Maple make it's own virtual memory handler? That would be a good idea I beleive. BTW I saw a MAC SE/30 with 2 MEGS running system 7 with Virtual Memory. What a joke! The system allocates 1.7 MEGS for itself, leaving 300 K for applications. Starting SUPERPAINT allocates 1.2 MEGS for superpaint and has to swap .9 MEGS to run it. Everytime you switch to the FINDER it swaps again. Good thing it doesn't have real multitasking! Question: Since on a MAC you need to specify the size of an application (in the INFO window) does it still give an out of memory error if it needs more than that size, even with Virtual Memory? (That seems stupid) Do you still need to quit to change that size? (Even more stupid) Does the CPU still spend time on the Memory Manager? besides the MMU ?? Nils Gokemeijer (NJ_GOKEMEIJE@FANDM)
awessels@ccwf.cc.utexas.edu (Allen Wessels) (06/20/91)
In article <AD66AB3A80002F6C@FANDM> NJ_GOKEMEIJE@FANDM.BITNET writes: >BTW I saw a MAC SE/30 with 2 MEGS running system 7 with Virtual Memory. >What a joke! The system allocates 1.7 MEGS for itself, leaving 300 K for System 7 takes up 1 meg on my SE/30. Remember that in that System partition memory used included the cache (which in 7 is always on) and any memory used by inits. >applications. Starting SUPERPAINT allocates 1.2 MEGS for superpaint and >has to swap .9 MEGS to run it. Everytime you switch to the FINDER it swaps >again. Good thing it doesn't have real multitasking! What do you mean by "real" multitasking. If your program needed a lot of memory it would be swapping. (By the way, the default partition for SuperPaint 2.0 is 700k.) >Question: Since on a MAC you need to specify the size of an application >(in the INFO window) does it still give an out of memory error if it needs >more than that size, even with Virtual Memory? (That seems stupid) Yes. Virtual memory simply increases the total memory available, not how applications use it. (And yes, it'd be nice if it worked better.) >Do you still need to quit to change that size? (Even more stupid) Yes.
dant@ryptyde.UUCP (Daniel Tracy) (06/20/91)
Responding to the following: >Question: Since on a MAC you need to specify the size of an application >(in the INFO window) does it still give an out of memory error if it needs >more than that size, even with Virtual Memory? (That seems stupid) Question: Does the Amiga have Dynamic Memory Allocation?
jet@karazm.math.uh.edu (J Eric Townsend) (06/20/91)
In article <76@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: >Question: Does the Amiga have Dynamic Memory Allocation? Always has had it. Programs ask for memory, as long as there's enough, they get it. If they don't, they get told to piss off. -- J. Eric Townsend - jet@uh.edu - bitnet: jet@UHOU - vox: (713) 749-2126 Skate UNIX! (curb fault: skater dumped) PowerGlove mailing list: glove-list-request@karazm.math.uh.edu
rjc@wookumz.gnu.ai.mit.edu (Ray Cromwell) (06/20/91)
In article <76@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: >Responding to the following: > >>Question: Since on a MAC you need to specify the size of an application >>(in the INFO window) does it still give an out of memory error if it needs >>more than that size, even with Virtual Memory? (That seems stupid) > >Question: Does the Amiga have Dynamic Memory Allocation? Of course! How else would it multitask if applications merely "took over" chunks of memory? Question: Why do you have to specify a size to the Mac OS? What's the point? -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
dant@ryptyde.UUCP (Daniel Tracy) (06/21/91)
Responding to the following: ">Question: Does the Amiga have Dynamic Memory Allocation? Of course! How else would it multitask if applications merely "took over" chunks of memory? Question: Why do you have to specify a size to the Mac OS? What's the point?" I believe I understand the difference now. Amiga applications take memory dynamically as they need it. Macintosh applications, having been bred in a single-tasking environment, instead check how much memory is available and use it all. Under Mac Multitasking, you tell the OS how large a contiguous chunk to give the application. Then when the application checks to see how much memory it has, it gets returned a value proportional to how much you specified. Interesting. Am I right?
jbickers@templar.actrix.gen.nz (John Bickers) (06/21/91)
Quoted from <76@ryptyde.UUCP> by dant@ryptyde.UUCP (Daniel Tracy):
> Question: Does the Amiga have Dynamic Memory Allocation?
Yes. It's not usually capitalized like that, though I imagine
the odd marketroid might think of doing so.
--
*** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz ***
*** "Endless variations, make it all seem new" - Devo. ***peterk@cbmger.UUCP (Peter Kittel GERMANY) (06/21/91)
In article <76@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: >Responding to the following: > >>Question: Since on a MAC you need to specify the size of an application >>(in the INFO window) does it still give an out of memory error if it needs >>more than that size, even with Virtual Memory? (That seems stupid) > >Question: Does the Amiga have Dynamic Memory Allocation? Yes, I think it has (if you don't mean *virtual* memory?). Any application can look how much memory is left and can allocate it if necessary. (Or it just tries to allocate and checks for success.) So, a really well-behaved Amiga program will allocate only little memory on first start (so that others can comfortably live in parallel with it) and will allocate after that only as much as is really needed. You see a faint attempt for this e.g. in AmigaBasic. By default it opens with only 25 K for program and variable space, and it's up to the program to use the CLEAR instruction to gain more space. (If you have a Basic source that already exceeds the 25 K, you must write a 2-line loader program that does a big enough CLEAR and then loads (in fact RUNs) the real program, clumsy but working.) -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
sho@gibbs.physics.purdue.edu (Sho Kuwamoto) (06/22/91)
In article <82@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: >> Question: Why do you have to specify a size to the Mac OS? What's >>the point?" > >I believe I understand the difference now. Amiga applications take memory >dynamically as they need it. Macintosh applications, having been bred in >a single-tasking environment, instead check how much memory is available >and use it all. Under Mac Multitasking, you tell the OS how large a >contiguous chunk to give the application. Then when the application checks >to see how much memory it has, it gets returned a value proportional to how >much you specified. Interesting. Am I right? Sort of. Applications don't assume they hog the whole machine, but the memory manager has a hard time with non-contiguous space. This is because the mac uses relocatable chunks of memory. I don't see why that *must* be so. I can see that using non-contiguous space would be inefficient as hell, but I don't see why it would be impossible. If all blocks stayed put, that's a different story. Ok. Now for the flip side. If you need more memory than you have, you can make a call to the OS to allocate memory outside your application zone. This area should only be used for temporary storage, but it helps out a lot. For example, the Finder uses temporary memory to buffer while copying files. Once the file copying is done, it lets go of the memory. It's not transparent to the programmer, but it's not horrible, either. All you need to do is to call TempNewHandle() instead of NewHandle(). In addition, you can afford to give applications more space with virtual memory. It's not ideal, but it is a step in the right direction. -Sho -- sho@physics.purdue.edu
rjc@wookumz.gnu.ai.mit.edu (Ray Cromwell) (06/22/91)
In article <5333@dirac.physics.purdue.edu> sho@gibbs.physics.purdue.edu (Sho Kuwamoto) writes: >In article <82@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: >>> Question: Why do you have to specify a size to the Mac OS? What's >>>the point?" >> >>I believe I understand the difference now. Amiga applications take memory >>dynamically as they need it. Macintosh applications, having been bred in >>a single-tasking environment, instead check how much memory is available >>and use it all. Under Mac Multitasking, you tell the OS how large a >>contiguous chunk to give the application. Then when the application checks >>to see how much memory it has, it gets returned a value proportional to how >>much you specified. Interesting. Am I right? > >Sort of. Applications don't assume they hog the whole machine, but >the memory manager has a hard time with non-contiguous space. This is >because the mac uses relocatable chunks of memory. I don't see why >that *must* be so. I can see that using non-contiguous space would be >inefficient as hell, but I don't see why it would be impossible. If >all blocks stayed put, that's a different story. From the way I interpret this, the Mac has some form garbage collection to prevent memory defragmentation. I get the suspicous feeling that the MacOS was developed originally in a language other than C, something with a run-time memory manager and garbage collector. Am I right? I see nothing but disadvantages in this type of memory system for modern computers 1) Double indirection of pointers is slower (yes you can lock a memory block, but why use handles in the first place? I know I would be irritated if I had to constantly do a ptr1->ptr2->mystuff when coding) 2) garbage collection is expensive and it gets worse depending on the amount of memory you have and the amount being used On modern computers an MMU can be used to defrag memory and private memory pool managing can reduce it greatly. Can someone tell me why Apple uses this type of memory management? >Ok. Now for the flip side. If you need more memory than you have, >you can make a call to the OS to allocate memory outside your >application zone. This area should only be used for temporary >storage, but it helps out a lot. For example, the Finder uses >temporary memory to buffer while copying files. Once the file copying >is done, it lets go of the memory. > >It's not transparent to the programmer, but it's not horrible, either. >All you need to do is to call TempNewHandle() instead of NewHandle(). >In addition, you can afford to give applications more space with >virtual memory. It's not ideal, but it is a step in the right direction. It still seems strange that you have to 'limit' or tell the OS the maximum memory your app will need. The only thing that is close to this on the Amiga is the need to predefine the stack size (this is because 68000,68010, 68020 w/o MMU cannot have dynamic stack growth without checking the stack constantly before pushing anything on it, this slows down code a lot and places burdens on the compiler) >-Sho >-- >sho@physics.purdue.edu -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
jbickers@templar.actrix.gen.nz (John Bickers) (06/22/91)
Quoted from <1991Jun21.235106.14465@mintaka.lcs.mit.edu> by rjc@wookumz.gnu.ai.mit.edu (Ray Cromwell): > to prevent memory defragmentation. I get the suspicous feeling that > the MacOS was developed originally in a language other than C, something Now it can be told! Pascal (or that's what it claimed to be back when I had to write stuff on the thing)! Gak. > / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***