Fwd: Re: Could you share your experience...

[Will Schroeder]

Hi Folks-

Luis has sent a message pointing to VIGRA (generic programming image system), and I followed up with some questions to the developer Ullrich Koethe. I think the dialog is informative.

Will
---------

>Hi Ullrich -
>
>My name is Will Schroeder, I'm working with a group of folks developing a segmentation and registration toolkit for the National Library of Medicine in the US. We are in the design stage, and have been struggling with architectural issues, mainly where to draw the line between run-time and compile-time binding.
>
>My prior experience is with the open-source Visualization Toolkit (VTK www.kitware.com/vtk.html) which leans towards run-time binding and a very conservative C++ design (single inheritance, limited use of templates, etc.). Part of the reason for this is that we wrap the C++ library with interpreted languages like Tcl, Python, and Java. VTK is successful, it's a huge system and runs everywhere, and people seem to be able to learn and use it pretty well.
>
>Some of the folks on the team have been encouraging us to go the generic programming route. We've been exploring and stumbled across the Vigra code. While I think this technology is promising, I'm concerned about the possible problems introduced such as code bloat, compiler difficulties, unreadable code, proliferation of classes, lack of run-time flexibility, etc. Part of my concern is that this toolkit has the potential to grow to 1000 classes and 250,000 lines of executable code. So it's code tha must be usable in production, not just in the academic sense.
>
>Can you point me to any articles that discuss these issues, or do you have any experience that you can share along these lines? I'm interested in hearing both sides of the story. I have downloaded Reusable Software in Computer Vision and will look at it today.
>
>Thank you,
>Will



>Sender: koethe at kogs.informatik.uni-hamburg.de
>Date: Fri, 25 Feb 2000 17:03:16 +0100
>From: Ullrich Koethe <koethe at informatik.uni-hamburg.de>
>X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u)
>X-Accept-Language: en
>To: Will Schroeder <will.schroeder at kitware.com>
>Subject: Re: Could you share your experience...
>X-MIME-Autoconverted: from 8bit to quoted-printable by kogs1.informatik.uni-hamburg.de id RAA02857
>
>Hi Will,
>
>this is a very interesting question indeed! As it happens I'm hoping to
>get a PhD for my answer next Tuesday. 
>
>Basically, i think you need both: generic programming to get flexibility
>at the low-level (functions and data structures), and 
>object-orientation for run-time flexibility.
>
>In comparison to e.g. computer graphics, image analysis is a much less
>mature field (inverse problems are always much harder). So, there is no
>set of standard algorithms that work most of the time (some people claim
>otherwise, but don't be fooled). Instead, we keep changing all kinds of
>details as circumstances (i.e. the images to be processed) and
>understanding evolve. These changes occur at a relatively low-level:
>exchange float for byte, replace a particular formula for second
>derivatives by another one and the like. 
>
>Using virtual functions (and perhaps dynamic_cast) to cope with this
>kind of changes will result in a very inefficient system. You can't
>simply do a dynamic cast for each pixel, i.e. 1 million times a second.
>Compile-time techniques are much more appropriate here. In addition,
>generic programming gives you some techniques that are not present in
>the OO part of C++:
>
>- code generation upon necessity
>- multiple polymorphism with powerful pattern matching (by partial
>ordering 
>   of overloaded functions and function templates)
>- meta classes (traits)
>
>So I use generic programming to write the real 'work horse
>functionality'. (Some of the related ideas are described in my paper.)
>
>Now, to get runtime flexibility, I build a larger pieces of
>functionality from the generic building blocks and wrap them into
>objects. These objects are then exported to Python. So I have both: I
>can change alsogrithmis details in the generic layer and collaboration
>of modules in the OO layer.
>
>When implementing this in C++, some care is required to manage compile
>dependencies. Since templates are usually kept in header files,
>visibility of these headers must be controlled. (Otherwise, a simple
>implementation change could cause a huge recompile). This is part of the
>benefit of wrapping genericity into objects. (Hopefully, this situation
>will change when compilers start to support separate compilation for
>templates).
>
>As to the choice of compiler: if your your goal is maximum portability,
>you might be better of not using generic programming. However, since the
>standard library depends on it, compilers are quickly catching up. Also,
>one can use a subset of techniques that retains most of the benefits and
>runs on most compilers. I've successfully used GNU g++, the SGI native
>compiler and Microsoft Visual C++ (with some limitations). 
>
>Code bloat is a problem that I havn't gone into very much (which means
>it wasn't so severe as to cause trouble). Often, the main reason for
>code bloat are long template names which can easily be stripped off the
>final executable (on SGI, this sometimes reduces code size to 50%).
>
>I hope this helps. Please ask again if any question remain
>
>Regards
>Ulli
>-- 
>  ________________________________________________________________
>|                                                                |
>| Ullrich Koethe  Universität Hamburg / University of Hamburg    |
>|                 FB Informatik / Dept. of Computer Science      |
>|                 AB Kognitive Systeme / Cognitive Systems Group |
>|                                                                |
>| Phone: +49 (0)40 42883-2573                Vogt-Koelln-Str. 30 |
>| Fax:   +49 (0)40 42883-2572                D - 22527 Hamburg   |
>| Email: u.koethe at computer.org               Germany             |
>|        koethe at informatik.uni-hamburg.de                        |
>| WWW:   http://kogs-www.informatik.uni-hamburg.de/~koethe/      |
>|________________________________________________________________| 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20000228/706af4c5/attachment.html>