Intel's Meteor Lake CPUs are slower at single-core work than previous-gen models — new benchmarks show IPC regressions vs Raptor Lake
Intel's Meteor Lake CPUs are slower at single-core work than previous-gen models — new benchmarks show IPC regressions vs Raptor Lake
Single threaded performance was the only reason to go Intel.
Maybe this will push more game developers to develop games that use multiple cores? I know nothing about game development.
That has been happening for the last decade, but it’s really hard.
Most AAA game studios target consoles first. Their in-house or external porting teams will then adapt it for Windows, but by then major engine decisions will likely have already been made in service of supporting the Ryzen/RDNA based Xbox Series and PS5 consoles. Smaller studios might try to target all systems at once but aiming for the least common denominator (Vulkan, low hardware requirements). Switch is a bit of its own best when trying to get high performance graphics.
Multi threading is mostly used for graphics, sound, and animation tasks while game logic and scripting is almost always single threaded.
I wish all the computer parts companies would only release new products when they are definitively better rather than making them on a schedule no matter what. I don't want to buy this year's 1080p gaming CPU and GPU combo for more than I spent for the last one with the same capabilities, I want the next series of the same part to be capable of more damn it.
How's the performance per watt?
Oh wait. Nevermind, Intel sucks anyway. If it's not performance issues, it's hardware exploits. Not to mention Intel's support for genocide in Gaza.
The article mentions the results are probably because of Intel's focus on AI, but it's more likely that this was because of Intel's focus on making their chips use less power. Laptops with the new generation have a significantly better battery life.
wasn't Intel the one which raised the bar of TDP on laptop CPUs in the first place? so they could win in CPU benchmarks
On a technical level, it's hard to say why Meteor Lake has regressed in this test, but the CPU's performance characteristics elsewhere imply that Intel simply might not have cared as much about IPC. Meteor Lake is primarily designed to excel in AI applications and comes with the company's most powerful integrated graphics yet. It also features Foveros technology and multiple tiles manufactured on different processes. So while Intel doesn't beat AMD or Apple with Meteor Lake in IPC measurements, there's a lot more going on under the hood.
comes with the company's most powerful integrated graphics yet.
Not a particularly high bar there...
I wonder if these have increased ram latency due to the chiplet design. These are the first mobile chiplet I've seen, aside from desktop-replacements using am4/am5 ryzens.
Hopefully Anandtech will have more detailed look whenever they ever get their hands on a sample.
At how many watts?
Only a TJ’s worth.
https://www.notebookcheck.net/Intel-Core-Ultra-7-155H-Processor-Benchmarks-and-Specs.783323.0.html
Has various tests and results. Looks like TDP is 23 watts and the range during tests is 30-77 watts with one at 90 but given that it was tested at idle, I don't know what to make of it.
Say it with me: For the shareholders!
ITT: non devs that think multithreading is still difficult.
It's become so trivial in many frameworks/languages nowadays, its starting to actually shifting towards single threading being something you have to do intentionally.
Everything is async by default first class and you have to go out of your way to unparallelize it.
It's being awhile since I have seen anything mainstream that seriously cared about single thread performance enough to make it the most important benchmark.
I care about TDP way more. Your single thread performance doesn't mean shit if your cpu starts to thermal throttle.
Async features in almost all popular languages are a single thread running an event loop (Go being an exception there I believe). Multi threading is still quite difficult to get right if the task isn't trivially parallelizable.
Exactly.
Also every time I've used async stuff, I've pined for proper threads. Continuation spaghetti isn't my bag.
Wait, wat? Looking at first sentence. Also async != multi threading.
My goto for easy multi threading is lock free queues. Generate work on one thread and queue it up for another thread to process. Easy message passing and stuff like that. It doesn't solve everything but it can do a lot if you are creative with them. As long as you maintain a single thread ownership of memory and just pass it around the threads via message passing on queues, everything just sorta works out.
A lot of languages have an asunc/await facade for tasks run on a background thread for result (c#, clj, py, etc), but it's certainly not the default anywhere, and go most goroutines(?)/other csp implementations are probably going to be yielding for some io most of the time at the bottom anyway
Concurrent is not the same as parallel.
But concurrent execution is multithreaded. “unparallelize” is the only misnomer in the comment you replied to. Asynchronous execution is not necessarily concurrent, but often is.
However, a high TDP does not inherently mean that thermal throttling will occur, and there are countless everyday processes that are inherently sequential (“single-threaded”), so I still disagree with the comment on most counts.
I'm a software engineer. And yes multithreading is difficult, just slapping on async isn't necessarily going to help you run code in parallel
Think about the workload a game is using, you have to do most calcs on a frame by frame basis and you tend to want effects to apply in order. So you have a hard time running in parallel as the state for frame 1 needs to be calculated before frame 2. And within frame 1 any number of scripts can rely on the results of another, so you can't just throw threads at the problem You can do some things like the sound system but beyond that it's not trivial
many professional apps. solidworks comes to mind
as a dev, seeing you conflate "async" with "multithreaded" is painful.
And what you're saying is just not true anyway.