15 ms·

LLVM Patches Confirm Google Has Its Own In-House Processor

165 points by buserror 11y ago

TheCoreh 11y ago
Now, would it even make sense to merge into the mainline codebase of LLVM backend code targeting a platform that noone else can test or use? Is Google planning on eventually releasing this architecture publicly or maybe licensing it to third party manufacturers, a-la ARM?
- lhecker 11y ago
  Maybe they just don't want to backport their backend code again and again for every LLVM snapshot they do, because that can be a tedious thing to do compared to just having it in origin/master forever for free.
  - iainmerrick 11y ago
    What makes that tedious? And can't it be fixed?
    - coldpie 11y ago
      Suppose the LLVM devs change a function signature used by Google's private backend. If the backend is private, Google will have to update their usage of that API when they do a merge. But if the backend is present upstream when the LLVM devs make that change, then the LLVM devs are responsible for making sure all supported backends update their usage of the API.
      - iainmerrick 11y ago
        But as people have noted, if you don't have the hardware, it's impossible to test that any changes actually work. If we're just talking about pure refactoring that doesn't change any output, you could test that the generated machine code is identical. But then you have to ask, why isn't there a stable API rather than all this refactoring churn? I guess this is just the way LLVM and Clang are designed -- all components really tightly coupled together. And it's a successful project so it must be working out for them. But...!
        microcolonel 11y ago
        In this case you would just need to compile to know it's broken.
        coldpie 11y ago
        I'm just explaining why Google might want it merged upstream. The work you're talking about has to be performed in either case.
        mywittyname 11y ago
        So I'd venture to presume that there's an extensive battery to tests for each target processor. It seems unlikely to me that developers on the LLVM/Clang team all have physical access to every target CPU.
        DannyBee 11y ago
        "If we're just talking about pure refactoring that doesn't change any output, you could test that the generated machine code is identical. But then you have to ask, why isn't there a stable API rather than all this refactoring churn? " LLVM deliberately does not want a stable API. It wants people to keep up with trunk. They do this because they saw what has happened with other compilers, where the stable API became literally impossible to change over time. This is one of the reasons GCC still has a crappy backend. You either have to build a new API and port everyone over, or you have to find an incremental way to change an API interface with hundreds of random interface points.
        thrownaway2424 11y ago
        That is definitely not true about needing the hardware. There are loads of compilers for fictitious hardware and they work perfectly well. There was an entire x86-64 tool chain before anyone ever manufactured one of those.
  - jacquesm 11y ago
    Without the ability to test though they will still have to do a bunch of work in order to be able to use a new release. Possibly the release breaks their backend but nobody will know until google tries to use it.
    - VikingCoder 11y ago
      If their contribution includes unit tests, it could be enough to guarantee most changes won't break it.
- usrusr 11y ago
  For Google, sure. Everybody working with the in-house hardware could do so without hunting for a version of the internal patch/fork. Using the fork would surely be easy enough when directly using LLVM, but the deeper it is hidden within a dependency tree, the more friction it adds to whatever the user at the root of that tree is doing. Everybody else pays a small "maintenance tax" when working on the codebase or relying on work being done on that codebase. Being by no means a compiler expert I do suspect however, that this "tax" is tiny and likely to be dwarfed by other contributions from Google, so letting them solve distribution of their private backend by piggybacking on the public release is most likely the right course of action.
- tyingq 11y ago
  It appears to be for the Myricom LanAI processor, which is available to others. It's an older 32 bit RISC processor, used as the offload engine for their NIC cards. Here's gcc for it: https://github.com/myri/lanai-gcc https://github.com/myri/lanai-gcc Sounds like it's not particularly interesting unless you want to write your own network offload code. Edit: Probably just the offload processor they are choosing for their in-house routers/switches/servers. And, probably they want their own firmware either for security/nsa reasons, or performance, or both.
  - mikecb 11y ago
    I thought this too, but someone in the email thread explicitly mentioned the myricom, and the _response_ to that message was that it was purely internal hardware, not useful for others...so it may just be a coincidence.
    - geofft 11y ago
      But then they go on to say that their "previous binutils used" was https://github.com/myri/lanai-binutils https://github.com/myri/lanai-binutils. It certainly seems believable that this is a third-party processor architecture, but Google has a contract with them to build specific models of that processor that meet their needs (possibly alongside some other proprietary hardware, like a high-speed NIC), and those models aren't sold to the general public. That's pretty common outside x86, right? For instance, is there a way for me to buy a BCM2835 other than by buying a Raspberry Pi?
      - ShinyCyril 11y ago
        Chips like the BCM2835 are available for purchase, just you need to have a very large purchase order.
      - tyingq 11y ago
        If you search a little, you'll find that Google hired Myricom's CEO, Founder/CTO, and several engineers. I suppose it's possible they licensed the IP too.
