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

[Even Rouault]

Janne,

> 
> we have already tested all possible optimizations SSE2 etc. which ever
> we couild
> switch our compiler to produce ..

You mean: with proj ?

Well, on Intel 64bit platforms, some compilers (at least GCC) do already 
generate SSE code for floating point operations, but I don't think they can 
manage to auto-vectorize it (no way to predict the number of loops, issue with 
all the trigonometric functions, etc..). So they will generate SSE 
instructions, but only with their "sd" form (single double). My experiment 
made it possible to use the "pd" forms (pair of double).

> 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...). 

> 
> If you anyway like to do some special C++ work on the proj.4 package,
> please add
> the syntax scanner in front of it .. so that it makes sure the user
> entered
> some projection definitions that the library did really understand. That
> would
> reduce the number of errors the users makes with the rather complex
> definitions
> the library needs. (No the Proj.4v accepts almost what ever definitions
> and says
> nothing about the fact that it was maybe totally discarded and did not
> make any
> sense)..

That's another topic. And it doesn't really require C++ to have a syntax 
scanner.

> 
> And name it something else than "Proj.4" .. there is already "libProj4"
> .. maybe
> "Cpp.Proj.4" for example .. so you are free to do what ever! :D

Well, if I pursue the experiment to a further stage than just this proof of 
concept, it'll certainly begin as a fork, but the ultimate goal would  be to 
merge it back into the master branch. I've no interest in creating a long term 
fork. I think a RFC would be appropriate, although I don't think proj.4 has a 
formal project steering committee yet.

> 
> I have not had time to check what the github people have done with the
> package?
> Most likely nothing but taken all the glory and destroyed some important
> sections? :) -- which is the usual approach.. haha :)

I don't think this is very constructive to critize other's work without giving 
any evidence of what they would have supposedly done wrong, and it is rather 
rude to state they have done that for their "glory". In Open Source projects, 
the power belong to those who do the work. Why don't you contribute a patch to 
add a syntax scanner ?
One of the benefit I can see with the github migration is that we have now a 
continuous integration mechanism + code coverage.

Even

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