That's wild that Apple, the ultimate tech image company, left that in there considering this is whole thing is all lip service and PR anyway, not a real change in the global manufacturing mix. Their entire campaign lost all credibility for me in a matter of seconds. I'm not even an Apple hater, I like my Apple products.
Well put. I tried to explain this to someone years ago after they asked a question like "why don't they just build a factory here?". I was like "you need more than _a_ factory, you need a whole ecosystem of manufacturing". I guess I didn't make my argument clear enough based on their response.
I think the USA has been very clear based on our actions over the past 4 or so decades: we don't want this kind of labor in this country. I don't see any material changes despite the recent puff pieces and political grandstanding.
It is really unclear why you think that either the political interest or strategic logic of not wanting to rely on manufacturing in China, and having some on the value being created here goes away, or is some idle whim.
Sure, if it took decades of slow patient effort to create the current situation, it might take decades to unwind it. And, sure, the US political system is exceptionally bad at industrial policy.
But, at the end of the day, the political and military logic is, and will be for the forseeable future, get your supply chains out of China. Just because it is slow and difficult doesn't there is any reason to believe the pressure will relax. (Putting aside the possibility of an AGI/robotics revolution)
Language syntax is like the weather. When it's good (or when you're acclimated to it, I guess) you don't notice it. When the weather is perfect you don't even feel like the atmosphere even exists. When a language is so ingrained in your mental models, you don't even notice syntax, you just see semantics.
In the follow up article, I wrote something like this in the conclusion:
> Designing a language is more than just getting the syntax right, and denotation semantics are a lot more important in most ways, but that does not mean syntax does not matter. When you get syntax right, people won’t even know you’ve done anything at all. But when you’ve got it wrong (and have actually tried using the language), they will complain instantly.
If much of your value is tied up in reputation, as Apple's is, I don't see how you can rush into AI in its current state. It's too risky. If Grok tweets something racist, yeah that's bad but people will move on. If an agent on someone's iPhone leaks sensitive personal information or drains their bank account on mistaken purchases, that's a massive hit on Apple's rep.
I'm keeping my eye on progress in this area as well. I need to free engineering design data from tens of thousands of PDF pages and make them easily and quickly accessible to LLMs.
Exactly. CUDA is huge moat and all competitors must be adopting SOFTWARE first approach similar to what tinycorp is trying to do.
Find one single thing that makes CUDA bad to use and TRIPLE DOWN on that.
Why doesn't AMD make a similar framework than CUDA? Is this so much of a task? But if that increases their market share that should be financially viable, no?
ROCm is their CUDA-like and imo it's been a buggy mess, and I'm talking bugs that make your entire system lock up until you hard reboot. Same with their media encoders. Vulkan compute is starting to recieve support by stuff like llama.cpp and ollama and I've had way better luck with that on non-nvidia hardware. Probably for the best that we have a single cross-vendor standard for this.
Intel focused on SyCL which not many people seem to actually care about. It looks far enough removed from CUDA you’d have to think hard about porting things as well. From what I understand ROCm looks very close to CUDA.
It's also complicated by the notion that raster performance doesn't directly translate to tensor performance. Apple and AMD both make excellent raster GPUs, but still lose in efficiency to the CUDA's architecture in rendering and compute.
I'd really like AMD and Apple to start from scratch with a compute-oriented GPU architecture, ideally standardized with Khronos. The NPU/tensor coprocessor architecture has already proven itself to be a bad idea.
That may be true, but assuming you meant "within 30% of the performance" ... can we just acknowledge that is a rather significant handicap, even ignoring CUDA.
The customers are players that can throw money into the software stack, hell, they are even throwing lots of money in the hardware one too with proprietary tensors and such.
And the big players don't necessarily care about the full software stack, they are likely to optimize the hardware for single usage (e.g. inference or specific steps of the training).
I which no one cares about. As a 1% player having a convoluted C++ centric stack when the 99% player has something different e ouch porting requires critical thinking means no one gives a damn about it.
ZLUDA has more interest that SyCL and that should say it all right there.
Yes, that’s a good example — thanks for the link.
Tools like this seem very strong at visualizing and exploring state, but they still tend to stay fairly close to the traditional “pause and inspect” model.
What I keep struggling with is understanding how a particular state came to be — especially with concurrency or events that happened much earlier.
That gap between state visualization and causality feels hard to bridge, and I’m not sure what the right abstraction should be yet.
Sounds like you want a time travel debugger, eg. rr.
Sophisticated live debuggers are great when you can use them but you have to be able to reproduce the bug under the debugger. Particularly in distributed systems, the hardest bugs aren't reproducible at all and there are multiple levels of difficulty below that before you get to ones that can be reliably reproduced under a live debugger, which are usually relatively easy. Not being able to use your most powerful tools on your hardest problems rather reduces their value. (Time travel debuggers do record/replay, which expands the set of problems you can use them on, but you still need to get the behaviour to happen while it's being recorded.)
That’s a very fair point.
The hardest bugs I’ve dealt with were almost always the least reproducible ones, which makes even very powerful debuggers hard to apply in practice.
It makes me wonder whether the real challenge is not just having time-travel, but deciding when and how much history to capture before you even know something went wrong.
Sounds like you want time travel debugging [1]. Then you can just run forwards and backwards as needed and look at the full evolution of state and causality. You usually want to use a integrated history visualization tool to make the most of that since the amount of state you are looking at is truly immense; identifying the single wrong store 17 billion instructions ago can be a pain without it.
This doesn't sound like a particularly difficult problem for some scenarios.
It's definitely convoluted as it comes to memory obtained from the stack, but for heap allocations, a debugger could trace the returns of the allocator APIs, use that as a beginning point of some data's lifetime, and then trace any access to that address, and then gather the high-level info on the address of the reader/writer.
Global variables should also be trivial (fairly so) as you'll just need to track memory accesses to their address.
(Of course, further work is required to actually apply this.)
For variables on the stack, or registers, though, you'll possibly need heuristics which account for reusage of memory/variables, and maybe maintain a strong association with the thread this is happening in (for both the thread's allocated stack and the thread context), etc.
It's for embedded systems though, which is where I come from. In embedded we have this concept called instruction trace where every instruction executed with the target gets sent over to the host. The host can reconstruct part of what's been going on in the target system. But there's usually so much data, I've always assumed a live view is kind of impractical and only used it for offline debugging. But maybe that's not a correct assumption. I would love to see better observability in embedded systems.
For context, I’ve been experimenting with a small open-source prototype while thinking about these ideas:
https://github.com/manux81/qddd
It’s very early and incomplete — mostly a way for me to explore what breaks once you actually try to model time and causality in a debugger.
> I keep struggling with is understanding how a particular state came to be — especially with concurrency or events that happened much earlier.
Yeah, I faced this problem. I have no general solution to it, but I wonder if a fuzzer can be bred with a debugger to get a tool that can given two states of a program to find inputs that can transition program from state A to state B. Maybe you would need to define state A and/or B with some predicates, so they would be a classes of states. Or maybe the tool could fuzz the state A to see what part of it are important to transition to the state B eventually.
As an American, I feel like I'm sitting on the sidelines as the world, particularly China, zooms past us in the future of automobile technology, and more broadly, battery tech.
Yep. Exactly this. Can't buy BYD cars either. Going to have to a hard time selling Donut Lab batteries, attracting new talent, welcoming tourists, and more.. it's completely unnecessary self-sabotage by a hateful, felonious, child-diddling slumlord and failed reality star.
reply