Ugh, you know it really wouldn’t be so bad if they would just go back to selling cpus like they're meant to be kept around for more than a year. The thing that has me really ticked off at Intel right now is the i915 sriov capabilities introduced in 11th gen which were meant to supersede GVT-G. I didn’t even know GVT-G was a thing until it was already gone. They didn’t even make a driver that supports 11th gen and 12th is apparently supported in some capacity but I’m not understanding it very well myself. I damn sure wouldn’t buy a 12th gen though if its a thing you think you might actually care about. If 11th gen is any example of how 12th will turn out, any development will be left up to one person who miraculously understands i915 well enough to develop for it, doing for free and doing a good job but not well enough to keep up with linus/linux~HEAD; needless to say if 11th gen support for i915 sriov does ever get merged the cheap low quality construction of the hardware will probably be starting to break down, seems like most of it is by the time you unbox it anyway these days :(
The Great CPU Stagnation
121–130 of 222 posts
Re: The Great CPU Stagnation
#122The perfect time to shed ourselves of the idea that "optimisation is a waste of dev-time". Mobile computing was the last godsent t actually rethink performance a little bit, but we still have a lot of relatively low-hanging fruit. I sometimes dream about a month-of-no-new-features, where everyone would just have a bit of time to clean up and improve on existing stuff.
OS and device manufacturers don't necessarily want to optimize. Optimization would reduce the hardware replacement cycle, cutting into their profits. Microsoft gets pressure from their hardware partners to keep up the hardware replacement cycle, and they themselves of course get a cut of that via OS licenses. Phone manufacturers seemingly invented "Always On Displays" to also cause people to start to think they neede…
Huh, the always on display on my S23 non-plus was only a 10% battery hit over a day or so. Still disabled it, of course.
Also nice that they've finally added an option on Samsung phones to only charge to 85%, but it would be nice if it had smarter options like on iOS. Eg, an option to charge up to 100% just before you expect to wake up, so you have the full charge but it doesn't sit at 100% all night degrading the battery.
Re: The Great CPU Stagnation
#123Earlier quoted context omitted.
I think two major revolutions would be optical and reversible computing. The former would significantly shrink the heat generated which is a huge bottleneck but is very hard to build generic computing out of and expensive. The latter would basically result in computing obtaining a new theoretical lower bound on energy required but is purely research with no known approaches for actually building the things. Asynchron…
Clockless designs did find their use, just not for the entire chips. Certain parts of modern CPUs are asynchronous.
Yeah, I'm just a bit surprised it didn't go further. Do you know what the reasons were that they couldn't make the entire thing clockless?
Re: The Great CPU Stagnation
#124Earlier quoted context omitted.
OS and device manufacturers don't necessarily want to optimize. Optimization would reduce the hardware replacement cycle, cutting into their profits. Microsoft gets pressure from their hardware partners to keep up the hardware replacement cycle, and they themselves of course get a cut of that via OS licenses. Phone manufacturers seemingly invented "Always On Displays" to also cause people to start to think they neede…
Huh, the always on display on my S23 non-plus was only a 10% battery hit over a day or so. Still disabled it, of course. Also nice that they've finally added an option on Samsung phones to only charge to 85%, but it would be nice if it had smarter options like on iOS. Eg, an option to charge up to 100% just before you expect to wake up, so you have the full charge but it doesn't sit at 100% all night degrading the ba…
iOS has an Optimized Battery Charging option that does something like that. You can't set a schedule, though - it's based on your usage patterns.
Re: The Great CPU Stagnation
#125I think you should factor in inflation. Inflation has been significant recently. Also you are not comparing to Intel's cost per core which would show that this pricing issue is not new. I think you just didn't notice it before.
Inflation has only been significant in the last 2 years max.
Re: The Great CPU Stagnation
#126Earlier quoted context omitted.
> CPU core count does not easily translate to performance gains. In theory, performance scales logistically with the number of parallel processors (Amdahl's law). In practice, the limit is (and has always been) memory and i/o. That's why Apple silicon kicks everyone's ass. If we want faster computers, the biggest gains are not to be found in making processors do more work. It's in designing systems (not just CPUs) th…
> That's why Apple silicon kicks everyone's ass. ??? But it doesn't: https://browser.geekbench.com/processor-benchmarks https://browser.geekbench.com/mac-benchmarks
*kicks ass per-watt
Re: The Great CPU Stagnation
#127Earlier quoted context omitted.
> CPU core count does not easily translate to performance gains. In theory, performance scales logistically with the number of parallel processors (Amdahl's law). In practice, the limit is (and has always been) memory and i/o. That's why Apple silicon kicks everyone's ass. If we want faster computers, the biggest gains are not to be found in making processors do more work. It's in designing systems (not just CPUs) th…
> That's why Apple silicon kicks everyone's ass. ??? But it doesn't: https://browser.geekbench.com/processor-benchmarks https://browser.geekbench.com/mac-benchmarks
Doesn’t Geekbench overwhelmingly measure raw CPU performance, whereas GP was talking about overall system performance? Isn’t this chalk and cheese?
Re: The Great CPU Stagnation
#128Ugh, you know it really wouldn’t be so bad if they would just go back to selling cpus like they're meant to be kept around for more than a year. The thing that has me really ticked off at Intel right now is the i915 sriov capabilities introduced in 11th gen which were meant to supersede GVT-G. I didn’t even know GVT-G was a thing until it was already gone. They didn’t even make a driver that supports 11th gen and 12t…
There’s actually 2, theres the intel lts one, which i guess they did do something it just never amounted to anything, explained here:
https://github.com/intel/linux-intel-lts/issues/33
The ongoing development:
Re: The Great CPU Stagnation
#129The perfect time to shed ourselves of the idea that "optimisation is a waste of dev-time". Mobile computing was the last godsent t actually rethink performance a little bit, but we still have a lot of relatively low-hanging fruit. I sometimes dream about a month-of-no-new-features, where everyone would just have a bit of time to clean up and improve on existing stuff.
It would be nice if every developer had to run their latest build on 10 year old hardware while testing it out.
Instead of their high-powered development machine with the latest CPU, tons of high speed memory, and the fastest SSD; they would get to experience what many of their customers have to endure on slower hardware with capacity constraints.
Nothing spurs optimization like seeing first hand how your code creeps along on slow hardware.
Re: The Great CPU Stagnation
#130Earlier quoted context omitted.
> CPU core count does not easily translate to performance gains. In theory, performance scales logistically with the number of parallel processors (Amdahl's law). In practice, the limit is (and has always been) memory and i/o. That's why Apple silicon kicks everyone's ass. If we want faster computers, the biggest gains are not to be found in making processors do more work. It's in designing systems (not just CPUs) th…
> In practice, the limit is (and has always been) memory and i/o Absolutely not. In practise the limit is (1) how many cores are actually _used_ by programs and (2) how much work is put into making anything fast at all, ever. We're using web frontends powered by python backends over a network. The vast majority of programs use nowhere near the resoures available to them.
Those backends are spending most of their time waiting to do work, which is my point.