[HN Gopher] Ampere switching to in-house CPU designs
___________________________________________________________________
Ampere switching to in-house CPU designs
Author : gautamcgoel
Score : 269 points
Date : 2021-05-20 07:09 UTC (15 hours ago)
(HTM) web link (www.anandtech.com)
(TXT) w3m dump (www.anandtech.com)
| saagarjha wrote:
| Was wondering where they got their architectural license; it
| seems like they somehow obtained it indirectly from Applied
| Micro? Does anyone have more details as to how/when they acquired
| one?
| ksec wrote:
| I dont think anyone would know and I am not sure why that is
| important. And it is not like it needs some secret deal or
| special case for a company to acquire architectural license.
| Not to mention ARM is an investor in Ampere.
| saagarjha wrote:
| Architectural licenses are often secret deals, with the
| licensee being anonymous in many cases. As they are handed
| out fairly rarely, I personally find them fairly interesting
| to follow along.
| varispeed wrote:
| Why are these secret? To evade the tax? Seems dodgy as
| hell.
| therealcamino wrote:
| I think it's just that buying an architecture license can
| reveal future product plans. "Trade secret" doesn't imply
| tax fraud.
| Aissen wrote:
| My understanding is that this PR session is basically the
| announcement of the deal. True, it would be nice to know
| how long they've had a deal, but IMHO it's more interesting
| to know for how long the team has been working on the new
| design, and when it's slated to launch.
| ksec wrote:
| From the article
|
| >In fact, Ampere explains that what the move towards a
| full custom microarchitecture core design was actually
| always the plan for the company since its inception, and
| their custom CPU design had been in the works for the
| past 3+ years.
|
| So my guess is that they always had the license but never
| put out the announcement until they actually have their
| custom core.
|
| Although in modern days PR speak a "custom" core could
| also be a custom ARM X-1 [1] type of custom. We will have
| to wait for more details.
|
| [1] https://www.arm.com/products/cortex-x
| floatboth wrote:
| "somehow indirectly" - I think they basically _are_ Applied
| Micro, just rebranded after the acquisition?
|
| Their first product (eMAG) was based on the last APM X-Gene
| (3?) cores.
| k__ wrote:
| How much do you think the industry can push RISC in terms of
| performance?
|
| Apple and AWS seem to leave the competition behind.
| mastax wrote:
| I'm surprised.
|
| There have been many failures in the past to outdo ARM's cores:
| Intel, AMD, Nvidia, Samsung, Qualcomm. Granted, some of those are
| ancient history or were more management failures than technical
| failures. It seemed to me that with ARM finally focusing on
| developing high performance cores, and the success of N1, the
| industry would coalesce around that. ARM has control over the ISA
| development which can influence and be influenced by
| microarchitecture designs, though they do work with Apple and
| Fujitsu somewhat. ARM gets to combine license fees from many
| customers into a single large R&D budget, much like TSMC. There's
| a huge risk that you spend billions for years and end up with
| custom cores that are worse than what ARM puts out.
|
| So why design custom cores?
|
| Maybe it's a necessity for a viable CPU company. Maybe it's too
| easy to create a custom CPU with stock ARM cores so unless you
| can do substantially better than that, all your biggest potential
| customers will just make their own: Amazon, Microsoft, IBM,
| Oracle, Baidu, Google, Tencent, Alibaba, are all perfectly
| capable of putting some stock cores together. Yes, the devil is
| in the details but I don't think the details are enough to base a
| company around. Maybe even if making a better microarchitecture
| is unlikely you have to try or be doomed to failure in the long
| run.
|
| Maybe they believe their engineering is better. It's tempting to
| discount the value of individual contributors in projects
| involving hundreds or thousands of people. Maybe Ampere believe
| their engineers and/or managers are just better than the
| competition, and can beat them with fewer resources.
|
| Maybe it's not as hard as it used to be. The received wisdom
| after decades of Intel dominance was to not even try to compete.
| Now we seem to be reaching a plateau in microarchitecture
| innovation. Yes, CPUs are still getting faster but the designs
| seem to have converged a lot. It certainly seems easier to catch
| up given that Apple, ARM, and AMD have all succeeded recently.
| Ampere also starts with an _A_ so they 're in good company.
|
| Maybe it doesn't actually have to be substantially better. Maybe
| the N1 license fees are high and they just need something similar
| for less money. Maybe they just need something different that
| their sales team can sell as being better.
| ksec wrote:
| >Microsoft in particular is a big addition to the customer list,
|
| Google are working on their own ARM Server Chip. And we finally
| have ( some sort of ) confirmation Microsoft will be using
| Ampere.
|
| At least Ampere will have fixed their Go to Market problem where
| no hyperscaler were committed to buying ARM instead of building
| their own. Along with Tencent Cloud which is a big surprise.
|
| Which got me to question why Marvell lost the battle to Ampere.
| Veedrac wrote:
| *Arm
|
| Subtle but significant difference. The company is sentence case
| now.
| lowbloodsugar wrote:
| And the logo is "arm"! WTF!
| api wrote:
| I hereby declare that the coming ARM core wars will be termed
| "ARM wrestling."
|
| Please, please, hold the applause...
| Teongot wrote:
| If all the companies doing custom AArch64 microarchitectures had
| spent the effort building systems around ARM's designs instead,
| we'd probably have a thriving ARM server ecosystem by now.
| gsnedders wrote:
| Most of the custom AArch64 implementations are only semi-
| custom; they're mostly just derivatives of the ARM designs. The
| AWS Graviton chips are some of the few that are just using the
| ARM designs.
|
| I don't think it's the wrong option for most of these
| companies; the ARM designs are really designed with a bit too
| much of a focus on power consumption and die area for server
| applications. The Neoverse V1 is the first ARM design really
| targeted at that market, and is shipping late this year AIUI.
| (That said, the Neoverse N2 is shipping not much later, and is
| a generation newer design, so we might end up with more N2 than
| V1, despite the V1 being a higher end part.)
| StreamBright wrote:
| What does this mean from the software support point of view? Do
| we need a new target architecture in compilers?
| emteycz wrote:
| The ISA remains the same. This is one level down, how the CPU
| itself works - ISA instructions are turned to micro
| instructions.
| wyldfire wrote:
| Microarchitectures are used in -mtune= so there's an
| opportunity to tweak compilers to suit this design. But no
| changes are required: Aarch64 support is already present in
| popular compilers.
| mhh__ wrote:
| Target no(technically yes depending on what features it
| implements etc.), set of tuning parameters yes.
| baybal2 wrote:
| Important note X-Gene already used own cores long time ago, so
| it's non-news.
|
| They also had two from-scratch developed microarchitectures.
| floatboth wrote:
| Well, the first Ampere product (eMAG) was based on the last
| X-Gene, and it was way behind contemporary Cortex/Neoverse
| cores. It is news that they took the time and effort to
| continue with custom uarch development, that they have
| confidence in the ability to make a good one.
| IanCutress wrote:
| Ampere were all in with N1, and it seemed that they'd stay with
| the Neoverse ecosystem for several generations. Everything
| coming out of them contact wise was very much Neoverse related,
| so for them to get up and say that they're ditching Neoverse
| after one generation is big news. Still SBSA compliant, but big
| news. Renee and Atiq brought over a lot of Intel SoC designers
| when they left.
| throwaway4good wrote:
| But still using ARM ISA?
| varispeed wrote:
| ISA is like API. I don't think you can copyright that, so it
| would make sense if they did it this way.
| mhh__ wrote:
| Yes you can.
|
| I don't think you can patent trivial details of "API" but you
| can absolutely patent a given function of an ISA.
|
| You probably shouldn't be able to (Alpha vs. MIPS, x86 etc.)
| but currently you can.
| robert_foss wrote:
| Ampere probably has an Arm architecture license, which grants
| them the ability to change Arm designs and use their ISA.
| liaukovv wrote:
| That's the question I have as well, but since microarchitecture
| is in large parts dictated by isa how custom it can really be?
| On the other hand custom isa would require rolling the entire
| software stack, which is a complete non-starter. Really weird
| article and announcement
| ajb wrote:
| "microarchitecture is in large parts dictated by isa "
|
| This is very much not the case. Just consider that, for
| example, Intel still supports running the same ISA that ran
| on 8086. The microarchitecture now running those instructions
| isn't at all like the 8086 microarchitecture. (Its running a
| bunch of other instructions too, but the points stands)
|
| An example in the reverse direction, is that a some MIPS chip
| teams saw that MIPS was dying, and reused their MIPS
| microarchitectural designs to build ARM processors.
|
| Sure, ISA can be designed assuming some things about
| microarchitecture, and then it can be inconvenient to change
| it. But not impossible. And during the transition to ARM64,
| ARM took the opportunity to remove things that were
| inconvenient for different microarchitectures (eg, directly
| accessible PC reg, changes to how condition codes work, etc)
| mhh__ wrote:
| CPU design isn't like software. A microarchitecture is some
| you _design_ rather than adding features in a software-like
| manner, there is an enormous scope for design choices within
| a given ISA.
|
| And using a custom uarch is also a statement to your
| customers, shareholders, competitors etc. that you mean
| business rather than just going the well-trodden path with
| ARM cores.
| jholman wrote:
| I'm not disagreeing with either of your paragraphs, they're
| both correct... but the thing to note is that, to some
| degree, they argue in _opposite directions_.
|
| That's because a consequence of the second paragraph is
| that it's potentially business-profitable to make a "custom
| uarch" even if you make no use of the enormous scope for
| design changes.
| mhh__ wrote:
| I'm not sure what you mean.
| jholman wrote:
| ON THE ONE HAND.....
|
| The comment you replied to said "with a given ISA, how
| custom can the uarch be", implying that it would not be
| very custom.
|
| You replied, in your first paragraph, that on the
| contrary, it _could_ be pretty custom, with the
| implication being that it probably _would_ be, because
| that 's the value proposition that Ampere is presumably
| offering.
|
| So your paragraph 1 is suggesting that the sentence
| "Ampere will now use a custom uarch" is an argument that
| Ampere's custom arch might well be pretty highly
| customized.
|
| ON THE OTHER HAND....
|
| Your second paragraph points out that simply being custom
| is a social signal (the signal of being, in your words,
| "that you mean business rather than just going the well-
| trodden path"). You argue (and I agree) that this social
| signal might make you more attractive to some customers.
| I.e. the signal might increase sales. This implies that
| it would be reasonable for Ampere to spend a certain
| amount on a barely-custom custom uarch, purely for
| sales/marketting reasons, as long as it didn't
| substantially harm performance. You know, because of the
| _implication_.
|
| So your paragraph 2 is suggesting that the sentence
| "Ampere will now use a custom uarch" is NOT an argument
| that Ampere's custom arch has any particular need to be
| highly customized.
| quanticle wrote:
| >but since microarchitecture is in large parts dictated by
| ISA
|
| Well, Apple uses the ARM ISA for their A and M series chips,
| and but not ARM's microarchitecture, and their chips have
| significantly higher IPC than comparable parts from Qualcomm
| or Samsung. Similarly, Intel and AMD both implement the same
| x86 ISA, but the performance advantage has swung repeatedly
| between the two. Microarchitecture might be "in large parts"
| dictated by the ISA, but there's still enough left over for
| hardware designers to have a significant influence on the
| overall performance.
| snvzz wrote:
| >but since microarchitecture is in large parts dictated by
| isa
|
| Refer to RISC-V unprivileged spec, chapter one. Not dictating
| microarchitecture is one of its goals.
| andrewcchen wrote:
| Yes, custom cores in the sense of what apple does.
| karamanolev wrote:
| Yes: "the fact that Ampere continues to use the Arm
| architecture is a further encouragement and win for the Arm
| ecosystem".
|
| Personal take: it would be the end of them if they weren't.
| throwaway4good wrote:
| So much for RISC-V then.
| Pet_Ant wrote:
| Could a chip have two ISAs? If instruction decoding is as
| minimal as Intel makes it out to be, then it should be able
| to have two ISAs translating to the same microarchitecture,
| non?
| toast0 wrote:
| Definitely. Some ARM processors can switch between ARM
| and Thumb mode for example, and I think I've seen it on
| different types as well, but not 100% on details; IIRC
| things like chips that were compatible with 6502 or
| similar, but had a native mode with more capabilities and
| a different instruction set.
|
| Of course, it helps if the ISAs are at least broadly
| similar in terms of register space and available
| operations and memory ordering specifications. And the
| performance is in the details.
| throwaway4good wrote:
| Sure. Probably not always practical. But why not? You
| could also do just in time translation at the os level.
| cesarb wrote:
| The ISA affects more than just the instruction decoder.
| For instance, x86 has partial register writes and TSO
| memory ordering; RISC-V does not have a condition code
| register, and has some special rules for the division
| operation; and so on.
|
| However, RISC-V is so minimal that it might be possible
| to add it as a second ISA to a chip without much effort.
| On the other hand, it's so minimal that a JIT translator
| from RISC-V to the native ISA can be a valid alternative
| (see for instance
| https://carrv.github.io/2017/papers/clark-
| rv8-carrv2017.pdf).
| liaukovv wrote:
| Maybe risc-v will take current place of arm with arm taking
| over x86's segment of the market? Risc-v being open would
| be a real boon for low cost embedded chips
| mhh__ wrote:
| The only companies I can think of that could really make it
| would probably be Apple (because they have an iron grip
| over that platform) or Intel (because they actually have
| good software unlike almost all of their competitors, which
| could make the migration easier) - Apple are happy with ARM
| and Intel are probably terrified after what happened with
| Itanium. Any move to RISC-V will probably either happen in
| China or incrementally.
| e3bc54b2 wrote:
| I once read on HN that Apple gets ARM ISA and designs for
| free by virtue of being a founder. So the closed
| proprietary nature isn't enough for them to move to RISC
| V.
|
| I'm not sure that's true though..
| ksec wrote:
| >I once read on HN that Apple gets ARM ISA and designs
| for free by virtue of being a founder.
|
| I can bet $100 on it being wrong. Especially the ARMv8 (
| and v9 )
| philistine wrote:
| They probably have a very generous, very old contract by
| virtue of being the first third-party to use ARM in a
| device. But we won't know the specifics unless there's a
| court case that touches that relationship.
|
| With the way Apple operates, we have ten years before we
| can reasonably assume that they would change their
| architecture. Is RISC-V really going to be worth all the
| headaches of a transition in ten years?
| mpweiher wrote:
| As previous posters have pointed out, Apple is not a
| third party.
|
| "The company was founded in November 1990 as Advanced
| RISC Machines Ltd and structured as a joint venture
| between Acorn Computers, Apple Computer (now Apple Inc.)
| and VLSI Technology."
|
| https://en.wikipedia.org/wiki/Arm_Ltd.#Founding
|
| More details about ARM licensing:
|
| "Finally at the top of the pyramid is an ARM architecture
| license. Marvell, Apple and Qualcomm are some examples of
| the 15 companies that have this license."
|
| https://www.anandtech.com/show/7112/the-arm-diaries-
| part-1-h...
| moosebear847 wrote:
| Why is it that treating collective nouns (e.g. Apple) as
| plural has a tendency to trigger an irrational negative
| emotional response for me? What's even weirder is that I
| used to think that made more sense and used it too, until
| convention in American society changed my thinking to
| flip to singular.
| mumblemumble wrote:
| The English-language grammar concerning pronouns and
| subject-verb agreement is something that shows a lot of
| regional variation. In the variety I grew up speaking,
| whether you use the singular or plural depends on both
| the part of speech of the word you're inflecting, and the
| specific collective noun you're trying to agree with.
| It's a complicated enough set of conventions that I
| wouldn't necessarily expect anyone who didn't grow up in
| the same region as me to be able to follow them
| precisely.
|
| Long story short, it's probably not terribly utilitarian
| to have strong opinions about the subject when
| participating in an international forum such as this one.
| TheMagicHorsey wrote:
| Geopolitics has ensured that RISC-V will be relevant for
| the foreseeable future. China, Russia, Iran ... and any
| other country that doesn't want to be locked out of
| computing by an American embargo, are doubling down on
| RISCV development. In Russia's case its mostly military
| hardware applications. In Iran's case its just software.
| But in China's case its heavily funding projects to bring
| commercial products to market to replace US-controlled IP
| on everything from mobile phones to desktop workstations.
| It will take ten years for these projects to see fruition,
| but the Chinese state is pouring state-actor level funds
| into the project through multiple different private and
| public entities.
|
| It's good news for open source hardware development. But
| bad news for USA and for people with security concerns. I
| don't know how comfortable I'd be with a Chinese designed
| CPU, Chinese compilers, and a Chinese kernel ... even if
| they were all open source.
| lucian1900 wrote:
| How comfortable do you think the rest of us are with US-
| designed CPUs and software? I'll take the country that
| hasn't invaded and is still occupying much of the world,
| I think.
| Tuna-Fish wrote:
| RISC-V is amazing as what it is, but it isn't a competitor
| for high-end performance. It's simply not designed for
| that.
| nickik wrote:
| That's simply wrong. RISC-V is explicitly designed to
| enable high-end performance. That was literally one of
| their goals. Of course with the necessary extensions but
| that is the case on all ISA.
| tyingq wrote:
| The original paper with the goals: https://www2.eecs.berk
| eley.edu/Pubs/TechRpts/2011/EECS-2011-...
| snvzz wrote:
| Please also link the current version[0], so that people
| can see whether the goals have changed.
|
| [0] https://riscv.org/technical/specifications/
|
| (start with chapter 1 of the unprivileged spec)
| throwaway4good wrote:
| They could have gone for the license free instruction set
| of RISC-V + extensions instead of continueing to pay for
| ARM.
|
| Just shows the power of an establed ISA (all the software
| that runs on top of it) and how solid ARM's business
| model is.
| loup-vaillant wrote:
| Something I don't understand here: do we really have to
| pay ARM for their _instruction set_? Does AMD pays Intel
| a fee for using x86? Does Intel pay AMD a fee for using
| their 64 bit extensions? Does anybody pay the inventor of
| the SSE and AVX instruction sets? Does anybody pays
| Nintendo for deploying emulators?
|
| The ISA is an interface, and as such may not be
| copyrightable or even patentable. Even if it was, we've
| had various interoperability exceptions, and one does
| need an ARM ISA to run a program compiled for ARM.
|
| Besides, as far as I know ARM doesn't just license the
| ISA. It licenses _cores_. There 's a good chance that if
| you make your own cores to implement an ARM ISA, you
| wouldn't have to pay any fee. You may however have to get
| around trademark, and not call your CPUs "ARM CPUs".
| Though I suspect "ARM compatible" would work perfectly
| (just like "IBM compatible" worked with third party PC
| vendors).
| toast0 wrote:
| > Does AMD pays Intel a fee for using x86?
|
| The terms are secret, but basically yes, AMD had access
| to 386? designs and what not as part of IBMs second
| source requirements with Intel, but Amd486 and up designs
| were AMD original with instruction sets under license
| from Intel, although the licenses were set up after
| release under litigation.
|
| > Does Intel pay AMD a fee for using their 64 bit
| extensions?
|
| Yes / sort of. Use of the AMD64 extentions was negotiated
| under the broad cross licensing between the two
| companies.
|
| > Does anybody pay the inventor of the SSE and AVX
| instruction sets?
|
| Do the persons involved get royalties? I'd guess not, but
| who knows. Would you have to pay more to get a license
| for them, almost certainly.
|
| You'll note there's been a lot fewer x86 processor
| designs not from the big two over the past many years
| than there were in the late 90s. Some of that is because
| 'RISC is going to change everything', but a lot of it is
| becsause nobody can get an x86 license.
|
| > Does anybody pays Nintendo for deploying emulators?
|
| I don't think so. Patents are too old, and there's not a
| whole lot of non-Nintendo emulation in the commercial
| market (but I know Capcom has released some collections,
| of Megaman games, etc). If those types of releases
| started including systems with system roms, then you
| would start having copyright claims.
|
| Nintendo has never seriously impeded system emulation;
| there's just no case to be made. ROM distribution is
| clear copyright violation though, of course.
| Grazester wrote:
| Emulators if they are non pattern infringing then no
| license are needed. See Sony vs Bleem
| dageshi wrote:
| AMD did or does pay for an x86 license, I think to intel?
| Pet_Ant wrote:
| I believe the situation is that they both have relevant
| patents, especially since AMD went 64 bit, and so they
| cross-license to each other and call it even.
| [deleted]
| bluGill wrote:
| Even if you don't have to legally, you want to because
| those license fees are how the money for the next ISA
| version are made. It is a prisoners delimma situation
| where nobody has defected.
| whazor wrote:
| RISC-V is ideal to build around a custom ASIC and could
| be used for high-end performance stuff, just very
| specific performance stuff.
| audunw wrote:
| > It's simply not designed for that.
|
| I don't agree with that. The base ISA is highly optimised
| for high performance. Many of the decisions made are
| precisely because it makes it easier to design very wide
| superscalar CPUs. The vector extension is also looking
| like it'll be more efficient than ARMs.
|
| What's missing, is instruction set extensions that makes
| it comparable to ARM/x86 across all workloads. And
| obviously it's far less mature in general.
| adrian_b wrote:
| Sorry, RISC-V is not a bad ISA, but saying that it "is
| highly optimised for high performance" is extremely far
| from the truth.
|
| RISC-V has been optimized for a single-purpose, being as
| simple as possible to be easily taught to students and
| implemented by them in a limited time.
|
| It lacks many features required for high performance
| without hardware of excessive complexity, the most
| obvious being that RISC-V does not have decent addressing
| modes, so that the highest performance implementation
| reported until now (by Alibaba at the 2020 Hot Chips
| Conference) had to add a non-standard ISA extension to
| correct this.
|
| Nobody remotely competent chooses RISC-V for "high
| performance" in any definition of that term.
|
| RISC-V can be the right choice in many cases because:
|
| 1. No costs for using the RISC-V ISA
|
| 2. Easy customization with non-standard extensions
|
| 3. An already existing complete software development
| environment, with compilers, debuggers etc.
|
| 4. Acceptable performance at a given implementation cost
|
| There is no need to invent extra fictitious advantages,
| like "high performance".
| userbinator wrote:
| In other words, it's basically closer to a replacement
| for MIPS, which is already everywhere in a lot of
| embedded devices (and arguably not "high performance"
| ones --- the cheapest tablets and smartphones use MIPS.)
| hajile wrote:
| > It lacks many features required for high performance
| without hardware of excessive complexity, the most
| obvious being that RISC-V does not have decent addressing
| modes, so that the highest performance implementation
| reported until now (by Alibaba at the 2020 Hot Chips
| Conference) had to add a non-standard ISA extension to
| correct this.
|
| Do you have any proof that additional addressing modes
| would increase performance? What I remember from college
| and papers I've read is that more modes are generally a
| detriment to pipelining.
|
| Maybe you're talking about "needing more instructions".
| You'd be wrong in this case. Using the compact
| instruction set gives an average of 15% more dense code
| compared to x86 and somewhere around 25-35% more dense
| compared to aarch64 (about equivalent density to thumb,
| but without the switching overhead that makes thumb
| slow).
| acidbaseextract wrote:
| https://conferences.computer.org/isca/pdfs/ISCA2020-4QlDe
| gUf...
|
| "Xuantie-910: A Commercial Multi-Core 12-Stage Pipeline
| Out-of-Order 64-bit High Performance RISC-V Processor
| with Vector Extension"
|
| From "VIII. NON-STANDARD INSTRUCTION SET EXTENSION"
|
| _Targeting at various industrial applications, XT-910
| enables a set of custom non-standard instructions,
| additional to the standard RISC-V instructions. The non-
| standard instruction extension can be categorized into
| two groups based on the purposes - memory access
| enhancement, and basic arithmetic operation enhancement.
|
| A. Memory access enhancement
|
| Memory access instructions usually account for a high
| proportion in the total number of instructions, so
| enhancing memory access instructions can directly benefit
| the overall performance. By analyzing the mainstream
| applications running on RISC-V, we observed that for the
| basic RISC-V instructions there is still quite some room
| for improvement in memory access related instructions.
|
| First, we support register + register addressing mode,
| and support indexed load and store instructions. This
| type of instruction extension reduces the usage of the
| registers for calculation and reduces the number of
| instructions for address generation, thereby effectively
| accelerating the data access of a loop body. Second,
| unsigned extension during address generation is
| supported. Otherwise, the basic instruction set does not
| support direct unsigned extension from 32-bit data to
| 64-bit data, resulting in too many shift instructions._
|
| I'm not certain if they break out the results by
| individual optimization, but in Fig. 20 in the paper it
| looks like all their tweaks add up to a 20% boost over
| the standard RISC-V ISA. Pretty huge.
| s-macke wrote:
| RISC-V is first and foremost an instruction set
| architecture. Like all architectures it has a few
| weaknesses. But if you spend enough money, there is no
| reason for RISC-V not to be a competitor in the high-end
| performance segment.
| solarkraft wrote:
| Yet?
|
| I know virtually nothing about the internals, but that's
| also what people said about ARM.
| snvzz wrote:
| This is a load of bull, and it can be readily dismissed
| after reading the first pace of the unprivileged spec[0].
|
| As a practical counterexample to that FUD, it is also the
| ISA chosen by the Barcelona Super-computing Center
| EuroHPC[1] to design a new high performance CPU for
| future supercomputers.
|
| [0]https://riscv.org/technical/specifications/
|
| [1]https://www.bsc.es/news/bsc-news/bsc-working-towards-
| the-fir...
| einpoklum wrote:
| Can you link to an explanation of why that is?
| mhh__ wrote:
| If X86 still competes I see no reason why RISC-V can't
| also
| pjmlp wrote:
| RISC-V doesn't have 40 years of ecosystem.
| mhh__ wrote:
| > but it isn't a competitor for high-end performance.
| It's simply not designed for that.
| pjmlp wrote:
| x86 owns most high-end performace systems, still fail to
| see the relation of the statement.
|
| > If X86 still competes I see no reason why RISC-V can't
| also
|
| First RISC-V needs to catch up with the 40 years of x86
| improvements that kicked out SPARC, Cray, SGI and others
| from high-end performace systems.
| mhh__ wrote:
| What is RISC-V? It's an ISA not a microarchitecture. If
| you can make x86 fast you can make RISC-V fast
| toast0 wrote:
| Sure, you can make anything fast, but the question is
| will it take 40 years of a lot of work, and if so, where
| will x86 and ARM be when you get there?
|
| I'd suspect an ISA designed in the last few years with
| performance in mind (even if not a priority), wouldn't
| take as long to get to where the industry is now, but
| it's still a lot of years of focused effort required, and
| we'll see.
|
| I don't have a horse in the race, except that I do like
| my experience to not evaporate; and I sincerly hope real
| mode segmented address edge cases aren't something I'd
| need to relearn on another ISA even though they're still
| (barely) relevant on x86 in early boot.
| mhh__ wrote:
| The point is that you can make it fast more easily.
| Decoding x86 instructions in parallel efficiently is
| taxing, whereas with ARM and RISC-V it's much more
| tractable for example.
|
| Saying X86 is 40 years work is also kind of stupid, as a
| huge amount of the ISA dead weight, and high performance
| implementations have their roots much earlier than that
| (e.g. Intel have tried to move on at least once and ended
| up coming back to the OOO superscalar paradigm).
| pjmlp wrote:
| As stupid as it may be, it is 40 years of tooling,
| libraries and languages.
| p_l wrote:
| Alibaba is working hard on high-end RISC-V cpus.
|
| Generally, for RISC-V, look to China it seems?
| cmrdporcupine wrote:
| RISC-V's play won't be in the desktop or server market but
| in the absolutely huge embedded devices market. A place
| where the licensing cost on an ARM core can actually
| contribute significantly to the BOM. Or where having the
| ability to roll ones own ISA extensions can have a
| significant win. Or where the politics of licensing a core
| from a corporation HQ'd in a geopolitical rival means
| something.
| alkonaut wrote:
| What does their predictable performance bullet point with "128
| cores at consistent frequency" mean? That 128 cores would run at
| the same frequency?
| viraptor wrote:
| Something related to being able to go full speed without
| thermal throttling / instruction side effects? I.e. You know
| what the consistent performance ceiling is, and it won't drop
| just because you started using avx512 instructions on a nearby
| core?
| alkonaut wrote:
| Not having some instructions be a noisy neighbor is a good
| idea. But it seems wasteful to cap 128 cores at the power
| output possible if _all_ cores have that output (if that 's
| what it is).
|
| Assuming the default mode of operation is having just a few
| cores operating at 100% with the majority running at 0%, it's
| wasteful to not let those active cores run as fast as
| possible.
| jholman wrote:
| Why would the default mode of operation for a 128-core
| datacenter chip be to have 120 idle cores?
|
| Obviously the default mode of operation is to run all
| cores, or very nearly all cores, at full tilt all of the
| time. This chip is designed to be garbage at few-threaded
| workloads.
| em500 wrote:
| Indeed. For cloud vendors, a large part of the business
| model is to resell/oversell idle CPU time as much as they
| can ("vCPU"), taking advantage of the fact that
| small/individual clients are usually extremely over-
| provisioned CPU-wise.
| alkonaut wrote:
| That depends on the workload? For HPC it's easy, for
| other loads like DBs or VMs it's harder, especially with
| fewer nodes (e.g a single node running 32 VMs with
| dedicated cores will probably look a lot like a desktop
| workload with lots of idle cores). I suppose it's going
| to be rare to see these in deployments with fewer than
| several dozen sockets, and workloads must be balanced (so
| e.g not using dedicated VM cores).
|
| That's I suppose a simplification they can make by
| focusing only on "datacenter" while intel needs the same
| design to work from 1 socket to hundreds.
| viraptor wrote:
| Depends what your use case is. HPC for example wants
| predictable performance with every pipeline filled as much
| as possible - there won't be idle cores. The average
| performance is more important than bursts there. That's one
| of the reasons hyperthreading is universally disabled in
| HPC clusters.
| walrus01 wrote:
| I realize it's probably targeted at hyperscale "cloud" stuff, but
| when their previous CPU was announced, I took a good long and
| hard look at what it would take to actually buy and use it.
| Unlike being able to buy a $650 Supermicro, MSI or Tyan dual
| socket motherboard and put your choice of a couple of Intel or
| AMD CPUs on it, it turned out that it was unavailable for mere
| mortals to purchase at any reasonable price.
|
| My message for people trying to make "ARM Server" CPUs a thing is
| that you have a real chicken or egg problem to solve, getting
| these things into the hands of people doing Linux development on
| x86-64 right now. Without a robust ecosystem of all the Taiwan-
| based motherboard manufacturers behind you, it's never going to
| get more than a few percent market share.
| mcqueenjordan wrote:
| Same. I'd love to throw together one or two 1U servers with an
| Ampere chip, but I could not find a single way to buy one.
| walrus01 wrote:
| This is exactly the same thing that happened several years
| prior to Ampere, with other "ARM Server" CPU vendor
| offerings. I thing it turned out that the only thing I could
| purchase was a $3000 cpu and motherboard kit that were
| significantly slower and weaker than a $350 core i7 on a $120
| motherboard (at the time, this was at least 3.5 to 4 years
| ago).
| lowbloodsugar wrote:
| I feel like you think that theres only two markets: "hyperscale
| cloud stuff" and colocation. Sure, nobody can drop $1000 on an
| ARM server and stick in 1U at their local colo. Do you want to?
| Is that what is fun for you? Or is it more about physical
| ownership?
|
| When I first started developing on AWS, I bought the company a
| beefy server so we could run virtual machines on it to "test it
| locally". We bought a dual socket supermicro board and put our
| choice of Intel Xeons on it. It ended up being north of $2000
| (ten+ years ago). At the time AWS c1.xlarge were $0.80 per
| hour. Paying per hour just felt wrong. And then, within a few
| months, we had a working system, and we were running 250
| c1.xlarge for hours on end, and charging 50x for the end
| result. The $2000 machine sat idle and was a total waste of
| money. We developed on our local machines (a Mac), and deployed
| to test machines on AWS.
|
| Now I pay some hosting company $x per month to host my eldest's
| minecraft server. I don't want to manage that shit! I have
| money but not time, and I use my time effectively. That means I
| don't waste my time buying and configuring servers.
| wmf wrote:
| https://store.avantek.co.uk/ampere-altra-64bit-arm-workstati...
|
| It's available but as you said, not at any reasonable price.
| The motherboard alone seems to be $5,000.
| chrischen wrote:
| Most devs are using mac, and all future macs are now Arm. I
| deploy to linux and develop on such an ARM mac, and I've
| already converted pretty much all my toolchain to ARM. Now
| choosing ARM is just a matter of telling Docker buildx to build
| for ARM.
| LargoLasskhyfv wrote:
| I think you mistake marketshare with mindshare. The devs can
| play with Raspberry Pies or similar, because why not, it runs
| AARCH64, don't it? The few devs who really need deep system
| level access are either paid, or get devkits. Meanwhile, 'the
| market' _IS_ the hyperscalers. Nobody cares about the few nerds
| wetting themselves. They can go gaming, obsess over
| retrocomputing, toolkits, theming, /r/unixporn, whatever.
| imtringued wrote:
| >Nobody cares about the few nerds wetting themselves. They
| can go gaming, obsess over retrocomputing, toolkits, theming,
| /r/unixporn, whatever.
|
| The problem with this stance is that they can also keep using
| the non elitist platform, considering the elitist platform is
| inferior for many use cases.
| LargoLasskhyfv wrote:
| And thereby banging rocks against each other into eternity.
|
| No sparks...
| selfhoster11 wrote:
| Nerd mindshare eventually converts to some marketshare. Adobe
| has been lax on their enforcement of their software among
| non-professional market segments for this exact reason.
| tomc1985 wrote:
| Nerds wetting themselves built the world that business stole
| from them
| [deleted]
| petre wrote:
| Remember alpha and sparc? Their parent companies targeted the
| enterprise market as well.
| KingOfCoders wrote:
| I do think getting it in the hand of more people, more people
| will run it and say "yes, works" and then take it into
| consideration when making architecture/purchasing decisions.
|
| I've been a CTO for a decade+ and did try to get one the last
| time they made a splash.
| LargoLasskhyfv wrote:
| That could be remedied by giving affordable or even free
| evalution accesss in 'the cloud'.
| vngzs wrote:
| You can get ARM desktops now at non-crazy prices. The neat
| thing about them is they are 32/48 core CPUs at consumer-
| available prices[0]. Sure, they're on the high end, but it's
| around the cost of a workstation that one might use for, e.g.,
| kernel development.
|
| I'm not affiliated with Avantek in any way. I just did a bunch
| of research looking to build/buy a desktop, and ARM was a
| contender, but I ended up building a beefy x86 machine with a
| Ryzen instead.
|
| [0]: https://store.avantek.co.uk/arm-desktops.html
| raesene9 wrote:
| At $2818 for the barebones, I think they've got some work to
| do yet to be affordable for hobbyists, but nice to see some
| progress :)
| Quequau wrote:
| Years ago I read an interview with one of Intel's upper
| managers for the Itanium product line and when he listed off
| the various reasons it was not successful the top of the list
| was the lack of availability to those people actually doing the
| work of Linux & compiler development having very expensive and
| unplanned consequences.
| NextHendrix wrote:
| That sounds interesting, do you have a link for it?
| sharpneli wrote:
| Reminds me of the AMD ARM server boards, that happened way
| after Itanium and they still repeated the exact same mistake.
|
| Basically there was no way of getting your hands on them.
| They were interested only in "Serious customers".
| Quequau wrote:
| I presume that the performance segment that Itanium was
| intended for is Intel's most profitable. So everyone who
| proposes to make server chips targets that segment, pretty
| much to the exclusion of everything else.
|
| Having seen this play out a number of times I don't think
| targetting that segment and only that segment is a great
| idea.
| ethbr0 wrote:
| I'm convinced sales forecasters don't actually understand
| how software ecosystems work.
|
| From a stack perspective, you can't really go it alone
| anymore. The total necessary software universe is too
| large to rebuild on a reasonable timescale, and too
| expensive to rebuild by oneself.
|
| IBM is about the smallest scale that can do this -- and
| even they're leveraging decades of effort.
| dralley wrote:
| Although IBM is doing it x2, with s390x and also with
| POWER.
| oblio wrote:
| IBM and Apple. Which makes Apple's Big Brother ad even
| funnier.
| mumblemumble wrote:
| I see this happen with software projects, too. For example,
| I'm pretty sure that this same phenomenon is the main thing
| that killed Smalltalk.
| PaulHoule wrote:
| If the market for something is already established it makes
| sense to stick to "serious customers".
|
| If the market isn't established then you may need to get
| traction with the dreamers and misfits.
| kps wrote:
| 'Unplanned' only because Intel learned absolutely nothing
| from the i860. Amazing performance on a hardware spec sheet,
| while real programs could never gain the benefit and only
| paid for the complexity.
| jeroenhd wrote:
| I don't know if getting Itanium to more people would've saved
| the platform because of their architecture. The first models
| had trouble with their memory performance, which was fixed in
| hardware. The compiler also needed to watch the instructions
| it outputted, as not putting out the right combination of
| instructions in order would leave CPU hardware underutilized.
| Instructions were very wide, causing more frequent cache
| misses as the cache was full of instructions that were
| shorter in other architectures. Furthermore, the compiler
| needed to emit certain hints for the branch predictor and
| other speculative execution units to function well.
|
| I think the lack of availability certainly didn't help, but
| the architecture itself was probably the biggest downfall of
| the IA-64 platform. When it was introduced, the hardware was
| certainly advanced, but relied too much on software to get
| proper performance out of the chips. The product was doomed
| from the start.
|
| Ampere will likely have entirely different problems bringing
| their architecture into the market, but I don't think Itanium
| ever stood a chance even if they'd sent out free chips to as
| many influential people and companies as possible.
| hajile wrote:
| Later Itanium chips literally went right back to the
| "hardware JIT" (speculation, OOO, etc) they were trying to
| get away from in order to increase performance.
|
| If Itanic had won, we'd still be basically where we are
| today from a hardware perspective, but with even less
| competition.
| acdha wrote:
| There were many reasons why it failed but I think the
| combination of these two was more synergistic than it
| seems. Itanium's designers made some very dubious
| assumptions about the kind of code they needed to run
| (businesses buy branchy code, not hand-tuned SPEC
| benchmarks) but then the systems cost considerably more
| than the earlier predictions _and_ almost everything was
| much slower than predicted because few developers had
| access to a system to tune it and the best compilers were
| not free.
|
| The architecture was probably a fatal mistake on its own
| (even if Intel had disbanded its x86 line, the "older" RISC
| processors outperformed, often substantially) but ensuring
| that almost nobody saw anything close to what performance
| it could deliver definitely made it fatal. If Intel hadn't
| been greedy trying to charge for compilers, the gap
| wouldn't have been nearly as bad.
| twic wrote:
| > the best compilers were not free
|
| This must have been a huge part. Maybe ICC could squeeze
| more MIPS per dollar out of Itanium than x86, but if GCC
| can't, people are going to not buy Itanium rather than
| buy ICC.
| acdha wrote:
| It was especially hard because compatibility was not a
| given and proprietary compilers of that era were
| notorious for having both compatibility issues and
| fragile optimizations where seemingly minor code changes
| had large performance impacts, especially when they'd
| basically targeted one SPEC benchmark. I saw multiple
| times where teams switched to GCC for
| compatibility/features and the performance impact on most
| other platforms was relatively modest.
| lmm wrote:
| > The compiler also needed to watch the instructions it
| outputted, as not putting out the right combination of
| instructions in order would leave CPU hardware
| underutilized. Instructions were very wide, causing more
| frequent cache misses as the cache was full of instructions
| that were shorter in other architectures. Furthermore, the
| compiler needed to emit certain hints for the branch
| predictor and other speculative execution units to function
| well.
|
| I think that's the kind of issue they're talking about. If
| it had been easier for nerds in bedrooms to run Itanium,
| we'd've seen much better support for it in GCC etc. much
| sooner.
| acdha wrote:
| I don't disagree with your comment but I think "nerds in
| bedrooms" is possibly what works for tuning a particular
| open source project. GCC and other popular open source
| projects should have been a room full of Intel engineers
| because it's a hard problem and their revenue from their
| proprietary compiler & libraries was a tiny rounding
| error of the amount they spent building Itanium.
|
| Back when I supported computational scientists, the total
| cost of the servers + compilers was so steep that even if
| everything had worked as well as the Itanium salespeople
| promised it would have needed to be many times faster to
| be worth the hassle of changing toolchains, especially
| since you had to pay up front for the hope that with a
| fair amount of work you'd at least hit the point of
| breaking even.
| p2t2p wrote:
| In the end of the day it will be Apple disrupting x86 on
| servers. I already can run all my work related stuff natively
| on M1. There's JDK, Node is here as well, ones lots of devs
| have M1 on their desktops it will only make sense to run
| aarch64 on servers as well.
| matwood wrote:
| > In the end of the day it will be Apple disrupting x86 on
| servers.
|
| Apple made it happen on the client, but Amazon is making it
| happen on the server. The people who want to run their own
| DCs or hardware will end up part of the niche left on x86. I
| don't see Apple doing anything in the server space beyond
| providing minis like they do now.
| PixelOfDeath wrote:
| iServer with 64 cores and 128 GiB DDR4 for only $
| 399,999.95
|
| iServer with 64 cores and 256 GiB DDR4 for only $
| 699,999.95
| hestefisk wrote:
| Remember Xscale, anyone?
| kingsuper20 wrote:
| I got to use an Intel XScale in a product once. I never
| did see the point of it's choice.
| geerlingguy wrote:
| Xserve
| hestefisk wrote:
| Sorry you are right. Xscale was an Intel cpu :)
| Krustopolis wrote:
| And one with an ARM instruction set at that!
| acdha wrote:
| Do you think a lazy troll is contributing to the
| conversation? You could look at Apple's old XServe
| pricing to see how much markup they historically had, or
| compare the current MacPro to equivalent workstations --
| it won't be 2 orders of magnitude, and based on what
| we've seen so far it's more like to be within the range
| of +-25%.
| dasloop wrote:
| They have the Mac Pro rack: 28 cores, 384 GiB DDR4 for
| only $19,699
|
| You are off by an order of magnitude :)
| antoinealb wrote:
| I think what's interesting is that having access to a good
| development platform (the M1 mac) might enable projects
| like Docker, Node or Linux to get up to speed on ARM
| earlier. The dev experience is really much better on a
| local machine than working through SSH on a server.
| matwood wrote:
| From my standpoint there isn't much else to speed up. I'm
| already running a bunch of workloads on AWS Graviton2.
| Having an m1 Mac did help a bit with testing, even though
| the final is running on ARM Linux. Which btw, Linux
| already runs on ARM just fine from what I've seen.
| zaphirplane wrote:
| I'm no expert in the area, there must be someone in Apple
| doing a profit analysis on selling server cpu even if the
| profit is tiny the economy of scale alone carries a benign
| bredren wrote:
| I'd expect Apple already has more than one proof-of-
| concept M1-based operational data centers.
|
| If they are to be commercialized, I'd expect them to be
| part of a development stack related to Xcode, or some
| kind of AWS like services for applications developed for
| the Apple ecosystem.
|
| Offering generalized compute would invite too much
| initial cost performance comparison and they couldn't
| keep up with demand.
| Someone wrote:
| https://www.idc.com/getdoc.jsp?containerId=prUS47529021
| says the server market is about 12 million servers in
| 2021. I don't think you can call that "economy of scale",
| compared to 200 million iPhones.
|
| (I'm not sure whether that includes servers at large
| cloud providers, but I don't think that matters. Unless
| there's a huge performance advantage, I don't see Amazon,
| Google or Microsoft buying Apple server CPUs)
| TradingPlaces wrote:
| Whatever goes in the Mac Pro will likely be as capable as
| x86 data center chips at a fraction of the power
| requirement. Whether they put it in a server is another
| question
| brobdingnagians wrote:
| I do admire how Apple did the M1 release. There was a lot of
| publicity with developers, good performance and solid roll-
| out with availability in everything, and it seems to be
| picking up steam. It seems obvious to everyone they are fully
| committed and that if you spend the time getting your
| software ready for it, then you will have a market. I'm not
| even interested in the Apple ecosystem and I am familiar with
| the major developments.
| DoomHotel wrote:
| RISC-V International's plan to give away 1,000 boards to
| developers seems like a good idea. I like some of the products
| I've seen but the cheap ones are just toys and the decent ones
| are way overpriced.
| carlhjerpe wrote:
| I hope those 1k boards end up in the right peoples hands,
| they could make all the difference or none of the difference
| depending on who gets them.
| ticviking wrote:
| Anecdotally, a guy in the Fedora project took a chance on
| giving a free OLPC laptop to a random education student in
| the middle of nowhere Utah. We met at a Panda Express in a
| strip mall. He helped me with some random problems I had on
| my ubuntu laptop and gave me a list of good resources to
| learn python.
|
| I never did deliver for the OLPC project, but I tested a
| lot of things other people were working on. I also finally
| grokked the free software idea and became and engineer
| instead of a history teacher.
|
| The $250 or so of prototype hardware has been repaid in
| testing, bug reporting other things I was able to do then.
| It sits on a shelf in my office to remind me how I got
| started, and what it mean to really be a part of a
| community that takes risks to invest in newcomers.
| chokeartist wrote:
| That's a very neat story. I have always loved the idea of
| paying things forward - investing in things or people in
| which you yourself do not see the direct return. Thanks
| for sharing.
| geodel wrote:
| Such a beautiful story!
| fbn79 wrote:
| I remember and interesting speech by Linus Torvalds about
| success of x86 and why is hard for AMD to break into servers
| that I think can be relevanto for Ampere too:
|
| "I can pretty much guarantee that as long as everybody does
| cross-development, the platform won't be all that stable. Or
| successful.
|
| Some people think that "the cloud" means that the instruction
| set doesn't matter. Develop at home, deploy in the cloud.
|
| That's bullshit. If you develop on x86, then you're going to
| want to deploy on x86, because you'll be able to run what you
| test "at home" (and by "at home" I don't mean literally in your
| home, but in your work environment).
|
| Which means that you'll happily pay a bit more for x86 cloud
| hosting, simply because it matches what you can test on your
| own local setup, and the errors you get will translate
| better...
|
| Which in turn means that cloud providers will end up making
| more money from their x86 side, which means that they'll
| prioritize it, and any ARM offerings will be secondary and
| probably relegated to the mindless dregs (maybe front-end,
| maybe just static html, that kind of stuff).
|
| Guys, do you really not understand why x86 took over the server
| market?
|
| It wasn't just all price. It was literally this "develop at
| home" issue. Thousands of small companies ended up having
| random small internal workloads where it was easy to just get a
| random whitebox PC and run some silly small thing on it
| yourself. Then as the workload expanded, it became a "real
| server". And then once that thing expanded, suddenly it made a
| whole lot of sense to let somebody else manage the hardware and
| hosting, and the cloud took over. (All emphasis original)"
| TheMagicHorsey wrote:
| I'm not sure I agree. Many customers are working at a level
| of abstraction where this objection is not relevant.
|
| For example, if I'm building on Firebase with Cloud Functions
| I'm so far abstracted from the underlying hardware that these
| architecture specific issues are less important.
|
| Similarly, if I'm working in Django/Python on AWS RDS, using
| an ARM server for my EC2 instance might be an issue ... but
| moving my RDS Postgres instance onto ARM might not make a
| difference.
| cmrdporcupine wrote:
| It's that way, and you're 100% right, until you hit the
| corner case performance bug that you can't track down and
| you spend hours trying to track down why some performance
| counter is incrementing monotonically on one platform but
| not on the other. Or why some highly threaded code has
| great throughput on your development workstation but falls
| down in production and it probably has something to do with
| differences in lock behaviour, etc.
| MonaroVXR wrote:
| This reminds me off that story on hackernews about
| getting that laptop in the datacenter, because they
| couldn't figure out why it was slower on the server.
| vlovich123 wrote:
| That's already true today. At work I have a 12 core
| laptop with 32gb of RAM. In the cloud is significantly
| more on all fronts. We encounter all the challenges you
| mention and still make it work (and yes, it's hard). That
| being said, I doubt anyone writing in a managed language
| or hitting the database will actually care. Databases
| that have defects on a certain architecture will have
| resources poured into finding and fixing the issue
| (although it's entirely possible there will be cloud
| lockin for those fixes if they aren't contributed back)
| MaxBarraclough wrote:
| > moving my RDS Postgres instance onto ARM might not make a
| difference
|
| I have no specific knowledge here but I imagine the x86-64
| builds are far better tested, regarding correctness. As
| cmrdporcupine points out, the performance of the x86-64
| builds will also have been better studied. Whether it's an
| issue in practice, I don't know, but if you're looking to
| minimize risk, there are good reasons to stick with x86-64.
| madeofpalk wrote:
| Most people are essentially developing fancy/overcomplicated
| wordpress themes. They're at an abstraction where
| architecture just isn't exposed to them directly, or as much.
|
| I can certainly imagine a 'serverless' platform like Lambda
| or something where running on ARM is just an implementation
| detail (if it's not already).
| salicideblock wrote:
| That is true, but it is also true that the WordPress and
| PHP running on that ARM lambda will not be as stable as the
| x86 lambda if the vast majority of _their_ developers only
| run x86 at home.
| madeofpalk wrote:
| ("overcomplicated wordpress themes" was just a dig at how
| a lot of business is just landing pages or essentially
| blogs)
| twic wrote:
| Linus knows what he knows, but he has some significant
| blindspots. Here, it's the existence of languages other than
| C. I think this argument basically doesn't apply to any
| interpreted or JITted language.
|
| I wouldn't be at all worried about deploying my Ruby, Python,
| or Java app on ARM, having worked with x86 locally.
|
| That is, as long as the Ruby, Python, and Java development
| teams themselves have been able to test on ARM hardware
| themselves!
| freedomben wrote:
| Ruby and Python both have significant parts of their
| implementation and libraries in C, so it's still a
| significant problem there.
|
| Java less so, but the behavior and performance
| characteristics are definitely different.
| tachyonbeam wrote:
| Definitely. A huge chunk of Python and Ruby packages are
| written as "C extensions", and if those C extensions are
| going to get compiled on some platform the developers
| haven't tested them on, it will make for fun surprise
| bugs.
|
| I know Java has C extensions for some things too. I'm
| curious how much code is actually "pure Java", but I've
| actually rarely seen Java used at any of the places I
| worked at.
| spamizbad wrote:
| One thing you might encounter is some C-binding building
| correctly on your machine but not in production (or vice-
| versa). Sure 99% of what you deploy is Python, Ruby, or
| JS... but that 1% in C/C++? Well.. you need that 1%.
| AdamN wrote:
| Even in Python, OS differences and architecture differences
| pop up between testing, staging, and prod. It's annoying
| and can definitely cause user-facing problems.
|
| With Python, some of the really useful libraries are
| written in C so you really need consistency between your
| environments if you don't want gotchas in your deployment
| pipelines.
| softfalcon wrote:
| Even if I'm using a JIT-ed product like C#/Java apps, I
| might still need to use OS-specific features that might
| differ from the ARM vs x86 flavour of Linux.
|
| I develop and test against docker containers that run on a
| specific image + arch + base OS.
|
| Even though my environment is supported on ARM, I am still
| not keen on using ARM servers even if I think it will work.
| There's just too much risk involved and I don't have the
| time to set it up and test it thoroughly.
| mumblemumble wrote:
| Kindasorta? Even higher level languages still rest atop the
| native code. For starters, someone's got to maintain the
| port of the interpreter or VM. It's going to get a lot more
| attention if developers are using it as their daily driver.
|
| And then there are all the other native and system packages
| that you depend on. For example, I do a lot of work in
| Python, and I would be very hesitant to have anything but
| an Intel CPU in my workstation. Because that's what our
| servers run, and I know that a lot of packages I use
| include native code that has been carefully tuned for Intel
| CPUs. If I choose AMD or get an M1 Macbook, I'm going to
| have a much poorer sense of how the things I'm working on
| would behave in production.
|
| That said, I'd be willing to at least try it. On the other
| hand, if work started talking about switching to ARM
| servers in production, I'd instantly be clamoring for a
| (non-M1) ARM workstation to develop on, because I need to
| _know_ that I 'm not going to get into trouble with
| packages that get a lot of love in the x86 versions of the
| native libraries but not so much on ARM.
| outworlder wrote:
| > For starters, someone's got to maintain the port of the
| interpreter or VM
|
| This was a good argument a couple of decades ago. Now?
| Keep in mind that most devices in this planet are ARM-
| based, ever since we started talking about 'smartphones'.
| They have been running these interpreters for a long time
| now. Most applications and libraries of any importance
| have been ported.
|
| > If I choose AMD or get an M1 Macbook, I'm going to have
| a much poorer sense of how the things I'm working on
| would behave in production.
|
| I thought that's what staging environments were for? Plus
| scale tests? A laptop provides a pretty poor proxy for a
| server environment behavior. For starters, they are not
| really the same spec, are they? Are you running a Xeon-
| based laptop?
| mumblemumble wrote:
| It at least gets you in the same ballpark. I'm not
| allowed to hook a debugger up to anything in the staging
| environment, and it's not terribly fun to be stuck, for
| example, having to guess at how memory fences are
| behaving in production because all the machines where you
| _can_ test things empirically have a different memory
| model.
|
| Or, for example, there's one library I use that includes
| some inline assembly language routines. Which target SSE,
| not SVE. So, if we're targeting different ISAs, then my
| dev box isn't even executing the same code as what would
| be running in production.
| Sindisil wrote:
| > I'm not allowed to hook a debugger up to anything in
| the staging environment
|
| That seems crazy to me. What bizarre excuse does your
| organization have for that policy?
|
| To me, part of the point of a staging environment is to
| provide something as close as practical to prod in which
| to test, reproduce, evaluate, and investigate issues, be
| they performance, correctness, or what have you.
| mumblemumble wrote:
| Honestly, does it even matter?
|
| Even if it were allowed, it would still be awkward. I
| want to, as much as is practicable, find problems as
| early as possible, and _not_ wait for them to get all the
| way to staging. I 'm not really interested in making
| myself less able to do my job effectively just because I
| can.
| jayd16 wrote:
| That all depends on how far you trust "write once, deploy
| anywhere." It doesn't have a flawless track record.
|
| I think Linus' comments still apply to those higher level
| languages. They all rely on platform dependent code.
| lmm wrote:
| If that were actually an important factor then no-one would
| do development on OSX, because servers don't run OSX, and the
| debugging, tools etc. are all a bit different on server *nix
| from what they are on OSX. And yet we see many developers
| who'd rather use a Macbook. So while there may be some
| premium to being able to "develop at home", clearly many
| developers value other considerations more highly.
| smoldesu wrote:
| >If that were actually an important factor then no-one
| would do development on OSX
|
| People only develop on MacOS _because_ of how similar it is
| to Unix, not in spite of it. Go ahead, look at how many
| developers were using MacOS before OSX. I 'll wait. The
| reason why people develop on Macs is because it's "close
| enough" to Linux to deploy with, and "good enough" as a
| desktop to keep tabs on most of your other apps.
|
| > So while there may be some premium to being able to
| "develop at home", clearly many developers value other
| considerations more highly.
|
| Let's clear this up: there is no development without
| development at home. If you work for a company as a
| developer, you'll be expected to maintain a machine that
| can consistently build and deploy your software. Unless
| you're working as a web developer (in which case, may god
| have mercy on your soul), you're probably going to end up
| using an x86 machine. Hell, my best friend is a die-hard
| Apple fan, and even he has admit that he can't really
| upgrade his Xeon iMac unless Apple offers him an upgrade
| within the x86 ecosystem.
| MonaroVXR wrote:
| >Unless you're working as a web developer (in which case,
| may god have mercy on your soul), you're probably going
| to end up using an x86 machine. Hell, my best friend is a
| die-hard Apple fan, and even he has admit that he can't
| really upgrade his Xeon iMac unless Apple offers him an
| upgrade within the x86 ecosystem.
|
| Why can't he upgrade? (Genuine question)
| nemothekid wrote:
| Servers don't run Windows either, but Linux still is still
| the preferred server platform. Being UNIX-like is way more
| compatible than a different instruction set altogether.
| nine_k wrote:
| Many people use macbooks as glorified terminals to run a
| text editor and a browser, while running the actual program
| being developed on a remote Linux machine.
|
| Even more people use macbooks to develop for the browser,
| or to develop using platform-independent languages: Python,
| Ruby, Node, maybe even golang.
|
| Quite a few people then package their backend code in a
| container and test it in a Linux VM which "Docker for Mac"
| helpfully provides.
|
| But indeed the fact that Macs used to run on Intel, so the
| libraries you used in development were mostly that same
| versions of the same code as in production, must have been
| helping.
| rkangel wrote:
| OSX is a different abstraction layer from processor
| architecture. Until recently Mac hardware was x86 and all
| the deployment targets were x86. A VM could take care of
| all the other differences.
| ip26 wrote:
| Didn't Macbook-as-developer-machine only really take off
| after the switch to Intel?
| smoldesu wrote:
| Macbook-as-developer-machine started getting popular
| around the release of the iPhone. Apple took the
| opportunity to lock down their ecosystem and allow you to
| exclusively build and sign applications on their own
| platform, basically locking out anyone who isn't a Mac
| owner.
| FractalParadigm wrote:
| I think it was a bit of that, mixed with the iPhone
| launch and subsequent release of the App Store and third-
| party apps. Limiting app development and distribution
| exclusively to Macs through Xcode probably forced a lot
| of people into using them for the first time. Mac OS X
| also received UNIX certification around this time IIRC, I
| wouldn't be surprised if that compatibility pushed some
| more people tired of fiddling with their OS towards the
| "it just works" Mac.
| Edman274 wrote:
| That happened in 2006, and I would argue that the effect
| of them moving from PowerPC to Intel was dwarfed by the
| effect of people wanting to be able to do things like
| iPhone app development.
| evgeniysharapov wrote:
| To your point there's nothing developed on OSX (and
| specific to OSX) that runs "in the cloud". There is some
| niche Swift offering but they are niche.
| an_opabinia wrote:
| The better interpretation seems, people want their servers
| to look like their MacBooks.
| kingsuper20 wrote:
| >It wasn't just all price. It was literally this "develop at
| home" issue.
|
| Whether you're right or not, I think I agree with the idea.
|
| It also seems to me that, in general, working with a
| different CPU architecture and instruction set implies that
| the new & improved stuff has to be significantly better to be
| worth the cost and risk.
|
| At this point, is one really that much better than another?
| Are large improvements happening at the margin?
|
| Another camel that'll poke it's head in the tent, in
| large/expensive embedded (which I realize that the parts in
| the article aren't aimed at) is whether a CPU and it's
| battlegroup of other stuff will be supported right off the
| bat by software infrastructure and later on by actually being
| available in the long run. You have to wonder how out on a
| limb anyone who used a Motorola 88k felt.
| smoldesu wrote:
| Yep. Wanna know why my M1 Macbook Air never gets any usage?
| Because all my servers are x86.
| gonzo wrote:
| if you're not using it,... want to sell it cheap? ;-)
| ksec wrote:
| He has a point, although that is not all there is.
|
| Most web stuff dont deploy on x86, they deploy on VM or more
| specifically JVM. Which is someone else's problem. Amazon and
| Oracle are both spending resource making sure it works
| flawlessly.
|
| I mean seriously, most doing Web Development dont even want
| to touch the VM.
|
| You may want to ask Amazon, who is trying to get as many
| Graviton 2 produce as possible from TSMC because the demand
| for them are outstripping supply.
|
| And all of that was before Apple even announced their switch
| to ARM on Mac.
|
| For some workload it is half the cost on R6g than x86
| instances. And for some like Twitter, they will invest into
| making sure it works with ARM. Those works get filter down
| the pipe. Medium-Large size companies see ecosystem matures
| and clear cost benefits they will move.
| Gravityloss wrote:
| If you run things on the JVM or some other VM, then you're
| relying on that having good support for the architecture.
| maven29 wrote:
| https://www.cnx-software.com/2020/02/18/raspberry-pi-4-uefia...
|
| Once Raspberry Pi CM4 support is added, I assume that you would
| be able to work on drivers for PCIe devices as well. Besides,
| non-server vendors like NXP have released official boards with
| ARM ServerReady support.
| rubyist5eva wrote:
| All the cool kids have a closet full of Raspberry Pis running
| their next billion dollar idea.
| Twirrim wrote:
| Unlike POWER[1] and Itanium, you can very easily pick up ARM
| systems for experimenting with. That means there's way less of
| a burden to experimenting with new architecture. There's also
| ARM based Chromebooks and all sorts of devices, and you can
| also get ARM based servers for pennies per hour.
|
| ARM's dominance in the cell phone market means it is ample
| popular enough, got lots of eyes on it, and increasing amounts
| of software is picking up dedicated optimisations for it.
|
| I'm not sure what else you're really expecting. The hardware is
| there. The software is there. Very likely you could switch to
| ARM without noticing.
|
| [1] Last time I mentioned this to someone involved in POWER
| architecture, they told me there were going to be cheap POWER
| based systems coming out to meet the "home hackers" market. I'm
| not paying particularly close attention, but I haven't seen
| anything yet?
| api wrote:
| The high-end workstation and on-premise server markets overlap
| with the hyperscale cloud market. That's been true all along on
| X64 with high-end Xeon and Epyc parts.
|
| "Hyperscale cloud" is just buzzword for "huge data center
| somewhere else" so there's not much of a difference except
| packaging and power (machines for hyperscale data centers often
| take direct DC power, not AC into one PSU per machine.)
| bogomipz wrote:
| Out of curiosity what was the price point? Was there a high
| minimum number of units required to place an order as well?
| Veedrac wrote:
| It didn't seem to matter for Graviton2, TBH. ARM servers took
| off the moment they got fast enough to be worth converting
| software.
|
| https://twitter.com/IanCutress/status/1387061860965437440
| 908B64B197 wrote:
| Amazon made Graviton affordable. You even get a discount
| compared to running x86 instances.
|
| Pay-As-You-Go is great for trying out new architectures: it's
| easy to justify spinning a few instances to test whether
| something can work under ARM. And if it does then convert
| existing instances to save money. No (hard to get unless you
| are a large business) dev boards to purchase.
| [deleted]
___________________________________________________________________
(page generated 2021-05-20 23:02 UTC)