I mean there were mainframes which could be described as that. IBM just fixed it in hardware instead of software so its not like it was an unknown field.
Not the OP, but: -march says the compiler can assume that the features of that particular CPU architecture family, which is broken out by generation, can be relied upon. In the worst case the compiler could in theory generate code that does not run on older CPUs of the same family or from different vendors.
-mtune says "generate code that is optimised for this architecture" but it doesn't trigger arch specific features.
Whether these are right or not depends on what you are doing. If you are building gentoo on your laptop you should absolutely -mtune=native and -march=native. That's the whole point: you get the most optimised code you can for your hardware.
If you are shipping code for a wide variety of architectures and crucially the method of shipping is binary form then you want to think more about what you might want to support. You could do either: if you're shipping standard software pick a reasonable baseline (check what your distribution uses in its cflags). If however you're shipping compute-intensive software perhaps you load a shared object per CPU family or build your engine in place for best performance. The Intel compiler quite famously optimised per family, included all the copies in the output and selected the worst one on AMD ;) (https://medium.com/codex/fixing-intel-compilers-unfair-cpu-d...)
On every project I've worked on, the PC I've had has been much better than the minimum PC required. Just because I'm writing code that will run nicely enough on a slow PC, that doesn't mean I need to use that same slow PC to build it!
And then, the binary that the end user receives will actually have been built on one of the CI systems. I bet they don't all have quite the same spec. And the above argument applies anyway.
it certainly has scale issues when you need to support larger deployments.
[P.S.: the way I understand the words, "shipping" means "passing it off to someone else, likely across org boundaries" whereas what you're doing I'd call "deploying"]
If you use a cloud provider and use a remote development environment (VSCode remote/Jetbrains Gateway) then you’re wrong: cloud providers swap out the CPUs without telling you and can sell newer CPUs at older prices if theres less demand for the newer CPUs; you can’t rely on that.
To take an old naming convention, even an E3-Xeon CPU is not equivalent to an E5 of the same generation. I’m willing to bet it mostly works but your claim “I build on the exact hardware I ship on” is much more strict.
The majority of people I know use either laptops or workstations with Xeon workstation or Threadripper CPUs— but when deployed it will be a Xeon scalable datacenter CPU or an Epyc.
Hell, I work in gamedev and we cross compile basically everything for consoles.
We use physical hardware at work, but it's still not the way you build/deploy unless it's for a workstation/laptop type thing.
If you're deploying the binary to more than one machine, you quickly run into issues where the CPUs are different and you would need to rebuild for each of them. This is feasible if you have a couple of machines that you generally upgrade together, but quickly falls apart at just slightly more than 2 machines.
It isnt that weird. Just look at the gemini-cli repo. Its a gong show. The issue is that LLMs can be wrong sometimes sure but more that all the existing SDL were never meant to iterate this quickly.
If the system (code base in this case) is changing rapidly it increases the probability that any given change will interact poorly with any other given change. No single person in those code bases can have a working understanding of them because they change so quickly. Thus when someone LGTM the PR was the LLM generated they likely do not have a great understanding of the impact it is going to have.
Companies compete by optimizing margins. Lower margins, more sales, and more customers for more forward looking sale. Higher margins, more profit per sale.
That's a "fixed" constraint, because maximizing future adjusted value is what companies do.
So they don't play little games with mass products. If they did they would be harming their own bottom line/market cap.
(For small products, careful optimization often doesn't happen, because they are not a priority.)
Note this thesis explains what is going on here. What was previously one kind of customer (wide distribution of use), is now identifiably two. The non-automated token maxers (original distribution) and automated token maxers (all maxed, and growing in number). To maintain margins Anthropic has to move the latter to a new bin.
But the customer centric view also holds. By optimizing margins, that counter intuitively incentivizes reduced pricing on lower utilized products. (Because margin optimization is a balance to optimize total value, i.e. margins are not the variable being maximized.)
The alternatives would be bad for someone. Either they under optimize their margins, or change regular customers more which is unfair. Neither of those would be a rational choice.
(Fine tuning: Well run companies don't play those games. But companies with sketchy leaders do all kinds of strange things. Primarily because they are attempting manage contradictory stories in order to optimize their personal income/wealth over the companies. But I don't see Anthropic in that category.)
Those will dry up soon enough. Corporate laptop refreshes will be drawn out as they try and cost save on the increased price.
You also better hope the aliexpress dont figure out a way to get the RAM out of those things because they will start harvesting it for sure if there is money to made.
We're talking about a pi replacement. The Pi 5 is slower than a 10yo laptop. That's gives us a very vast pool of used laptops.
> You also better hope the aliexpress dont figure out a way to get the RAM
That is a real worry and I can see used machines being gutted because selling DDR3/4/5 sticks is way easier and profitable than the whole machine. Adapters for SODIMM to regular DIMM are readily available and cheap, too.
I recently did an install of Windows 11 on a machine without TPM
To bypass the check during installation:
Boot the laptop from your USB.
When you see the "This PC can't run Windows 11" screen, press Shift + F10 to open a command prompt.
Type regedit and hit Enter.
Navigate to HKEY_LOCAL_MACHINE\SYSTEM\Setup.
Right-click Setup, create a new Key named LabConfig.
Inside LabConfig, create two DWORD (32-bit) values:
BypassTPMCheck = 1
BypassSecureBootCheck = 1
Close the registry and the command prompt; the installer will now let you proceed.
It's a never-ending cat-and-mouse game, and unsupported hacks like these usually aren't well-received in corporate environments. Decent stop-gap for home use, though!
And worse, they're shucking surplus for RAM And SSD's now. I am seeing more and more eBay auctions for surplus PC's sans SSD and RAM. So the second hand market is going to be invaded by the reseller parasites leaving us with $50 CPU-in-a-box and $500+ RAM/SSD parts
The Pi isnt a loss leader for user acquisition nor do they get to enjoy Apples economy of scale. Apple can take a small loss on this and it will still be worth it if they retain the users in their ecosystem.
Is there any evidence that’s the case? They always had massively bigger margins than all other PC manufacturers so it’s unlikely they are selling it at a loss even if’s significantly reduced
For most older laptops it's easy enough, you just open them up and take the RAM sticks out. There are SO-DIMM to DIMM adapters to fit a laptop memory stick in a DIMM socket.
You can still write JS or TypeScript code that tries its best to keep memory use under check. JavaScript was around in the late 90s when the memory footprint of software was at least an order of magnitude lower, so it's absolutely doable.
You don't have to go that deep. 99% of the time our analytics or risk management teams have some really memory inefficient Python and they want me to write them one of our "magic C things" it turns out to be fixable by replacing their in-memory iterations with a generator.
Most people don't have the chance to do that, but hopefully we can see some other languages get first class access on the web. At least there is the whole WASM project.
I mean there were mainframes which could be described as that. IBM just fixed it in hardware instead of software so its not like it was an unknown field.
reply