Keep these things the hell away from the people who develop Chrome and desktop JS apps.
Keep these things the hell away from the people who develop Chrome and desktop JS apps.
At this point we may need TSMC to make a specialized chip to run Electron.
If you disassemble some armv8 binaries that aren't dealing with Javascript, you do see still see FJCVTZS.
https://web.archive.org/web/20201119143547/https://twitter.c...
> 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. > some not-significant CPU cycles
should say: > some not-insignificant CPU cyclesI am looking forward to the HTML Frameworks explosion. You thought there were too many JS options? Imagine when anyone can fork HTML.
For simple components, I much prefer them to firing up the React ecosystem.
Isn't that Flutter?
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 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.
I’ve found some resources but when I look at them I also hear stories of blind people saying these guidelines only make things worse.
Regarding the vague criticism you mention, I'd need something more concrete to tell you if the rumors are truish...
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”.
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.
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.
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.)
You misunderstood my post, and I don't appreciate the tone of your reply.
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)
I found one here from Supermicro: https://www.supermicro.com/en/products/motherboard/X13OEI-CP...
Has anyone see one of these in action? What was the primary use case? Monolithic database server?
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.
Know that scene from one episode of Aqua Teen Hunger Force where George Lowe (RIP) is a police officer and has his feet amputated, so he drags himself while pursuing a suspect?
Yeah. It does that.
I can even use VS Code remote on it in a pinch, though that's pushing it...
We had some hefty rigs at the last studio I worked at.
The old xeon stations were power houses.
The joke being that Apple realized that so many apps are built in Electron and made a decision to provide a shit ton of RAM to just to handle Electron. It seems very on point to the discussion
At this point, it's more satirical than haha funny. Electron is so bloated that it requires way more RAM than say native apps. To poke fun of its inefficiencies isn't going to win Last Comic Standing, but it is valid criticism even if attempted to be told in a humorous manner. Just because it's stuck in your craw doesn't mean the rest of us are in the same place as you, yet you are unwilling to accept that your view isn't the only view.
I actually almost totally agree with the perspective the “joke” comes from! I just don’t see it as a topic that warrants so frequently disrupting otherwise interesting discussion.
I really think a sizable chunk of people in the “omg my RAM!” camp are basing it on vibes, backed up by a misread of reported usage.
This reminds a long time ago when I was trying to figure out why the heck my Intel Mac was allocating all my RAM and most of my swap to Preview or Chess.
It’s true reported memory allocation does not equal actual memory used and that’s very clever of everyone who brings it up, but it does actually cause real annoyances.
I thought ublock was forced out of Chrome months ago... how are you people still using it? I switched back to Firefox a couple years ago already, even if it's occasionally painful.
But in my example I was thinking of a particular 2-month stretch where this kept biting me and I was using Chrome at that point. In terms of memory usage, Firefox is no better though (at one point it was, but not any more).
Now I'm afraid of saying "memory usage" lest someone pops out to comment "that's not how memory works" like whack-a-mole.
There are many specialized allocation patterns -- especially for larger system things like DBs, virtual machine / runtimes etc. -- that will mmap large regions and then only actually use part of it. Many angry fingers get pointed often without justification.
And this attitude "oh memory usage problems are a misreading of top" promotes poor memory management hygiene - and I think there's a strong argument that's all good in server applications / controlled environments but for desktop environments this attitude causes all sorts of knock on effects.