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
