[Coco] the final stage of optimization

[Lothan]

If you're currently booting from a good OS-9 or NitrOS-9 boot disk/image, 
all you really need to do is merge the driver and descriptor, load the 
merged file into memory, and then init the descriptor:

merge /dd/modules/rbf/rammer.dr /dd/modules/rbf/r0_128k.dd >/dd/cmds/ramr0
attr /dd/cmds/ramr0 e pe
load ramr0
link rammer
link r0
iniz /r0
format /r0

At this point /r0 is ready to use. Also note that I used r0_128k.dd as an 
example, but you can use either of the r0_8k.dd, r0_96k.dd, r0_128k.dd, or 
r0_192k.dd descriptors as appropriate.

--------------------------------------------------
From: "Wayne Campbell" <asa.rand at yahoo.com>
Sent: Friday, November 20, 2009 11:45 PM
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Subject: Re: [Coco] the final stage of optimization

> When I wrote DCom I used a RAM disk. I recommended the use of a RAM disk 
> as it did speed up the program significantly. With the current setup I'm 
> using, I am unable to setup a ram drive. The NitrOS9 disk image I'm using 
> is not a proper system master, and I'm spending all of my available time 
> working on this project. I just don't have time to try to figure it out 
> right now. I'm attempting to get the copy of the OS9 system disk to boot, 
> but for reasons unknown the screen comes up black-on-black with a magenta 
> cursor, and the display commands don't change it. If I can't see what I'm 
> doing, I can't work on anything. So, I make do with what I have.
>
> The sort I'm using is based on the bubble sort, but instead of repeatedly 
> starting at the top and working to the bottom, it souts back upward when 
> it gets to the bottom. This way, it is constantly sorting in both 
> directions, and uses fewer iterations of the loop. It proved to be over 
> twice as fast as top-to-bottom-top-to-bottom.
>
> Thanks for the tips. I've heard of mergesort, but have never seen it in 
> operation or looked at its code. I know there were many things developed 
> on the mainframes for dealing with massive volume sequential data, but 
> I've never been around it. Always looking from a distance. I'll see what I 
> can find on the web.
>
> Wayne
>
>
>
>
> ________________________________
> From: Gary <bear at bears.org>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Fri, November 20, 2009 11:20:20 AM
> Subject: Re: [Coco] the final stage of optimization
>
> On Fri, 20 Nov 2009, Aaron Wolfe wrote:
>
>> Hi, I don't know your project well enough to be sure, but this seems
>> like a situation where keeping the data in ram, or at least an index
>
> Years ago, I wrote a database for Basic09 and the only sort I knew at the 
> time was bubblesort -- using a ramdisk instead of the physical floppy sped 
> it up by two orders of magnitude.
>
> If something like that isn't an option -- since it sounds like the data is 
> largely sequential (one long file broken into records) what about treating 
> it like tape?  There are a number of well-understood algorithms from the 
> 50s that might apply -- such as mergesort -- that were designed for 
> handling large amounts of data for sorting and searching on machines with 
> small ram spaces.
>
> Might be worth a shot?
>
> Peace,
> Gary
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>