- Sir_Cmpwn 11y ago
  No, I don't think it really makes sense for LLVM to mainline an architecture no one can use. I doubt they'll be on board with this.
  - verbatim 11y ago
    It's not exactly unprecedented. GCC supports mmix, which hardware doesn't even exist for. (An educational platform from TAOCP.) https://gcc.gnu.org/backends.html https://gcc.gnu.org/backends.html
    - iainmerrick 11y ago
      MMIX is fully documented, though. Being an educational platform is a valid reason to be supported.
    - cmrx64 11y ago
      "Only has simulators" is very different from "nobody can use". MMIX has value.
    - FullyFunctional 11y ago
      The difference between hardware and software is getting fuzzy (Transmeta, NVIDIA Denver, ...), but there's at least one (admittedly terrible) FPGA implementation of a subset of MMIX large enough to execute small graphical demos: https://github.com/tommythorn/fpgammix https://github.com/tommythorn/fpgammix
  - kenferry 11y ago
    Looks like there's consensus to accept it as an "experimental" backend. I think that means the code is in tree, but other people changing LLVM aren't obligated to keep it working. It may be accepted as a full backend in the future, but that discussion is deferred since people are happy with it being experimental for now.
  - jakejake 11y ago
    Ordinarily I'd agree with you. Except the tradeoff of having Google's other contributions to the main branch is probably worth it for a little bit of code that isn't harming anyone else. It's perhaps not fair, but just a reality that a company like Google has a lot to offer so they can sometimes get special treatment.
