On Tue, Nov 1, 2016 at 8:58 PM, Ondrej <ondrej.ko...@gmail.com> wrote: > It seems that a universal binary, as Go requires it, would be slow on > dispatch, because there would be too much checking for individual intrinsics > support. Do I understand it correctly, that to overcome this, people either > compile natively (which we cannot do [and don't want to allow]) or JIT it > (which we cannot do as there's no runtime assembly allowed)?
Another ignorant question from me, but what do you mean exactly by universal binary? FWIW, the golang.org/x/image/vector package is portable, in that it has an pure Go implementation. If compiled on GOARCH=amd64, it has SIMD optimizations, guarded at runtime by a very cheap check (look for haveFixedAccumulateSIMD). But that check is made once per e.g. accumulate call (a higher level function composed of many SIMD ops), not once per e.g. 128-bit add. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
