Re: GLPSOL in webassemby faster than native ?

[Andrew Makhorin]

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