Re: GLPSOL in webassemby faster than native ?

Hello !

I just got glpsol with "long double" working and add binaries for anyone 
that want to test then here https://github.com/mingodad/GLPK/releases

As noted there it'll benefit from tuning the constants in src/glpk_real.h

Any help/suggestion/comment is welcome !

Cheers !

On 22/9/20 21:49, Michael Hennebry wrote:
> On Tue, 22 Sep 2020, Domingo Alvarez Duarte wrote:
>
>> Due to the big difference in solver time how could we figure out 
>> what's is it in order to use this knowledge to improve the native 
>> solver time ?
>>
>> I mean what debug/verbose options could help us have a clue ?
>
> I expect the answer is none.
> My guess is that neither platform is inherently better than the other.
> Which small roundings will be better doubtless depends
> on the particular problem and version of GLPK.
> Andrew insists on C89.
> That pretty much eliminates control over how floating point is done.
>
> double x=1./3., y=1./3.;
> C89 does not require x and y to have the same value.
> IEEE arithmetic would, despite possible double rounding.
>
> Even with IEEE, platforms are allowed to evaluate floating point
> expressions with a precision larger than required by the expressions.
> They are not required to be consistent.
> double x=2.0+DBLE_EPSILON-2.0, y=2.0+DBL_EPSILON-2.0;
> x could be 0 or DBLE_EPSILON, as could y.
> They need not be the same.
> Once upon a time, that was a real problem with gcc.
> For C89, it might still be.
>
> With a lot of casts to long double and sufficient
> care in the representation of constants,
> Andrew might be able to get consistent behaviour between
> IEEE platforms with matching doubles and long doubles.
>
> It's been a while since I looked at any GLPK code.
> My expectation is that at least some of it, e.g. dot product, is 
> memory bound.
> In such a case, explicitly using long doubles would
> not slow it down and could improve its accuracy.
> Possibly Andrew already does that.
> I haven't looked lately.
>