instruction sets used for Power

[lab...@linux.vnet.ibm.com]

Hi,

In order to fully optimize the generated code for the Power GOARCHes (ppc64 & ppc64le) for the latest
processors, I need to be able to use some of the instructions from the more recent instruction sets,
some of which don't exist on older processors.

Doing this for GOARCH=ppc64le is not an issue since that can only be run on power8 or later.

What are the expectations/requirements for the instruction set used for ppc64 (BE)?  I have not found any
golang documentation that mentions the instruction set used for either Power GOARCH value.

With gcc the mcpu option can be used to identify the instruction set to use.  I asked a question about this
a few months ago and got a variety of responses that mostly told me the golang community doesn't like
switches.

I plan to start using power8 instructions for ppc64le.
I can leave ppc64 as compatible with the old instruction set it uses now, which means for some functions it
could be significantly slower than it should be, or if possible, could there be a new GOARCH value or
other environment variable to indicate BE with a current instruction set?

[Ian Lance Taylor]

Would you expect to generate those instructions in the compiler? Or
is it more that you want to use them in functions written in
assembler? We don't need to change anything significant to permit
specific instructions in assembly code; on amd64 we already check the
CPU at runtime and select algorithms based on that. See, for example,
the init function in runtime/alg.go.

If you want to generate the instructions in the compiler then they
really have to be worth it. It's not impossible--see the GO386 and
GOARM environment variables--but it has to be a significant
improvement.

Ian

[Russ Cox]

Minux is running a ppc64 builder on an old Mac Pro, which is not Power8, but that was mainly for convenience of obtaining hardware. I don't personally believe it's important to preserve non-Power8 support, although I'm happy to listen to counterarguments.

Russ

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

[lab...@linux.vnet.ibm.com]

Right his old machine has to be BE, not LE, so if I only use newer/incompatible instructions for ppc64le, then that shouldn't affect him.
LE has to be power8.

However that would mean those using ppc64 BE would not see the performance improvements from using newer instructions.

[lab...@linux.vnet.ibm.com]

I plan to start with asm.  There's a lot to do there so I'm not sure how long before I
would get to making compiler changes or even investigating if that was of value.

[Aram Hăvărneanu]

On Wed, Feb 17, 2016 at 4:59 PM, <lab...@linux.vnet.ibm.com> wrote:
> Right his old machine has to be BE, not LE, so if I only use
> newer/incompatible instructions for ppc64le, then that shouldn't affect him.
> LE has to be power8.

But you're introducing complexity in the implementation. Right now
little-endian and big-endian assembly is mostly common. After your
change, we'd have two sets of assembly functions to maintain.

--
Aram Hăvărneanu

[Russ Cox]

As I said, I personally have no problem assuming that both BE and LE are Power8. Let's see if anyone objects and if so what the objections are.

Russ

[lab...@linux.vnet.ibm.com]

Are you saying you prefer they be the same and drop support for the old instruction sets?

[lab...@linux.vnet.ibm.com]

OK

[minux]

On Feb 17, 2016 11:33 AM, "Russ Cox" <r...@golang.org> wrote:
> As I said, I personally have no problem assuming that both BE and LE are Power8. Let's see if anyone objects and if so what the objections are.

My only concern is that it's hard to get access to power8 machines, esp. big endian ones.

I certainly welcome a new big endian builder though, the powermac is just too noisy.

[lab...@linux.vnet.ibm.com]

Jeff Scheel and I discussed machines with Brad F. last Friday, due to the fact that your ppc64le builder has gone away.

Jeff has set up some instances at OSU, which can be BE or LE.  You may have tried to use this in the past and had
issues but hopefully those are now resolved.  Please try those and let us know if there are problems.  The information
about those was sent to Brad but I believe he is on vacation this week.

[Brad Fitzpatrick]

I did get access to five Power8 instances yesterday. I'll be setting them up when I have a second, but maybe not before I'm back from GopherconIndia on Monday.

There's also no rush, because I don't want to restart farmer.golang.org to add new builders until 1.6 is cut and out. Changing anything builder-wise isn't worth it at this point.

--

[Russ Cox]

On Wed, Feb 17, 2016 at 12:42 PM, <lab...@linux.vnet.ibm.com> wrote:

Jeff Scheel and I discussed machines with Brad F. last Friday, due to the fact that your ppc64le builder has gone away.

Jeff has set up some instances at OSU, which can be BE or LE.  You may have tried to use this in the past and had
issues but hopefully those are now resolved.  Please try those and let us know if there are problems.  The information
about those was sent to Brad but I believe he is on vacation this week.

Sounds great, thanks.

Given Minux's reply it sounds like we are OK with assuming Power8 on both BE and LE.

Russ

[Michael Hudson-Doyle]

On 18 February 2016 at 07:00, Brad Fitzpatrick <brad...@golang.org> wrote:
> I did get access to five Power8 instances yesterday. I'll be setting them up
> when I have a second, but maybe not before I'm back from GopherconIndia on
> Monday.
>
> There's also no rush, because I don't want to restart farmer.golang.org to
> add new builders until 1.6 is cut and out. Changing anything builder-wise
> isn't worth it at this point.

Is there anything we/I can do to help here? I'd like to get ppc64le
back on the dashboard.

Cheers,
mwh

[Brad Fitzpatrick]

I have one of the 5 now running and I see builds appearing on the dashboard.

I want to finish a bit more automation before I do all 5.

Once it's good for a bit and the performance looks okay, then I can enable trybots and such too.

[Dave Cheney]

Thanks Brad!

[Michael Hudson-Doyle]

Indeed, thanks for this. Nice to see the tests still pass too :-)

Cheers,
mwh

[lab...@linux.vnet.ibm.com]

In this discussion, I thought it was decided that it was OK to use power8 instructions for both ppc64 BE & LE?

If so, then why the question/concern about continuing to support ppc970 in https://go-review.googlesource.com/#/c/22772 with ppc64?

I don't even see ppc64 on the builders any more, has the OSU ppc64 power8 been set up, or have there been problems with it?

On Wednesday, February 17, 2016 at 11:34:48 AM UTC-6, minux wrote:

[Florian Weimer]

On 05/05/2016 02:38 PM, lab...@linux.vnet.ibm.com wrote:
> In this discussion, I thought it was decided that it was OK to use power8
> instructions for both ppc64 BE & LE?

Do you know if POWER7 support has since been removed from Go for ppc64
(not pp64le)?

Thanks,
Florian

[Russ Cox]

Since CL 22772 has been submitted, I believe that yes, we now require POWER8 even for big-endian.

Russ

[lab...@linux.vnet.ibm.com]

CL 22772 added the fcfidu instruction but that should work on power7 according to the table in binutils.

However I think that the change I made to improve performance of some of the atomics now use lbarx/stbcx and those are power8 only.  That is upstream only -- go 1.6 doesn't have those and should still work for power7.

I am fine with continuing to support power7 at a minimum for ppc64 but I don't know what methods are allowed for determining the instruction set.  In the case for the atomic functions an #ifdef could be added to the asm file but I believe there is concern about the complexity that introduces?

[John Paul Adrian Glaubitz]

Hello!

On Wednesday, February 17, 2016 at 3:48:26 PM UTC+1, lab...@linux.vnet.ibm.com wrote:

I can leave ppc64 as compatible with the old instruction set it uses now, which means for some functions it
could be significantly slower than it should be, or if possible, could there be a new GOARCH value or
other environment variable to indicate BE with a current instruction set?

Making the minimum requirement for ppc64 Big-Endian POWER8 means that a large number of users who are running ppc64 Big-Endian
operating systems will no longer be able to use golang on their systems as the vast majority of ppc64-BE systems are running on hardware
which is more on par with POWER4/PowerPC G5.

In fact, there are even many ppc64-BE systems which don't even support AltiVec, such as the e5500. For this reason, we in have a initiated
an archive-rebuild in Debian which recompiled all ppc64-BE packages without AltiVec support [2].

Thus, while I perfectly understand the reasoning behind the decision to set the minimum architecture requirement for ppc64-BE to POWER8,
this decision will actually render this particular port of golang more or less useless since as far as I understand, most people with POWER8 machines
will actually run the ppc64-LE port of Linux anyway. At least in Debian, the ppc64el (Little-Endian) port is the one that Debian officially supports
while ppc64-BE is "just" a ports architecture.

