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

[support at mnspoint.com]

Even Rouault kirjoitti 02.07.2015 22:24:
>> 
>> 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.
> 

I don't believe it would add anything much to the project..

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

In that environment with that processor tested optimizing too heavily 
the code yielded worse response of the overall user interface .. meaning 
that the OS was not at its best with too much such instructions .. and 
it makes sense since those instructions clearly allocate all the CPU and 
it will no more response so fast to external interrupt loading.. (what 
you believe is your problem!)

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

Much possible .. but nobody wants to tie it to the Proj.4 structure too 
closely since it just adds complexity .. and nobody wants that! (it is 
of course a different joke in the academic world where all possible 
complexity is welcome to trop the poor student fellows and take all the 
glory to one self, haha!)

Janne.