I have heard this claim before. IIRC, it had to do with early Core 2 Duo processors being potentially out-performed by fast Pentium 4 processors.

That said, I can't recall seeing any benchmarks that prove this out.

Early 00's a big doubt (hardware T&L / DXTC was more of an emphasised leap starting from 2002), some games were just released infamously slow (Giants, Operation Flashpoint), the exact-high-clock-for-proper-gameplay games were more like shoddy xbox360 ports later in the decade like Saints Row 2.

Also in the early 00s, the Pentium 4's IPC was terrible compared to the P3 but Intel didn't want you to know that in their GHZ marketing approach.

eddman wrote on 2023-08-12, 20:55:

Came about this comment on youtube: […]
Show full quote

Came about this comment on youtube:

Back in 2010 there were games made in the early 2000s that literally could not run at high performance levels because the were build specifically to use the very high speeds of single CPUs and there were no longer CPUs on the market that ran threads that fast.

I asked which games but haven't gotten a response.

I'm not familiar with enough games from this period, but it still doesn't seem plausible to me that an i5 or i7 from 2010, or even any Core 2, couldn't soundly outperform even the fastest Pentium 4 in any game.

That does not make sense to me, or at least the explanation in the youtube comment does not.

I'm guessing that the reference is to Core2 series CPUs that were released after Pentium 4 CPUs. Core2 CPUs initially had lower clock speeds than the fastest Pentium 4 CPUs, but were always faster per clock (better IPC, aka instructions per clock) and significantly so, and this when looking at a single core of each CPU. Were there games that somehow broke on CPUs with very high IPC AND relatively low clock speeds ? Maybe, but I do not know of any.

There were however 3 phenomena (that I know of ) that initially broke some games :

a) Running some games that predated multi-core CPUs on such CPUs caused them to misbehave as thet were not prgrammed to expect some of their threads to be run on different cores (this may be oversimplified to the point of inaccuracy, but disabling all but one core or sometimes setting affinity in the OS to run such games on just one core would resolve the issue)
b) dynamic power management and clock adjustment in real time during gamex execution was also, AFAICR, an issue in some games (sometimes the opposite was true, see https://www.quake3world.com/forum/viewtopic.php?f=13&t=13363 )
c) Some games will either break, behave weirdly (or possibly slow down) if the CPU is too fast compared to what the game was designed and expected to run on.

This is what I remember from that time period, others here will surely keep me honest by pointing out and correcting any errors or misconceptions on my part.

Curse my bad memory, I was on a mission to find something else out last week and in passing came across a game benchmark with high Celeron D scores and thought to myself "Ohhh that's the one." and went merrily on my way. Buggered if I can remember now, might have begun with a T. By high Celeron scores, I mean it was just up there with similar core speed stuff not leading the pack.

Shponglefan wrote on 2023-08-13, 00:19:

I have heard this claim before. IIRC, it had to do with early Core 2 Duo processors being potentially out-performed by fast Pentium 4 processors.

That said, I can't recall seeing an benchmarks that prove this out.

Neither can I.

I'm guessing that at least some of this was spread by owners of 3GHz+ Pentium 4 CPUs who were in denial of the fact that a 1.86GHz Core2 E6300 beats a 3.6GHz Pentium D 960 (one of the last and fastest Pentium 4 CPUs).

EDIT : looks like I forgot to add the link that I wanted to refer to https://www.anandtech.com/show/2757/2

I've noticed Quake 3 performs rather well on P4, and seems to like its clock speed compared to P3 or Athlon.

Couldn't find proper performance numbers of it running on a Core 2 though.

leileilol wrote on 2023-08-13, 00:32:

the exact-high-clock-for-proper-gameplay games were more like shoddy xbox360 ports later in the decade like Saints Row 2.

Does that really run better on a higher clocked P4? It's really hard finding P4 numbers for such later games.

darry wrote on 2023-08-13, 00:45:

There were however 3 phenomena (that I know of ) that initially broke some games ...

Yea, those definitely affected quite a few games, specifically the first one. I can't recall which games, but IINM some would not even launch with multi-core processors.

BitWrangler wrote on 2023-08-13, 00:46:

Curse my bad memory, I was on a mission to find something else out last week and in passing came across a game benchmark with high Celeron D scores and thought to myself "Ohhh that's the one." and went merrily on my way. Buggered if I can remember now, might have begun with a T. By high Celeron scores, I mean it was just up there with similar core speed stuff not leading the pack.

Reminds me of all the times I came across things that I thought are interesting but not really worth bookmarking, only to regret it later.

Do you remember the genre of the game, or perhaps its general launch period?

leileilol wrote on 2023-08-13, 00:32:

Also in the early 00s, the Pentium 4's IPC was terrible compared to the P3 but Intel didn't want you to know that in their GHZ marketing approach.

I suffered from that so much back when my late father first got me a "Dell Dimension" desktop that had one of the early Pentium 4 processors and Rambus RDRAM too I think, what a nightmarish combo.

The prior Quantex tower he got me that had a Pentium II felt way more performant and less unstable than that Dell.

As for the subject in the OP; The only game I've played that really needed a fast CPU was Battlezone II: Combat Commander, and I even remember that having a "PIII Optimizations" that you have to switch on in the options menu. But if I recall right, if you don't specifically have a Pentium 3... it refuses to enable it even if you have a later processor that obviously supports KNI in the first place. (KNI "Katmai New Instructions" was the early name for the first SSE)