Regards,
Adrian

> [1] https://en.wikipedia.org/wiki/PowerPC_e5500
> [2] https://lists.debian.org/debian-powerpc/2016/03/msg00064.html

[lab...@linux.vnet.ibm.com]

Hi,

It would be fine with me to allow the older instruction sets to be used for ppc64 BE and use the latest (power8) instruction set for ppc64 LE.

The question is how to do that within golang?  There seems to be a lot of concern in the golang community with adding #ifdefs or switches to indicate which instruction set to use because of the potential complexity that would add to the implementation. 

[Austin Clements]

How much of the code is using the new instructions and where is it? Is the compiler generating it or is it in library assembly code (or both)? If it's feasible to do feature detection at runtime, that's likely the best solution. It introduces implementation complexity, but not interface complexity, which is why feature detection is strongly preferred over giving the user flags like GOARM. But the feasibility depends on where the code is.

[lab...@linux.vnet.ibm.com]

In Go 1.7, I made changes to some library asm files to improve performance.  Some of those functions now use instructions that are from the later power instruction sets (>= power5?).  There is one file that uses a power8 only instruction.  If the goal is keep ppc64 BE backward compatible with the oldest instruction set, #ifdefs could be added in a few places to use the new instructions for ppc64le only.  There were already #ifdefs for some of these functions anyway because of the cases where BE vs. LE require different code.  There were no changes to generated code, only asm files.

For future golang releases the solution will need to be different if new instruction sets are used but in that case feature checking should work.

[John Paul Adrian Glaubitz]

On 06/07/2016 06:34 PM, lab...@linux.vnet.ibm.com wrote:
> In Go 1.7, I made changes to some library asm files to improve performance. Some of those functions now use instructions that are from the later power
> instruction sets (>= power5?). There is one file that uses a power8 only instruction. If the goal is keep ppc64 BE backward compatible with the oldest
> instruction set, #ifdefs could be added in a few places to use the new instructions for ppc64le only. There were already #ifdefs for some of these functions
> anyway because of the cases where BE vs. LE require different code. There were no changes to generated code, only asm files.

That would be really awesome and highly appreciated :). Thanks a lot for putting this into consideration!

> For future golang releases the solution will need to be different if new instruction sets are used but in that case feature checking should work.

There is also PowerPC e500v2 in Debian which uses the SPE instructions but doesn't have any FPU instructions. The GHC people are already looking into
extending their NGC to add support for that. And, of course, the classic, 32-bit PowerPC. IBM has really produced lots of different variations of
POWER CPUs over the time, so that would require lots of #ifdefs to accommodate for all of them :). I think we currently have four different variants
of POWER in Debian.

Again, thank you for your consideration and work!

Adrian

PS: Also big thanks to whoever added s390x support to golang. I assume that happened at IBM, too.

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

[lab...@linux.vnet.ibm.com]

Just to be clear what I'm suggesting:

I could make the change so ppc64 BE would work with older instruction sets like were used in Go 1.6.  ppc64le would continue to use the new instruction sets in Go 1.7 and future Go language versions.

I have no plans to add ppc32 or any other old instruction sets that weren't there before.

But I'm not the one that makes the final decision on what changes are accepted.  I'm just saying I'm willing to undo the instruction set incompatibility I introduced for ppc64 BE in Go 1.7 if that's allowed.

[David Chase]

One of the relevant CLs concerns unsigned-to-float conversion:

https://go-review.googlesource.com/c/22772/

and how the same bug was fixed on MIPS64, see discussion in comments also:

https://go-review.googlesource.com/c/22835/

--

[Keith Randall]

We discussed this at the runtime meeting today and we'd like to get ppc64be working on power5 again, if possible.

This would mean

 1) Implementing CL 22772 in a different way for ppc64be and ppc64le, conditioned on the architecture.

 2) Doing assembly changes with #ifdefs around power8 instructions, with fallback to power5 instructions.  In assembly we have the architecture as a macro we can check.

How feasible are doing these changes?  I hope we can do all this with no runtime checks and no duplication of code (i.e. no separate asm_ppc64.s and asm_ppc64le.s files).

[mun...@ca.ibm.com]

1) Implementing CL 22772 in a different way for ppc64be and ppc64le, conditioned on the architecture.

 

Re-implementing CL 22772 using the same method used for mips64 should be straightforward. I can do it at some point this week if no-one beats me to it.

However I would suggest that, unless uint64 to float64 conversions are considered performance critical, we stick to one implementation. Maintaining two implementations, particularly when there is no big endian ppc64 builder, seems to me like something to be avoided. I'm happy to be persuaded otherwise though.

2) Doing assembly changes with #ifdefs around power8 instructions, with fallback to power5 instructions.  In assembly we have the architecture as a macro we can check.

AFAICT the only new instructions added to the assembly since go 1.6 are STBCCC (stbcx) and LBAR (lbarx). These were added to optimise/simplify the Or8 and And8 functions in CL 22549. Since the old code was endianness dependent it already had two implementations so we could just add back the big endian implementation for ppc64 more or less unchanged (presumably this is what Lynn is thinking of doing).
 

[lab...@linux.vnet.ibm.com]

On Tuesday, June 7, 2016 at 6:02:42 PM UTC-5, mun...@ca.ibm.com wrote:

1) Implementing CL 22772 in a different way for ppc64be and ppc64le, conditioned on the architecture.

 

Re-implementing CL 22772 using the same method used for mips64 should be straightforward. I can do it at some point this week if no-one beats me to it.

However I would suggest that, unless uint64 to float64 conversions are considered performance critical, we stick to one implementation. Maintaining two implementations, particularly when there is no big endian ppc64 builder, seems to me like something to be avoided. I'm happy to be persuaded otherwise though.

2) Doing assembly changes with #ifdefs around power8 instructions, with fallback to power5 instructions.  In assembly we have the architecture as a macro we can check.

AFAICT the only new instructions added to the assembly since go 1.6 are STBCCC (stbcx) and LBAR (lbarx). These were added to optimise/simplify the Or8 and And8 functions in CL 22549. Since the old code was endianness dependent it already had two implementations so we could just add back the big endian implementation for ppc64 more or less unchanged (presumably this is what Lynn is thinking of doing).

Yes I had already started working on a change for the And8 and Or8 to be guarded by #fidefs and I'm testing it now.  I agree with Michael's comment that none of the other changes I made introduced anything newer than power5.
 

[lab...@linux.vnet.ibm.com]

I opened this issue https://github.com/golang/go/issues/16004

[lab...@linux.vnet.ibm.com]

Keith,

Does this decision apply to Go 1.7 only, or for future releases too?
Some further optimizations are being considered for ppc64le for Go 1.8 that use power8 instructions, so I'd like to know if maintaining power5 compatibility will continue to be required.

Thanks

[John Paul Adrian Glaubitz]

On 07/14/2016 04:06 PM, lab...@linux.vnet.ibm.com wrote:
> Does this decision apply to Go 1.7 only, or for future releases too?

Speaking for Debian, it would definitely be important to keep the compatibility
even for future releases.

> Some further optimizations are being considered for ppc64le for Go 1.8 that use power8 instructions, so I'd like to know if maintaining power5 compatibility
> will continue to be required.

Wouldn't it be just possible to guard these instructions with additional #ifdefs?

Adrian

[minux]

I'm really glad we finally made the consensus to keep Power 5 compatibility for the

ppc64 port, which I advocated ever since the port is completed.

On Thu, Jul 14, 2016 at 10:15 AM, 'John Paul Adrian Glaubitz' via golang-dev <golan...@googlegroups.com> wrote:

> Some further optimizations are being considered for ppc64le for Go 1.8 that use power8 instructions, so I'd like to know if maintaining power5 compatibility
> will continue to be required.

Wouldn't it be just possible to guard these instructions with additional #ifdefs?

That means we need to distinguish different linux/ppc64le architectures at build time,

which is not something we should do lightly --- Go generally prefers runtime detection.

Currently, there are only two ports that required such sub-arch support:

1. GO386=387/sse2: this is unavoidable. For board 386 support, we have to support

387 for FP, but as the amd64 port uses sse2, we will always have two FPU to support,

so unless we drop support for sse2 for linux/386, we have to have a knob for linux/386.

2. GOARM=5/6/7. Because most pre-ARMv7 cores lack FPU, we need to at least

