It really depends on the workload. My old MacBook Pro feels the same as the newer model 98% of the time that I'm using it, but I really appreciate the extra RAM and double the core count when I need it.
Reducing build times from 30 seconds down to 15 seconds doesn't sound like much when you're not pressing the compile button very often, but it really does help improve my engagement and focus.
The newer graphics cards are also much better at handling large and high-resolution external monitors. The difference isn't pronounced if you're just using the built-in laptop screen, but start using multiple external 4K+ monitors and the faster GPU starts to shine.
1. If they previously had less than 4GB of memory and were often swapping
2. If they previously had a spinning HDD and moved to an SSD
3. If they previously had a really low end CPU like something outside the Core range, and moved to an i5 or better
Beyond that, all the other stuff is either a marginal performance gain or a convenience feature. The only other "must have" thing from the last few years that I wouldn't want to lose is a high res monitor, but that falls into the convenience category for me and not performance.
Power users like your family member got quantifiable benefit from performance upgrades over the years, but if they were already running decent hardware like a Macbook Pro, they didn't get any life altering upgrades. Taking 15 seconds to compile vs 30 is definitely faster, but you still have to sit and wait each time you push the button, so any habits that you learned from the 30 second pause will probably continue.
https://www.cpubenchmark.net/compare/Intel-Celeron-N2830-vs-...
It took 700ms or so for my server process to even start on a r.pi - I'd noticed a brief delay on my laptop, but it was so awful on the pi that I ended up spending the whole weekend profiling and optimizing. Anyway, come Monday I pulled the changes onto my fancy laptop and they made a noticable difference in subtle responsiveness. Everything just felt faster. I probably wouldn't have even noticed if I didn't spend that time programming on the pi.
Facebook has "slow internet thursdays" or something, where once a week developers can opt in to experience their internal facebook dev environments in the same way it feels for people on slow connections in poorer countries. I think that sort of thing would be good for all of us. Programming in constrained environments makes our software work better everywhere.
There are several race conditions in many webpages related to waiting for video or images to load.
Tangentially my late 2018 i5 MBA feels sluggish compared to my 2014 MBP. Simple things like switching windows are noticeably slower and janky. Unfortunately my 2014 MBP has an no longer supported NVidia GPU by Chrome/Firefox/Photoshop so I may have to upgrade but I know it will basically feel no different than what I have except I'll have the touch bar which I'm not really interested in.
I believe there is an option in the Performance pane to throttle the CPU in Chrome.
Some games supposedly have been optimised similarly by running parts of it on a C64 or Amiga. I cant recall the game or studio but John Carmack comes to mind.
This improves both motion quality and latency. When poorly designed software makes you wait multiple frames, halving (or better) the frame time makes a noticeable difference.
I think jitter is more important than FPS and until software has caught up (likely never) I would rather cap the frame rate at 60 FPS and experience that somewhat consistently rather than have such disparate performances.
It’s the same thing with retina/HiDPI. It’s amazing when everything is retina, but all the random bits and pieces of UI, let alone entire softwares, that appear blurry make for a worse experience than a strictly low dpi UX.
However, you are definitely correct when it comes to GUI productivity applications. Drawing text in boxes is apparently much harder than rendering an immersive world in real time. The implications are too disturbing to consider, so I do not.
https://github.com/GNOME/vte/blob/master/src/vte.cc#L10543
It's another harmful effect of mobile-first design. A trivial power saving gives measurably improved battery life, but the horrible latency is ignored.
...if you're playing with v-sync :-P. I got a (rather expensive too) 165Hz monitor recently and the main benefit is to lessen the lag that Windows' forced composition (which also does v-sync) has. But in games i always played with v-sync turned off (i do not mind the tearing, unless it only happens at a fixed position i never really notice it) and the responsiveness was already very high. And on Linux and older versions of Windows where i could disable the compositor, i already had high responsiveness on the GUI too (if anything i feel like even with the 165Hz monitor, the Windows 10 desktop is still not as responsive as Windows 7 and previous versions of Windows were with the compositor disabled).
Though a large issue with that is how modern monitors work. I also have a CRT connected to an older computer here which can do 120Hz and the motion feel is considerably better to the point where i wonder what the hell was wrong with people in the mid-2000s to switch away from CRTs when in pretty much every other area except size and weight, the CRTs were superior - especially at the time (better image quality, better and true dark colors, better responsiveness/no 'response time', higher refresh rates, higher resolutions, variable resolutions with no scaling artifacts, etc). In fact a reason i decided to try a 165Hz monitor was because i recently connected that CRT to a machine that can do 120Hz and have some games to run at 120fps and wanted that experience for my main PC too.
(sadly i do have a feeling that if i hadn't used a CRT the last few years i'd be more enthusiastic about my new monitor since i do not think the currently technology can do much better - at least without going to something like that gigantic $3k OLED monitor though even that would annoy me for its size)
High refresh rate monitors tend to support freesync or Gsync. For minimum latency disable vsync, enable free / gsync. Only enable vsync if your fps is above the monitors refresh rate. Alternatively you can enable a framerate limit just below the refresh rate.
Even supports VR. '80s Cyberpunk matrix here I come!
pulls out a virtual gun to kill a process dead
Take the same idea and put it into Unreal Engine. Add further OS interactions like files, maybe a floating virtual window for web browsing etc.
The UX has to be done very well though otherwise you are a prediction by TV show Community:
A lot of software, especially websites, have annoying waits for Vsync that are not needed in them.
When you update styles that triggers a reflow or repaint, then you can introduce a wait for VSync in your website thats stalls flow until it is finished.
If you add 3 frames of delay at 60fps then it's 50ms of delay, and only 25ms at 120fps. It doesn't sound like a lot, but that 25ms can be the difference between feeling totally fluid and not, and a lot of websites are even worse than that.
Software can be IO bound, Network bound, CPU bound, memory bound.
Modern software is Vsync bound!
The very, very first thing I did at my last company after migrating to a retina Macbook Pro was go into our monitoring systems and configure it to render the graphs at 2x size and then scale them down on the client.
These days, it's more like if they previously had less than 12 GB of memory and were often swapping. Having a few dozen tabs open isn't that uncommon and interactive websites (Twitter, Gmail, Google Docs) can use an enormous amount of RAM.
Examples:
https://github.com/Tecate/bitmap-fonts
If you're on 4K you can simulate how they look on 1080p with 2x integer nearest neighbor scaling.
The by current standards normal sharpness is nice too (1080 screens aren't really blurry, they're pixely).
I basically went back to 1080p because of this.
Eye resolution is ridiculously high. There's a reason companies started marketing 'retina' displays.
Small fonts will not always fall into discrete pixels which is especially true if the resolution is not very high. Which requires you to do antialiasing or mangle the characters.
Higher resolution displays allows you to render them more faithfully.
4. If they previously had an early generation of Core CPU like a Sandy Bridge that suffered great performance hit due to vulnerability, and then moved to an Ice Lake, or better, an AMD...
And heat up, unfortunately.
I'm completely fine with it getting loud and toasty when I push it, but the 5300M and 5500M in the 16" MacBook Pro ramp their memory clocks up to max as soon as two displays are on, even when idling. This results in a constant ~20W power draw that destroys the battery life, has the fans constantly audible, and makes the top case above the keyboard uncomfortably hot.
Apparently similar issues in desktop AMD cards have been addressed via driver updates, but considering whoever is responsible for updating Mac GPU drivers never actually does it, I'm not holding my breath.
I'd love to see the new processors and RAM in a 2015 enclosure. Makes me wonder whether someone has attempted to hack it together.
As one of may examples, set up an SMB3 connection to a network-attached storage device and then write a short program that uses two or three threads that walk a big director calling stat and lstat on every file. For large complex file hierarchies, Catalina (unlike Mojave) will start stuttering the entire UI and media playback.
"rclone" with --transfers=3 can bring a 2019 mbp to its knees, like Windows 3.1 writing to a floppy disk.
We’re actually planning on running that gear longer and moving people with more memory needs to newer gear with more memory — it’s all about the maintenance cost curve. We can get much more memory now with the same density, which offsets the CPU suckage.
I think much of the increase comes from going from dual core to quad core and perhaps not as much the single core gains, but still, I'd be curious what kind of software he's deving to not see much improvement.
If he's doing compiling or web-dev transpiling kinda stuff, I'm really surprised he's not seeing better gains.
Felt definitely faster than the 7200u I keep using, though I didn't get much of a chance to benchmark both. I also noticed that, despite having a much weaker battery (some 36W/hr mess), it managed to pull 6hs on a single charge, on merit of dropping to 1.2Ghz as fast as it could (though it quickly climbed to 3.4Ghz if required).
So results can be a little mixed. It’s clearly pulling more weight at lower clocks but lacks the high frequency performance of intel’s hella refined at this point 14nm process.
And that’s what makes Tiger Lake interesting. It’s all the good stuff Ice Lake has going for it, but now Intel is able to take off the training wheels.
Dollar cost per compute, Watt-hr/compute, latency, io bandwidth, running on real world workloads. The process size is a red herring.
Any increases in single node performance are not red herrings and should be called out. This is excellent news.
I'm in a not dissimilar position with my (older) personal laptop and my (newish) work laptop. Two things I notice:
* Battery life. My work laptop lasts longer on battery because it uses less power to do the same amount of work. Not really a problem 99% of the time when I'm plugged into an outlet. * Compile times. Work laptop is much faster at compiling, but this is really only noticeable on cold-builds. Incremental builds are fast enough in both cases.
I recently upgraded my monitor from a Dell U3014 to an OMEN 27i (it's gaudy and "gamer" oriented, but it was the best I could get in an afternoon at a physical store). That's an upgrade from a 60 Hz monitor to a 165 Hz monitor, and a significant (though not numerically measured so far) drop in input delay, some tens-of-milliseconds.
This has been the biggest improvement in "snappyness" that I've experienced since I moved to solid-state storage 10 years ago.
Really? i7-9750H (from 2020) scores more than twice as high in cinebench single threaded than i7-3615QM (from 2012)
https://hwbot.org/benchmark/cinebench_-_r15/rankings?hardwar...
https://hwbot.org/benchmark/cinebench_-_r15/rankings?hardwar...
I also notice windows starting up faster than it used to before, but I know its because of the SSDs and caching. These 20% and 30% YOY improvements are simply not worthy to invest in because the returns are negligible for me.
I just upgraded my 13" MBP from a 2017 i7 to the 2020 i7.
Single core benchmarks are basically the same but it's also running at 2/3 the clock speed, so much cooler. Plus two additional cores.
I'd say the same thing about upgrading from an i7-6800K (2016 Broadwell-E) to a Threadripper 3960X. Barely a difference (my main work is a ~250k loc c# solution, also a similar medium-ish sized Angular app).
Honestly, I think this speaks to the quality of Apple's hardware and engineering (8 years ago), combined with the lack of serious improvement from Intel lately.
That said, one thing I've noticed when doing IT and desktop support is that, unless someone's hardware is woefully inadequate, they won't notice a huge change going from slower to faster, but they will notice faster to slower after they've been using it for a week or two.
Anecdote: a family member and software dev just bought the latest macbook pro coming from about an 8 year old macbook pro. Apparently he doesn't perceive much real world performance difference between the 2 machines. He said single core synthetic benchmarks were higher, but not by much.