Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tracking developer build times to decide if the M3 MacBook is worth upgrading

incident.io

Post reply on HN
Print view View original

251–260 of 432 posts

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#251

Post by wtallis »

ComputerGuru wrote: post #240
white_dragon88 wrote: post #234

Earlier quoted context omitted.

5+ year old i7 are potato and would be a massive time waster today. Build times matter.

I have a seven year old ThreadRipper Pro and would not significantly benefit from upgrading.

The Threadripper PRO branding was only introduced 3.5 years ago. The first two generations didn't have any split between workstation parts and enthusiast consumer parts. You must have a first-generation Threadripper, which means it's somewhere between 8 and 16 CPU cores.

If you would not significantly benefit from upgrading, it's only because you already have more CPU performance than you need. Today's CPUs are significantly better than first-generation Zen in performance per clock and raw clock speed, and mainstream consumer desktop platforms can now match the top first-generation Threadripper in CPU core count and total DRAM bandwidth (and soon, DRAM capacity). There's no performance or power metric by which a Threadripper 1950X (not quite 6.5 years old) beats a Ryzen 7950X. And the 7950X also comes in a mobile package that only sacrifices a bit of performance (to fit into fairly chunky "laptops").

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#252

Post by notzane »

kaishiro wrote: post #165
rsanek wrote: post #137

Earlier quoted context omitted.

This might have to do with scale. At my employer (~7k employees) we started down this path a few years ago as well, and while it has taken longer for remote to be better than local, it now definitively is and has unlocked all kinds of other stuff that wasn't possible with the local-only version. One example is working across multiple branches by switching machines instead of files on local has meant way lower latency…

One thing I've never understood (and admittedly have not thoroughly researched) is how a remote workspace jives with front-end development. My local tooling is all terminal-based, but after ssh'ing into the remote box to conduct some "local" development, how do I see those changes in a browser? Is the local just exposed on an ip:port?

My company is fully using cloud desktops for engineering except iOS and Android development (we get faster laptops instead).

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#253

Post by kaishiro »

notzane wrote: post #252
kaishiro wrote: post #165

Earlier quoted context omitted.

One thing I've never understood (and admittedly have not thoroughly researched) is how a remote workspace jives with front-end development. My local tooling is all terminal-based, but after ssh'ing into the remote box to conduct some "local" development, how do I see those changes in a browser? Is the local just exposed on an ip:port?

My company is fully using cloud desktops for engineering except iOS and Android development (we get faster laptops instead).

Are you using a product or have you just rolled your own solution?

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#255

Post by ComputerGuru »

wtallis wrote: post #251
ComputerGuru wrote: post #240

Earlier quoted context omitted.

I have a seven year old ThreadRipper Pro and would not significantly benefit from upgrading.

The Threadripper PRO branding was only introduced 3.5 years ago. The first two generations didn't have any split between workstation parts and enthusiast consumer parts. You must have a first-generation Threadripper, which means it's somewhere between 8 and 16 CPU cores. If you would not significantly benefit from upgrading, it's only because you already have more CPU performance than you need. Today's CPUs are signi…

I guess I should clarify: I am a rust and C++ developer blocked on compilation time, but even then, I am not able to justify the cost of upgrading from a 1950X/128GB DDR4 (good guess!) to the 7950X or 3D. It would be faster, but not in a way that would translate to $$$ directly. (Not to mention the inflation in TRx costs since AMD stopped playing catch-up.) performance-per-watt isn’t interesting to me (except for thermals but Noctua has me covered) because I pay real-time costs and it’s not a build farm.

If I had 100% CPU consumption around the clock, I would upgrade in a heart beat. But I’m working interactively in spurts between hitting CPU walls and the spurts don’t justify the upgrade.

If I were to upgrade it would be for the sake of non-work CPU video encoding or to get PCIe 5.0 for faster model loading to GPU VRAM.

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#256

Post by Rapzid »

postalrat wrote: post #160

If you are working at home why bother with a laptop? You can get a much more powerful desktop for the same price.

I rock a workstation for this reason and that I also don't want a separate computer for other workloads(games, etc).

5950X, 64GB of RAM, Windows 11 + WSL.

An AMD based ThinkBook for travel.

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#257

Post by whynotminot »

maerF0x0 wrote: post #249
Erratic6576 wrote: post #40

Earlier quoted context omitted.

2,356 € is way over my budget. The machine is amazing but the specs are stingy. Returning it and getting a cheaper one would give me a lot of disposable money to spend in restaurants

Yes, you can get a lot more hardware for your money than buying the Apple Logo.

Not really in a laptop though—and certainly not with the same efficiency (battery life, fan noise, weight). If you want a laptop, the MacBooks are pretty indisputably king these days.

If a desktop is fine then yes you can build some great Windows rigs for much less money.

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#258

Post by MonaroVXR »

kaishiro wrote: post #171
avbor wrote: post #167

Earlier quoted context omitted.

You can expose the browser port via ssh, with a command line flag like `-L 8080:127.0.0.1:8080`. So you can still preview locally

Ah yeah, tunneling it back makes perfect sense - not sure why I never considered that. I'll explore that a bit - thanks for the heads up!

If you're using vs code, vscode is doing that automatically

Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading

#260

Post by unsung »

NavinF wrote: post #239
dash2 wrote: post #78

As a scientist, I'm interested how computer programmers work with data. * They drew beautiful graphs! * They used chatgpt to automate their analysis super-fast! * ChatGPT punched out a reasonably sensible t test! But: * They had variation across memory and chip type, but they never thought of using a linear regression. * They drew histograms, which are hard to compare. They could have supplemented them with simple me…

> cumulative distribution functions, where you can see if they overlap or one is shifted Why would this be preferred over a PDF? I've rarely seen CDF plots after high school so I would have to convert the CDF into a PDF inside my head to check if the two distributions overlap or are shifted. CDFs are not a native representation for most people

I can give a real example. At work we were testing pulse shaping amplifiers for Geiger Muller tubes. They take a pulse in, shape it to get a pulse with a height proportional to the charge collected, and output a histogram of the frequency of pulse heights, with each bin representing how many pulses have a given amount of charge.

Ideally, of all components are the same, there is no jitter, and if you feed in a test signal from a generator with exactly the same area per pulse, you should see a histogram where every count is in a single bin.

In real life, components have tolerances, and readouts have jitter, so the counts spread out and you might see, with the same input, one device with, say, 100 counts in bin 60, while a comparably performing device might have 33 each in bins 58, 59, and 60.

This can be hard to compare visually as a PDF, but if you compare CDF's, you see S-curves with rising edges that only differ slightly in slope and position, making the test more intuitive.

Post reply on HN