I know this may sound ridiculous, but m-maybe... maybe it's time for us to make software... less bloated? Maybe... just maybe, a TODO list app shouldn't run 4 processes, and consume hundreds of megabytes of RAM?
Hold on to Your Hardware
351–360 of 559 posts
Re: Hold on to Your Hardware
#352I don't buy the central thesis of the article. We won't be in a supply crunch forever. However, I do believe that we're at an inflection point where DC hardware is diverging rapidly from consumer compute. Most consumers are using laptops and laptops are not keeping pace with where the frontier is in a singular compute node. Laptops are increasingly just clients for someone else's compute that you rent, or buy a time…
Re: Hold on to Your Hardware
#353Earlier quoted context omitted.
> I personally dropped $20k on a high end desktop - 768G of RAM, 96 cores, 96 GB Blackwell GPU - last October, before RAM prices spiked […] 768GB of RAM is insane… Meanwhile, I’ve been going back and forth for over a year about spending $10k on a MacBook Pro with 128GB. I can’t shake the feeling I’d never actually use that much, and that, long term, cloud compute is going to matter more than sinking money into a sing…
> spending $10k on a MacBook Pro with 128GB. As someone who just bought a completely maxed out 14" Macbook Pro with an M5 Max and 128GB of RAM and 8TB SSD, it was not $10k, it was only a bit over $7k. Where is this extra $3k going?
Turns out the heatsink in the 14" isn't nearly enough to handle the Max with all cores pegged. I'd get about 30 seconds of full power before frequency would drop like a rock.
Re: Hold on to Your Hardware
#354I don't buy the central thesis of the article. We won't be in a supply crunch forever. However, I do believe that we're at an inflection point where DC hardware is diverging rapidly from consumer compute. Most consumers are using laptops and laptops are not keeping pace with where the frontier is in a singular compute node. Laptops are increasingly just clients for someone else's compute that you rent, or buy a time…
And I fear they will be equally confused and annoyed by disposing of all of them.
Re: Hold on to Your Hardware
#355Earlier quoted context omitted.
Local is a dead end. Open source efforts need to give up on local AI and embrace cloud compute. We need to stop building toy models to run on RTX and instead try to compete with the hyperscalers. We need open weights models that are big and run on H200s. Those are the class of models that will be able to compete. When the hyperscalers reach take off, we're done for. If we can stay within ~6months, we might be able to…
Man, going to personal computing was a mistake, we should’ve stayed jacked to the mainframes /s
Here's my retort: https://news.ycombinator.com/item?id=47543367
Re: Hold on to Your Hardware
#356Earlier quoted context omitted.
3D CAD/CAM is still CPU (and to a lesser extent memory) bound --- I do joinery, and my last attempt at a test joint for a project I'm still working up to was a 1" x 2" x 1" area (two 1" x 1" x 1" halves which mated) which took an entry-level CAM program some 18--20 minutes to calculate and made a ~140MB file including G-code toolpaths.... (really should have tracked memory usage....)
Is that by convention or is there a good reason that it’s so CPU bound? I don’t have experience with CAD, so I’m not sure if it’s due to entrenched solutions or something else.
A lot of commercial CAD software exists for a very long time, and it is important for industrial customers that the backward compatibility is very well kept. So, the vendors don't want to do deep changes in the CAD kernels.
Additionally, such developments are expensive (because novel algorithms have to be invented). I guess CAD applications are not that incredibly profitable that as a vendor you want to invest a huge amount of money into the development of such a feature.
Re: Hold on to Your Hardware
#357Re: Hold on to Your Hardware
#358I don't buy the central thesis of the article. We won't be in a supply crunch forever. However, I do believe that we're at an inflection point where DC hardware is diverging rapidly from consumer compute. Most consumers are using laptops and laptops are not keeping pace with where the frontier is in a singular compute node. Laptops are increasingly just clients for someone else's compute that you rent, or buy a time…
> Laptops are increasingly just clients for someone else's compute Are you kidding? Apple's mobile chips are now delivering perf that AMD & intel desktop never could or did.
Most applications don't make aggressive use of the SIMD instructions that modern x86 chips offer, thus you get this impression. :-(
Re: Hold on to Your Hardware
#359Earlier quoted context omitted.
The thing is, other than AI stuff, where does a non powerful computer limit you? My phone has 16gigs of ram and a terabyte of storage, laptops today are ridiculous compared to anything I studied with. I'm not arguing mind you, just trying to understand the usecases people are thinking of here.
> other than AI stuff, where does a non powerful computer limit you? Running Electron apps and browsing React-based websites, of course.
Re: Hold on to Your Hardware
#360Earlier quoted context omitted.
> The recent MacBook Pros are every bit as fast as my Zen 5 desktop for most tasks like compiling. Bad example. That's highly parallel, so a higher core-count die is going to destroy the base M5 here. I don't typically compile Linux on my M5, so I don't really care, but at least online available clang benchmarks put it at roughly half the LOC/s of a 9950X, which released in 2024. Anything single threaded it should ma…
> Bad example. That's highly parallel, so a higher core-count die is going to destroy the base M5 here. The base M5 starts at 10 cores and scales to 18 cores. The performance is similar to high end dekstop consumer CPUs. > I don't typically compile Linux on my M5, so I don't really care, If you don't compile large codebases, why do you care then? I do compile large codebases and I'm speaking from experience with the…
There's a large C++ codebase I need to compile, but it can't compile/run on OSX in the first place, hence the desktop that I use remotely for that. Since it's also kind of a shitshow, that one has really terrible compile times: up to 15 minutes on a high powered Intel ThinkPad I no longer use, ~2 minutes on desktop.
I could do it in a VM as well, but let's be real: running it on the M5 in front of me is going to be nowhere near as nice as running it on the water cooled desktop under my desk.