- maaku 11y ago
  Having been in this position before, I can tell you that maintaining large patch sets increases friction against submitting anything upstream. Even if this was a Google-only CPU (it's not), that'd still be an argument for merging upstream.
desdiv 11y ago
This story has a little more info, including the chip's origin from Myricom: http://www.theregister.co.uk/2016/02/09/google_processor/ http://www.theregister.co.uk/2016/02/09/google_processor/
- rurban 11y ago
  This LANai v11 RISC chip seems to be the successor of the LANai v7 and LANai v9 chips described here: https://www.myricom.com/scs/myrinet/...ogramming.html https://www.myricom.com/scs/myrinet/...ogramming.html for which the gcc toolchain already exists: https://github.com/myri https://github.com/myri Porting this to LLVM makes more sense. Nothing too interesting, as it doesn't use IBM's 7nm or Intel's 10nm chip tech. Just a simple but parallel high-speed network chip, as used in the Myrinet network cards. The old ones ran with 33MHz but very low latency. Really exciting would be the Power8 based on IBM's new 7nm, which would finally blow away Intel advantages on an fully open (and unbackdoored) design.
  - pgeorgi 11y ago
    > Really exciting would be the Power8 based on IBM's new 7nm, which would finally blow away Intel advantages on an fully open (and unbackdoored) design. Sounds like you read https://raptorengineeringinc.com/TALOS/prerelease.php https://raptorengineeringinc.com/TALOS/prerelease.php :-)
  - cmrx64 11y ago
    Nothing about the POWER8 or IBM's process technology implies unbackdoored. I can't inspect the factories, or their supply chain, or the HDL they used, or the tools that processed the HDL. The only thing more "open" about POWER8 is firmware in some deployments, and maybe licensing the ISA (if you have enough clout/money to join the foundation, I can't find any licensing information at all). RISC-V is more interesting in every way, with respect to openness.
userbinator 11y ago
Lanai is a simple in-order 32-bit processor with 32 x 32-bit registers, two registers with fixed values, four used for program state tracking, and two reserved for explicit usage by user, and no floating point support. Might as well be a MIPS. The fact that Google has suppoedly developed its own CPU is interesting, but the architecture itself seems quite mundane. Edit: comments on the article suggest it's the Myricom LANai, a NIC embedded processor. Google may just happen have these NICs in their machines and want to write firmware for them.
- vmorgulis 11y ago
  http://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/851180-llvm-patches-confirm-google-has-its-own-in-house-processor?p=851195#post851195 http://www.phoronix.com/forums/forum/phoronix/latest-phoroni... It could be lanAI too...
  - eternalban 11y ago
    OT(?): reverse(Lanai) // todo: see if copying XXX cpu is OK
deleted 11y ago
[deleted]
ZenoArrow 11y ago
I wonder if they'll be using RISC-V for the same purposes in the near future. http://www.eetimes.com/document.asp?doc_id=1328561 http://www.eetimes.com/document.asp?doc_id=1328561
- PeCaN 11y ago
  Seeing as Google partially sponsored RISC-V[1], it wouldn't really surprise me. 1. Indirectly, via ASPIRE Lab.
  - cmrx64 11y ago
    Google is also a member of the OpenPOWER Foundation (though they've done much more with that). I don't think sponsorship is necessarily endorsement or deployment plans -- it'd be nice if that were the case though!
pyvpx 11y ago
perhaps folks will now take 'intelligent' NICs more seriously than "we tried offloading once and it went poorly so thanks but no thanks"
koder2016 11y ago
If you are serious about your software...
at-fates-hands 11y ago
but at least for Lanai it looks like a CPU used just internally and isn't something that is going to power the next generation of Android devices; How many times have we seen a huge corporation do something in house, then release it for public consumption several years later? At this time, it will probably stay in house, but if there is a revenue opportunity, trust me, they'll release it.
mpu 11y ago
Hurray, no floating points!
Nano2rad 11y ago
First part is lan second part is ai. It could be something to do with artificial intelligence.
Nano2rad 11y ago
Maybe there is no chip, could be they are implementing on FPGA or virtual machines.
WestCoastJustin 11y ago
Must be funny working at Google and knowing the inside scoop (watching people speculate). So, here is my wild speculation about a similar secret project. There was a talk given by Dick Sites (from Google) [1, 2], where he talks about performance monitoring across the Google fleet. Very technical and useful if you are into monitoring (highly recommend it). A large part of his talk is dedicated to issues and limitations with off-the-shelf CPUs. Given that AWS has custom chips (talked about at Invent a few years back), why wouldn't Google solve this issue too, they have the talent and money. [1] http://www.pdl.cmu.edu/SDI/2015/slides/DatacenterComputers.pdf http://www.pdl.cmu.edu/SDI/2015/slides/DatacenterComputers.p... [2] https://vimeo.com/121396406 https://vimeo.com/121396406
- wmf 11y ago
  It's already been posted in this thread that it's just a smart NIC evolved from existing Myricom NICs. (Of course, my coworker was just telling me a story about how John Cocke hid his RISC processor in a printer project.) And Amazon's "custom" CPUs are 100 MHz faster Xeons.
  - deleted 11y ago
    [deleted]

165 points by buserror 11y ago

Now, would it even make sense to merge into the mainline codebase of LLVM backend code targeting a platform that noone else can test or use? Is Google planning on eventually releasing this architecture publicly or maybe licensing it to third party manufacturers, a-la ARM?

lhecker 11y ago
Maybe they just don't want to backport their backend code again and again for every LLVM snapshot they do, because that can be a tedious thing to do compared to just having it in origin/master forever for free.
- iainmerrick 11y ago
  What makes that tedious? And can't it be fixed?
  - coldpie 11y ago
    Suppose the LLVM devs change a function signature used by Google's private backend. If the backend is private, Google will have to update their usage of that API when they do a merge. But if the backend is present upstream when the LLVM devs make that change, then the LLVM devs are responsible for making sure all supported backends update their usage of the API.
    - iainmerrick 11y ago
      But as people have noted, if you don't have the hardware, it's impossible to test that any changes actually work. If we're just talking about pure refactoring that doesn't change any output, you could test that the generated machine code is identical. But then you have to ask, why isn't there a stable API rather than all this refactoring churn? I guess this is just the way LLVM and Clang are designed -- all components really tightly coupled together. And it's a successful project so it must be working out for them. But...!
      - microcolonel 11y ago
        In this case you would just need to compile to know it's broken.
      - coldpie 11y ago
        I'm just explaining why Google might want it merged upstream. The work you're talking about has to be performed in either case.
      - mywittyname 11y ago
        So I'd venture to presume that there's an extensive battery to tests for each target processor. It seems unlikely to me that developers on the LLVM/Clang team all have physical access to every target CPU.
      - DannyBee 11y ago
        "If we're just talking about pure refactoring that doesn't change any output, you could test that the generated machine code is identical. But then you have to ask, why isn't there a stable API rather than all this refactoring churn? " LLVM deliberately does not want a stable API. It wants people to keep up with trunk. They do this because they saw what has happened with other compilers, where the stable API became literally impossible to change over time. This is one of the reasons GCC still has a crappy backend. You either have to build a new API and port everyone over, or you have to find an incremental way to change an API interface with hundreds of random interface points.
      - thrownaway2424 11y ago
        That is definitely not true about needing the hardware. There are loads of compilers for fictitious hardware and they work perfectly well. There was an entire x86-64 tool chain before anyone ever manufactured one of those.
- jacquesm 11y ago
  Without the ability to test though they will still have to do a bunch of work in order to be able to use a new release. Possibly the release breaks their backend but nobody will know until google tries to use it.
  - VikingCoder 11y ago
    If their contribution includes unit tests, it could be enough to guarantee most changes won't break it.
usrusr 11y ago
For Google, sure. Everybody working with the in-house hardware could do so without hunting for a version of the internal patch/fork. Using the fork would surely be easy enough when directly using LLVM, but the deeper it is hidden within a dependency tree, the more friction it adds to whatever the user at the root of that tree is doing. Everybody else pays a small "maintenance tax" when working on the codebase or relying on work being done on that codebase. Being by no means a compiler expert I do suspect however, that this "tax" is tiny and likely to be dwarfed by other contributions from Google, so letting them solve distribution of their private backend by piggybacking on the public release is most likely the right course of action.
tyingq 11y ago
It appears to be for the Myricom LanAI processor, which is available to others. It's an older 32 bit RISC processor, used as the offload engine for their NIC cards. Here's gcc for it: https://github.com/myri/lanai-gcc https://github.com/myri/lanai-gcc Sounds like it's not particularly interesting unless you want to write your own network offload code. Edit: Probably just the offload processor they are choosing for their in-house routers/switches/servers. And, probably they want their own firmware either for security/nsa reasons, or performance, or both.
- mikecb 11y ago
  I thought this too, but someone in the email thread explicitly mentioned the myricom, and the _response_ to that message was that it was purely internal hardware, not useful for others...so it may just be a coincidence.
  - geofft 11y ago
    But then they go on to say that their "previous binutils used" was https://github.com/myri/lanai-binutils https://github.com/myri/lanai-binutils. It certainly seems believable that this is a third-party processor architecture, but Google has a contract with them to build specific models of that processor that meet their needs (possibly alongside some other proprietary hardware, like a high-speed NIC), and those models aren't sold to the general public. That's pretty common outside x86, right? For instance, is there a way for me to buy a BCM2835 other than by buying a Raspberry Pi?
    - ShinyCyril 11y ago
      Chips like the BCM2835 are available for purchase, just you need to have a very large purchase order.
    - tyingq 11y ago
      If you search a little, you'll find that Google hired Myricom's CEO, Founder/CTO, and several engineers. I suppose it's possible they licensed the IP too.
Sir_Cmpwn 11y ago
No, I don't think it really makes sense for LLVM to mainline an architecture no one can use. I doubt they'll be on board with this.
- verbatim 11y ago
  It's not exactly unprecedented. GCC supports mmix, which hardware doesn't even exist for. (An educational platform from TAOCP.) https://gcc.gnu.org/backends.html https://gcc.gnu.org/backends.html
  - iainmerrick 11y ago
    MMIX is fully documented, though. Being an educational platform is a valid reason to be supported.
  - cmrx64 11y ago
    "Only has simulators" is very different from "nobody can use". MMIX has value.
  - FullyFunctional 11y ago
    The difference between hardware and software is getting fuzzy (Transmeta, NVIDIA Denver, ...), but there's at least one (admittedly terrible) FPGA implementation of a subset of MMIX large enough to execute small graphical demos: https://github.com/tommythorn/fpgammix https://github.com/tommythorn/fpgammix
- kenferry 11y ago
  Looks like there's consensus to accept it as an "experimental" backend. I think that means the code is in tree, but other people changing LLVM aren't obligated to keep it working. It may be accepted as a full backend in the future, but that discussion is deferred since people are happy with it being experimental for now.
- jakejake 11y ago
  Ordinarily I'd agree with you. Except the tradeoff of having Google's other contributions to the main branch is probably worth it for a little bit of code that isn't harming anyone else. It's perhaps not fair, but just a reality that a company like Google has a lot to offer so they can sometimes get special treatment.
maaku 11y ago
Having been in this position before, I can tell you that maintaining large patch sets increases friction against submitting anything upstream. Even if this was a Google-only CPU (it's not), that'd still be an argument for merging upstream.

desdiv 11y ago

This story has a little more info, including the chip's origin from Myricom: http://www.theregister.co.uk/2016/02/09/google_processor/ http://www.theregister.co.uk/2016/02/09/google_processor/

rurban 11y ago
This LANai v11 RISC chip seems to be the successor of the LANai v7 and LANai v9 chips described here: https://www.myricom.com/scs/myrinet/...ogramming.html https://www.myricom.com/scs/myrinet/...ogramming.html for which the gcc toolchain already exists: https://github.com/myri https://github.com/myri Porting this to LLVM makes more sense. Nothing too interesting, as it doesn't use IBM's 7nm or Intel's 10nm chip tech. Just a simple but parallel high-speed network chip, as used in the Myrinet network cards. The old ones ran with 33MHz but very low latency. Really exciting would be the Power8 based on IBM's new 7nm, which would finally blow away Intel advantages on an fully open (and unbackdoored) design.
- pgeorgi 11y ago
  > Really exciting would be the Power8 based on IBM's new 7nm, which would finally blow away Intel advantages on an fully open (and unbackdoored) design. Sounds like you read https://raptorengineeringinc.com/TALOS/prerelease.php https://raptorengineeringinc.com/TALOS/prerelease.php :-)
- cmrx64 11y ago
  Nothing about the POWER8 or IBM's process technology implies unbackdoored. I can't inspect the factories, or their supply chain, or the HDL they used, or the tools that processed the HDL. The only thing more "open" about POWER8 is firmware in some deployments, and maybe licensing the ISA (if you have enough clout/money to join the foundation, I can't find any licensing information at all). RISC-V is more interesting in every way, with respect to openness.

userbinator 11y ago

Lanai is a simple in-order 32-bit processor with 32 x 32-bit registers, two registers with fixed values, four used for program state tracking, and two reserved for explicit usage by user, and no floating point support. Might as well be a MIPS. The fact that Google has suppoedly developed its own CPU is interesting, but the architecture itself seems quite mundane. Edit: comments on the article suggest it's the Myricom LANai, a NIC embedded processor. Google may just happen have these NICs in their machines and want to write firmware for them.

vmorgulis 11y ago
http://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/851180-llvm-patches-confirm-google-has-its-own-in-house-processor?p=851195#post851195 http://www.phoronix.com/forums/forum/phoronix/latest-phoroni... It could be lanAI too...
- eternalban 11y ago
  OT(?): reverse(Lanai) // todo: see if copying XXX cpu is OK

deleted 11y ago

[deleted]

ZenoArrow 11y ago

I wonder if they'll be using RISC-V for the same purposes in the near future. http://www.eetimes.com/document.asp?doc_id=1328561 http://www.eetimes.com/document.asp?doc_id=1328561

PeCaN 11y ago
Seeing as Google partially sponsored RISC-V[1], it wouldn't really surprise me. 1. Indirectly, via ASPIRE Lab.
- cmrx64 11y ago
  Google is also a member of the OpenPOWER Foundation (though they've done much more with that). I don't think sponsorship is necessarily endorsement or deployment plans -- it'd be nice if that were the case though!

pyvpx 11y ago

perhaps folks will now take 'intelligent' NICs more seriously than "we tried offloading once and it went poorly so thanks but no thanks"

koder2016 11y ago

If you are serious about your software...

at-fates-hands 11y ago

but at least for Lanai it looks like a CPU used just internally and isn't something that is going to power the next generation of Android devices; How many times have we seen a huge corporation do something in house, then release it for public consumption several years later? At this time, it will probably stay in house, but if there is a revenue opportunity, trust me, they'll release it.

mpu 11y ago

Hurray, no floating points!

Nano2rad 11y ago

First part is lan second part is ai. It could be something to do with artificial intelligence.

Nano2rad 11y ago

Maybe there is no chip, could be they are implementing on FPGA or virtual machines.

WestCoastJustin 11y ago

Must be funny working at Google and knowing the inside scoop (watching people speculate). So, here is my wild speculation about a similar secret project. There was a talk given by Dick Sites (from Google) [1, 2], where he talks about performance monitoring across the Google fleet. Very technical and useful if you are into monitoring (highly recommend it). A large part of his talk is dedicated to issues and limitations with off-the-shelf CPUs. Given that AWS has custom chips (talked about at Invent a few years back), why wouldn't Google solve this issue too, they have the talent and money. [1] http://www.pdl.cmu.edu/SDI/2015/slides/DatacenterComputers.pdf http://www.pdl.cmu.edu/SDI/2015/slides/DatacenterComputers.p... [2] https://vimeo.com/121396406 https://vimeo.com/121396406

wmf 11y ago
It's already been posted in this thread that it's just a smart NIC evolved from existing Myricom NICs. (Of course, my coworker was just telling me a story about how John Cocke hid his RISC processor in a printer project.) And Amazon's "custom" CPUs are 100 MHz faster Xeons.
- deleted 11y ago
  [deleted]