support soft float and VFP on ARM. GOARM=6/7 is latter (ab)used to also indicate

the architecture of the ARM core itself, but that's another story.

Going forward, I can see that the various mips (both 32-bit and 64-bit) ports will need

similar treatment as ARM. Almost all MIPS systems lack FPUs, and the kernel assisted

FPU emulation is really slow (on 32 cores machines, all.bash took less than 1 hour,

with test/bench/go1 alone taking more than 30 minutes due to its heavy FP usage.)

There are few ways to go for linux/ppc64le (I think linux/ppc64 must not drop support

for older architectures):

1. we bump required architecture for linux/ppc64le whenever the corresponding

architecture is widely deployed.

2. we keep the minimum requirement at power8 for the foreseeable future. Newer

instructions can be used, but they need to be enabled at runtime.

3. we introduce GOPPC (or a more generic mechanism that doesn't involve more

environment variables) to support multiple sub-architectures at the same time.

If we choose the 3rd option, I'd like to see very clear performance benefits (at least

on the same magnitude as 387 vs see2 on 386 or soft float vs. FPU on arm/mips).

Thanks.

[lab...@linux.vnet.ibm.com]

Yes that is certainly possible.  My question is not how to do it but to verify if the plan is to continue maintaining power5 for ppc64 BE.  I have no objections to that.

[Keith Randall]

Yes, we want to maintain power5 support for ppc64be as long as possible.

I concur with minux, we should maintain power8 support for ppc64le as long as possible also.

For both, newer instructions (>power5 for ppc64be and >power8 for ppc64le) would only be used in hand-written assembly and guarded by runtime arch checks.  The tricky part is when the compiler itself wants to issue the newer instructions - it's often not feasible to issue runtime arch checks for those.  At that point, given a strong argument for why we want the new instructions, we could introduce an environment variable option like e.g. 386 has.

--

[lab...@linux.vnet.ibm.com]

Right now there are no plans to add >power8 instructions in Go 1.8.  More use of power8 where it proves valuable (which would require #ifdefs or something to avoid those for ppc64 BE), some algorithms written with vector instructions which can be controlled by runtime checks.

We'll see when we get to Go 1.9...   We understand the concerns about controlling instruction set selection and only add those in cases where they proved to improve performance.

[Carlos Eduardo Seo]

On 7/14/16 11:15 AM, 'John Paul Adrian Glaubitz' via golang-dev wrote:
>
>> Some further optimizations are being considered for ppc64le for Go 1.8 that use power8 instructions, so I'd like to know if maintaining power5 compatibility
>> will continue to be required.
>
> Wouldn't it be just possible to guard these instructions with additional #ifdefs?
>

I personally prefer runtime detection, the same way amd64 does with its
AVX2 check:

CMPB runtime·support_avx2(SB), $1

If anyone is interested, I'm working on a change that will enable such
tests for Power, by checking against the hwcap/hwcap2 bits from the auxv.

--
Carlos Eduardo Seo
Software Engineer - Linux on Power Toolchain
cs...@linux.vnet.ibm.com

[John Paul Adrian Glaubitz]

Hello!

On 07/14/2016 10:29 PM, 'Keith Randall' via golang-dev wrote:
> Yes, we want to maintain power5 support for ppc64be as long as possible.
> I concur with minux, we should maintain power8 support for ppc64le as long as possible also.
>
> For both, newer instructions (>power5 for ppc64be and >power8 for ppc64le) would only be used in hand-written assembly and guarded by runtime arch checks. The
> tricky part is when the compiler itself wants to issue the newer instructions - it's often not feasible to issue runtime arch checks for those. At that point,
> given a strong argument for why we want the new instructions, we could introduce an environment variable option like e.g. 386 has.

Sorry for digging this discussion out again, but I just saw the release notes for Go 1.9 Beta1
and it says that again the big-endian ppc64 port drops support for POWER5 and now requires
at least POWER8.

I understand that removing POWER5 means less maintenance burden for the maintainers, but as I
have already elaborated in the original discussion regarding this topic, it doesn't make much
sense to maintain a ppc64 big-endian port which requires the POWER8 instruction set. As far as I
know, all POWER8 machines are also able to run the little-endian port of the Linux kernel and hence
little-endian variants of Linux distributions of Debian, openSUSE and Fedora.

Since the little-endian port also features a modern ABI and IBM is mainly focusing on the
little-endian port, most if not all owners of a POWER8 machine will install the little-
endian port especially because they usually run an enterprise version of Linux on these
machines together with a support contract and these are usually only available for the
little-endian port (at least SUSE and RedHat). Hence there will be effectively no users
of the ppc64 big-endian port of Go starting from version 1.9.

Now, distributions like Debian and openSUSE still have ppc64 big-endian ports which
people are installing on POWER5 compatible hardware, primarily on machines like Apples
PowerMac G5 or the AmigaOne X5000. Those people are mostly end users who usually
cannot afford shelling out several thousand US Dollars to buy a POWER8 machine. I
know there have been attempts to make affordable POWER8 hardware with the Talos, but
these campaigns failed [1].

So, with the decision to drop POWER5 support in the big-endian ppc64 port, Go will
effectively cut off all end users who run Go on ppc64 and becomes an enterprise-only
language on ppc64.

Is there really no way to avoid this?

Adrian


> [1] https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation

[Brad Fitzpatrick]

John Paul,

See also https://github.com/golang/go/issues/19074 if you missed that discussion.

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

[Russ Cox]

Hi,

The discussion on this thread moved to two issues on the issue tracker. We discussed the general problem of when to start or end support for particular hardware on golang.org/issue/19075. We identified the important considerations - availability and support of hardware, actual or expected user base, and incurred ongoing costs of keeping old support - but are leaving the decision of how to balance them to specific cases.

We then applied those considerations to pre-POWER8 ppc64, which is golang.org/issue/19074. We determined the following. 

First, pre-POWER8 ppc64 hardware is fairly unavailable and uncommon. Apple's PowerMac G5 was discontinued over 10+ years ago and is only unavailable in used, unsupported, as-is form. I had not heard of the AmigaOne X5000, but I did a search for it and found the home page http://www.a-eon.com/?page=x5000. The only USA reseller listed on that page is http://amigaonthelake.com/, and their home page reads:

We have made a decision, concerning both A-EON and AmigaKit. The decision we made is grounded in our experience during the last 8 months in regards to both companies. As a result we have made the choice to no longer support A-EON or AmigaKit in any way, shape or form.

We are still here and "WILL" be carrying more stuff soon. However no more X5000 or A1222 or, frankly anything produced from either company. 

I didn't look at the other resellers, but this hardware does not appear to be widely available or supported.

Second, we were unable to identify a significant extant user base for Go on pre-POWER8 ppc64. The closest we found one was serious hobbyist (Minux). Even if there are (optimistically) tens more, that's a very small number of people for which to maintain a port.

Third, there is a real ongoing cost to keeping the old support. It makes the big-endian ppc64 a different port from ppc64le. In contrast, spec'ing them both to POWER8 makes them essentially one port, not two.

Based on those determinations, we decided to require POWER8 support for ppc64, to match ppc64le. If you want us to reconsider, I think we'd want to see evidence of both currently available, supported hardware and a significant actual or expected user base for Go on that hardware.

In contrast, for ppc64 on POWER8, there is commercially available hardware, we know of companies interested now or in the recent past in using it, and the cost of support is almost zero, so the balance goes the other way. One might reasonably argue for dropping ppc64 entirely, but the ongoing costs (if we assume POWER8) are near zero, and the Go project gets one very important benefit, namely a demonstration and continual test that we don't have any implicit little-endian assumptions in the code base. (The initial ppc64 port shook out a few.)

Thanks.

Russ

 

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

[John Paul Adrian Glaubitz]

First of all, my answer will be brief as I’m currently on mobile.

Having said that, I find the requirements a bit strange. How exactly am I supposed to measure the number of active ppc64 users? You know, this isn’t possible as Linux distributions usually don’t phone home like Windows does. Plus, there are many Linux users around the world in third-world countries for whom a 10-year-old computer is the best they can afford. You’re only seeing this from the Western world where the majority of users can afford always buying the latest and greatest hardware, ignoring that there are countries in the world where the situation is much different. Heck, there are 7 billion people on this planet. Do you really think there is just one users running Linux on POWER5 hardware? You know, not everyone can read all issues on github or read all messages on this mailing list.

I also don’t really understand why you consider it so much of a burden to continue to provide support for POWER5. There are other compiler projects like the Free Pascal Compiler which have much less manpower yet the they manage to maintain architecture support for even older architectures like m68k or 8086.

When it comes to availability, POWER8 hardware is probably unaffordable for most users because IBM doesn’t manage to scale the hardware down enough. Heck, when talking about the number of users and availability of hardware, Go should be Windows x86 only because that’s what most people run on the planet.

Reading answers like yours from Google is always very frustrating and disappointing, to be honest. Google is such a large company with much more resources than most other companies writing software. Google profits from the work by the community on large scale with lots of community developers spending tons of their freetime for free to improve open source.

Google always claims to be an open source company and all about community, but then constantly puts out statements like yours come which read like „We won’t do that because we can’t earn money with that!“.

Sorry, but I can’t be anything but frustrated. If you don’t want to work with the community, then heck, just make this whole language closed source and sell it for money. At least you would be honest about your intentions about making money instead of providing something to the open source community to make programmers and users live easier.

Adrian

[Brad Fitzpatrick]

On Thu, Jun 15, 2017 at 10:06 AM, 'John Paul Adrian Glaubitz' via golang-dev <golan...@googlegroups.com> wrote:

First of all, my answer will be brief as I’m currently on mobile.

You are a better phone typist than I.  :-)

 

