[Boost-users] [boost] Formal Review: Boost.Polygon
starts today August 24, 2009]
mbdavis at refractions.net
Mon Aug 31 15:34:56 EDT 2009
Ok, I can see that. So in other words, GEOS uses a dynamic coordinate
access paradigm, which gives flexibility to access different data
structures, but can't be optimized by the compiler?
Is this the reason for the performance difference for *all* the other
libraries which beat it in peformance? Or maybe some of them *don't*
provide the dynamic data structure wrapper, and hence also can be
optimized by the compiler (but thus they are less adaptable for use with
external data structures).
It would be nice to have this confirmed with some detailed code
inspection and/or profiling.
I presume it would be a big job to convert GEOS to a template-based
paradigm? It's somewhat annoying that the problem of efficient memory
access and compiler optimization is quite orthogonal to the actual
geometric algorithms, and yet it seems difficult to express the
algorithms in a sufficiently abstract way to allow optimizations to take
place. Perhaps what we need is a meta-language, in which the raw
algorithms could be expressed and then compiled into whatever codebase
was most efficient to execute. Or - C++ seems incredibly powerful with
it's templating and operator overloading - would it be possible to
define a DSL using C++ constructs which would allow GEOS to be compiled
Mateusz Loskot wrote:
> Martin Davis wrote:
>> Hmmm... GEOS comes off rather badly compared to GGL. Is that because
>> of memory access issues? Or perhaps the fact that less code is
> It's hard to judge, but I'm quite sure inlining is only a small and
> minor optimisation available.
> GEOS and GGL follow completely different programming paradigms.
> GGL is strongly based on static polymorphism resolved and calculated in
> compile-time. This increases changes that compilers will apply finest
> possible optimisations.
> Best regards,
Senior Technical Architect
Refractions Research, Inc.
More information about the geos-devel