On Sat, Apr 27, 2019 at 6:13 AM bin.cheng <bin.ch...@linux.alibaba.com> wrote:
>
> Hi,
>
> This is the draft patch avoiding scaling cost overflow by introducing a
> scaling bound
> in IVOPTs. For now the bound is 20, and scaling factor will be further
> scaled wrto
> this bound. For example, scaling factor like 1, 1000, 2000(max) would be
> scaled to
> 1, 10, 20 correspondingly.
>
> HI Martin, I remember you introduced comp_cost/cost_scaling to improve one
> case
> in spec2017. Unfortunately I don't have access to the benchmark now, could
> you help
> verify that if this patch has performance issue on it please? Thanks
>
> Bootstrap and test on x86_64, and this is for further comment/discussion.
+ float factor = 1.0f * bfreq / lfreq;
+ if (adjust_factor_p)
+ {
+ factor *= COST_SCALING_FACTOR_BOUND;
+ factor = factor * lfreq / max_freq;
+ }
+ body[i]->aux = (void *)(intptr_t)(int) factor;
float computations on the host shouldn't be done.
I wonder if changing comp_cost::cost to int64_t would help instead? See also my
suggestion to use gmp.
Otherwise the approach looks sane to me - can we then even assert that
no overflows
happen and thus INFTY only appears if we manually set such cost?
Thanks,
Richard.
> Thanks,
> bin