Having said that, I find the requirements a bit strange. How exactly am I supposed to measure the number of active ppc64 users? You know, this isn’t possible as Linux distributions usually don’t phone home like Windows does. Plus, there are many Linux users around the world in third-world countries for whom a 10-year-old computer is the best they can afford.

I sympathize with that, but at least 6 month old software will continue to run on 10 year old hardware. Go 1.8 will continue to be supported for a number of releases.

 

I also don’t really understand why you consider it so much of a burden to continue to provide support for POWER5. There are other compiler projects like the Free Pascal Compiler which have much less manpower yet the they manage to maintain architecture support for even older architectures like m68k or 8086.

Out of curiosity, do you know how they run their tests?

  

Reading answers like yours from Google is always very frustrating and disappointing, to be honest. Google is such a large company with much more resources than most other companies writing software. Google profits from the work by the community on large scale with lots of community developers spending tons of their freetime for free to improve open source.

I know it's common to think of Google as an infinitely large company with infinite resources, but that is not true. We also have an infinite number of projects and ambitions, so the infinities cancel out and everybody gets the headcount they get.

Google probably already spends millions of dollars per year on Go (employee salaries, compute resources, etc) and like every team, we're always struggling to do everything we want to do with the resources we have.

So you want Google to spend even more to support machines we don't have? Why shouldn't IBM, if it's a company that needs to do it? They're the POWER people, after all. Yet they were the ones pushing to remove it. Why is Google singled out here?

 

Google always claims to be an open source company and all about community, but then constantly puts out statements like yours come which read like „We won’t do that because we can’t earn money with that!“.

Now you talk about community, but where is the community stepping up here?

When we proposed removing ARM5, the ARM5 community stepped up and helped and kept it alive. When the rarely-used Plan 9 port breaks, the Plan 9 community fixes it.

Being part of an open source community does not mean that a corporate benefactor necessarily does everything that community wishes for them.

Sorry, but I can’t be anything but frustrated. If you don’t want to work with the community, then heck, just make this whole language closed source and sell it for money. At least you would be honest about your intentions about making money instead of providing something to the open source community to make programmers and users live easier.

It's obvious you're frustrated, but that isn't a great closing argument.

Keeping POWER5 requires ongoing work & maintenance & testing & machines, and it needs people to do it. That's the problem that needs to be solved and that you'd want to focus on to enact change.

[cherry]

So, with the decision to drop POWER5 support in the big-endian ppc64 port, Go will
effectively cut off all end users who run Go on ppc64 and becomes an enterprise-only
language on ppc64.

Go as a language doesn't really drop POWER5 support. It is a particular implementation, cmd/compile in this case, that may do.

gccgo probably supports POWER5 and will continue to. There might be other compilers.

[Ian Lance Taylor]

I'm sorry that this decision seems wrong to you. As far as I know,
it's not irreversible, but it does require some real argument.

Google doesn't earn any money on Go, so that part of your comment
seems to me to be a non-sequitur. And, frankly, it's backward: if
Google earned money on Go, we would be dropping ports much more
aggressively to only focus on the ones that people were willing and
able to pay for.

We are of course very grateful for the extensive open source
contributions to Go. If someone were to step up and convincingly
volunteer to fully maintain the POWER5 support for ppc64 big-endian,
that would be a factor in our decision. Right now, nobody is
volunteering to do that. And the people who actually are maintaining
the ppc64 port, who mostly work for IBM, have specifically requested
that we only support POWER8 and above, to make their lives simpler.

it's an easy mistake to think that because Google has a lot of
resources, which is true, that that implies that Google should do
everything. But that is impossible. Google has to allocate finite
resources like any other organization. And the Go team is a tiny tiny
part of Google, and the Go team's mission is really tangential to
Google's mission.

Whatever we decide here, the gccgo compiler fully supports the Go
language, and it continues to work fine on POWER5.

Ian

[Russ Cox]

On Thu, Jun 15, 2017 at 1:06 PM, John Paul Adrian Glaubitz <adrian....@googlemail.com> wrote:

First of all, my answer will be brief as I’m currently on mobile.

Having said that, I find the requirements a bit strange. How exactly am I supposed to measure the number of active ppc64 users?

Well, we can estimate them the best we can (today, we think there are hardly any) and then if we're wrong we find out with feedback like this. As Brad pointed out, this worked well for ARMv5. We believed we could drop it, we announced that we were going to, and then enough users stepped forward that we didn't drop it.

 

You know, this isn’t possible as Linux distributions usually don’t phone home like Windows does. Plus, there are many Linux users around the world in third-world countries for whom a 10-year-old computer is the best they can afford. You’re only seeing this from the Western world where the majority of users can afford always buying the latest and greatest hardware, ignoring that there are countries in the world where the situation is much different.

I don't think that's true at all. The vast majority of 10-year-old computers on the secondary market are not PowerMac G5s. They are 32- or 64-bit x86 machines, both of which are very well supported by Go and will continue to be. You don't have to have the "latest and greatest" hardware to run Go, you just can't use a PowerMac G5 (anymore).

 

Heck, there are 7 billion people on this planet. Do you really think there is just one users running Linux on POWER5 hardware? You know, not everyone can read all issues on github or read all messages on this mailing list.

I am sure there are many people running Linux on POWER5, but yes I really do think there is just one user (at most) running Go on Linux on POWER5. I'd be happy to be corrected but again I'd have to be off by multiple orders of magnitude to change the decision.

 

I also don’t really understand why you consider it so much of a burden to continue to provide support for POWER5. There are other compiler projects like the Free Pascal Compiler which have much less manpower yet the they manage to maintain architecture support for even older architectures like m68k or 8086.

With all respect to those projects, there's a difference between supporting a fixed language spec and supporting ongoing significant evolution of a language and its libraries. The Free Pascal Compiler is not simultaneously developing whole new versions and evolutions of Pascal and its implementation, at least not anywhere near the scale that Go is.

 

When it comes to availability, POWER8 hardware is probably unaffordable for most users because IBM doesn’t manage to scale the hardware down enough. Heck, when talking about the number of users and availability of hardware, Go should be Windows x86 only because that’s what most people run on the planet.

I agree with you that hobbyists cannot afford POWER8 hardware and therefore cannot run Go on ppc64. That's OK. Go works just as well on x86, and as you say there are plenty of x86 boxes. Go 1.10 also supports systems with 1024 cpus, but that hardware is not practical for hobbyists either.

Finally, as Cherry pointed out and Ian confirmed, gccgo will continue to support POWER5, for I assume as long as gcc does, which is probably forever. This is only one implementation. If you are worried about Debian in particular depending on Go in some important way and needing POWER5 support to keep working on those systems, gccgo is there. In fact I am sure there are supported Debian architectures today for which gccgo is the only Go compiler. This just adds one more architecture to that list.

Russ

[Lynn Boger]

One additional point to add besides just the instruction set ...

