FAQ
Are there plans to provide in golang/gc the capability to indicate an
alternate target instruction set, similar to what is done now with -mcpu in
gccgo?

Or will this be done with new GOARCH values?

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Ian Lance Taylor at Sep 9, 2015 at 5:03 pm

    On Wed, Sep 9, 2015 at 9:15 AM, wrote:
    Are there plans to provide in golang/gc the capability to indicate an
    alternate target instruction set, similar to what is done now with -mcpu in
    gccgo?

    Or will this be done with new GOARCH values?
    What we do today is use CPU-specific environment variables. To date
    we have two: GOARM and GO386. They are documented at
    https://golang.org/cmd/go . We hope to have as few of these as
    possible.

    Ian

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Laboger at Sep 9, 2015 at 6:31 pm

    On Wednesday, September 9, 2015 at 12:03:11 PM UTC-5, Ian Lance Taylor wrote:

    On Wed, Sep 9, 2015 at 9:15 AM, <lab...@linux.vnet.ibm.com <javascript:>>
    wrote:
    Are there plans to provide in golang/gc the capability to indicate an
    alternate target instruction set, similar to what is done now with -mcpu in
    gccgo?

    Or will this be done with new GOARCH values?
    What we do today is use CPU-specific environment variables. To date
    we have two: GOARM and GO386. They are documented at
    https://golang.org/cmd/go . We hope to have as few of these as
    possible.

    Ian
    Since at some point it will be necessary to distinguish between power8 and
    power9,
    something like GOPPC64 would be needed.

    Or if you want to limit the number of env variables but still provide this
    type of
    capability, a new generic env var could be added like
    GOCPUSPEC, with different allowable values depending on the GOARCH.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at Sep 9, 2015 at 7:18 pm

    On Sep 9, 2015 2:31 PM, wrote:
    On Wednesday, September 9, 2015 at 12:03:11 PM UTC-5, Ian Lance Taylor wrote:
    Since at some point it will be necessary to distinguish between power8
    and power9,
    something like GOPPC64 would be needed.
    Why do we need to distinguish power 8 and power 9 (for the compiler)?
    Individual packages can do runtime detection and select the optimum code.
    Or if you want to limit the number of env variables but still provide
    this type of
    capability, a new generic env var could be added like
    GOCPUSPEC, with different allowable values depending on the GOARCH.
    I really don't like more arch-specific variables. I don't wang gc to become
    gcc/llvm where you have 100 knobs for the backend.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Lynn A. Boger at Sep 9, 2015 at 8:17 pm

    On 09/09/2015 02:18 PM, minux wrote:
    On Sep 9, 2015 2:31 PM, wrote:
    On Wednesday, September 9, 2015 at 12:03:11 PM UTC-5, Ian Lance
    Taylor wrote:
    Since at some point it will be necessary to distinguish between
    power8 and power9,
    something like GOPPC64 would be needed.
    Why do we need to distinguish power 8 and power 9 (for the compiler)?
    Individual packages can do runtime detection and select the optimum code.
    Someone might want to build a program to run on different instruction
    sets. The compiler doesn't know if you want your program to run on
    power8 or power9 hardware. Especially in the cross-compiled case. Same
    reason that the GOARM and GO386 env variables were added.
    Or if you want to limit the number of env variables but still
    provide this type of
    capability, a new generic env var could be added like
    GOCPUSPEC, with different allowable values depending on the GOARCH.
    I really don't like more arch-specific variables. I don't wang gc to
    become gcc/llvm where you have 100 knobs for the backend.
    My last suggestion was to eliminate arch-specific variables, like GOARM
    and GO386 and replace them with a single, more general purpose one that
    can be used for any GOARCH. Just an idea.

    OR: allow multiple values on the GOARCH env var, like ppc64le,power8 or
    ppc64,power9.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at Sep 9, 2015 at 9:49 pm

    On Wed, Sep 9, 2015 at 4:17 PM, Lynn A. Boger wrote:
    On 09/09/2015 02:18 PM, minux wrote:
    On Sep 9, 2015 2:31 PM, wrote:
    On Wednesday, September 9, 2015 at 12:03:11 PM UTC-5, Ian Lance Taylor wrote:
    Since at some point it will be necessary to distinguish between power8
    and power9,
    something like GOPPC64 would be needed.
    Why do we need to distinguish power 8 and power 9 (for the compiler)?
    Individual packages can do runtime detection and select the optimum code.

    Someone might want to build a program to run on different instruction
    sets. The compiler doesn't know if you want your program to run on power8
    or power9 hardware. Especially in the cross-compiled case. Same reason
    that the GOARM and GO386 env variables were added.
    Both GOARM and GO386 are about FP instruction sets. Is power8 and power9
    differ
    in significant ways that programs compiled for power 8 won't run on power 9
    machines?
    Or power 8 programs will run very slowly on power 9 machines?

    Packages might need instructions introduced in Power 9, but I don't think
    the Go
    compiler needs to know that distinction. We certainly don't want to
    differentiate
    between intel and amd chips or even different family of chips implementing
    the
    same basic ISA. The compiled program should just work.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Laboger at Sep 10, 2015 at 12:05 pm

    On Wednesday, September 9, 2015 at 4:49:55 PM UTC-5, minux wrote:

    On Wed, Sep 9, 2015 at 4:17 PM, Lynn A. Boger <lab...@linux.vnet.ibm.com
    <javascript:>> wrote:
    On 09/09/2015 02:18 PM, minux wrote:
    On Sep 9, 2015 2:31 PM, <lab...@linux.vnet.ibm.com <javascript:>> wrote:
    On Wednesday, September 9, 2015 at 12:03:11 PM UTC-5, Ian Lance Taylor wrote:
    Since at some point it will be necessary to distinguish between power8
    and power9,
    something like GOPPC64 would be needed.
    Why do we need to distinguish power 8 and power 9 (for the compiler)?
    Individual packages can do runtime detection and select the optimum code.

    Someone might want to build a program to run on different instruction
    sets. The compiler doesn't know if you want your program to run on power8
    or power9 hardware. Especially in the cross-compiled case. Same reason
    that the GOARM and GO386 env variables were added.
    Both GOARM and GO386 are about FP instruction sets. Is power8 and power9
    differ
    in significant ways that programs compiled for power 8 won't run on power
    9 machines?
    Or power 8 programs will run very slowly on power 9 machines?

    Packages might need instructions introduced in Power 9, but I don't think
    the Go
    compiler needs to know that distinction. We certainly don't want to
    differentiate
    between intel and amd chips or even different family of chips implementing
    the
    same basic ISA. The compiled program should just work.
    You can't build a program for power9 and have it run on power8 if it uses
    new instructions.

    I didn't intend this to be a debate about whether to add new instruction
    sets and why it should be done. I just
    was wondering if such a switch existed for other platforms. When the
    response contained comments about too
    many environment variables, I tossed out a few ideas. That is all. My
    question has been answered.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Matthew Dempsky at Sep 10, 2015 at 4:47 pm

    On Thu, Sep 10, 2015 at 5:05 AM, wrote:

    You can't build a program for power9 and have it run on power8 if it uses
    new instructions.
    I think it's understood that new power9 instructions won't work on existing
    power8 CPUs. The real question is what are the new power9 instructions and
    how widely they would be used within a compiled Go program.

    For example, AES-NI instructions aren't universally available on X86, but
    they're also not widely needed either (just a few hashing and crypto
    subroutines), so the Go runtime is able to use runtime detection (via
    CPUID) to see if they're available and fallback to generic code when
    they're not.

    On the other hand, the decision to use 387 vs SSE2 instructions affects
    every function that uses floating point arithmetic, which is why that makes
    sense to be a compiler knob.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Laboger at Sep 22, 2015 at 12:49 pm
    I understand. For implementing a specific language you really only care
    about the instructions that might be generated for that language.
    On Thursday, September 10, 2015 at 11:47:34 AM UTC-5, Matthew Dempsky wrote:

    On Thu, Sep 10, 2015 at 5:05 AM, <lab...@linux.vnet.ibm.com <javascript:>>
    wrote:
    You can't build a program for power9 and have it run on power8 if it uses
    new instructions.
    I think it's understood that new power9 instructions won't work on
    existing power8 CPUs. The real question is what are the new power9
    instructions and how widely they would be used within a compiled Go program.

    For example, AES-NI instructions aren't universally available on X86, but
    they're also not widely needed either (just a few hashing and crypto
    subroutines), so the Go runtime is able to use runtime detection (via
    CPUID) to see if they're available and fallback to generic code when
    they're not.

    On the other hand, the decision to use 387 vs SSE2 instructions affects
    every function that uses floating point arithmetic, which is why that makes
    sense to be a compiler knob.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Laboger at Sep 22, 2015 at 2:04 pm

    On Wednesday, September 9, 2015 at 2:19:01 PM UTC-5, minux wrote:
    On Sep 9, 2015 2:31 PM, <lab...@linux.vnet.ibm.com <javascript:>> wrote:
    On Wednesday, September 9, 2015 at 12:03:11 PM UTC-5, Ian Lance Taylor wrote:
    Since at some point it will be necessary to distinguish between power8
    and power9,
    something like GOPPC64 would be needed.
    Why do we need to distinguish power 8 and power 9 (for the compiler)?
    Individual packages can do runtime detection and select the optimum code.
    Depends on the impact of doing the runtime detection? If you have to add
    runtime checks all over the generated code then you've minimized or lost
    whatever performance value there is in using the new instructions. If a
    user can provide the compiler with information that will help it to
    generate the best code possible at compile time I think that is a good
    thing. I don't understand the downside of having knobs if they are
    reasonably implemented and well designed and documented and meaningful
    defaults are chosen so that those who don't care if the knobs even exist
    don't need to know about them.
    Or if you want to limit the number of env variables but still provide
    this type of
    capability, a new generic env var could be added like
    GOCPUSPEC, with different allowable values depending on the GOARCH.
    I really don't like more arch-specific variables. I don't wang gc to
    become gcc/llvm where you have 100 knobs for the backend.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Sep 22, 2015 at 3:18 pm

    On Tue, Sep 22, 2015 at 7:04 AM, wrote:
    Depends on the impact of doing the runtime detection? If you have to add
    runtime checks all over the generated code then you've minimized or lost
    whatever performance value there is in using the new instructions.
    I don't know what the new instructions in power 9 are. The current
    runtime package does runtime checking for x86 instructions. The test
    is done at startup and recorded in global variables (see the global
    variables cpuid_ecx and cpuid_edx). Those global variables are used
    in init functions to select specific algorithms (see the init function
    in alg.go). For 32-bit, they are tested at runtime in runtime·memclr,
    but only when clearing large blocks of memory. So for instructions
    like that, the cost is low compared to the benefit.

    If a
    user can provide the compiler with information that will help it to generate
    the best code possible at compile time I think that is a good thing. I
    don't understand the downside of having knobs if they are reasonably
    implemented and well designed and documented and meaningful defaults are
    chosen so that those who don't care if the knobs even exist don't need to
    know about them.
    The downside is increased testing requirements, code complexity, and
    maintenance costs. These costs are bearable, but there needs to be a
    corresponding benefit.

    Ian

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at Sep 22, 2015 at 11:54 pm

    On Tue, Sep 22, 2015 at 11:18 AM, Ian Lance Taylor wrote:

    If a
    user can provide the compiler with information that will help it to generate
    the best code possible at compile time I think that is a good thing. I
    don't understand the downside of having knobs if they are reasonably
    implemented and well designed and documented and meaningful defaults are
    chosen so that those who don't care if the knobs even exist don't need to
    know about them.
    The downside is increased testing requirements, code complexity, and
    maintenance costs. These costs are bearable, but there needs to be a
    corresponding benefit.
    Yeah, the current GO386/GOARM (esp the latter) are already causing us
    a lot of troubles.

    It's highly unlikely that Power 9 introduces an instruction that will be
    benefit
    the compiler enough that the toolchain needs to use the new instruction.

    Even the bound checking instructions extension (MPX) which is appealing
    at first is probably not worth the trouble to use in the compiler for bound
    checking.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Laboger at Oct 2, 2015 at 12:52 pm
    Thanks for all the comments.

    I was just trying to get a general understanding of how this was done now,
    if a new instruction set is to be used, and of course I was thinking of the
    way it gets done in gcc and binutils. But as a result of the comments
    here, I understand there would be no need to add the full instruction set,
    but only those that are worthwhile for use by gc in golang, and that is a
    different type of implementation. That can be investigated when we are
    ready to add them, which is not yet.

    As far as the questions about options and switches, I understand your goal
    of reducing code complexity and improving maintainability, but for some
    features that might be the only way to do the implementation by adding an
    option or switch? I'm trying to understand what you mean when you say you
    "don't like knobs", if that is the best way to implement a new feature, all
    things considered, does that mean you don't implement the feature?

    On Tuesday, September 22, 2015 at 6:55:00 PM UTC-5, minux wrote:


    On Tue, Sep 22, 2015 at 11:18 AM, Ian Lance Taylor <ia...@golang.org
    <javascript:>> wrote:
    If a
    user can provide the compiler with information that will help it to generate
    the best code possible at compile time I think that is a good thing. I
    don't understand the downside of having knobs if they are reasonably
    implemented and well designed and documented and meaningful defaults are
    chosen so that those who don't care if the knobs even exist don't need to
    know about them.
    The downside is increased testing requirements, code complexity, and
    maintenance costs. These costs are bearable, but there needs to be a
    corresponding benefit.
    Yeah, the current GO386/GOARM (esp the latter) are already causing us
    a lot of troubles.

    It's highly unlikely that Power 9 introduces an instruction that will be
    benefit
    the compiler enough that the toolchain needs to use the new instruction.

    Even the bound checking instructions extension (MPX) which is appealing
    at first is probably not worth the trouble to use in the compiler for bound
    checking.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Oct 2, 2015 at 1:55 pm

    On Fri, Oct 2, 2015 at 5:52 AM, wrote:
    As far as the questions about options and switches, I understand your goal
    of reducing code complexity and improving maintainability, but for some
    features that might be the only way to do the implementation by adding an
    option or switch? I'm trying to understand what you mean when you say you
    "don't like knobs", if that is the best way to implement a new feature, all
    things considered, does that mean you don't implement the feature?
    It's a cost/benefit decision. For a tool like GCC, the cost of adding
    a new option is considered to be zero. For Go, the cost of adding a
    new option is considered to be high. That doesn't mean that we can't
    add a new option. It means that the benefit has to also be high.

    Ian

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedSep 9, '15 at 4:15p
activeOct 2, '15 at 1:55p
posts14
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase