Re: [boost] GIL - Breeze presentation posted

From: Ivan Vecerina (ivec_at_[hidden])
Date: 2006-06-30 17:32:04

"Andy Little" <andy_at_[hidden]> wrote in message 
news:e82q57$4i4$1_at_sea.gmane.org...
: "Ivan Vecerina"  wrote
...
: > I develop an internal application. For validation purposes,
: > my preference so far has been to release "debug" builds
: > (i.e. with all runtime checks enabled and without aggressive
: > compiler optimizations).
: > In this scenario, abstraction penalty can be huge, because
: > inlining is weak/inexistent.
: >
: > Writing a "C-style" version of the basic algorithms I need
: > (e.g. erosions etc), there is only a minor difference
: > between debug and optimized builds (e.g. often less than x 2).
: > Using generic GIL code ... I suspect that the difference
: > would be of an order of magnitude.
:
: What is stopping you adding checks in an optimised version?

Error 1 Command line error D8016 :
  '/O2' and '/RTC1' command-line options are incompatible cl

This is about automatic range-checking and other runtime checks
that can automatically be generated by Visual C++ into the
generated code. They interfere with optimization, and inlining.

Granted, I could either:
 - Work on finding a compromize between optimizations & tuning,
   and enabling library runtime checks.
 - Modify compiler options for specific code modules only
... but for now the software has been doing well without this,
and the "full runtime checks" approach helps give an extra
level of confidence when facing the regulatory guys.
Over time, as our confidence level (experience with audits)
increases, I might move towards more aggressive optimization
[ in practice I have never had a problem detected in the field ]

Anyway, the point is:
In debug mode, abstraction penalty can be quite high.
It can get even worse if your standard library implementation
includes built-in runtime checks, as the one that ships with
VS2005 (checked iterators can be excruciatingly expensive
within an inner loop). And mixing runtime check options
within the same target application does not work well
(different in-memory representations...).

It would help if compilers would already start by get better
at inlining functions (especially single-statement functions)
when generating code in debug mode.

[  The same would apply when comparing boost::spirit
   to parsers based on code generators, such as flex  ]

-- Ivan
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form