[dead]
We were wrong about GPUs
601–604 of 604 posts
Re: We were wrong about GPUs
#602Side note: "we were wrong" - are there any more noble and beautiful words in the English language?
My favorite is "This too shall pass."
Re: We were wrong about GPUs
#603Earlier quoted context omitted.
Computers are still Von-Neumann machines, and other architectures lost out due to the great returns on investment for that architecture. However, in the AI world, this might not be the case. For instance, neuromorphic computing is one example, and there are others. Or back to analog again! Superposition is instant—no slow adders with carry bits to propagate! Who knows. Fun times!
Not always. Modern computers are like several computers networked into one, if you think about it. Since the DMA, that approach is not valid. Today we have IOMMU's. The 9front/plan9 guys are trying to write a kernel (Nix) which wants to exploit every concurrent core of your CPU at crazy scaling levels.
"Are trying" is a pretty generous phrase for something that seems to last have been thrown over the fence in one-commit repos about 5 years ago.
Re: We were wrong about GPUs
#604Earlier quoted context omitted.
No problem at all! I would be curious how the Attic server would have gone with a Tigris bucket and local caching. Not sure how hard that is to pull off, but Tigris should be substantially cheaper than our NVMes and if you don't really NEED the io performance you're not getting anything for that money. Which is a long winded way of saying "we aren't great at block storage for anything but OLTP workloads and caches".…
Tbh I haven't looked at Tigris at all. I still have my attic server deployed (just disabled/not in use) so I might give it a shot just to compare pricing. I do remember a decent portion of the cost being storage-related, so it's a good idea. I'll have to look at autosuspend again too. I remember having autostop configured, but not autosuspend. I could see that helping with start times a lot for some stuff. It's not s…
Necrobump.
I love fly. It's perfect for certain kinds of apps/sites.
https://github.com/jgbrwn/my-upc
For instance this is a python flask app, it uses an sqlite DB, but I wouldn't really call it dynamic nor needing state because the DB is read only (gets updated daily from an authoritative source, but a website user can only search the db). It costs about $3.50 a month, but could be less because I have two instances at the ready (although only one is ever active/up).
But if you start needing state or persistence on an instance down/up I'd probably not go with Fly myself personally..
But I think it fits the bill perfectly for like that sort of in-between static and true dynamic. Eg not exactly static (for truly static I'd just use shared hosting or CF Pages, etc, et al), but not really truly dynamic either or needing state. That's sort of the sweet spot in my view. Package up your flask or fastapi or FastHTML into a Dockerfile, send to fly, easy peasy, love it.
I can't wait to play around with FastHTML and fly btw, haven't done so yet.. also would like to play around with a Datasette DB instance on fly..