[ptx] x64 benchmarks

[Sebastian Nowozin]

Hi everybody,


On Tue, Jan 17, 2006 at 02:35:19PM -0700, JD Smith wrote:

> [...]
> That, said the slowest parts of panorama creation are now, for me, SIFT point
> detection, and enblend, so it may be worth putting emphasis on those
> components instead.

I totally agree here.  There is definitely a lot of room for speeding up the
SIFT extraction and matching (especially the matching!).  I don't know about
enblend, but I think its basically RAM-bound for performance, whereas
autopano-sift is bound by four factors:

 1. Memory consumption by less than optimal data structures and flow.

    The whole interna is happening using double floats, whereas the accuracy of
floats would suffice.  Image octaves are processed together instead of
one-by-one.  Fixing these two would allow larger image sizes and a higher
accuracy.

 2. SIFT extraction.

    The main two functions here are the convolution primitive and the SIFT
descriptor creation function.  Both are not optimized except simple things like
separability for the convolution.

 3. SIFT matching.

    By far (to me) the most expensive step, especially for large panorama
images with 80 images or more this can take hours even on fast computers.  What
is needed here is a good data structure to match high dimensional (d=128)
points efficiently, which is a research level problem.  But if somebody is into
such data structure I would be most happy to include an implementation.

 4. Mono runtime.

    Not much can be done here and things will improve in the future, but for
FPU intense code as autopano-sift is the Mono runtime is quite slow.  The same
code runs about two to three times faster on Windows with the .NET runtime.


I maybe get around to implementing multiprocessor/core support in autopano-sift
in the next week or so, as I have just completed such code for another project
and its really easy to integrate into autopano-sift for the parallelizable
steps (both extraction and matching are parallelizable).

In the longterm I would be happy to see the keypoint creation code integrated
into hugin as a rewritten C++ code with no additional dependencies (which has
been a reason to complain for many users when they are using autopano-sift).


Greetings,
Sebastian

-- 
nowozin at cs.tu-berlin.de --- http://user.cs.tu-berlin.de/~nowozin/