[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: And the Winner Is...
On Mon, 05 Feb 2001 12:50:45 -0600, Tom Droege
<tdroege@veriomail.com> wrote:
>Rob now has his code working so we can compare the results:
>
>Tom QuickBasic 64.48 Seconds
>Rob C and CFITSIO 37.12 Seconds
>Andrew Pascal 35.12 Seconds
Not enough of a margin. I am rewriting the whole
thing in Assembler ... operating sytem and all ;>)
Tom - it shouldn't take more than a couple of years
to rewrite your Basic stuff in Assembler. :>(
Actually, may I suggest that the Basic is doing
rather a good job? How long does it take to put in
a change for tests? Minutes? Less? I don't think I
am exagerating the two year time scale for Assembler
and Rob and I have demonstrated a time scale of days
for Pascal or C!
>
>All tests were made on a 500 MHz K6 in a DOS window with no other windows
>open. It is also run with an ALT ENTER which gives windows the full
>screen. This may make a difference. Note that the programs slow down a
>lot, as much as a factor of two, if a second window is open.
>
>Tom is not writing a .fts header so the raw files need a processing step
>with RawToFits with will take a few seconds per file. Note that this only
>takes a few seconds, so it is much faster to read a file, add a .fts header
>and then write it back to disk than it is to read from the memory card and
>write a disk file. Obviously most of the time is taken reading the memory
>card with an 8 bit wide I/O instruction.
>
>Rob is using C and CFITSIO which wirtes out an "official" looking .fts
>header. He is also writing out some test data so it is possible that the
>program will speed up a little when that is removed.
>
>Andrew is coding in Pascal and makes up his own .fts header.
And is astonished to hear that a utility program
is actually reading it as legitimate FITS!
>
>It looks like we are running up against the brick wall of the I/O speed. I
>am curious as to how Chris gets to 20 seconds.
I also get 20 seconds ... so long as I don't write
it to disk with what are essentially DOS routines;
these provide no overlap of reading and writing. The
story that there is disk caching in there appears to
be a myth.
Or is it just that Bennett is too stupid to know how
to turn it on? (Windows says it IS on.)
>
>OK, this is just great and a near halving of the present run time with
>QBasic. It also writes out the .fts headers on the first pass. The
>remaining job is to have the program read in two files that I will write in
>a specified format to put arbitrary things into the .fts header. I
>envision a constants file which contains things like location name,
>lattitude and longitude, etc..
Give this a fixed name and compile this in to the SHELL
program.
> The second file will be changed each time
>the program runs
Giving one extra name to pass to SHELL.
Or even none, if you don't mind overwriting the same file
each time - probably better to write and pass a unique file
then you get two chances at archiving what you did; one in
the FITS header and one when you back up these files.
As an aside, my current solution to the unique file name
problem is to give every file associated with a given raw
data file the same name but keep it in a specific directory.
That way, all my names are DOS 8.3 compatible but are still
sufficiently mnemonic to avoid confusion.
info\rawname, results\rawname etc
>and writes a file and will include things like shutter
>open times and RA and Declination of the telescope.
Ooh! I can't wait! ... I hope it will know when you
kick the mount: I just had to restart my analysis program
with changed magic numbers when the declination shifted
outside the rather small box the program was using.
> OK, you experts will
>have better names for these files, I will fix my QBasic code to write
>anything requested. I hope I can write straight .txt files.
Yes. Put all the fancy FITS format generation in the
program that writes the FITS files. It should really
be done by cfitsio rather than Bennett-ad-hoc.
Andrew Bennett, Avondale Vineyard