Support for the ppc64 v1 ABI was never added to golang.  That means the types of linking modes that can be used with golang on ppc64 big endian are limited,
preventing many of the commonly used Go applications to build or run on ppc64 big endian.  None of the newer buildmodes (pie, shared, etc.) are supported on
ppc64 big endian because of this.  While there have been a few complaints on this, there haven't been many.  To me that is an indicator of how golang on
ppc64 big endian is used.  I believe if there were serious users for ppc64 big endian, there would have been more requests for full linker support.

golang for ppc64 big endian was always documented as an "experimental port" and has never been available on the golang.org/dl website.

gccgo is a good option, and it can be targeted for power5 or power8.

On Wednesday, February 17, 2016 at 8:48:26 AM UTC-6, Lynn Boger wrote:

Hi,

In order to fully optimize the generated code for the Power GOARCHes (ppc64 & ppc64le) for the latest
processors, I need to be able to use some of the instructions from the more recent instruction sets,
some of which don't exist on older processors.

Doing this for GOARCH=ppc64le is not an issue since that can only be run on power8 or later.

What are the expectations/requirements for the instruction set used for ppc64 (BE)?  I have not found any
golang documentation that mentions the instruction set used for either Power GOARCH value.

With gcc the mcpu option can be used to identify the instruction set to use.  I asked a question about this
a few months ago and got a variety of responses that mostly told me the golang community doesn't like
switches.

I plan to start using power8 instructions for ppc64le.

[John Paul Adrian Glaubitz]

Hi Brad!

Sorry for the late reply! I was quite busy before the weekend.

On 06/15/2017 07:46 PM, Brad Fitzpatrick wrote:
> First of all, my answer will be brief as I’m currently on mobile.
>
>
> You are a better phone typist than I. :-)

Hehe, thanks!

>
> Having said that, I find the requirements a bit strange. How exactly am I supposed to measure the number of active ppc64 users? You know, this isn’t
> possible as Linux distributions usually don’t phone home like Windows does. Plus, there are many Linux users around the world in third-world countries for
> whom a 10-year-old computer is the best they can afford.
>
>
> I sympathize with that, but at least 6 month old software will continue to run on 10 year old hardware. Go 1.8 will continue to be supported for a number of
> releases.

At least in Debian unstable, Golang 1.9 will replace 1.8 pretty quickly meaning that a large number
of packages immediately become "BD-Uninstallable" on ppc64 meaning that the build dependencies cannot
be fulfilled for these packages which are all Go packages.

Looking at m68k, for example, there are 91 packages which are currently "BD-Uninstallable" because
they build-depend directly on Golang (the package being golang-go):

91 golang-go:m68k
54 libghc-aeson-dev:m68k
47 libgmp3c2:m68k
37 libghc-text-dev:m68k
30 libghc-attoparsec-dev:m68k
29 libghc-quickcheck2-dev:m68k
28 gnuplot-data:m68k
28 gnat-6:m68k
27 ghc-ghci:m68k
26 libghc-hashable-dev:m68k
25 libghc-async-dev:m68k
22 rebar:m68k
22 libghc-blaze-builder-dev:m68k
18 mono-utils:m68k | cil-disassembler:m68k
18 libwebkit2gtk-4.0-dev:m68k
18 libatlas-headers:m68k
(...)

In fact, golang-go is the number one missing package missing on these architectures meaning
that no other package missing causes so many packages to become "BD-Uninstallable". GHC,
the Haskell compiler, results in a larger number of packages (around 600) to become
"BD-Uninstallable" but since GHC supports an unregisterised compiler, I can bootstrap
it on ANY architecture which I have done. It doesn't have the best performance, but
works well enough. OpenJDK has the same feature with its Zero VM (Zero standing for
"zero assembler"). Both GHC and OpenJDK Zero even work fine on Debian/m68k.

> I also don’t really understand why you consider it so much of a burden to continue to provide support for POWER5. There are other compiler projects like the
> Free Pascal Compiler which have much less manpower yet the they manage to maintain architecture support for even older architectures like m68k or 8086.
>
>
> Out of curiosity, do you know how they run their tests?

They run the testsuite on native hardware or on emulators like QEMU if they don't
have native hardware available, see:

> https://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi

For Linux SPARC, I have provided them with access to a SPARC machine inside the
Debian project. So they are relying on the community for supporting more exotic
architectures which Golang could do as well.

> Reading answers like yours from Google is always very frustrating and disappointing, to be honest. Google is such a large company with much more resources
> than most other companies writing software. Google profits from the work by the community on large scale with lots of community developers spending tons of
> their freetime for free to improve open source.
>
>
> I know it's common to think of Google as an infinitely large company with infinite resources, but that is not true. We also have an infinite number of projects
> and ambitions, so the infinities cancel out and everybody gets the headcount they get.

I understand that. But Google could just be more open to the community, then it would
be easier for external to people. If Google doesn't have the manpower to maintain a
POWER5 port of Golang why not rely on the community? It works for the Linux kernel
and many other projects. You do not have to test each line code and every target
you are supporting. That's where you rely on the community.

> Google probably already spends millions of dollars per year on Go (employee salaries,
> compute resources, etc) and like every team, we're always struggling to do
> everything we want to do with the resources we have.

As I said, the problem is obviously you trying to do all the work yourself. If you want
Go to be successful everywhere and not just the cloud ecosystem, you have to open up
the community and allow easy drive-by patches. It's fine that you don't care about
more exotic architectures, but the community does and I can guarantee you, there *will*
always be someone who is sending in patches and is happy to help. Heck, there are
even enough crazy people who are working on Linux/m68k these days, so it would be
just a matter of time until someone sent you patches for supporting this target. And
people are constantly compiling and testing things for their pet architectures, there
is no need for Google to do that themselves.

> So you want Google to spend even more to support machines we don't have?

For one thing, I have heard that there was a request for Google to host a
SPARC-T7 machine for Oracle so that there would be infrastructure to enable
the CI tests on the Solaris/sparc64 port and Google rejected the request
claiming that they don't care about these exotic targets. I was rather
disappointed to hear that. I don't honestly think that Google doesn't enough
space that they couldn't just host another 2U server. I mean, even I am hosting
such machines at my old university to support Debian and I'm pretty sure
my university doesn't have as nearly as much resources as Google or IBM
have.

I mean, yes, your resources aren't unlimited, you're right. But it's honestly
also not too much to ask for to spin up a GCE instance to run some qemu-system
instances for ppc64 or host another 2U server. For Debian, I'm hosting buildds
for hppa (PA-RISC), m68k, sh4 (SuperH), PowerPCSPE (e500v2) and Intel x32
and I'm not infinitely rich. In fact, I was already doing that when I was
only earning very little money working as a sysadmin.

> Why shouldn't IBM, if it's a company that needs to do it? They're the POWER people,
> after all. Yet they were the ones pushing to remove it. Why is Google singled out here?

I didn't mean to solely criticize Google, here. Sorry. It's just that I also
made similar experiences regarding Golang when it came to the Solaris/sparc64
port which I really anticipated to get merged for 1.9. So, I apologize for
singling out Google here.

>
> Google always claims to be an open source company and all about community, but then constantly puts out statements like yours come which read like „We won’t
> do that because we can’t earn money with that!“.
>
>
> Now you talk about community, but where is the community stepping up here?

Did you reach out to Debian? You know, not everyone can be on every list.

I already said that to the OpenJDK people: If you need help with a specific
port, send an email to projects like Debian or NetBSD. You will almost always
find someone who is willing to help. Debian is testing its packages on
22 different targets,

> https://buildd.debian.org/status/package.php?p=gcc-6&suite=sid

so there are is always someone you can ask for help.

> When we proposed removing ARM5, the ARM5 community stepped up and helped and
> kept it alive. When the rarely-used Plan 9 port breaks, the Plan 9 community fixes it.

Ok, so that obviously works. Good :).

> Being part of an open source community does not mean that a corporate benefactor
> necessarily does everything that community wishes for them.

That's right and I fully agree here. It seems to be an issue with the lack of
communication. It shouldn't be just up to IBM to decide which POWER targets
they support. I know they probably had good intentions trying to lower the
maintenance burden for the POWER code, but can't help thinking that marketing
at IBM isn't quite with dropping of support for older hardware either as
an incentive to buy new shiny POWER8 servers ;-).

