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 > >
