[HN Gopher] Lanai, the mystery CPU architecture in LLVM
___________________________________________________________________
Lanai, the mystery CPU architecture in LLVM
Author : todsacerdoti
Score : 159 points
Date : 2022-03-21 18:31 UTC (4 hours ago)
(HTM) web link (q3k.org)
(TXT) w3m dump (q3k.org)
| CalChris wrote:
| > The world's best instruction mnemonic: PUNT, to switch between
| user and system contexts.
|
| That's pretty good but I still prefer PowerPC's EIEIO.
|
| https://www.ibm.com/docs/en/aix/7.2?topic=set-eieio-enforce-...
| classichasclass wrote:
| There are many great Power mnemonics. VSX introduced one nearly
| as good, xxlxor (which, quite reasonably, is a logical XOR
| between VSX registers/FPRs). It's delightful to try to even
| pronounce.
|
| The best part is that eieio's derivation is totally plausibly
| serious from its stated function. (Remember, IBM doesn't have a
| corporate sense of humour.) It's also an easy, fairly
| lightweight speculation barrier apart from its official usage.
| thebester5 wrote:
| My favorite PPC instruction is darn. It delivers a random
| number, either raw or NIST conditioned. We decided to use the
| same instruction name in an internal RISCV implementation,
| and fun times have been had complaining about the darn
| instruction not working.
| illegalmemory wrote:
| This seems related
|
| https://github.com/chriseth/notes/blob/186d7ea0742336ed38e39...
|
| "TrueBit - Off-Chain Computations for Smart Contracts"
| q3k wrote:
| This is https://github.com/TrueBitProject/lanai , which is in
| itself an interesting endeavor which I forgot to write about.
| I've added a mention about it to TFA.
| Melatonic wrote:
| Given the timing by Google I suspect this COULD be involved in
| what Paul Debevec was doing there with giant camera sphere arrays
| hogehoge51 wrote:
| Lanai .... Sounded familiar, of course myri. I used these NICs to
| implement wire speed 10g packet capture. They were a fraction of
| the cost of dedicated packet capture boards and had a nice api.
|
| These days I guess a Risc-v would be a perfect match for this
| sort of application, but back then it seemed every accelerator
| startup would implement a custom ISA.
| davidw wrote:
| If Google acquired it, the cynical take is that they ended up
| sitting on it and doing nothing or killing it.
| ncmncm wrote:
| Mentor Graphics used to buy up silicon-compiler companies just
| to shut them down, so that manual layout tools would have a
| longer shelf life. They finally had to give that up around
| 1990, and figure out a different business to be in. Amazingly,
| they did.
| wmf wrote:
| The fact that they developed and upstreamed an LLVM backend
| indicates that they probably did something with it.
| rsstack wrote:
| The Google way: Force the rest of the world adjust to your
| new "cool thing", and then kill it because it wasn't that
| great.
| monocasa wrote:
| Google isn't really forcing anyone to do anything in this
| case. Another RISC backend that was made clear would be
| ripped out of upstream the instant the Google maintainers
| stopped responding isn't really an imposition.
| uluyol wrote:
| Would something like this be accepted in open source
| projects that are not significantly driven by Google?
|
| E.g. would Linux accept code for drivers / architectures
| that are not available to the public? I'm genuinely
| curious.
| JonChesterfield wrote:
| xcore (mentioned in that thread) is pretty obscure and
| still in trunk last I looked. Extra backends don't carry
| that much of a maintenance cost, mostly patching them up
| on api changes. Weirder targets hit bugs that the common
| ones don't so there's a benefit from having them in tree
| too.
|
| I'm not sure that generalises beyond modular compilers
| though.
| duskwuff wrote:
| > E.g. would Linux accept code for drivers /
| architectures that are not available to the public?
|
| Drivers is an unequivocal "yes". Here's an example --
| from Google, in fact:
|
| https://github.com/torvalds/linux/commit/e561bc45920aade3
| f8a...
|
| Architectures is less likely. But the pendulum has swung
| away from "making your own architecture" anyways.
| rstat1 wrote:
| Given how ridiculously strict the Linux folks are being
| with the DXGKRNL stuff that MS is working on (which is
| public as part of WSLg), I would say definitely not.
| monocasa wrote:
| I think that has more to do with DXGKRNL coming from
| Microsoft than any policy that would be applied to other
| contributers.
| detaro wrote:
| Other Microsoft contributions got into the kernel just
| fine.
| monocasa wrote:
| And other thin veneers over closed source paravirtualized
| VM graphics acceleration pipes get in as well, even from
| companies that flagrantly violate Linux's license.
|
| I think that it's a difference of subtree maintainer as
| to why some Microsoft code gets in and some is fought
| tooth and nail; you can't treat Linux developers as a
| monolith, and the graphics side is significantly more
| Microsoft adverse.
| hoten wrote:
| The relevant discussion:
| https://lists.llvm.org/pipermail/llvm-
| dev/2016-February/0951...
|
| Seems the maintainers were more than happy to accept it,
| and even had policies in place for such contributions.
| One maintainer even mentioned it's a good policy because
| it brings more developers into using LLVM's ToT, which is
| overall good for project health.
| kleton wrote:
| trasz wrote:
| Random, tangentially related thing I just remembered: FreeBSD
| used to provide its own firmware for (iirc MIPS-like) core used
| in very early Broadcom NICs. There also used to be a custom
| firmware for some Adaptec controllers, along with an assembler
| tool to compile it during kernel build.
| drewg123 wrote:
| I think you're talking about the Alteon Tigon-II NICs (Alteon
| was acquired by Broadcom). Ken Merry and I modified Alteon
| firmware so that it supported zero-copy sockets by doing page-
| flipping on receive.
|
| See https://people.freebsd.org/~ken/zero_copy/
| maximilianburke wrote:
| Here's the thread on the LLVM development lists from when Lanai
| was proposed to be upstreamed with some good commentary about why
| it should be accepted even if Google isn't willing to go into
| details: https://discourse.llvm.org/t/rfc-lanai-backend/39874
| drewg123 wrote:
| I worked for Myricom 2001->2013, and Google 2013->2015. And, wow,
| I wish I could comment on this thread.. :)
|
| EDIT: Scott's Medium blog post linked from this article is
| fascinating: https://medium.com/swlh/myricom-an-hpc-story-and-
| lessons-lea...
| jandrese wrote:
| > The CEO capped the full time headcount at 49 people so he
| wouldn't be subject to California law requiring him to provide
| his employees with a health plan.
|
| Can you imagine being this stingy and short sighted? The
| employees are largely PhDs and he is willing to cripple his
| company to avoid paying benefits.
| drewg123 wrote:
| I'm not sure that part of Scott's article was accurate.
|
| I worked remotely, and I'm pretty sure that I was offered
| benefits. I declined them, and used my wife's benefits
| because they were less expensive, and meshed better with
| local health care providers.
|
| EDIT: And I know we had a 401K
| drewg123 wrote:
| I worked there and have evidence that this statement in the
| blog is not true, and I'm being down-voted?
| refulgentis wrote:
| I don't think so, your comment is black text for me, so
| it's either at it's original score or higher.
| drewg123 wrote:
| It was at 0 points and grey when I replied to myself, but
| now its black..
| ChuckMcM wrote:
| Downvotes are fickle things. Unrelated, why turn down the
| health care? With double health care you can tell you're
| health provider you've got double coverage and they will
| bill the primary first, and then the secondary for what
| is left (and if the secondary is designed to be a primary
| program it will cover all that is left so you end up with
| zero out of pocket, even for co-payments).
| drewg123 wrote:
| Because it was CA focused, and I was remote. So most
| local providers were out of network. And it was not free
| ... Its been almost a decade, but I seem to recall that
| it was cheaper to add me to my (then) wife's coverage.
| foobiekr wrote:
| It's not even that hard or expensive to offer 401k, health,
| life insurance in a startup. Been there, done that.
| [deleted]
| djbusby wrote:
| At least 10k/yr/employee.
| edgyquant wrote:
| After the ACA passed, I remember my ex getting 29 hours at
| the places she worked because 30 hours demanded they be given
| benefits like health insurance. I really think regulations
| with a set number like this are the result of corruption or
| something. No way anyone doesn't foresee companies playing
| them this way.
| _tom_ wrote:
| I believe that There are many things that kick in at 50
| people. It's oversimplifying to assume this was due to not
| wanting to offer benefits.
|
| First google hit: https://www.aeisadvisors.com/california-
| compliance-is-my-com...
| lumost wrote:
| Defense contracting also has special bonus's when your
| company is less than 50 people IIRC.
| edgyquant wrote:
| Why 50? Isn't that arbitrary? Why not just force benefits
| for all employees? At least target revenue, if a company
| makes X revenue it has to provide Y benefits per employee.
| CEOs definitely won't be able to easily make the decision
| to take in less money, as that will piss off share holders.
| Fnoord wrote:
| Plot twist: you were the CEO.
| CalChris wrote:
| I just want to know why it needs to be in-tree.
| Fnoord wrote:
| Some important/big customer pays a maintainer to maintain it
| upstream instead of having to maintain/port it in-house. If
| there's two of these, it makes sense. Even with one it would
| otherwise require backporting. Might as well do it in public?
| wyldfire wrote:
| Google uses upstream llvm as their dev repo. I don't know if
| they do any development downstream.
| IshKebab wrote:
| LLVM doesn't have a plugin system so it's that, or maintain a
| fork and deal with horrible merges all the time.
| alduin32 wrote:
| > The moral of the story is simple, expect that in a small
| start-up your stock will NEVER be worth anything, and get what
| you can in your normal paycheck.
|
| That's an important moral.
|
| I wish someone had told me that back then.
| ncmncm wrote:
| pcwalton wrote:
| It is _absolutely_ not the case that you can just quit a
| company, wait a year, and then dump all their confidential
| information.
|
| Even if there were no legal repercussions (which there are),
| that's a great way to never be hired again.
| postalrat wrote:
| Never be hired because you gave away most of your value for
| free?
| dboreham wrote:
| Hard to make a more wrong post (everything apart from the
| advice to consult a lawyer is incorrect).
| ncmncm wrote:
| q3k wrote:
| Yeah, that blog post was a great reference to get a general
| overview of What Happened At Myricom.
|
| ... and I just hope I didn't write anything factually wrong in
| TFA. :)
| [deleted]
| phkahler wrote:
| Regarding the blog post: "Why did Myricom's second CEO fail so
| fast, lack of experience, and loss of respect? If one were to
| attempt to explain the plummeting fortunes of Myricom during
| the term of the second CEO, two characteristics suggest
| themselves:"
|
| It seems to me the second CEO didn't care about the company,
| the product or the risk the previous CEO wanted to take (more
| investment to bring out the new chip). Instead they proposed
| (and got) another round of dividends for the investors, a
| promotion to CEO, and ultimately an aqui-hire to Google. To me
| this reads very simply as putting profit and self-interest
| ahead of the product. Understandable, and it happens all the
| time. If you have a vision, the best way to achieve it is to
| remain in control. Somehow the CEO lost that control.
| quercusa wrote:
| This line in that post is mystifying: _they peddled Infiniband,
| an inferior design based on bus technology, but repositioned as
| a point to point network_
| detaro wrote:
| I think that's a confusing reference to the fact that
| InfiniBand initially was supposed to be also a replacement
| for system-internal buses (i.e. a PCI replacement), before
| PCIe took that place instead.
| gnufx wrote:
| I wasn't there, but understood it was intended for general
| machine-room -- I dislike "datacentres" -- use; Wikipedia
| implies it was intended for ~everything...
|
| Anyway, IB at least had lower latency than Myrinet, which
| is what counts in a lot of HPC. I don't remember the
| numbers, but I got quite close to Myrinet latency with the
| on-board 1GbE NICs on Sun x2200s, an un-managed switch, and
| Open-MX, which was interoperable with the Myrinet MX
| protocol. (I remember MX being slagged off by Mellanox; I
| don't know how similar MXM later was for IB.)
| monocasa wrote:
| Yeah that makes sense, it's an RDMA protocol, and PCIe has
| wayyyy more in common with infiniband then it does with
| legacy PCI.
| le-mark wrote:
| So what is the max speed you can realistically get on
| parallel, on pcb interface, 64 match length wires for
| example? 100mhz, 233?
| dboreham wrote:
| You can use a bus PHY in a p2p configuration.
| wmf wrote:
| But Infiniband didn't do that.
| paulmd wrote:
| you can do point-to-point connections with infiniband,
| it's a pretty common homelab use-case since adapters are
| so cheap these days.
| detaro wrote:
| InfiniBand is always point-to-point, that's the point.
| The talk about "bus" is confusing/wrong since it never is
| a bus.
| NavinF wrote:
| Yeah that makes no sense.
| drewg123 wrote:
| At least initially (~2005 or so?) we had customers who were
| given free IB for their HPC clusters ripping the IB out and
| replacing it with with paid Myrinet installations because
| they could never get their IB clusters to work reliably.
|
| Although we had the superior product, we could not market our
| way out of a wet paper bag. Our CEO counted on our (then)
| superior engineering & expected our products to market
| themselves. Eventually the IB engineering caught up and
| surpassed ours, but our marketing never even came close to
| theirs, so they were the clear winner.
| _tom_ wrote:
| When does the NDA expire? 7 years is a long time.
| Melatonic wrote:
| Interesting - I had never heard of Myricom. I have used
| Infiniband quite a bit in budget super high performance
| applications - the old hardware can sometimes be found quite
| cheaply compared to 40gig/100gig ethernet (or it was at least a
| few years ago). Much more fiddly to get working but the
| performance was impressive once it did.
| gnufx wrote:
| For what it's worth, I've had rather more trouble with
| Ethernet than IB, especially given IB management facilities.
| detaro wrote:
| IB always seemed like the kind of thing where you loose out
| a lot of comfort if you go with "old hardware sometimes
| found cheaply" and thus don't have vendor support, have to
| dig out drivers and tools from random sources, ...
| biorach wrote:
| wheybags wrote:
| I gotta say, if I was the BDFL of llvm, I would kick this out of
| tree without a second thought. Why on earth should a foss project
| support a private architecture? How many man-hours have been
| wasted waiting for the Lanai backend to compile? Not to mention
| applying project-wide refactoring to the Lanai code.
| judofyr wrote:
| There's more context in the thread where it was upstreamed:
| https://lists.llvm.org/pipermail/llvm-dev/2016-February/0951...
|
| Some notable comments:
|
| > I was going to mention it, but you guys know very well the
| drill, so unless this hardware changes fundamental parts of the
| middle end in ways that are unnatural to most other targets
| (doesn't seem that way), then I see no reason why not have it
| upstream.
|
| > I see no problem with having the backend upstream with the
| understanding that all the normal policies apply. Getting more
| people working on ToT is valuable to the community as a whole
| and provided it's "just another backend" with plenty of tests,
| the cost is low.
| klausa wrote:
| A significant part of work on LLVM comes from Apple, which
| includes support for quirks of _their_ proprietary chips and
| platform; and the world is much better for those changes being
| upstreamed rather than living in a fork somewhere.
| mjw1007 wrote:
| There's a big difference between "we are the only people who
| sell hardware using these chips" and "we are the only people
| who have access to hardware using these chips".
| [deleted]
| Someone wrote:
| Removing architectures because they're obsolete/maintainers
| can't be found, I can see (and the llvm maintainers agree. They
| removed Alpha at some time, for example), but because they're
| proprietary? That would mean kicking out x86, x64, ARM, AMD
| Terascale, IBM's z/architecture, etc.
|
| I'm sure clang would be very happy with that.
| tedunangst wrote:
| > How many man-hours have been wasted waiting for the Lanai
| backend to compile?
|
| Probably zero? Is it compiled by default?
| jcelerier wrote:
| Yes. Run `strings /usr/lib/libLLVM.so| grep -i Lanai` to
| check on your version ; mine has all the relevant symbols
| tedunangst wrote:
| Oh, wow. I'm honestly surprised. My build does not.
| jcelerier wrote:
| afaik, by default LLVM builds support for all its
| supported architectures, I guess you passed
| -DLLVM_TARGETS_TO_BUILD="X86" or something to cmake when
| building your llvm ?
| nwatson wrote:
| For the link, Norton reports: "This is a known dangerous webpage.
| It is highly recommended that you do NOT visit this page." The
| "page full report" doesn't reveal any particulars. I rarely get
| this warning elsewhere.
| q3k wrote:
| This is an old domain, and once upon a time some private
| malware sample links hosted on it got indexed. Years later and
| some software still think I'm evil :).
| biorach wrote:
| > The CEO capped the full time headcount at 49 people so he
| wouldn't be subject to a California law requiring him to provide
| his employees with a health care plan.
|
| ...
|
| words fail me
| IncRnd wrote:
| > Some of my recent long-term projects revolve around a little
| known CPU architecture called 'Lanai'. Unsurprisingly, very few
| people have heard of it, and even their Googling skills don't
| come in handy.
|
| I don't get this. Searching for [lanai cpu] shows tons of links
| on the LANai cpu architecture from Myricom, purchased by Google.
| kyrra wrote:
| Googler, opinions are my own.
|
| Btw, the Lanai target in LLVM can be found here:
| https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ....
| Latest commit is only 24 days ago, so it looks to still be
| active. Though I'm not sure how much of that is generic target
| updates, vs target specific changes.
| zozbot234 wrote:
| How would Lanai compare to a simple RV32I isa/core for this
| application area? The short description in OP doesn't really
| clarify what, if anything, might be specifically compelling about
| this arch.
| q3k wrote:
| Lanai is significantly older than RISC-V. These days you'd
| likely easily pick designing or using an existing RISC-V core
| for an application like this, possibly adapting it to your
| particular usecase.
|
| The decision is different, however, if you happen to have the
| entirety of the Lanai engineering team on board and own the
| entire Lanai IP portfolio. :)
___________________________________________________________________
(page generated 2022-03-21 23:00 UTC)