Re: Mandrake 10.1 Community
From: David Wright (david_c_wright_at_hotmail.com)
Date: 10/12/04
- Next message: David Wright: "Re: Linux and WLAN Internet access"
- Previous message: Oddbjørn Hansen: "Re: Suse 9.1 and WLAN 802.11g cards"
- In reply to: James Knott: "Re: Mandrake 10.1 Community"
- Next in thread: James Knott: "Re: Mandrake 10.1 Community"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 12 Oct 2004 09:01:57 +0200
James Knott wrote:
> Arthur Hagen wrote:
>
>> Paul J Gans <gans@panix.com> wrote:
>>>
>>> Most of the sorting algorithms in Knuth's "The Art of Computer
>>> Programming" (Volume 3, I think) date from the era right after
>>> that when rich companies had banks of tape drives. It is a hoot
>>> reading those chapters today. The algorithms for optimum use
>>> of the tape drives are probably long forgottne now.
>>
>> Not really. It makes sense these days too, when making backups to CD's
>> or DVD's, or even when backing up to another harddrive a staggered tower
>> of hanoi scheme can minimize the backup time and storage requirements of
>> incremental backups. From my crontab:
>>
>> 40 4 1,17 * * /usr/local/sbin/xfsbackup -l 0
>> 40 4 9-31/16 * * /usr/local/sbin/xfsbackup -l 2
>> 40 4 5-31/8 * * /usr/local/sbin/xfsbackup -l 4
>> 40 4 3-31/4 * * /usr/local/sbin/xfsbackup -l 6
>> 40 4 2-31/2 * * /usr/local/sbin/xfsbackup -l 8
>>
>> This has certainly reduced the time spent and disk space required for
>> doing backups every single day.
>>
>
> He was talking about sorting, not backing up. In the days before cheap
> memory and disk drives, it was difficult to sort data stored on tapes.
> The problem was how to efficiently sort data on a linear access storage
> medium. Sorting is much easier on a random access device, such as disk
> drives or in
> memory, as is practical today. Remember, we're talking about way back in
> the '50s, when disks were not available and memory was very expensive and
> scarce.
I think that is one talent that many programmers today have never learnt.
They have machines with oodles of disk, memory and processing power. I've
worked on several projects where the code to be delivered has been dog slow
and the programmers say "the customer will need to upgrade their hardware."
A quick look at optimising the code suddenly finds that additional iron
isn't necessary after all, just a little care in the coding department.
When I started work, there wasn't any faster hardware to upgrade to. If
something ran too slow, you had to look at why and try and sort it out, or
if what the customer wanted really needed did take that long, you had to
sell it to them. My first "official" project when I started full time work
(the oil stuff mentioned elsewhere was part time in the school holidays),
was to upgrade some accounts data collection software. It was horrendous,
it was in MS-BASIC for CP/M and MS-DOS running on HP-125 and HP-150
machines; it had been written by Fortran programmers and maintained by
COBOL programmers... To say it was a mess was an understatement. Using
loops instead of computed go to's helped a lot for performance for a start,
and little tricks like not displaying every account that was being
consolidated, but every 10th or 20th (I think we switched to every 50th in
the end) made things a lot faster (I think after 3 weeks working on the
project we had the consolidation time down from over 1 hour to just over 12
minutes).
Dave
- Next message: David Wright: "Re: Linux and WLAN Internet access"
- Previous message: Oddbjørn Hansen: "Re: Suse 9.1 and WLAN 802.11g cards"
- In reply to: James Knott: "Re: Mandrake 10.1 Community"
- Next in thread: James Knott: "Re: Mandrake 10.1 Community"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
