Back in the late 1980s and early 1990s, I was programming in a language called System Z that still had a version of the merge sort algorithm built in. You would define an input loop and an output loop. The input loop would process, writing data to a temporary file on disk, until EOF was reached. The program would then do a merge sort, and repeat the output loop until EOF of the sorted data was reached. The sort algorithm would read data into a buffer until memory was full, then write it out to a series of temporary files. The program would then go through a series of comparisons and merges, one pair of files at a time, then go back again and do the same thing with the resulting new files, etc. The tokenized program, variables, and buffers used by the interpreter all had to fit into a single 64K memory space, suggesting that the language had originally been written for use on the original IBM PC, which had a segmented memory architecture.
----- Original Message ----- From: Jason Orendorff [EMAIL PROTECTED] To: [email protected] Sent: 11/20/08 2:22 PM Subject: [nlug] Re: You just have to love math... > > On Wed, Nov 19, 2008 at 9:41 PM, Jack Coats wrote: > > Tapes for working data etc were the technology of the day. Archival, > > working and temp storage, even bringing in bits of programs (overlays) > > from tape was not that unusual. As hardware has gotten cheaper, we > > throw that at a problem rather than brain cells, [...] > > In our defense, brain cells are precious. > > So is time. Apparently different eras have very different views on > trading space for speed. For example, Knuth's discussion of dynamic > memory allocation talks about best-fit and first-fit algorithms. This > is good stuff, still useful--but you really don't want to implement > malloc this way, not today. For that you want size-classes and > freelists, because they avoid fragmentation and they are much, much > faster. > > In other words, if you needed a dynamic memory allocator, and you went > straight to Knuth, you would be led horribly astray. You would be > scraping for bytes, when bytes are in plentiful supply and milliseconds > are not. > > I need to keep plugging at it, but it's a lot of extra thinking to figure > out what's still relevant, and in what situations. > > -j > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "NLUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en -~----------~----~----~----~------~----~------~--~---
