David,
I just saw your note for the first time yesterday; I must have missed it
when you e-mailed it to the Blitz list.
I am a Principal Scientist at HP Labs, in Color Imaging & Printing
Technology. I telecommute to the Palo Alto area from my home in Redmond,
Washington, so I'm easily available for further discussions if needed.
At 02:07 PM 1/19/2001 -0800, you wrote:
>1. Which libraries do you use?
MTL and Blitz++ are the primary libraries, but we also try to use freely
available cross-platform code wherever possible.
>2. If you cannot use Visual C++ with these libraries, what are the
>causes of this? For example, does the library require partial
>template specialization support? Do other issues also prevent you
>from using the library with Visual C++?
(a) Partial template specialization!
(b) Lightweight object optimization (i.e., aggressive reduction of fully
specialized template class complexity); needed for efficient run-time
performance of expression templates.
(c) Lack of support for basic C++ language features/libraries, ranging from
the trivial (e.g., min and max) to the extremely annoying (for-loop
scoping; currently handled by a macro).
(d) Extremely poor performance in some standard library routines (e.g.,
std::vector).
In principal, there is a hacked version of MTL that allows compilation with
Visual C++, but its performance is terrible.
>3. If you are a library developer, what workarounds or design
>constraints were required for compatibility with Visual C++? What
>were the most significant ones? Did the workarounds or constraints
>have performance impacts?
Here's a typical code fragment from one of our configuration header files:
// MSVC++ bugs/problems; not needed for the Intel compiler
#if defined(_MSC_VER) && !defined(__ICL)
#pragma warning( disable : 4786 4250 4244 4305)
#define NO_TYPENAME
#define TEMPLATE_COPY_CONSTRUCTOR_BUG
#define NO_PARTIAL_TEMPLATE_SPECIALIZATION
#define NO_STL_MEMBER_TEMPLATES
#endif // _MSC_VER && !__ICL
As you can see, we've been using the Intel compiler for most of our work on
Windows. In our numerical work, we can get within a factor of 2 or so of
the performance of code generated by the Linux Kuck & Associates KCC
compiler _on the same processor_ by using Intel's compiler. We hope that
this performance gap will close now that Intel has purchased KAI. When we
can compile similar code under MSVC++, we usually see performance degrade
by a factor of 3 to 10 compared to KCC.
We're also investigating STLport, the third-party implementation of the
STL, to get ANSI-standard STL support.
>4. Are you mainly a "consumer" or "producer" of library templates?
Both. I am currently leading the development of a template-based library
(similar in architecture to the STL) for image processing and computer
vision at HP Labs. We hope to propagate this library into as many of HP's
divisions as possible. The primary resistance to widespread adoption of our
work is our inability to provide decent performance using MSVC++, which is
still pervasive in the divisions. (In some cases, we haven't had the time
to port our standard C++ code to MSVC++ yet, so some parts of the library
won't even compile.) We are currently investigating the cost of a site
license for the Intel compiler, and in performance-critical simulation
work, we are simply giving up and using KCC under Linux.
I'd be grateful if a future version of Visual C++ could (1) compile all
code conforming to ANSI-standard syntax, and (2) have an explicit
ANSI-compatibility switch (instead of the obscurely named ``Disable
language extensions'' check-box) that will allow us to guarantee that our
syntax conforms to the ANSI standard. I suppose it isn't critical that VC++
generate high-performance executables from code that makes heavy use of
complex templates, since we can use the Intel (and/or KCC) compiler for
final executable construction. But full ANSI compatibility would be a
tremendous help for our internal development efforts. (Personally, I'd
prefer to have a separate switch to set ANSI/IEEE floating-point
compatibility, but that's another issue entirely.)
Regards,
Ray
============================
Ray Beausoleil
Hewlett-Packard Laboratories
mailto:beausol@hpl.hp.com
425-883-6648 Office
425-957-4951 Telnet
425-941-2566 Mobile
============================
--------------------- blitz-dev list --------------------------------
* To subscribe/unsubscribe: use the handy web form at
http://oonumerics.org/blitz/lists.html
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 04:30:12 EST