|
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
[Prev in Thread] | Current Thread | [Next in Thread] |