Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!dogie.macc.wisc.edu!uwvax!astroatc!nicmad!madnix!perry From: perry@madnix.UUCP (Perry Kivolowitz) Newsgroups: comp.sys.amiga Subject: Re: The Art Department and Memory Summary: Sand Box Versus Major Construction Message-ID: <1636@madnix.UUCP> Date: 24 Nov 90 23:22:34 GMT References: <1990Oct25.193715.8382@hayes.ims.alaska.edu> <1990Oct25.224025.7029@ux1.cso.uiuc.edu> <1611@madnix.UUCP> <1990Nov5.053442.4010@uokmax.ecn.uoknor.edu> <35817@cup.portal.com> Reply-To: perry@madnix.UUCP (Perry Kivolowitz) Organization: ASDG Incorporated Lines: 50 In article limonce@pilot.njin.net (Tom Limoncelli) writes: >It turned down the idea because I didn't want to waste the memory; >other programs could use that memory when I'm not using it. The >phrase I invented to describe the technique was that the program "made >it's own sandbox so that it could ignore the others". I thought it >that if I wrote a program that did this people would accuse the >technique of being a holdover from the C-64 mentality. "If I can't >have the whole machine, I'll just make my own mini-machine and stay >within it." >ASDG's technique has similar qualities but is one step closer to >"making your own sandbox" because it's a contiguous block (or "box"?). >Now I understand how ASDG makes their software so reliable. :-) >This all confuses me because ASDG is the one company that I've never >seen have a C-64 mentality. Maybe I'm off the wall and this is an >accepted technique that everyone uses. Tom's analogy to ``making your own sandbox'' is a good one. In fact, to use his metaphore it would be more accurate to liken TAD's actions to ``making its own construction site''. This is because TAD is constantly reorganizing its pre-allocated memory in ways to best optimize performance for a given image type and size. The reason we made the allocation in one large block was not to ease our programming effort, but rather, to make somethings possible which would not have been possible without our total control over our own memory. Memory bounds and borders within our pre-allocated area are free to shift at will (under our program's control). This freedom has allowed us to make some optimizations which boost performance of some operations by as much as a factor of 10. >could deallocate everything easier. The former would completely avoid >the "out-of-memory crashes" that people complain about. This is another concern. TAD (and even more so, ADPro) are dynamic in nature. It would be very rude to interrupt the user in the middle of a sequence of steps with an out of memory message. While you can still run out of memory while using TAD or ADPro, these occasions are much fewer and more gracefully handled as a result of our choices in memory architecture. Our memory usage is really predicated on the immutable law of computing, that of the trade-off between time and space. TAD and ADPro are optimized for time (performance), the one resource which is sometimes priceless. -- Perry Kivolowitz, ASDG Inc. ``We look for things. Things that make us go.'' UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!perry CIS: 76004,1765 PLINK: pk-asdg