> and corporate labs pick it up once it reaches the point where the basics show commercial promise.
How does that work when the research team moved elsewhere? Re-hire talent? That takes time - the 1 thing you don't have in a fast-moving field like AI. Post sums it up nicely:
"Do the math—how much is it worth to halve training and inference cost given that the industry has investments approaching a trillion dollars?"
How much is these researchers' salaries, compared to what MSFT spends on compute? Chances are it's peanuts in comparison.
Yes but you forget that spending on compute is spending on machines that the company owns while spending on researchers is spending on other apes that trigger the social hierarchies of executives brains and who have the dreaded key word of “rights”
Companies will try to ruthlessly rid themselves of labor as long as those members of labor have agency and rights.
If someone disagrees they can convince me by explaining why a company wouldn’t choose to spend X on a machine they wholly own vs X on an employee they don’t.
There’s some room for argument that employees can do more than machines can but in the current AI zeitgeist arguing that we have machines with equivalent to human intelligence I don’t see how you wouldn’t see this coming if you believed the zeitgeist.
If compute:people were roughly equal spend, I'd agree with that thinking. But we all know AI's 100s of billions $$ spend is on datacenters+GPUs, not people.
In a way this suggests that MS doesn't aim to be a leader in AI <the core tech>. Only in its applications + related services (read: profit to be had there).
Nothing wrong with that btw. But understandable that fundamental researchers then pack up & leave.
> But we all know AI's 100s of billions $$ spend is on datacenters+GPUs, not people.
That’s bolstering my argument. Companies are willing to spend a shit ton on machines. They are not only unwilling to spend on labor but are actively seeking ways to remove labor spend, even though this new technology supposedly makes every unit of labor significantly more productive and thus profitable.
This is a cultural choice not an economic one.
If I see a company laying off people while admitting they’ve maximized a niche and automation lets them increase profitably, or I see them go on a hiring spree because labor is now netting them 10x-100x-1000x-whatever productivity increase they claim, then I will believe them about the value add of AI.
Currently I see companies using AI’s productivity increase as a reason to cut labor and achieve roughly the same productivity.
They aren’t competing, they just want to cut out workers.
> Inputmon does have the enormous, un-auditable dependency of LLVM and Clang
You mean build-time dependency? Not a run-time one.
If that bothers you, there's simpler/smaller compilers out there (TinyCC and the Portable C Compiler come to mind, but there's others). Or drop down to assembly?
Coincidentally, I had Claude fix 18 bugs in PCC earlier this week actually. But PCC itself doesn't support the UEFI calling convention or PE32+ image format. Those can be provided by something much smaller and simpler than LLVM, of course, but I'm not there yet.
Well, articles about touching said hardware directly is exactly I'm missing here. As far as I can see, the only article about actual code is article 5, and that one is about "using EFI’s Simple File Protocol to read and write files". That doesn't qualify as bare-metal programming to me. Perhaps the goal is for those articles to appear later, but for now this is "prerequisites for doing bare-metal programming" more than "first steps".
Of course, I'm aware that doing actual hardware access on a complex platform such as x86 is massively complicated, which is why most bare-metal targets tend to use simpler platforms in the first place.
UEFI also provides block device and SCSI passthrough interfaces, and you're free to write your own drivers and poke storage controllers directly if you prefer, or for that matter, call ExitBootServices and then do anything the hardware itself allows.
Related: OSes based on persistent memory. As in: main RAM persists across reboots, distinction RAM <-> storage goes away, saving files & the whole concept of memory-mapped files can be tossed, code of any executable is always ready to jump to, etc.
But all the legacy operating modes too? A modern x86 cpu should only have 2:
# Full-on 64 bit, legacy cruft cleared out as much as possible
# A compatibility mode to run application code written for 32-bit protected mode OSes like Win2k/XP etc
And even that last mode could be optional. Any other legacy support is just waste of transistors imho (however 'few').
Intel made a move in that direction years ago (X86S). Sadly that went nowhere.
reply