> Sorry, but I can’t be anything but frustrated. If you don’t want to work
> with the community, then heck, just make this whole language closed source and sell
> it for money. At least you would be honest about your intentions about making
> money instead of providing something to the open source community to make
> programmers and users live easier.
>
> It's obvious you're frustrated, but that isn't a great closing argument.
>
> Keeping POWER5 requires ongoing work & maintenance & testing & machines, and it
> needs people to do it. That's the problem that needs to be solved and that you'd
> want to focus on to enact change.

I am happy to provide full access to a Debian instance running the latest unstable
release on ppc64 (running on a FAST POWER8 machine) providing both ppc64 (POWER5)
and powerpc change roots to set up a testsuite for Golang. In fact, we have done
the same for the Free Pascal Project, their test suite runs on Debian servers now.
QEMU upstream has also access to one of our SPARC boxes which I provided to keep
them to drop sparc64 as a host architecture.'

So, I'm absolutely willing to help where I can and providing all resources necessary
to help test code of various upstream projects on the more exotic architectures.

And I'm doing all this in my freetime without anyone paying me for that ;-).

Adrian

[John Paul Adrian Glaubitz]

On 06/15/2017 07:47 PM, cherry wrote:
> Go as a language doesn't really drop POWER5 support. It is a particular implementation, cmd/compile in this case, that may do.

Well, it seems that after 1.9 I won't be able to build Golang on POWER5 anymore, will I?

> gccgo probably supports POWER5 and will continue to. There might be other compilers.

gccgo doesn't seem to be on par with Golang. At least in Debian, we have 91 source
packages which directly build-depend on the Golang and won't build with gccgo.

Adrian

[Russ Cox]

Go is a language. There are currently two implementations: the main distribution on golang.org, which we call the gc toolchain, and also gccgo.

For all the reasons outlined in the issue and repeated above, we're not going to reintroduce POWER8 into the gc toolchain at this point.

Gccgo is believed to work just as well as the gc toolchain, and of course it supports many more architectures. If there are reasons that certain Debian packages require the gc toolchain and don't work with gccgo, we'd love to hear about those gccgo problems on the Go issue tracker (golang.org/issue/new). Fixing those would help not just POWER5 but also any other architectures missing from the gc toolchain but supported by gccgo.

Thanks.

Russ

[John Paul Adrian Glaubitz]

On 06/15/2017 07:53 PM, Ian Lance Taylor wrote:
> I'm sorry that this decision seems wrong to you. As far as I know,
> it's not irreversible, but it does require some real argument.

Well, the argument is that not everyone on this planet is always
able to afford the latest and greatest hardware. And the fact
that 10-year-old hardware is not so common in the Western World,
it's absolutely common in other parts of the world. A 10-year-old
computer or an embedded PPC64 board with a Freescale SoC are
perfectly fine hardware.

> Google doesn't earn any money on Go, so that part of your comment
> seems to me to be a non-sequitur.

No, but I'd also think that it would be a bit dishonest to say that
Google created Go solely because they wanted to give something to
the world. If I remember the story correctly, one of the ideas was
to have a language which college gradates could learn quickly
when joining a new company and they would become productive very
quickly in the new language so they can already work on projects
very soon after joining.

> And, frankly, it's backward: if Google earned money on Go, we
> would be dropping ports much more aggressively to only focus
> on the ones that people were willing and able to pay for.

That's not what I said. The original statement was that you cannot
afford to maintain support for old hardware which is the project
seemed to me to be rather driven by commercial interests than
by the community.

> We are of course very grateful for the extensive open source
> contributions to Go. If someone were to step up and convincingly
> volunteer to fully maintain the POWER5 support for ppc64 big-endian,
> that would be a factor in our decision. Right now, nobody is
> volunteering to do that. And the people who actually are maintaining
> the ppc64 port, who mostly work for IBM, have specifically requested
> that we only support POWER8 and above, to make their lives simpler.

Well, you didn't ask Debian, for example, where there are almost
always people willing to help.

> it's an easy mistake to think that because Google has a lot of
> resources, which is true, that that implies that Google should do

> everything.But that is impossible. Google has to allocate finite

> resources like any other organization. And the Go team is a tiny tiny
> part of Google, and the Go team's mission is really tangential to
> Google's mission.

I'm not arguing that Google is infinite. I'm arguing that Google
has definitely much more resources than the Free Pascal Compiler
project or Debian where people are actually able to maintain
support for the less common targets.

As I have mentioned in my other mail to Bret. I have heard that
Google was offered a SPARC-T7 server for hosting to set up a
CI server for Solaris/sparc64 and that was allegedly rejected with
the statement that sparc64 isn't relevant enough.

> Whatever we decide here, the gccgo compiler fully supports the Go
> language, and it continues to work fine on POWER5.

Then I don't understand why there are 91 source packages in Debian
which won't build with gccgo.

Adrian

[John Paul Adrian Glaubitz]

On 06/15/2017 08:00 PM, Russ Cox wrote:

> On Thu, Jun 15, 2017 at 1:06 PM, John Paul Adrian Glaubitz <adrian....@googlemail.com <mailto:adrian....@googlemail.com>> wrote:
> Having said that, I find the requirements a bit strange. How exactly am I supposed to measure the number of active ppc64 users?
>
>
> Well, we can estimate them the best we can (today, we think there are hardly any) and then if we're wrong we find out with feedback like this. As Brad pointed
> out, this worked well for ARMv5. We believed we could drop it, we announced that we were going to, and then enough users stepped forward that we didn't drop it.

OK. I wasn't aware of that. I was just reading through the github issue which basically said "We only know one person using Golang
on POWER5 so it doesn't make sense to continue supporting it there." I mean, I don't know anyone who is running Debian on s390x
or ppc64el, yet I am willing to fix packages when they break on these targets - without anyone paying me for that. In fact, many
many Debian developers and maintainers work on fixing code on these mainframe or server architectures for free.

>
> You know, this isn’t possible as Linux distributions usually don’t phone home like Windows does. Plus, there are many Linux users around the world in
> third-world countries for whom a 10-year-old computer is the best they can afford. You’re only seeing this from the Western world where the majority of
> users can afford always buying the latest and greatest hardware, ignoring that there are countries in the world where the situation is much different.
>
>
> I don't think that's true at all. The vast majority of 10-year-old computers on the secondary market are not PowerMac G5s. They are 32- or 64-bit x86 machines,
> both of which are very well supported by Go and will continue to be. You don't have to have the "latest and greatest" hardware to run Go, you just can't use a
> PowerMac G5 (anymore).

Today it's POWER5, tomorrow it will be ARMv7 and x86_32. gcc-7, on the other hand, still works fine on the 22 targets we support in Debian.

> Heck, there are 7 billion people on this planet. Do you really think there is just one users running Linux on POWER5 hardware? You know, not everyone can
> read all issues on github or read all messages on this mailing list.
>
>
> I am sure there are many people running Linux on POWER5, but yes I really do think there is just one user (at most) running Go on Linux on POWER5. I'd be happy
> to be corrected but again I'd have to be off by multiple orders of magnitude to change the decision.

Golang is being built on Debian/ppc64, Fedora/ppc64 and openSUSE/ppc64 on the latest releases:

> https://buildd.debian.org/status/package.php?p=golang-1.8&suite=sid
> https://build.opensuse.org/package/show/devel:languages:go/go
> https://koji.fedoraproject.org/koji/buildinfo?buildID=861725

So, everyone running openSUSE, Fedora or Debian on ppc64 can just install golang from the package
manager just fine and use it.

> I also don’t really understand why you consider it so much of a burden to continue to provide support for POWER5. There are other compiler projects like the
> Free Pascal Compiler which have much less manpower yet the they manage to maintain architecture support for even older architectures like m68k or 8086.
>
>
> With all respect to those projects, there's a difference between supporting a fixed language spec and supporting ongoing significant evolution of a language and
> its libraries. The Free Pascal Compiler is not simultaneously developing whole new versions and evolutions of Pascal and its implementation, at least not
> anywhere near the scale that Go is.

Then let's use LLVM or gcc for comparison. They also support ppc64 or sparc64 just fine or are these projects also less challenging than Golang?