FIrst games that come to my mind are GTA 4 and Saints Row 2

I seem to remember reading that some NFS games had issues with running on Hyperthreaded processors without patches - I don't know if those would perhaps run faster on single-core chips

There was the multi-core hiccups some 2000s games experienced as dual cores were rolling out, like some crashing on load etc... but nothing performance related IIRC

Anybody programming a multithreaded application would know they need to use an SMP machine to properly test it. I'm a little amazed that any programmer, or the managers who should also know programming, thought they could ignore this even if it was "just a video game".
Another failing of bureaucracy, I guess.

A company that directs it's employees to use threads but doesn't test with SMP hardware is acting just smart enough to be dangerous.

shamino wrote on 2023-08-16, 15:21:

Anybody programming a multithreaded application would know they need to use an SMP machine to properly test it. I'm a little amazed that any programmer, or the managers who should also know programming, thought they could ignore this even if it was "just a video game".
Another failing of bureaucracy, I guess.

A company that directs it's employees to use threads but doesn't test with SMP hardware is acting just smart enough to be dangerous.

That is a "modern" perspective. For example, even early OS/2 in the 1980s was multithreaded but only ran on a single core CPU. Over the next few decades, lots of multithreaded stuff was written with the expectation that it would only run on a single core/CPU system (under Windows or whatever else). That expectation was reasonable, in the consumer sphere until multi core CPUs (and hyperthreading) became a thing. Some devs/management were not ready for this. Some probably took intentional design shortcuts that came back to bite them.

darry wrote on 2023-08-16, 16:50:

shamino wrote on 2023-08-16, 15:21:

Anybody programming a multithreaded application would know they need to use an SMP machine to properly test it. I'm a little amazed that any programmer, or the managers who should also know programming, thought they could ignore this even if it was "just a video game".
Another failing of bureaucracy, I guess.

A company that directs it's employees to use threads but doesn't test with SMP hardware is acting just smart enough to be dangerous.

That is a "modern" perspective. For example, even early OS/2 in the 1980s was multithreaded but only ran on a single core CPU. Over the next few decades, lots of multithreaded stuff was written with the expectation that it would only run on a single core/CPU system (under Windows or whatever else). That expectation was reasonable, in the consumer sphere until multi core CPUs (and hyperthreading) became a thing. Some devs/management were not ready for this. Some probably took intentional design shortcuts that came back to bite them.

Multi-CPU systems, while not quite "mainstream", were not that rare or even costly in the 2000s. It was getting more common with enthusiasts ever since the introduction of Slot-1, and it wasn't any secret that multi-core CPUs were likely to come along.
I guess I just don't see this type of bug as something that can be justified by "system requirements". A bug is a bug, and failing to test multithreaded code with multiple CPUs is a known way to miss bugs, and therefore careless IMO.
To be fair I think most developers did test properly. I never personally encountered a program with this kind of an issue, which is why I was surprised to read about the examples here.

I'll give a pass to the 1980s when SMP hardware was exotic. I'll also give a pass to independent developers in the 1990s.
I'll give a pass to the 2000s corporate programmers if I can assume that they did care enough about the quality of their work to ask for SMP hardware, but ignorant managers didn't give it to them.

eddman wrote on 2023-08-12, 20:55:

Came about this comment on youtube: […]
Show full quote

Came about this comment on youtube:

Back in 2010 there were games made in the early 2000s that literally could not run at high performance levels because the were build specifically to use the very high speeds of single CPUs and there were no longer CPUs on the market that ran threads that fast.

I asked which games but haven't gotten a response.

I'm not familiar with enough games from this period, but it still doesn't seem plausible to me that an i5 or i7 from 2010, or even any Core 2, couldn't soundly outperform even the fastest Pentium 4 in any game.

Yeah it's absolute BS. With early Core2-s there were some games that run better on a 3+ GHz Pentium 4 than a sub-2 GHz Core2, but by the late-00s high-end (in their price range) Core2 CPUs were also 3+ GHz (E5800; C2D E7600; E8400; Q9650). The problem became that some early 2000s games had stability issues with multi-core CPUs or that they run too fast with Vsync turned off, but that can be fixed with setting CPU affinity to 1 core and turning Vsync on.

Edit: Though I vividly remember reading reviews back in the day where a 3.4 GHz single core P4 occasionally beat a 1.8GHz E4300, I can't seem to find it.

Ah, I assume the catch phrase here is "single core performance".

Older CPU designs like the Pentium IV had stellar performance in their primary core,
at the cost of high power usage and heat.

By the time Windows XP and the Pentium IV with hyper-threading (HT) became popular,
games and applications were being optimized for multi-threading and made better use of auxiliary cores.

The semiconductor industry liked this approach, because it more or less ended the MHz/GHz race.
Instead of making the CPUs run stable at high frequencies, they focused on adding more and more cores to a processor's die.

Unfortunately, this doesn't do well with applications that must run in sync with all their sub-routines or which can't be spread accross multiple cores.

Edit: There's something else to consider, maybe.
On a single-core processor, all the caches and the whole pipeline architecture serve a single CPU core.
In a multi-core design, things like cache coherency and parallelism are difficult to handle.
At one point, multiple cores become difficult to maintain and a overhead.
Both for the hardware and the operating system.