CN FORUMS ARCHIVE Telescope Reviews: DSLR Stacking for Linux

ok, my turn to weigh in on this a bit again. Stuff like this can get _fun_ when a group of folks with diverse experience on the topic get into the nitty gritty.

Like the above posters, this kind of code is the thing I've been doing for 30+ years. I originally started programming in assembler for a z-80, and, during my university years, we used punch cards to write fortran, so yes, I've been at this in various ways and forms for a _few_ years too.

In terms of optimizing, in our shop, attitudes have changed over the years. There was a time, many years ago, when we used to look at the assembler output from compilers very closely, and then using profile tools, target specific pieces for hand assembly to dramatically increase execution speeds. In particular, we used to target floating point stuff a LOT, and hand code stuff for the x87 instruction set to be executed on the co-processor. Modern compilers have negated a LOT of that, but, there's still a few areas where we can help a compiler a LOT, by taking advantage of details we know in advance.

First, on the issue of bit shift and add, for the x3 example above. Shift left and then add is an order of magnitude faster than actually implementing the multiply. This can be forced easily with a code snip that works like this:-

y=(x<<2)+x; // to replace y=x*3;

Note the commenting style, that's so when some kid in 10 years is looking to change the code, it's still understandable, and somewhat self documented.

No matter what the compile options, the former will generate the bit shift + add combination, and it'll likely all be done with a pair of registers on the processor, never referencing memory at all. Modern gcc variants for the x86 will indeed generate pretty much the same code for both with all optimization turned on, while a debug build with optimization off will generate much slower code. This optimization would be indeed generated because the 3 is a hard wired constant in the sources, all bets are off if the 3 were to be replaced by a variable to account for differing pixel sizes, ie code written to work with RGB triplets, or work also with monochrome data based on a width multiplier like this:-

y=x*PixelWidth;

The philosophy here now, has changed a lot based on the types of things we've seen compilers produce over the years. Clear concise code is FAR easier to maintain, and debug. Surprisingly, compilers find it a lot easier to optimize as well, and careful analysis of the output can be very surprising at times. Our philosophy these days is to write clear and maintainable code, then let the compiler do the grunt work of making it fast. Exceptions to this are areas where we KNOW things can be made faster by simple algorithm 'helpers', ie substitute bit shift for multiply because we have knowledge in advance that the optimizer cannot trigger on. When adding such optimizations, we always leave the original in place, commented, with more comments to explain the optimization. Otherwise, somebody else getting in to do some maintanence or bug fix, will likely not understand it at all.

Memory use and allocation, another area that's been historically a problem area for many applications. We always try and add a dose of realism into our rationale in this area. If I was in a design meeting, and the project in question was a DSLR stacking program, the first 'reality check' that I'd bring up goes like this. The target user has spent minimum of a kilobuck on a telescope/mount combination, likely 3 or 4 times that, another minimum 500 bucks on the dslr with triple that a real possibility, and, at least another 500 on the associated widgets and gadgets. It's unlikely this person is going to seriously try stacking on a computer with less than half a gig of ram, and far more likely the program will encounter 2 gigs than it'll encounter a deployment on 256 meg. Time spent on working the memory footprint to a minimum is likely better spent refining registration algorithms. If you consider the application will likely be the primary workload on the machine it's being run on, and that machine will have a reasonable memory base to begin with, assuming up front that a memory footprint of 256meg during the run (half of what I consider a minimum machine) is adaquate. I would put no effort into reducing below a 256meg runtime footprint until more important algorithmic issues are resolved. If the memory footprint is a problem, then, it's easily solved with a 20 dollar bill at the local computer hardware supplier. Based on the barrier to entry for program useage (telescope / photographic equipment requirements), a ram requirement in this range is not unrealistic. The program task is to align and stack, focus on that, worry about reducing memory footprint once that's done. Until align / stack is 'great', the memory footprint is irrelavent anyways, doesn't matter how small the footprint is if the primary task isn't being accomplished. A year from now, when the primary functions are all 'good', the typical memory deployment on off the shelf cheap hardware will be in the range of twice what it is today, and the memory footprint issue rapidly becomes moot.

The same rationale comes into play when figuring out what the processing sweet spot should be. 64 bit dual core machines are the norm today. It would be great if it still runs good on a 32 bit processor, but, 64 bit stuff is rapidly becoming the norm, as is the dual core. Since this whole thing is a very processor intensive task, it would be nice to see it prepared to spawn off enough threads to utilize all of the cores available. Cleanly separating the work units so they can be spun off into an arbitrary number of threads will ensure that the program keeps up to hardware as the norm moves from dual to quad cores etc. Again, from my perspective, effectively soaking up the cpu cycles from all the available cores would be far more efficient use of development time instead of focussing on the memory footprint. Again, reference the target end user, far more likely to have a relatively recent machine with a gig or two of ram and a 64 bit dual core processor than they are to have a machine with 256 meg of ram and a single core 32 bit processor. It's simply demographics, we are talking about an end user that spends significant amounts on the supporting hardware, they are not likely to have cheaped out on the computer equipment.

In order of priority, I'd look at objectives like this.

1) First and foremost, program must do a good job of stack and align.
2) The faster the better.
3) Smaller would be nice, but only if it doesn't impact the first two objectives.