[Proj] Experiment to speed up proj.4 by 2 or more

[Even Rouault]

> 
> you don't need any C++ just to optimize it .. the
> compiler can optimize it as it is as well. We are using
> C++ with Proj.4 and several other C libraries without
> touching it .. it is NOT good idea to write it C++
> since many people use it standard C. Or if you
> want to write C++ the rename your product totally.

Please read my previous emails on the subject where I explain that the C API 
would be preserved and C++ would be just a conveniency implementation detail 
of proj.4 code to be able to easily have common sources that could be compiled 
with support for non SIMD (as currently), SIMD with 2 doubles or SIMD with 4 
doubles.

> 
> >> the bad news is that even if the
> >> performance
> >> could be somewhat better in some speed aspects .. the overall system
> >> performance
> >> got worse and for example the screen updateing matters and interrupt
> >> servicing
> >> got worse! .. so basically there is not much to be gained taking that
> >> road. And
> >> we switched back not to optimize some important sections since the
> >> overloading
> >> of the cpu made the OS not any more work so efficiently and fluently.
> >> (At least for some processors)
> >> 
> >> The problem with very hard optimizations is that the results can be
> >> very
> >> strange
> >> with different processors an operating systems. And since most of them
> >> have only
> >> been tested with rather "lame" programs by the manufacturers of
> >> processors and
> >> operating systems .. it is usually best not to try too much! .. or at
> >> least
> >> all combinations should be tested .. which might be very huge a task!
> > 
> > Woo, that's news to me ! I'd be interested in links to articles, etc..
> > that
> > would document such behaviours.
> > Most video codecs etc use SIMD instructions. libjpeg-turbo too. libc
> > too I
> > think for string operations (strlen, strcmp, etc...).
> 
> There are no direct links and no articles .. we are using mostly
> Microsoft environments.

I'm still rather skeptical that SIMD instructions have the behaviour you 
describe without more probative evidence. I've never seen that on Linux for 
sure, and I'm not sure why the nature of the OS would matter for that.

> 
> yes, that is true. And the scanner should anyway be totally an
> independent part which could be omitted if not required.

Agreed. There should be a way to turn off validation as it might impact 
performance (although if it is done correctly, that should hopefully be 
neglectable)

> 
> I am not very much any open project man here .. I respect Gerald
> Evenden's work and Frank Warmerdam's additions to it. I see Proj.4
> mostly as a two man project (Gerald + Frank) .. and since it is very
> usable as it is now I don't see much point to alter it.

I also respect very much their work, but that's not a reason for not exploring 
further enhancements. And you can always use existing versions if you don't 
need/like new features.


> but it might as well be completely its
> own package or library since it does not need to be tied with Proj.4 to
> function. You just feed your definition first to the scanner if required
> and then to the proj.4 as normal if the scanner and/or the user said ok
> after possible error messages etc.

This is somehow linked to which projection methods are supported by the 
library, and a few are added from time to time, so I'm not completely sure 
that a validator could be externally added in a sustainable way.
I think that would also require projection methods to explicitely expose the 
parameters they support.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com