7 ms·

In 2025 the question isn't "will it run crysis", it's "will it run a simple CRUD app".

by whizzter 2y ago

esafak 2y ago
Will it run Electron?
- bloomingkales 2y ago
  Gonna pile on: At this point we may need TSMC to make a specialized chip to run Electron.
  - vvillena 2y ago
    There are already specialized instructions in the Apple Silicon chips. IIRC there's something tailored for the Objective-C runtime, and something useful for Javascript runtimes.
    - favorited 2y ago
      Uncontended acquire-release atomic operations are basically free on Apple Silicon, which synergizes with the Objective-C (and Swift!) runtimes, where every retain/release is an atomic increment/decrement. https://web.archive.org/web/20201119143547/https://twitter.com/Catfish_Man/status/1326238434235568128 https://web.archive.org/web/20201119143547/https://twitter.c...
      - throwaway2037 2y ago
        > Uncontended acquire-release atomic operations are basically free on Apple Silicon While I don't doubt you, the poster, specifically, how is this possible? To be clear, my brain is x86-wired, not ARM-wired, so I may have some things wrong. Most of the expense of atomic inc/dec is "happens before", which essentially says before the current core reads that memory address, it will be guaranteed to be updated to the latest shared value. How can this be avoided? Or is it not avoided, but just much, much faster than x86? If the shared value was updated in a different core, some not-significant CPU cycles are required to update L1 cache on current current with latest shared value.
        throwaway2037 2y ago
        EDIT: > some not-significant CPU cycles should say: > some not-insignificant CPU cycles
  - zitterbewegung 2y ago
    It has been done for Java [1] and as we make smaller and smaller chips who knows. [1] https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle
  - unilynx 2y ago
    ARM already has them. https://developer.arm.com/documentation/ddi0602/2022-03/SIMD-FP-Instructions/FJCVTZS--Floating-point-Javascript-Convert-to-Signed-fixed-point--rounding-toward-Zero- https://developer.arm.com/documentation/ddi0602/2022-03/SIMD...
    - therein 2y ago
      This was discussed before and interesting but apparently the name of that instruction is misleading. Someone had chimed in and talked about how having Javascript in its name is entirely unnecessary as that exact same floating point representation is commonly used outside Javascript as well. If you disassemble some armv8 binaries that aren't dealing with Javascript, you do see still see FJCVTZS.
  - imgabe 2y ago
    JSOC - javascript on a chip
- belter 2y ago
  You need an AWS Region for that...
Maken 2y ago
Will it run Discord?
gjsman-1000 2y ago
In the future, we’ll decide HTML, CSS, and JS are too much of an inconsistent burden; so every website will bundle their own renderers into a <canvas> tag running off a WASM blob. Accessibility will be figured out later - just like it was for the early JavaScript frontends. I am looking forward to the HTML Frameworks explosion. You thought there were too many JS options? Imagine when anyone can fork HTML.
- jsheard 2y ago
  Why stop there? LLMs will free us from the shackles of having to ship actual code, instead we'll ship natural language descriptions and JIT them at runtime. It may use orders of magnitude more resources and only work half of the time but imagine the Developer Velocity™
  - gjsman-1000 2y ago
    In fact, with AI becoming more powerful, the <canvas> tag might soon become even more viable; because nobody will need ARIA tags or similar to tell them what’s on screen. The AI screen reader will look at the website as a whole and talk to the user. With accessibility no longer required, and with any UI being just a dumb framebuffer, we’ll finally see perfect chaos.
    - lynx97 2y ago
      And blind people will be the first test subjects for the "we see everything you read" project. Sweet. A small enough group that has no way out. Besides, after the initial giveaways, imagine the revenue if you can charge for every single pageview.
  - Zekio 2y ago
    can't wait for all the imaginary features
    - tempodox 2y ago
      You can hallucinate them right now already. Just ask WebGPT.
cellularmitosis 2y ago
Speaking of CRUD, would Apple’s on-chip memory have significant advantages for running Postgres vs a threadripper with a mobo full of ram? It seems like vertical scaling has fallen out of fashion lately, and I’m curious if this might be the new high-water mark for “everything in one giant DB”.
- ffsm8 2y ago
  I'm not sure how this would impact the server market in any way considering that epyc thread ripper has supported 4 TB for over 5 yrs now. Is it the usual Apple distortion effect where fanboys just can't help themselves? It's definitely a sizeable amount of RAM though, and definitely enough to run the majority of websites running on the web. But so would a budget Linux server costing maybe 100-200 bucks per month.
  - Moto7451 2y ago
    The question is about embedded DRAM, not trying to put a Mac in the data center. I am unaware of an apples to apples comparison here, but on the same Intel and AMD platform there can be a performance increase associated with embedded high speed LPDDR5 vs something on an SODIMM, which is why CAMM is being developed for that space. I would be interested as well in what an on chip memory bank would do for an EPYC or similar system since exotic high performance systems are fun even if all I’ll ever touch at this point is commodity stuff on AWS and GCP.
    - deleted 2y ago
      [deleted]
    - ffsm8 2y ago
      He edited his comment. The previous version did reference the 512 GB being so big that it'd be a game changer for servers.
      - jmb99 2y ago
        Yeah, 512GB was a game changer for servers... with DDR3... And that wasn’t even where it topped out, there were servers supporting 6TB of DDR3 in a single machine. DDR4 had at least 12TB in a single (quad-CPU) machine that I know of (not sure if there were any 96*256GB DDR4 configs). These days, if money’s no object, there exist boards supporting 24TB of DDR5. I think even some quad-CPU DDR2-era SKUs could do 1.5TB. 512GB is nothing. (Not directly in response to you, just adding context.)

In 2025 the question isn't "will it run crysis", it's "will it run a simple CRUD app".

esafak 2y ago

Will it run Electron?

bloomingkales 2y ago
Gonna pile on: At this point we may need TSMC to make a specialized chip to run Electron.
- vvillena 2y ago
  There are already specialized instructions in the Apple Silicon chips. IIRC there's something tailored for the Objective-C runtime, and something useful for Javascript runtimes.
  - favorited 2y ago
    Uncontended acquire-release atomic operations are basically free on Apple Silicon, which synergizes with the Objective-C (and Swift!) runtimes, where every retain/release is an atomic increment/decrement. https://web.archive.org/web/20201119143547/https://twitter.com/Catfish_Man/status/1326238434235568128 https://web.archive.org/web/20201119143547/https://twitter.c...
    - throwaway2037 2y ago
      > Uncontended acquire-release atomic operations are basically free on Apple Silicon While I don't doubt you, the poster, specifically, how is this possible? To be clear, my brain is x86-wired, not ARM-wired, so I may have some things wrong. Most of the expense of atomic inc/dec is "happens before", which essentially says before the current core reads that memory address, it will be guaranteed to be updated to the latest shared value. How can this be avoided? Or is it not avoided, but just much, much faster than x86? If the shared value was updated in a different core, some not-significant CPU cycles are required to update L1 cache on current current with latest shared value.
      - throwaway2037 2y ago
        EDIT: > some not-significant CPU cycles should say: > some not-insignificant CPU cycles
- zitterbewegung 2y ago
  It has been done for Java [1] and as we make smaller and smaller chips who knows. [1] https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle
- unilynx 2y ago
  ARM already has them. https://developer.arm.com/documentation/ddi0602/2022-03/SIMD-FP-Instructions/FJCVTZS--Floating-point-Javascript-Convert-to-Signed-fixed-point--rounding-toward-Zero- https://developer.arm.com/documentation/ddi0602/2022-03/SIMD...
  - therein 2y ago
    This was discussed before and interesting but apparently the name of that instruction is misleading. Someone had chimed in and talked about how having Javascript in its name is entirely unnecessary as that exact same floating point representation is commonly used outside Javascript as well. If you disassemble some armv8 binaries that aren't dealing with Javascript, you do see still see FJCVTZS.
- imgabe 2y ago
  JSOC - javascript on a chip
belter 2y ago
You need an AWS Region for that...

Maken 2y ago

Will it run Discord?

gjsman-1000 2y ago

In the future, we’ll decide HTML, CSS, and JS are too much of an inconsistent burden; so every website will bundle their own renderers into a <canvas> tag running off a WASM blob. Accessibility will be figured out later - just like it was for the early JavaScript frontends. I am looking forward to the HTML Frameworks explosion. You thought there were too many JS options? Imagine when anyone can fork HTML.

jsheard 2y ago
Why stop there? LLMs will free us from the shackles of having to ship actual code, instead we'll ship natural language descriptions and JIT them at runtime. It may use orders of magnitude more resources and only work half of the time but imagine the Developer Velocity™
- gjsman-1000 2y ago
  In fact, with AI becoming more powerful, the <canvas> tag might soon become even more viable; because nobody will need ARIA tags or similar to tell them what’s on screen. The AI screen reader will look at the website as a whole and talk to the user. With accessibility no longer required, and with any UI being just a dumb framebuffer, we’ll finally see perfect chaos.
  - lynx97 2y ago
    And blind people will be the first test subjects for the "we see everything you read" project. Sweet. A small enough group that has no way out. Besides, after the initial giveaways, imagine the revenue if you can charge for every single pageview.
- Zekio 2y ago
  can't wait for all the imaginary features
  - tempodox 2y ago
    You can hallucinate them right now already. Just ask WebGPT.

cellularmitosis 2y ago

Speaking of CRUD, would Apple’s on-chip memory have significant advantages for running Postgres vs a threadripper with a mobo full of ram? It seems like vertical scaling has fallen out of fashion lately, and I’m curious if this might be the new high-water mark for “everything in one giant DB”.

ffsm8 2y ago
I'm not sure how this would impact the server market in any way considering that epyc thread ripper has supported 4 TB for over 5 yrs now. Is it the usual Apple distortion effect where fanboys just can't help themselves? It's definitely a sizeable amount of RAM though, and definitely enough to run the majority of websites running on the web. But so would a budget Linux server costing maybe 100-200 bucks per month.
- Moto7451 2y ago
  The question is about embedded DRAM, not trying to put a Mac in the data center. I am unaware of an apples to apples comparison here, but on the same Intel and AMD platform there can be a performance increase associated with embedded high speed LPDDR5 vs something on an SODIMM, which is why CAMM is being developed for that space. I would be interested as well in what an on chip memory bank would do for an EPYC or similar system since exotic high performance systems are fun even if all I’ll ever touch at this point is commodity stuff on AWS and GCP.
  - deleted 2y ago
    [deleted]
  - ffsm8 2y ago
    He edited his comment. The previous version did reference the 512 GB being so big that it'd be a game changer for servers.
    - jmb99 2y ago
      Yeah, 512GB was a game changer for servers... with DDR3... And that wasn’t even where it topped out, there were servers supporting 6TB of DDR3 in a single machine. DDR4 had at least 12TB in a single (quad-CPU) machine that I know of (not sure if there were any 96*256GB DDR4 configs). These days, if money’s no object, there exist boards supporting 24TB of DDR5. I think even some quad-CPU DDR2-era SKUs could do 1.5TB. 512GB is nothing. (Not directly in response to you, just adding context.)