> When it comes to availability, POWER8 hardware is probably unaffordable for most users because IBM doesn’t manage to scale the hardware down enough. Heck,
> when talking about the number of users and availability of hardware, Go should be Windows x86 only because that’s what most people run on the planet.
>
>
> I agree with you that hobbyists cannot afford POWER8 hardware and therefore cannot run Go on ppc64. That's OK. Go works just as well on x86, and as you say
> there are plenty of x86 boxes. Go 1.10 also supports systems with 1024 cpus, but that hardware is not practical for hobbyists either.

My problem with x86 is that the architecture is owned by a company who has their hands tight on the design and
is threatening everyone with lawsuits who want to make their own implementations, see:

> https://arstechnica.com/information-technology/2017/06/intel-fires-warning-shots-at-microsoft-claims-x86-emulation-is-a-patent-minefield/

And I think I don't need to remind people of things like Intel's AMT and their binary blobs
required for even their integrated sound cards nowadays. Lots of Linux and BSD users would
actually rather prefer buying POWER hardware if IBM would just make machines that people
can afford.

> Finally, as Cherry pointed out and Ian confirmed, gccgo will continue to support POWER5,
> for I assume as long as gcc does, which is probably forever.

But gccgo doesn't seem to be on par with Golang and lots of packages seem to expect
proper Golang to be present to be able to compile things. gccgo isn't that useful
if it only allows for a handful of the big Go packages like Docker or Kubernetes
to compile.

> This is only one implementation. If you are worried about Debian in particular
> depending on Go in some important way and needing POWER5 support to keep working on those
> systems, gccgo is there. In fact I am sure there are supported Debian architectures
> today for which gccgo is the only Go compiler. This just adds one more architecture to that list.

If I can compile every Go package with gccgo which I can compile with golang, that
would be ok. But that doesn't seem to be the case but I'm happy to be corrected
if I'm wrong.

Adrian

[John Paul Adrian Glaubitz]

On 06/16/2017 02:26 PM, Lynn Boger wrote:
> Support for the ppc64 v1 ABI was never added to golang. That means the types of linking modes that can be used with golang on ppc64 big endian are limited,
> preventing many of the commonly used Go applications to build or run on ppc64 big endian. None of the newer buildmodes (pie, shared, etc.) are supported on
> ppc64 big endian because of this. While there have been a few complaints on this, there haven't been many. To me that is an indicator of how golang on
> ppc64 big endian is used. I believe if there were serious users for ppc64 big endian, there would have been more requests for full linker support.

At least checking for packages with "golang" in their name, there don't seem to be many Go
packages on ppc64 which fail to build. In fact, I can only count four:

glaubitz@wuiet:~$ wanna-build --arch ppc64 --list build-attempted | grep -i golang
misc/golang-github-docker-docker-credential-helpers_0.5.0-2 by buildd_ppc64-kapitsa [extra:uncompiled:calprio{32}:days{39}]
misc/golang-github-docker-libnetwork_0.8.0-dev.2+git20170202.599.45b4086-1 by buildd_ppc64-ookuninushi [extra:uncompiled:calprio{32}:days{24}]
misc/dh-make-golang_0.0~git20161120.0.71f5e23-1 by buildd_ppc64-ookuninushi [extra:uncompiled:bp{-10000}:calprio{-9968}:days{96}]
misc/golang-gogoprotobuf_0.3+git20170120.144.265e960d-1 by buildd_ppc64-kapitsa [extra:uncompiled:bp{-10000}:calprio{-9968}:days{96}]
glaubitz@wuiet:~$

> golang for ppc64 big endian was always documented as an "experimental port" and has never been available on the golang.org/dl website.

Being able to download a binary build isn't necessary when Fedora, Debian and openSUSE are
building Golang packages for ppc64 by default.

> gccgo is a good option, and it can be targeted for power5 or power8.

But is it 100% on par with Golang? gccgo isn't of much use if I can
only build a fraction of the important Go packages like Docker, rkt
or Kubernetes with it.

[John Paul Adrian Glaubitz]

On 06/17/2017 08:16 PM, Russ Cox wrote:
> For all the reasons outlined in the issue and repeated above, we're not going to reintroduce POWER8 into the gc toolchain at this point.

Good, kick out support for "POWER8" :P.

