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.
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.
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.
> 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.
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.
<canvas> is already a middle finger in the direction of accessibility. You don't need wasm to put blind people at an extra disadvantage. SVG Accessibility anyone? No? What a surprise. Classical web accessibility has basically ended. We (blind people) are only using sites which are sufficiently old to be still usable.
I'm genuinely trying to do something about <canvas> element accessibility. Whether it's enough ...? Probably not. But if I can do the work to try and show that <canvas> elements can be made more accessible, then there's no excuse for developers working on far more popular JS canvas libraries from making an attempt to better my efforts.
I do strongly agree that <canvas> elements should not be used to replace HTML/CSS! My personal web hierarchy is 1. HTML/CSS/images; 2. Add (accessibility-friendly) JS if some fancy interaction is useful; 3. More complex - try SVG/CSS; 4. use <canvas> only if nothing else meets the project requirements.
Well, I am not a web dev... At least, my know-how ends when SPAs begin. All I can point you to are the WCAG, but I am sure you already know about them...
Regarding the vague criticism you mention, I'd need something more concrete to tell you if the rumors are truish...
There has been some exploration around developing a JavaScript API for accessibility. If implemented, that would allow <canvas> renderers to be accessible. I hope people will consider that blocking for shipping canvas renderers, but we'll see.
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™
The LLM created code will then be consumed by my AI agent which will rewrite the application to filter all of the bullshit and be fit for my minimalist preferences like a Reader Mode for CRUD apps.
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.
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.
The state of web deployment in 2025 is the universe punishing me for calling java applets and other java web deployment tech "heavyweight" back in the day.
Not that I intend to scale this in any way, but I'm working on an in-game UI rendered on the canvas, and I am thinking I might be able to hack something together based on this youtuber's library and excellent explainer video[0]. The thought had definitely occurred to me that if someone wanted to really roll up their sleeves and maintain a js port of the library, it would provide a translate-able UI from native C to native JS and back. At least, I can imagine a vite/webpack-like cli that reads the C implementation and spits out a js implementation.
Of course, I could also imagine one that reads the C and provides the equivalent html/css/js. And others might scoff "why not just compile the whole C app into wasm", which would certainly be plenty performant in a lot of cases. So I guess I don't know why it isn't already being done, and that usually means I don't know enough about the problems to have any clue what it would actually take to make such things.
In any case, I'm also looking forward to a quantum leap in web app UI! I'm not quite as optimistic that it's ever going to happen, I guess, but I can see a lot of benefit, if it did.
I'm thinking about this space now. Ideally, I want a new browser like platform with stricter security properties than browsers but better rendering out of the box capabilities.
Web Components was too verbose and nobody could figure it out. Flutter is just the beginning of the newest scheme by RAM manufacturers to bloat our RAM usage. We’ve stagnated at 8GB on midrange computers for too long.
Soon it'll be all 3D content anyway... the old world of a graph of documents is going away. The web breathed a sigh of relief when Apple's Vision Pro bombed.
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”.
Better get to the bottom of the mystery surrounding Apple's ECC patents on LPDDR ECC or you will have to make a leap of faith that your database on their chips won't wind up cruddy in a Bad Way. All we have now are assumptions and educated guesses about what they may be doing. It's also going to be an issue with AMD 395+ and nVidia+MediaTek GB10 (but I would assume NO ECC on those SoCs, based on their history).
It may only be a few mm to the LPDDR5 arrays inside the SoC, but there are all sorts of environmental/thermal/power and RFi considerations, especially on tiny (3-5nm) nodes! Switch on the numerical control machine on the other side of the wall from your office and hope your data doesn't change.
There are already big servers designed for huge single databases, for example the 8-socket Xeon types. Tbh I don't understand exactly why RAM is such a concern, but these machines have TBs of it.
I think a bigger business case is virtual machine hosting, say one of these is maxed out (8 Xeons with 56 cores ie 448 cores and 32tb of memory), say it's divided into a 1000 machines you can run each VM with 40% cpu utilization and 3gb of memory, considering many VM offerings have less RAM (and add a bit of overselling on top of it with regards to CPU) it could probably house over 2000 VM's.
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.
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.
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.)
While I did make a couple of cosmetic edits within a few minutes of posting (before there were any replies), even the original was referring to the speed of the memory ("on-chip"), not its size.
You misunderstood my post, and I don't appreciate the tone of your reply.
I didn't appreciate you removing everything I responded to either, replacing it with something making my comment look entirely out of context.
While I believe you that you meant to write about the different performance profile of on chip memory, that's not what you did at the time I wrote my reply. What you actually did write was how 512 GB of RAM might revolutionize i.e. database servers. Which I addressed.
And if you hadn't written that, I wouldn't have written my comment either, because I'm not a database developer that could speculate on performance side-grades of such kind (less memory, but closer to the CPU)
This is ridiculous, I changed like 3 words. While I did originally mention 512GB, the context (“on-chip”) made it clear I was referring to the speed, not the size.
