FAQ
Hi all, a few questions for those of you experienced enough with the Go
toolchain:

    - I am writing very small SIMD assembly functions, like Vec32Add,
    Vec64Add, etc.
    - There was talk somewhere about a potential change allowing assembly
    functions to be inlined by the compiler to avoid the overhead of a function
    call, what ever came of this?
    - I can use the CPUID instruction to test whether or not an amd64 CPU
    supports AVX instructions (like this
    <https://gist.github.com/slimsag/294e1a93d3d0f920939f>) -- and I know
    that all (except one?) amd64 CPU's support SSE2 instructions. But how can I
    choose the right code path efficiently? I could do an if statement but it
    doesn't seem optimal given that these are such small functions.
    - Any plans to add vector/SIMD instructions to 6a ? (e.g. vmovupd,
    vaddpd, etc) I can lay them down using the BYTE pseudo-op but it seems like
    something that the assembler should eventually have anyway?

Thank you,
Stephen

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Dave Cheney at Aug 25, 2014 at 11:27 pm

    On Tuesday, 26 August 2014 08:27:34 UTC+10, Stephen Gutekanst wrote:
    Hi all, a few questions for those of you experienced enough with the Go
    toolchain:

    - I am writing very small SIMD assembly functions, like Vec32Add,
    Vec64Add, etc.
    - There was talk somewhere about a potential change allowing assembly
    functions to be inlined by the compiler to avoid the overhead of a function
    call, what ever came of this?

    It is still something that we'd like to see, there are no plans at the
    moment do to it as the current inlining scheme works at the source code
    level, not the binary level.

    -
    - I can use the CPUID instruction to test whether or not an amd64 CPU
    supports AVX instructions (like this
    <https://gist.github.com/slimsag/294e1a93d3d0f920939f>) -- and I know
    that all (except one?) amd64 CPU's support SSE2 instructions. But how can I
    choose the right code path efficiently? I could do an if statement but it
    doesn't seem optimal given that these are such small functions.

    You can either do a test and set a function variable which you branch
    through at startup, we do this for the runtime map implementation, look at
    runtime/hashmap_fast.(go,c) or compile two versions of your program using
    build tags.

    - Any plans to add vector/SIMD instructions to 6a ? (e.g. vmovupd,
    vaddpd, etc) I can lay them down using the BYTE pseudo-op but it seems like
    something that the assembler should eventually have anyway?

    Please open an issue on the issue tracker specifying the exact
    instructions you want added


    Thank you,
    Stephen
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at Aug 28, 2014 at 11:45 pm

    On Mon, Aug 25, 2014 at 6:27 PM, Stephen Gutekanst wrote:
    I am writing very small SIMD assembly functions, like Vec32Add, Vec64Add, etc.
    There was talk somewhere about a potential change allowing assembly functions to be inlined by the compiler to avoid the overhead of a function call, what ever came of this?
    Probably it's me. Sadly, there is no plan to do that, and as the compiler
    is being migrating to Go, once that's done, it's probably time to
    bought this up again
    (although it seems to conflict with the cmd/asm plan and it's quite
    hard to do generally)
    I can use the CPUID instruction to test whether or not an amd64 CPU supports AVX instructions (like this) -- and I know that all (except one?) amd64 CPU's support SSE2 instructions
    i think SSE2 is required for all amd64 cpus. 6g unconditionally uses
    SSE2 for floating point computation.
    . But how can I choose the right code path efficiently? I could do an if statement but it doesn't seem optimal given that these are such small functions.
    Either use function pointer or use conditional jump. I guess
    conditional jump is probably easier for
    branch predictor to get right than call though a function pointer.

    e.g. see hash/crc32 for an example.
    Any plans to add vector/SIMD instructions to 6a ? (e.g. vmovupd, vaddpd, etc) I can lay them down using the BYTE pseudo-op but it seems like something that the assembler should eventually have anyway?
    There are plans to write a pure Go cmd/asm that could handle *ALL*
    supported instructions listed in the
    latest Intel manual. Not sure when that will come true though (the
    encoding will be parsed directly from
    the manual).

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dan Kortschak at Aug 29, 2014 at 12:16 am

    On Thu, 2014-08-28 at 19:45 -0400, minux wrote:
    There are plans to write a pure Go cmd/asm that could handle *ALL*
    supported instructions listed in the
    latest Intel manual. Not sure when that will come true though (the
    encoding will be parsed directly from
    the manual).
    I'd be interested in seeing how this is achieved/to be achieved.

    Dan

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at Aug 29, 2014 at 12:27 am

    On Thu, Aug 28, 2014 at 8:16 PM, Dan Kortschak wrote:
    On Thu, 2014-08-28 at 19:45 -0400, minux wrote:
    There are plans to write a pure Go cmd/asm that could handle *ALL*
    supported instructions listed in the
    latest Intel manual. Not sure when that will come true though (the
    encoding will be parsed directly from
    the manual).
    I'd be interested in seeing how this is achieved/to be achieved.
    Actually, the parsing step is already done by Russ a long time ago,
    and the table is what is powering the Go 1.3's cmd/objdump.

    code.google.com/p/rsc.x86 (similarly, rsc.arm for arm)

    To take a look at what the pdf extractor looks like, see the version for
    power64:
    code.google.com/p/rsc.power64/power64spec

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dan Kortschak at Aug 29, 2014 at 12:34 am
    Lovely, thanks.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Stephen Gutekanst at Aug 30, 2014 at 6:58 am

    It is still something that we'd like to see, there are no plans at the
    moment do to it as the current inlining scheme works at the source code
    level, not the binary level.

    Oh, okay.

    You can either do a test and set a function variable which you branch
    through at startup, we do this for the runtime map implementation, look at
    runtime/hashmap_fast.(go,c) or compile two versions of your program using
    build tags.

    Could you provide line numbers for where this happens? I've been looking
    but I am having trouble finding the code you are talking about.

    Either use function pointer or use conditional jump. I guess conditional
    jump is probably easier for branch predictor to get right than call though
    a function pointer.

    What is [a][the] branch predictor? I guess it predicts branching code and
    does an optimization -- but how?

    One last question -- Russ mentions in http://golang.org/issue/4978 that
    allowing methods implemented in assembly would complicate the toolchain a
    lot. It seems from my (rather naive) perspective that methods would be
    almost identical to regular assembly functions ? It would also help me
    write a cleaner API, for example:

    func (a Vec32) Add(b Vec32) Vec32
    func (a Vec32) Sub(b Vec32) Vec32
    ...
    a.Add(b).Sub(c)

    instead of:

    func Vec32Add(a, b Vec32) Vec32
    func Vec32Sub(a, b Vec32) Vec32
    ...
    simd.Vec32Sub(simd.Vec32Add(a, b), c)

    without another function call overhead inside the method (since they are
    rather small operations). How badly would this complicate/hinder future
    changes to the toolchain?

    - Stephen

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Lars Seipel at Aug 30, 2014 at 11:39 am

    On Fri, Aug 29, 2014 at 11:58:01PM -0700, Stephen Gutekanst wrote:
    What is [a][the] branch predictor? I guess it predicts branching code and
    does an optimization -- but how?
    A branch predictor is part of your CPU and should be pretty good
    nowadays. They mostly work by taking the history of a specific
    conditional jump into account - was the branch taken or not?

    You can imagine that for an oft-repeated loop this can lead to pretty
    good results. As it might for your case where the taken branch will be
    the same over the whole program execution.

    Test it.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 25, '14 at 10:27p
activeAug 30, '14 at 11:39a
posts8
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase