To me, this is no different than the c/c++ crowd screaming "But you need to understand types and memory management" to the Type-safe Managed Memory Language crowd.
Problem solving remains the primary skill. You're just working in a different medium. Instead of code, it's design and specification (which you should have been doing in the first place instead of firing it out on demand as fast as your fingers move and insisting your teammates get in the groove).
If you're worried that you won't be able to understand why generated code isn't behaving properly, pro tip: Ask mode > ask the LLM to map possible reasons why the code does this when it should be doing that. Your ability to target the 'right' problem area earlier vs later is a matter of experience, as it always has been.
And you have to spend more time being intentional about setting up context / rules to define your application-specific design patterns.
For the young-uns, they need to learn their own way to leap frog over the paradigms we were trained on. We should be honest with them and ourselves that those paradigms are obsolete. As is winding core memory by hand. As Musk has said, one day there will be no apps, just a model. We're not there yet but this is the future.
This question bothers me because I have never found a clear authoritative documentation.
The more detailed sources say, contra the mainstream impression, that Apple Silicon's vaguely-named "unified memory" is technically a hybrid System-on-Chip and System-in-Package architecture. The memory banks DRAM are on a second die (one source said it is made by Samsung), but the RAM controller sits on the CPU die and manages the RAM for the unified memory pool for graphics/main/neural memory usage (hence, "unified" from an ISA perspective). Both IC dies coexists on a shared enclosed package as a single microchip. Technically this is still called a System-on-Chip architecture according to Wikipedia because the electrical engineering definition allows for some parts, such as RAM or I/O, to still exist separately off the main piece of silicon die yet still be called an SoC architecture. In short, it is not a monolithic SoC.
I have tried several times to find citations about this but it is an ambiguous point that is often glossed over, as a kind of hardware abstraction.
The process used for RAM and the process used for the cutting edge microprocessors are nothing alike, so it’s physically impossible to have the same piece of silicon have both DDR RAM and the CPU. You’re not really going to find a citation to something this well known. Literally every phone, for instance, has “unified memory” with the RAM die stacked on top of the CPU die, as well.
The problem there is that Apple's marketing speak of "unified memory" creates different and confusing connotations.
It is not as surprising that modern chips stack or tile dies together, such as on phones and the like.
edit: Note also there is historical precedent for specialized SoCs that integrate DRAM on the same ASIC, see eDRAM: https://en.wikipedia.org/wiki/EDRAM
Your argument also require the reader knowing the technical premises that CPU and RAM processes are different nm, and that processes of different nm cannot be done on the same chip. These are not obvious or even absolute facts to anyone.
Actually a good place to find these sorts of citations are tech magazines that explain these new things, maybe like Ars Technica used to (i.e., a piece on "What is Apple's unified memory"), or else in academic research that sometimes studies contemporary chips, their research papers might have a blurb discussing the actual hardware architecture of such and such company's design. Or maybe there's an EETimes piece discussing Apple Silicon technology in one of their back issues, e.g. in trade journal literature.
So, what is well known varies depending on the audience. It is both plausible, and appropriate, for technological ambiguities and details to be explicitly discussed and clarified, either by the maker or by other journalists and writers.
And finally, consider also what is well-misknown. If you go online and look, lots of lay comments since Apple Silicon really do believe they are literally the same IC chip. So you have to ask how did that come to be?
> The problem there is that Apple's marketing speak of "unified memory" creates different and confusing connotations.
Unified memory has nothing to do with them being on the same chip… it just has to do with them being the same pool of memory shared between cpu and gpu. Apple marketing is pretty clear on that too. The only reason it’s unique is that doing unified memory on laptops is kinda unheard of until then. It’s been the standard on tablets and phones for years.
Yes and no. There is sharing of RAM with IGPs from AMD and Intel, but my understanding is the way Microsoft handles the RAM sharing isn't quite as 'unified' as with MacOS. It's not a difference in hardware really, but a software implementation. Also, when we're talking about older Intel/AMD IGP solutions, the graphics cards paired really couldn't take advantage of larger amounts of RAM.
Something like the new Strix Halo stuff from AMD is actually useful with larger amounts of RAM, and basically is the same as the Apple architecture.
No; that’s absurd to say it’s physically impossible, it is absolutely possible to etch whatever arbitrary pattern into a physical substrate, physics pending. What is true is that the CPU and DRAM fabrication processes are very unalike, one uses highly complex patterning for the logic, the other uses many blocks repeated for memory, and can be done on a higher process node as it does not require the same intricacy's. It’s not cost efficient to use logic fabrication to make memory. And you won’t get the yield with highly complex patterning for logic from something that is meant to stamp out the same DRAM block billions of times.
So one day, when we have process nodes far smaller what we do today, a DRAM fab can print highly complex patterning for logic, compatible to today’s CPUs on die. And the logic fabs will be making cpus many times more complex than that. Because economics.
> No; that’s absurd to say it’s physically impossible, it is absolutely possible to etch whatever arbitrary pattern into a physical substrate, physics pending.
Logic processes do not have the capabilities to even manufacture DRAM. It’s not about cost or yield, they just do not have the correct blocks to make DRAM. The processing to make DRAM makes it incompatible with making logic at the current speeds and densities.
There were some much older processes where you could do both, but those are about 10 years old now and we’ve long since moved on. I do not think there will be a future where you can do both.
Nah, you need the 405 Method Not Allowed to be returned by legacy systems and proxies along the way to your bleeding edge server rather than silently failing whilst dropping the params in the request body.
Yes, but like Windows for Workgroups before them, they didn't need to rely on DOS services once they had started. They were 32-bit multitasking OSes that could host multiple DOS VMs and (in the case of WfW) a 16-bit cooperatively multitasked GUI.
DOS basically acted as a bootloader. But all of those OSes had the very weird feature that they could switch back into a virtualised copy of their bootloader.
I do feel that Wikipedia understates the importance of Windows for Workgroups. Internally, it wasn't just Windows 3.1 with networking. It was a trial run for the fundamentals of the Windows 95 architecture.
In other words, they were bare-metal hypervisors which passed through the majority of the hardware, doing a minimum of virtualisation to allow sharing it between VMs. This is easy to see by comparing the responsiveness of a DOS box running something like EDIT in Win9x vs. NT/2K/XP's NTVDM; the latter is a full emulator of basically all the hardware except the CPU.
The unresponsive NTDVM was mainly due to its piss-poor text mode emulation. Win9x still virtualized the graphics card (so you couldn't use SVGA games in Win9x) but its emulation was implemented better.
Win95's ability to host multiple VMs was marginally better than Windows/386. It was a step in the right direction with the new driver architecture and elimination of TSRs (TSR-to-95 porting was one of my roles bitd). Just a baby step though, you could be just as rude in a '95 driver as a DOS TSR.
> They were 32-bit multitasking OSes that could host multiple DOS VMs
In theory, yes. Yet some games could not run in those "DOS VMs" because not enough real memory was available, which means that they weren't real VMs. The real "DOS VMs" appeared in Windows 2000.
This is exactly why I come to HN, vs Wikishemedia... People here WERE THERE!
When I worked at C_ we used to load Some solitaire game (Freecell) to verify that Windows98SE was in 32-bit mode before installing the network stack, and Chief Legal Officer, and from what I understand CLO was $4,000 a seat.
Load Driver, Reboot, Solitare, CLO. and then onward to disk optimizing, and then virus scanning... Two people did 89 machines, in 4 days. an entire floor... Food was delivered, and we slept for 4 hours, in the floor below, and on Friday, The head of Legal called us into his office... we showed him the checklist, as complete, and He laughed... the whole department was both amazed and happy.
He really called us to change his desktop into a scene from JAWS.
It was Windows 98SE that got a 32-bit disk driver upgrade, and FreeCell verified that it was installed.
