RE: Making the present code run faster

[Doug Welch <welch@physics.mcmaster.ca>]

I want to strongly reinforce Chris's remarks. Rewriting
FITS software is one of the greatest time-sinks ever
created and one of the largest sources of erstwhile
FITS-file incompatibilities. There are many other things
to spend time on - this shouldn't be one of them.

Cheers,
Doug

On Wed, 31 Jan 2001, Albertson, Chris wrote:

> 
> 
> Don't try to do FITS format file on your own.  There's no
> point.  Except as an excercise if you have time to kill.  The
> CFITSIO library is the only way to go.  It handles
> the blocking for you.    The feature list is longer then your
> arm and it runs on just about any kind of computer.  There is
> no way you could duplicate CFITSIO in only a few months.
> The library is in such common use that you could even say
> the it _defines_ the FITS file format.
> 
> CFITSIO goes on step farther the what you did. It maintains a
> block cache in RAM.  It writes out the bloks using random I/O
> as required.  If you have enough RAM nothing really is commited
> to disk until the file is closed.  The cache algorithum was
> been tweeked and re-tweeked for years now an is about as good
> as it is going to get.  As I said befor, I can write FITS
> at the hardware "media speed" using only a P200.
> 
> 
> > -----Original Message-----
> > From: Andrew Bennett [mailto:andrew.bennett@ns.sympatico.ca]
> > Sent: Tuesday, January 30, 2001 12:48 PM
> > To: Tom Droege; tass@listserv.wwa.com
> > Subject: Re: Making the present code run faster
> > 
> > 
> > On Mon, 29 Jan 2001 13:34:04 -0600, Tom Droege 
> > <tdroege@veriomail.com> or somebody wrote:
> > 
> > >   Then it is not a question of CPU speed, but rather disk
> > >speed or some interaction between the BASIC code and disk
> > >writing.
> > 
> > The biggest single factor in speeding up my Pascal
> > code was to quit trying to write in 2880 Byte chunks
> > (for FITS) and instead to block the data up in 2^n
> > segments. The odd sizes really screwed up the system
> > with or without SMARTDRV. With SMARTDRV, one could
> > use relatively short 2^n blocks without penalty. I used
> > 16384 Bytes.
> > 
> > I know nothing about Windows caching - I suspect it
> > will also be badly affected by non-2^n blocks.
> > 
> > My Pascal code looked like this:
> >   L := NAxis1*NAxis2 ; { Size in 16-bit words }
> >   N := LBufW ; { 8192 = 16384/2 }
> >   I := 0 ;
> >   Repeat
> >     B1 := InPortB(PortNo) ;
> >     B2 := InPortB(PortNo) ;
> >     BufA[I] := 256*Word(B1) + B2 ;
> >     B1 := InPortB(PortNo) ;
> >     B2 := InPortB(PortNo) ;
> >     BufB[I] := 256*Word(B1) + B2 ;
> >     Inc(I) ;
> >     If (I >= N) Then Begin
> >       BlockWrite(FileA, BufA, N) ;
> >       BlockWrite(FileB, BufB, N) ;
> >       Dec(L, N) ;
> >       N := L ; If (N > LBufW) Then N := LBufW ;
> >       I := 0 ;
> >     End ;
> >   Until (L <= 0) ;
> > 
> > I'm sorry, but I don't know enough BASIC to translate
> > this back. Note that the last disk writes are a
> > different size from the others so I could not
> > use File Of BufType; I was effectively using
> > File Of Word; N is the number of words to be
> > written (record size of 2 Bytes).
> > 
> > Andrew Bennett, Avondale Vineyard
> > 
> 

==============================================================
 Douglas L Welch     | Office/voicemail (905) 525-9140 x23186  
 Physics & Astronomy | FAX              (905) 546-1252 
 McMaster University | 
 Hamilton, Ontario   | 
 Canada L8S 4M1      | E-mail       welch@physics.mcmaster.ca

    On research leave at LLNL (Oct 1, 2000 - Apr 30, 2001)
        LLNL Office/voicemail         (925) 424-2857
        LLNL FAX                      (925) 423-0238
     Continue to use welch@physics.mcmaster.ca for e-mail
==============================================================