Re: GLPSOL in webassemby faster than native ?

[Chris Matrakidis]

It is well known that varying initial conditions can dramatically change the running time of a solver (and the tree searched). In this case there are floating point differences and in the first instance the integer solution is found very early and has the same value with the lp solution terminating the search instantly, while in the other it takes a few iterations more (and again terminates the search instantly).

You can't draw any conclusion about solver performance from just one instance, where you may be lucky (or not).

Best Regards,

Chris Matrakidis

On Tue, 22 Sep 2020 at 20:03, Domingo Alvarez Duarte <mingodad@gmail.com> wrote:

Hello Andrew !

In this case mean compiling with "-O3 -DNDEBUG -DWITH_SPLAYTREE" on
Arm7, "-O3 -DNDEBUG -flto -march=native -ffp-contract=off
-DWITH_SPLAYTREE" on x86_64 and "-O3 -DNDEBUG -flto -DWITH_SPLAYTREE" on
wasm.

How are the parameters for the cut generations selected ?

Isn't strange that on wasm it's been faster than native ?

Doesn't this difference gives insight to select the parameter differently ?

Cheers !

On 22/9/20 17:56, Andrew Makhorin wrote:
> On Tue, 2020-09-22 at 15:53 +0200, Domingo Alvarez Duarte wrote:
>> Hello again !
>>
>> On an Android phone arm7 32bits Nexux-5 with chrome browser (wasm)
>> solving the "hashi.mod" with "--cuts" takes 98s and without it 909s,
>> using glpsol native compiled within termux takes 497s with "--cuts"
>> and
>> without it 925s.
>
> What does "native" mean? Just changing, for example, optimization level
> of the compiler may essentially change the set of generated cuts and
> thus the solution time.
>
>
>> Arm7 32bits Nexus-5:
>>
>>       wasm "--cuts -m hashi.mod" -> 98s
>>
>>       wasm " -m hashi.mod" -> 909s
>>
>>       native "--cuts -m hashi.mod" -> 497s
>>
>>       native " -m hashi.mod" -> 925s
>>
>>
>> Laptop Linux 64bits I7:
>>
>>       wasm "--cuts -m hashi.mod" -> 8s
>>
>>       wasm " -m hashi.mod" -> 142s
>>
>>       native "--cuts -m hashi.mod" -> 73s
>>
>>       native " -m hashi.mod" -> 55s
>>
>>
>> On arm7 "--cuts" improves the performance in both wasm and native.
>>
>> On x86_64 "--cuts" improves in wasm but degrade in native.
>>
>> I hope this could give hints to improve GLPK solver performance by
>> inspecting the decision's criteria and eventually find a better ones.
>>
>> Anyone can give any idea with this data ?
>>
>> Cheers !
>>
>> On 21/9/20 17:11, Andrew Makhorin wrote:
>>> On Mon, 2020-09-21 at 16:09 +0200, Domingo Alvarez Duarte wrote:
>>>> Hello Andrew !
>>>>
>>>> Are you saying that floating point calculations are more
>>>> efficient/precise in webassembly ?
>>> No. I meant that due to floating-point computations running the same
>>> computer program with the same data as a rule produces different
>>> results
>>> on different platforms.
>>>
>>>> Cheers !
>>>>
>>>> On 21/9/20 15:08, Andrew Makhorin wrote:
>>>>>> Does someone can give a possible explanation ?
>>>>> floating-point computations
>>