5 ms·

This is significant. With POWER back in the game, and ARM server CPUs arriving, Intel will again have competition.

by fh973 12y ago

ithkuil 12y ago
I think currently there are few big customers that can afford the overhead of porting their code and dependencies to a different architecture. For example I don't expect cloud providers to have a huge marked soon for non x86 architectures. Well there are JVM or other VM users which in theory could not care, as long as you don't need some native library. In the past the battle with intel had to be played by providing an alternative implementation of the x86 instruction set for precisely the same reason: legacy. The mobile market proved you can achieve good performance with ARM and especially better power per performance. I really can't wait to see some more fights in this arena.
- justincormack 12y ago
  Many Linux distros have Power support; Ubuntu just added little endian ppc64 support for additional compatibility. JVM is available, and most other software. It is not that much work...
  - ithkuil 12y ago
    Cool, having the same endianness helps. Sure, it's doable, I have a few ppc at home, but I know first hand stories of small/medium companies just not wanting to risk that. They just have higher costs at maintaining some dependencies, custom builds etc. You never know when you will get some new version of something, like jdk8. Then you have things like missing Go compiler (yes there is gccgo for ppc but still not everything works the same). It's perfect for enthusiast, it's ok for companies with strong investment in IT infrastructure. I just wonder what is the best way to convince those small companies that there is no problem. Perhaps the tools/distros etc are starting to mature at the right point and this will soon no longer be a big practical problem.
    - pjmlp 12y ago
      Having gone through a few architectures, I think the worst offenders is the huge area of undefined/unspecified behavior of C and C++ compilers where many developers assume their compiler behavior is part of the standard. Other languages with more OS agnostic libraries tend not to suffer that much from porting issues except from bit fiddling code. There is however the availability issue as you mentioned.
    - justincormack 12y ago
      Maybe Go will get fixed if Google is trying ppc...
      - thrownaway2424 12y ago
        I think that's the tell. Go is developed at Google, largely for Google, and there's an ARM port but no POWER port.
    - kyrra 12y ago
      This was just asked on the Golang mailing list[0]. > nobody is working on it very seriously. [0] https://groups.google.com/forum/#!topic/golang-nuts/sDV6ZfhGXuo https://groups.google.com/forum/#!topic/golang-nuts/sDV6ZfhG...
- TillE 12y ago
  Writing architecture-agnostic C++ or C code is mostly just a matter of avoiding some silly tricks which you shouldn't be doing anyway, and using the correct types and sizeofs. Porting an operating system is hard. Porting a compiler is hard. But most applications on top of those are fairly straightforward to port, if not completely trivial.
  - Theodores 12y ago
    We have kind of forgotten this. Anyone old enough to remember the early browsers - Mosaic and Netscape - will remember how every platform was supported, regardless of CPU (including MIPS, SPARC, Alpha etc.) and regardless of OS (IRIX, AIX, System whatever, VMS, Windows, etc.). Furthermore you didn't have to wait two years for the non-Windows version to be updated. Only when Microsoft made NT Intel only did you get this arrangement where software was locked to a given architecture/OS. Thank goodness Linux came along.
  - thrownaway2424 12y ago
    It's possible but not trivial. If a programmer has never been exposed to any memory model other than the Intel PC model, they are in for big surprises when they start using POWER. When will write from thread A be visible to thread B? Can this atomic load pass that other load? For multithreaded C++ programs these are tricky. For other languages that always communicate between threads using messages, maybe not, but also maybe you're favorite language runtime doesn't exist on POWER.
    - mikeash 12y ago
      They're only tricky if you're communicating data between threads without using locks. Since this has always been a "here be dragons" area even with x86's convenient memory model, code that gets it right for x86 but not other architectures is pretty rare.
thescrewdriver 12y ago
I'm not sure that one motherboard can count as "back in the game".
jacquesm 12y ago
It's a huge difference between a custom made server board and a mainstream CPU for general purpose use in desktops or commodity servers. ARM is definitely taking market share from Intel on the low end, but AMD is just about the only viable competition intel has right now in the part of the market where they make the bulk of their income and margin.
- fh973 12y ago
  If it is seen as a credible threat, there is no need to walk the whole way. It is enough already if Intel gets the message.

