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

[support at mnspoint.com]

Even,

Even Rouault kirjoitti 02.07.2015 17:36:
> 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).
> 

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.


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

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

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


>> 
>> 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,

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.

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

Simply too busy at the moment to add anything except if it is rather 
important for the functionality of the product. Maybe one day I'll do 
that if nobody does it before .. 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.

Certainly some Lint-nism additional to the simple scanner would also be 
desirable..

https://en.wikipedia.org/wiki/Lint_%28software%29

Janne.