[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GLPSOL in webassemby faster than native ?

From: Domingo Alvarez Duarte
Subject: Re: GLPSOL in webassemby faster than native ?
Date: Thu, 24 Sep 2020 15:31:31 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Hello !

I just got glpsol with "long double" working and add binaries for anyone that want to test then here

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]