[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: Tue, 22 Sep 2020 15:53:23 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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.

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

reply via email to

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