This is significant. With POWER back in the game, and ARM server CPUs arriving, Intel will again have competition.

by fh973 12y ago

This is significant. With POWER back in the game, and ARM server CPUs arriving, Intel will again have competition.

I think currently there are few big customers that can afford the overhead of porting their code and dependencies to a different architecture. For example I don't expect cloud providers to have a huge marked soon for non x86 architectures. Well there are JVM or other VM users which in theory could not care, as long as you don't need some native library. In the past the battle with intel had to be played by providing an alternative implementation of the x86 instruction set for precisely the same reason: legacy. The mobile market proved you can achieve good performance with ARM and especially better power per performance. I really can't wait to see some more fights in this arena.

justincormack 12y ago
Many Linux distros have Power support; Ubuntu just added little endian ppc64 support for additional compatibility. JVM is available, and most other software. It is not that much work...
- ithkuil 12y ago
  Cool, having the same endianness helps. Sure, it's doable, I have a few ppc at home, but I know first hand stories of small/medium companies just not wanting to risk that. They just have higher costs at maintaining some dependencies, custom builds etc. You never know when you will get some new version of something, like jdk8. Then you have things like missing Go compiler (yes there is gccgo for ppc but still not everything works the same). It's perfect for enthusiast, it's ok for companies with strong investment in IT infrastructure. I just wonder what is the best way to convince those small companies that there is no problem. Perhaps the tools/distros etc are starting to mature at the right point and this will soon no longer be a big practical problem.
  - pjmlp 12y ago
    Having gone through a few architectures, I think the worst offenders is the huge area of undefined/unspecified behavior of C and C++ compilers where many developers assume their compiler behavior is part of the standard. Other languages with more OS agnostic libraries tend not to suffer that much from porting issues except from bit fiddling code. There is however the availability issue as you mentioned.
  - justincormack 12y ago
    Maybe Go will get fixed if Google is trying ppc...
    - thrownaway2424 12y ago
      I think that's the tell. Go is developed at Google, largely for Google, and there's an ARM port but no POWER port.
  - kyrra 12y ago
    This was just asked on the Golang mailing list[0]. > nobody is working on it very seriously. [0] https://groups.google.com/forum/#!topic/golang-nuts/sDV6ZfhGXuo https://groups.google.com/forum/#!topic/golang-nuts/sDV6ZfhG...
TillE 12y ago
Writing architecture-agnostic C++ or C code is mostly just a matter of avoiding some silly tricks which you shouldn't be doing anyway, and using the correct types and sizeofs. Porting an operating system is hard. Porting a compiler is hard. But most applications on top of those are fairly straightforward to port, if not completely trivial.
- Theodores 12y ago
  We have kind of forgotten this. Anyone old enough to remember the early browsers - Mosaic and Netscape - will remember how every platform was supported, regardless of CPU (including MIPS, SPARC, Alpha etc.) and regardless of OS (IRIX, AIX, System whatever, VMS, Windows, etc.). Furthermore you didn't have to wait two years for the non-Windows version to be updated. Only when Microsoft made NT Intel only did you get this arrangement where software was locked to a given architecture/OS. Thank goodness Linux came along.
- thrownaway2424 12y ago
  It's possible but not trivial. If a programmer has never been exposed to any memory model other than the Intel PC model, they are in for big surprises when they start using POWER. When will write from thread A be visible to thread B? Can this atomic load pass that other load? For multithreaded C++ programs these are tricky. For other languages that always communicate between threads using messages, maybe not, but also maybe you're favorite language runtime doesn't exist on POWER.
  - mikeash 12y ago
    They're only tricky if you're communicating data between threads without using locks. Since this has always been a "here be dragons" area even with x86's convenient memory model, code that gets it right for x86 but not other architectures is pretty rare.

thescrewdriver 12y ago

I'm not sure that one motherboard can count as "back in the game".

jacquesm 12y ago

It's a huge difference between a custom made server board and a mainstream CPU for general purpose use in desktops or commodity servers. ARM is definitely taking market share from Intel on the low end, but AMD is just about the only viable competition intel has right now in the part of the market where they make the bulk of their income and margin.

fh973 12y ago
If it is seen as a credible threat, there is no need to walk the whole way. It is enough already if Intel gets the message.