[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: When will MCL 2.0 be available? / MCL 2.0 runs w/ VM on?
- To: firstname.lastname@example.org (John Kim)
- Subject: Re: When will MCL 2.0 be available? / MCL 2.0 runs w/ VM on?
- From: Steve Strassmann <email@example.com>
- Date: Fri, 20 Mar 1992 11:29:35 -0500
- Cc: info-mcl
>Does anybody know when MCL 2.0 (not the beta version) would be available? (Or
>is it already so?)
Apple has not announced any ship date for the final release of MCL 2.0.
Believe me, we want to ship it just as much as you want to get it,
but at this point we still don't have an exact date. Off the record,
I'd say "very soon", like in the next month or two, but I really cannot
make any promises. In the meantime, you can use the latest version
of the beta which is very similar to the final.
>Would MCL 2.0 run with no problem when virtual memory is in effect? (What
>about the current MCL 2.0 beta version? How does it run when virtual memory
>is turned on? What about version 1.3.2?)
MCL 2.0 runs with no problem under Macintosh VM. For example, we've
run a lisp image that needed around 50MB. It's hard to tell how your speed will be
affected, since there's so many things to consider. In particular, it may
depend greatly on the nature of your code.
> I think I read from somewhere that running applications with
>virtual memory on terribly slows down everything, but when I ran quite many
>applications (5 to 6) with VM on (5 MB phyical RAM + 5 MB virtual (harddisk)
>= 10 MB total), they seemed to run very briskly without any noticeable slow
>down. (I didn't do any rigorous speed measuring with speedometer 3.0.)
Although all your applications had a footprint spanning 10Mb, they probably
made little use of all 10Mb at the same time. A virtual memory
system tries to anticipate which data you will need and keep them in RAM,
to minimize hard disk accesses (paging). If you're lucky, your data is relatively
localized, and the slowdown is minimal. In the worst case, every time you
refer to an object it must be fetched (paged in) from the hard disk, which
slows you down greatly.
>The reason I ask is because I would like to allocate more memory to the lisp
>application using VM; that is, without buying more expensive main memory, and
>of course this wish is being made under the assumption that using VM does not
>slow down the lisp process.
As with most things in life, you get what you pay for.
If you allocate more memory to your application, it will spend less time
garbage collecting. If more of your memory is real instead of virtual, it will
spend less time swapping data in from the hard disk. If your algorithms are
less memory-hungry, there will be less need for bigger storage space.