> Gccgo is believed to work just as well as the gc toolchain, and of course it supports many more architectures. If there are reasons that certain Debian packages
> require the gc toolchain and don't work with gccgo, we'd love to hear about those gccgo problems on the Go issue tracker (golang.org/issue/new

> <http://golang.org/issue/new>). Fixing those would help not just POWER5 but also any other architectures missing from the gc toolchain but supported by gccgo.

I don't know whether I'm willing to help support a project which is arbitrarily kicking
out support for targets I care about or rejects certain ports because there aren't enough
users. Projects like gcc and LLVM show that it is possible, so I don't buy your line
of arguments. Heck, I could even convince Oracle people to start accepting my patches
for OpenJDK and you know, Oracle is basically seen as the most evil company in the
industry (which is, in fact, unjustified because they are doing great community
work and they have amazing skilled people).

Sure, continue to have this attitude and care only about your use cases, but also
don't expect Go to be as successful as Java, Python or C/C++ with that attitude.

Cheers,

[John Paul Adrian Glaubitz]

On 06/17/2017 08:17 PM, John Paul Adrian Glaubitz wrote:
> As I have mentioned in my other mail to Bret.

Sorry, I meant to write "Brad", of course. I'm a bit tired today because I spent
the whole day today tearing down an old coal stove at my mother's place so my
brain isn't functioning so well at this time of the day anymore. I also noticed
my other mails contain some weird typos which I only caught after sending
my mails.

I apologize for that.

[Brad Fitzpatrick]

[+Aram]

On Sat, Jun 17, 2017 at 11:17 AM, 'John Paul Adrian Glaubitz' via golang-dev <golan...@googlegroups.com> wrote:

As I have mentioned in my other mail to Bret. I have heard that
Google was offered a SPARC-T7 server for hosting to set up a
CI server for Solaris/sparc64 and that was allegedly rejected with
the statement that sparc64 isn't relevant enough.

That is not accurate.

We do not run any physical builders. We spend a bunch of money per month on VMs & rented hardware hosted by other companies. Most of our VMs are on GCE. Some used to be on AWS. Some on Joyent. Some at Scaleway. Some at Packet.net. Bunch of Macs at MacStadium. We used to run physical machines in the past, but it's always been a struggle and game up on ARM builders (once we found Scaleway & Packet), and we stopped doing Macs once we found MacStadium.

Aram emailed me on 2016-04-13 offering to have Oracle lend Google a SPARC64 machine via Aram and we went back and forth two times on that same day, but concluded that the legal paperwork was too much work (figuring out a lending agreement, since they weren't giving it to the Go project or Google), and that we had no place to rack it anyways, because it would be running Oracle Solaris instead of Linux, and no datacenter technician we had would be willing to be remote hands for anything not Linux. The thread ended.

Then on 2016-05-06 I emailed Aram and said that I had SmartOS builders running (on Joyent) for Illumnos and he could take his down if he wanted. He replied updating me on the SPARC64 situation and said:

"I've also racked the future SPARC64 builder somewhere. In fact, I am configuring networking as we speak."

I never heard another update.

So it's 100% untrue that we claimed that sparc64 wasn't relevant.

I'm a huge fan of having many & diverse builders & Go ports:

https://farmer.golang.org/builders

https://golang.org/wiki/DashboardBuilders

But Aram hasn't yet started running an SPARC64 builder.

If he wants to start running one, he could & should, per:

https://golang.org/wiki/PortingPolicy#requirements-for-a-new-port

I look forward to SPARC64 being added in Go 1.10.

It missed Go 1.9 because we deleted the old compiler backend, probably without communicating that widely or often enough, and the SPARC64 port wasn't ready on the new backend yet.

[Jakub Cajka]

To be honest I'm currently considering proposal of drop(stop building) of all Go based packages in Fedora for ppc64 architecture starting from next Fedora release(unless Fedora moves to be p8+). Gccgo could be a way forward but it will require substantial time investment that I don't feel good about requiring from fellow packagers(especially as Go packaging in Fedora is mostly one man(jchaloup's) show, when not counting docker, kubernetes, openshift and golang package maintainers) and that I can't personally do(due to time constrains). Gccgo mostly worked(hm.. haven't checked on it in a while), but I'm afraid that among many things some packages/projects which use their own build scripts are quiet strict in their expectations/assumptions and will most probably require some hacking(*looks with dread at kubernetes and its derivates*).

As of ppc64 port. Will gc get ppc64 extld/Cgo support? If I have followed the discussions properly(might have missed something) it will be at power ABIv2 level, right?, which seems to me as bit odd as most of the ppc64 distribution(operation systems) that I know are ABIv1 and AFAIK ABI is incompatible, right?

JC

PS: BCC'ed fedora's ppc ML(p...@lists.fedoraproject.org), to take any "Fedora" discussion there.

>
> Adrian
>
> --
> .''`. John Paul Adrian Glaubitz
> : :' : Debian Developer - glau...@debian.org
> `. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>

> --
> 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+...@googlegroups.com.

[Lynn Boger]

On Saturday, June 17, 2017 at 1:37:47 PM UTC-5, John Paul Adrian Glaubitz wrote:

On 06/16/2017 02:26 PM, Lynn Boger wrote:
> Support for the ppc64 v1 ABI was never added to golang.  That means the types of linking modes that can be used with golang on ppc64 big endian are limited,
> preventing many of the commonly used Go applications to build or run on ppc64 big endian.  None of the newer buildmodes (pie, shared, etc.) are supported on
> ppc64 big endian because of this.  While there have been a few complaints on this, there haven't been many.  To me that is an indicator of how golang on
> ppc64 big endian is used.  I believe if there were serious users for ppc64 big endian, there would have been more requests for full linker support.

At least checking for packages with "golang" in their name, there don't seem to be many Go
packages on ppc64 which fail to build. In fact, I can only count four:

glaubitz@wuiet:~$ wanna-build --arch ppc64 --list build-attempted  | grep -i golang
misc/golang-github-docker-docker-credential-helpers_0.5.0-2 by buildd_ppc64-kapitsa [extra:uncompiled:calprio{32}:days{39}]
misc/golang-github-docker-libnetwork_0.8.0-dev.2+git20170202.599.45b4086-1 by buildd_ppc64-ookuninushi [extra:uncompiled:calprio{32}:days{24}]
misc/dh-make-golang_0.0~git20161120.0.71f5e23-1 by buildd_ppc64-ookuninushi [extra:uncompiled:bp{-10000}:calprio{-9968}:days{96}]
misc/golang-gogoprotobuf_0.3+git20170120.144.265e960d-1 by buildd_ppc64-kapitsa [extra:uncompiled:bp{-10000}:calprio{-9968}:days{96}]
glaubitz@wuiet:~$

> golang for ppc64 big endian was always documented as an "experimental port" and has never been available on the golang.org/dl website.

Being able to download a binary build isn't necessary when Fedora, Debian and openSUSE are
building Golang packages for ppc64 by default.

If the distro is always building from source then it can continue to use golang 1.8 when building distros that target old hardware.
 

> gccgo is a good option, and it can be targeted for power5 or power8.

But is it 100% on par with Golang? gccgo isn't of much use if I can
only build a fraction of the important Go packages like Docker, rkt
or Kubernetes with it.

 You can't build Docker or Kubenetes on golang for ppc64 big endian and never have.  (Kubernetes
considers ppc64 big endian an unsupported arch).  I'm not familiar with rkt.  Anything that uses cgo
can't be compiled or built on ppc64 big endian using golang.

From a compiler perspective, gccgo can compile and build the same Go source code that golang can.
If bugs are found, they need to be reported.  gccgo was the first Go compiler available on ppc64 big
and little endian, and Fedora 22 and 23 used it to build and deliver Docker and Kubernetes was
being built for ppc64le with gccgo in the beginning until golang was available.

Since gccgo and golang are in different toolchains,  there are some usability differences which means
that build scripts might need to be changed, which does require some work.

[Ian Lance Taylor]

On Sat, Jun 17, 2017 at 11:17 AM, John Paul Adrian Glaubitz
<adrian....@googlemail.com> wrote:
> On 06/15/2017 07:53 PM, Ian Lance Taylor wrote:
>
>> We are of course very grateful for the extensive open source
>> contributions to Go. If someone were to step up and convincingly
>> volunteer to fully maintain the POWER5 support for ppc64 big-endian,
>> that would be a factor in our decision. Right now, nobody is
>> volunteering to do that. And the people who actually are maintaining
>> the ppc64 port, who mostly work for IBM, have specifically requested
>> that we only support POWER8 and above, to make their lives simpler.
>
> Well, you didn't ask Debian, for example, where there are almost
> always people willing to help.

Perhaps you could ask Debian on our behalf.

>> Whatever we decide here, the gccgo compiler fully supports the Go
>> language, and it continues to work fine on POWER5.
>
> Then I don't understand why there are 91 source packages in Debian
> which won't build with gccgo.

I don't understand it either. I hope that people will file issues so
that these problems can be fixed.

Ian

[Lynn Boger]

I could look at the build logs for packages that build on ppc64 big endian
with golang but fail with gccgo.

Ian

[John Paul Adrian Glaubitz]

On 06/21/2017 11:32 PM, Ian Lance Taylor wrote:
>>> We are of course very grateful for the extensive open source
>>> contributions to Go. If someone were to step up and convincingly
>>> volunteer to fully maintain the POWER5 support for ppc64 big-endian,
>>> that would be a factor in our decision. Right now, nobody is
>>> volunteering to do that. And the people who actually are maintaining
>>> the ppc64 port, who mostly work for IBM, have specifically requested
>>> that we only support POWER8 and above, to make their lives simpler.
>>
>> Well, you didn't ask Debian, for example, where there are almost
>> always people willing to help.
>
> Perhaps you could ask Debian on our behalf.

I'm not sure what you mean. I think it's not a secret that Debian has
a large collection of porter boxes for various architectures and it
wouldn't have been a problem at all to provide a POWER8 machine for
golang upstream to run a CI.

We are already doing that for the FPC and QEMU project for their
SPARC64 port.

>>> Whatever we decide here, the gccgo compiler fully supports the Go
>>> language, and it continues to work fine on POWER5.
>>
>> Then I don't understand why there are 91 source packages in Debian
>> which won't build with gccgo.
>
> I don't understand it either. I hope that people will file issues so
> that these problems can be fixed.

I have the impression that no upstream project really cares about
gccgo-go. It's either golang-go or your target is unsupported.

[Ian Lance Taylor]

On Thu, Jun 22, 2017 at 11:45 PM, John Paul Adrian Glaubitz
<adrian....@googlemail.com> wrote:
> On 06/21/2017 11:32 PM, Ian Lance Taylor wrote:
>>>> We are of course very grateful for the extensive open source
>>>> contributions to Go. If someone were to step up and convincingly
>>>> volunteer to fully maintain the POWER5 support for ppc64 big-endian,
>>>> that would be a factor in our decision. Right now, nobody is
>>>> volunteering to do that. And the people who actually are maintaining
>>>> the ppc64 port, who mostly work for IBM, have specifically requested
>>>> that we only support POWER8 and above, to make their lives simpler.
>>>
>>> Well, you didn't ask Debian, for example, where there are almost
>>> always people willing to help.
>>
>> Perhaps you could ask Debian on our behalf.
>
> I'm not sure what you mean. I think it's not a secret that Debian has
> a large collection of porter boxes for various architectures and it
> wouldn't have been a problem at all to provide a POWER8 machine for
> golang upstream to run a CI.

There is a disconnect somewhere. From my point of view I said:
perhaps someone could volunteer to maintain the POWER5 support for
big-endian ppc64. You said: well, you didn't ask Debian. I said:
perhaps you could ask Debian [to find a volunteer to maintain POWER5
in Go]. You said: Debian has a bunch of machines.

Ian

[Michael Jones]

The big lesson in this is that the Go team underestimated the base of concerned users by as much as 100%

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

--

Michael T. Jones
michae...@gmail.com

[Lynn Boger]

Maybe I was not clear in my previous comment.  Can you please provide the names of a few of the packages that aren't building with gccgo
on ppc64 and details on what errors you get?  Either post them here or open an issue.  Last week I built gccgo on a power7 (I don't have easy access to old
unsupported hardware) and targeted it for the power4 instruction set (which will generate code that will work on G5 or power5 or anything later).  With that gccgo
 I was able to build over 40 of the packages that require Go and they all built successfully and without any changes to the packages.  So I would like to know
 specifically what packages and what errors you are seeing with gccgo that build with golang so we can understand what's lacking.

Thanks,

Lynn