GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    John Regehr (regehr@mastodon.social)'s status on Tuesday, 09-Sep-2025 10:54:54 JST John Regehr John Regehr

    is this bullshit? or does ISA not really matter in some fictitious world where we can normalize for process and other factors?

    https://www.techpowerup.com/340779/amd-claims-arm-isa-doesnt-offer-efficiency-advantage-over-x86

    In conversation about 3 months ago from mastodon.social permalink
    • Embed this notice
      Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 10:54:44 JST Fabian Giesen Fabian Giesen
      in reply to
      • Steve Canon

      @regehr @steve To wit: virtual memory is a lie, by design. Uniform memory is a lie. Shared instruction/data memory is a lie. Coherent caches are a lie, caches would rather be _anything_ else. Buses are a lie. Memory-mapped IO is IO lying about being memory. Oh and the data bits and wires are small and shitty enough now that they started lying too and everything is slowly creeping towards ECCing all the things

      In conversation about 3 months ago permalink
    • Embed this notice
      Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 10:54:45 JST Fabian Giesen Fabian Giesen
      in reply to
      • Steve Canon

      @regehr @steve Basically almost everything that _all_ major ISAs pretend is true about memory at the ISA level is an expensive lie, but one that ~ALL the SW depends on. :)

      In conversation about 3 months ago permalink
      ✧✦Catherine✦✧ repeated this.
    • Embed this notice
      Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 10:54:46 JST Fabian Giesen Fabian Giesen
      in reply to
      • Steve Canon

      @regehr @steve For example, it's a goddamn NIGHTMARE doing a high-performance memory subsystem for absolutely anything.

      This whole "shared memory" fiction we're committed to maintaining is a significant drag on all HW, but HW impls of it are just in another league perf-wise than "just" building message-passing and trying to work around it in SW (lots have tried, but there's little code for it and it's a PITA), so we're kind of stuck with it.

      In conversation about 3 months ago permalink
    • Embed this notice
      John Regehr (regehr@mastodon.social)'s status on Tuesday, 09-Sep-2025 10:54:47 JST John Regehr John Regehr
      in reply to
      • Fabian Giesen
      • Steve Canon

      @rygorous @steve sure sure

      In conversation about 3 months ago permalink
    • Embed this notice
      John Regehr (regehr@mastodon.social)'s status on Tuesday, 09-Sep-2025 10:54:48 JST John Regehr John Regehr
      in reply to
      • Fabian Giesen
      • Steve Canon

      @rygorous @steve I've seen part of a convincing / complete formal spec for x86 and I would run away from any effort to validate an implementation of this

      In conversation about 3 months ago permalink
    • Embed this notice
      Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 10:54:48 JST Fabian Giesen Fabian Giesen
      in reply to
      • Steve Canon

      @regehr @steve Anecdotally, there's at least 3 (Intel, AMD, Centaur) companies that do this on the regular, and one of them (Centaur) is quite small as such things go.

      I wouldn't want to do it either, but the other thing you gotta keep in mind is that the CPU core, while important, is only part of a SoC and ISA has very little impact on the "everything else".

      In conversation about 3 months ago permalink
    • Embed this notice
      Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 10:54:49 JST Fabian Giesen Fabian Giesen
      in reply to
      • Steve Canon

      @steve @regehr Anyway, take that with whatever amount of salt you want, but Intel and AMD both are strongly incentivized to seriously look at this.

      They for sure would prefer to sell you x86s because they have decades of experience with that, but they're looking at what it costs them to do it both in capex and in how much it hurts the resulting designs.

      And for the latter, the consistent answer has been "a bit, but not much".

      In conversation about 3 months ago permalink
    • Embed this notice
      Steve Canon (steve@discuss.systems)'s status on Tuesday, 09-Sep-2025 10:54:51 JST Steve Canon Steve Canon
      in reply to
      • Fabian Giesen

      @rygorous @regehr yeah, this

      In conversation about 3 months ago permalink
    • Embed this notice
      Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 10:54:52 JST Fabian Giesen Fabian Giesen
      in reply to

      @regehr Eventually, there's nowhere left to hide. For applications where you'd use say an ARM Cortex-M0 or a bare-bones minimal RV32I CPU, I'm not aware of anything x86 past or present that would really make sense.

      Intel did "Quark" a while back which I believe was either a 486 or P5 derivative, so still something like a 5-stage pipelined integer core. If you want to go even lower than that, I don't think anyone has (or wants to do) anything.

      In conversation about 3 months ago permalink
    • Embed this notice
      Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 10:54:53 JST Fabian Giesen Fabian Giesen
      in reply to

      @regehr Some more details:
      - the D/V and toolchain costs are amortized. Broadly speaking, the bigger your ecosystem/market share, the bigger your ability to absorb that cost.
      - This holds for what ARM would call "application" cores; oversimplifying a bit, it's essentially a constant overhead on the design that adds some extra area and pipe stages. It's more onerous for smaller cores, but you need to be really small.

      In conversation about 3 months ago permalink
    • Embed this notice
      Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 10:54:54 JST Fabian Giesen Fabian Giesen
      in reply to

      @regehr Every serious study (both from independent researchers and from vendors themselves) that I've ever seen (and I'm up to 5 or so at this point), broadly, supports this, with some caveats.

      It's not "no difference", but for server/application cores, what differences there are typically somewhere in the single-digit %. You can always find pathological examples, but typically it's not that much.

      There is a real cost to x86s many warts but it's mostly in design/validation cost and toolchains.

      In conversation about 3 months ago permalink

      Attachments


      Haelwenn /элвэн/ :triskell: likes this.
    • Embed this notice
      Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 10:57:21 JST Fabian Giesen Fabian Giesen
      in reply to
      • Steve Canon

      @regehr @steve Also, re: ISA efficiency, I like re-posting this, by now, rather old image that shows you what the score really is.

      This was on the Xeon Phis but the general trend holds to this day. (Source: https://people.eecs.berkeley.edu/~ysshao/assets/papers/shao2013-islped.pdf p. 3) NB this is an in-order core with 512b vector units.

      In conversation about 3 months ago permalink

      Attachments


      1. https://cdn.masto.host/mastodongamedevplace/media_attachments/files/115/171/846/175/792/521/original/25a9e7374936712e.png

      ✧✦Catherine✦✧ repeated this.
    • Embed this notice
      John Regehr (regehr@mastodon.social)'s status on Tuesday, 09-Sep-2025 10:57:22 JST John Regehr John Regehr
      in reply to
      • Fabian Giesen
      • Steve Canon

      @rygorous @steve yep this is more or less how I teach this stuff

      In conversation about 3 months ago permalink
      ✧✦Catherine✦✧ repeated this.
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 09-Sep-2025 11:08:25 JST Rich Felker Rich Felker
      in reply to
      • Fabian Giesen
      • Steve Canon

      @rygorous @regehr @steve If you throw out speculative & ooo execution to make a cpu that actually honors security boundaries, ISA will matter a lot more...

      In conversation about 3 months ago permalink
      Haelwenn /элвэн/ :triskell: likes this.
    • Embed this notice
      Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 11:08:26 JST Fabian Giesen Fabian Giesen
      in reply to
      • Steve Canon

      @regehr @steve This is one of the bigger reasons for why ISA doesn't matter more.

      Broadly, your uArch is only as good as its data movement, because that shit is what's really expensive, not the logic gates.

      It's things like:
      - how good is your entire memory subsystem
      - how good is your bypass network
      - how good are your register files
      etc.

      It's not like you can't make mistakes in the ISA that will really kill your design, you can. That's what happened to VAX.

      In conversation about 3 months ago permalink

      Attachments

      1. No result found on File_thumbnail lookup.
        etc.it
        This domain may be for sale!
      2. No result found on File_thumbnail lookup.
        Domain Details Page
    • Embed this notice
      Fabian Giesen (rygorous@mastodon.gamedev.place)'s status on Tuesday, 09-Sep-2025 12:44:12 JST Fabian Giesen Fabian Giesen
      in reply to

      @regehr It's not that x86 couldn't do that, but you'd need to dive even deeper into history, and P5 level is honestly about the lowest anyone still wants to go.

      You could do 286-or-less but that's 16-bit x86 and tooling for that is essentially extinct at this point. You're stuck with old compilers etc.

      In conversation about 3 months ago permalink
      Haelwenn /элвэн/ :triskell: likes this.

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.