I disagree. I don't read because I like to read books, I don't listen to audiobooks because I like listening to audiobooks, I don't talk to people because I like talking with people, heck, I don't take pictures because I like taking pictures.
I like stories and all of the above are simply ways of hoarding more stories. The way I'm getting the story is not important, the story is.
I'm not sure everyone uses the terms consistently, but the difference is that the old "shared" memory was reserving a section to act as VRAM under the control of the GPU, ignored by the OS. The CPU ran the same kind of code pretending there is a "bus transfer" between host memory and graphics memory.
In unified memory, all the memory is host memory and data can go from program to GPU with zero copy movements. The addresses of buffers can be shared via appropriate MMU translation support, so that the application and graphics subsystem are communicating effectively through the basic RAM cache coherency protocols over the same buffers.
Edit to add: Aside from the zero copy transfer potential, it also means dynamic allocation strategies can shift the balance between host and graphics allocations on the fly. Individual image and message buffers can be allocated on the fly instead of setting a static split between the two worlds.
To some degree this is how it already feels like to program basically anything with dma today. You map hardware into an iommu and stop touching it when the hardware is supposed to use it, and then you reclaim it afterwards. So the model from the os feels the same, the difference is that it's not copying the memory into some local memory to operate on it.
Shared memory of the past meant reserving a part of the memory for the GPU, which could then not be used or accessed by the CPU. If the CPU wanted to access something, it had to copy it from the GPU's section of the memory to its own. Unified memory means both just fully share the same memory.
For these in specific, they appear basically transparently to the GPU. There's a lot of software/firmware stuff for this, but also a different hardware architecture - while the RAM is on the CPU die, the nvlink-c2c gives it extremely low latency and 600GB/s bandwidth between the GPU and CPU.
No. Let’s define terms, as others have pointed out they’re not perfect.
Unified memory is what Apple is doing, other phones do, and many low end built in GPUs have done in PCs for ages. There is only one physical memory pool. Both the CPU and GPU can access it at full speed.
This means no copying between pools of memory. No speed penalty accessing the CPU memory from GPU or vice versa. If the GPU only needs 2 GB to draw the desktop it only uses 2 GB of the pool. Or it can use 45 GB if it needs it and the CPU doesn’t. But all memory has to be the same speed, and that ain’t cheap given how fast GPUs like things. I don’t know if expandable memory is possible, and they use the same bus do they compete for bandwidth. Seems theoretically easier to program for to me.
The opposite is what’s been common in graphics cards since the 2D era. CPU and GPU have their own memory and can talk over PCI/AGP/PCI-E. This is what I think they mean by shared memory, if it’s not what’s the point in touting unified?
In this model if the GPU uses 2 GB of its 12 GB total, the other 10 isn’t available to the OS at full speed and I’m not aware of any operating systems that would use it for programs/cache by default. If the GPU needs 45 GB… too bad. You have to page things in and out of GPU memory over the much slower system bus. Starting a game means loading assets into main memory then transferring them to the GPU (newer tech can accelerate this). But the CPU can have slower memory than the GPU saving money. Memory expansion on the CPU side easy. And the CPU saturating its memory bus has no effect on the speed of the GPU memory bus because it’s physically separate. More complicated memory model but it’s the one everyone uses used to.
Which is better is a matter of opinion and workload needs.
Yes, I know there is an actual difference vs. dedicated GPUs with their own VRAM. I say it's marketing because Apple popularized the unified memory term even though, as you said, it existed in iGPUs long before Apple Silicon and was called shared GPU memory.
> I don’t know if expandable memory is possible
It technically is. These new systems (mostly) get their high bandwidth by using more channels (wider bus) of normal RAM modules. A system that has LPCAMM2 sockets should allow using the same LPDDR5X memory but you'd need a socket per two channels. A typical PC only supports two channels so having four (two sockets) would double the bandwidth.
System RAM has much lower bandwidth and less predictable access. Notably, the transfer from system to GPU is very slow. About 30x slower. LLMs aren’t designed to queue or parallelise operations to account for this. They just become much slower.
Around 2005, I was hired by a company that was building software for USB drives, to build a porn site.
Turns out, they wanted me to build a poc for an authentication solution: some USB drives would have a fingerprint reader and they wanted to build this auth system based on that.
So I built that, but "perplexingly", they didn't get any finance or enough prospect customers, so the project got shelved.
Then, I was handed another project they had on the back burner, a sort of firewall for devices, meant to prevent exfiltration of company documents on unapproved USB drives.
I built the single user version, eg you had to be admin to allow devices and the product sold quite well, even winning some prizes iirc.
We started getting requests to have a centralized admin interface and a way to allow/disallow copying some file types. I started working on the centralized admin and the company hired a very talented engineer to build the file filtering thing. This last thing was based on a windows API that allowed for virtual file systems. Things were ticking along nicely and the company even hired a business manager to try to come up with other products we can build with our existing tech.
One afternoon, over a bunch of cold beers, to link with the hell on earth that happens right now in London, me and this person came up with a cunning plan! What if you sell an 1GB USB drive with an extra 1GB of space?
The plan was simple: plug in the device, you get a drive that's the regular USB drive, but also another drive, backed by the virtual file system thing and a version of my http auth thing, and you would read/write from a server on the Internet.
Big boss liked the idea and I started researching how to get servers and the like, while a third engineer was tasked to build the desktop app needed.
It all came crashing down, days later, when this engineer declared that is not possible to have a windows app minimize to sys tray and the project got cancelled. I left the company not long after that .
This was the story on how a small German-Romanian company could have beat Dropbox.
> I’d say perhaps once per day I’ll encounter a website that has never had zoom in/out (ctl +/-) tested because if you zoom up even one level from 100%, everything breaks
How does it break for you? Seems OK to me on android — in fact, I already had it at 110%. Reminded me to check my desktop settings which have HN fixed at 125%. I cannot believe that, in 2026, the default font size is set at 12px — is anyone actually reading it at that size?!
> I cannot believe that, in 2026, the default font size is set at 12px — is anyone actually reading it at that size?!
The very first "quality of life" thing I do when I install a new computer / operating system nowadays is double (sometimes triple) the default font size. 12pt was probably fine when our monitors were 640x480, and when we were 18 years old.
I leave HN on default everything, but I have a 1080p monitor so it might look bigger for me than someone with a higher resolution monitor... I don't know how that works. But I often have to zoom out of websites linked here because the text is so big and it feels uncomfortable to read
Yeah, 12px is fine (27" 1440p, no display scaling). It is on the small side. I'd go a bit larger for something I made. But it's not a small enough to slow down my reading.
I use DuckDuckGo Browser, Firefox, and Chrome on Android pretty much in that order of preference. In both mobile mode and desktop mode all of these browsers support pinch zoom and two-finger drag scrolling. I have no problems with this site using those.
I think we might need a little more information than just the OS to differentiate.
Of course the method described requires both input and output buffers, because everything is processed last-character-first.
Now that you mention it, if the assignment had called for arguments, instead of files or pipes, argv points to a writable array, so the result could be written directly to it, negating any need to allocate memory, and any out-of-memory conditions from large input data would occur before the program is even called.
If it usually uses a file to store the numbers, the same could be done by writing the result back to the file, but that only works if it is passed as an argument, as piping it would throw a seek error. I wonder if the instructor would accept an interleaved little-endian input syntax, with a little-endian output; then the program could use pipes without a need to seek. An infinite series of '9' characters would output an '8', followed by one '9' per two input characters.
Gimp will never be able to pull a Blender because they are operating on hugely different conditions.
Blender never had to play catch up with a proprietary file format. In Blender's world, fbx and any of the video formats are the way to interop with other studios.
In the Photoshop/Gimp world, the interop format is psd. Under full control of Adobe.
There is also the matter of price. Maya and 3dStudioMax are eye watering expensive, while Photoshop is dirt cheap. As a professional photographer, I can get the 300 GBP it costs me to have Lightroom and Photoshop for one year, in an afternoon.
Because then you have chosen a non-deterministic action when a deterministic action would do, thus making it more expensive, more prone to failure, and just more annoying to use.
Would you rather press a button and go through a simple process that's normalized across all crud apps or talk to a chatbot every time you want to solve a problem and invoke external apis?
Do keep in mind, the user has to be someone who can conceive of the idea of having a script instead of just having the job done, and also needs to have some semblance of understanding how to run it.
I like stories and all of the above are simply ways of hoarding more stories. The way I'm getting the story is not important, the story is.
reply