Hacker News Reader

Comment by bzb3 | Hacker News Reader

Once again crushing the competition in single core performance, which is what matters.

/s ?

For my computer graphics and processing work, multithreaded tasks scale amazingly well with the number of cores so single core performance doesn't matter all that much. A single thread isn't even be able to process all the data that's streamed from an SSD. I need three threads just to process/prepare the data in the background, in addition to the main thread that keeps rendering.

I suspect it's only a matter of time until multithreading is a must for games. The additional programming effort may not have paid off if players only have 2 or 4 core CPUs, but now that 8 cores with 16 threads are increasingly common, it's going to make a difference.

AAA games have all but required quad cores (or at least 2c/4t) for years now. I think a lot of games already scale well to 4c/8t today.

Do they use those cores? Sure. But when I’m playing a game (even a game that feels like it should be ripping threads like Factorio) I usually see that one core is pegged at 100% while the others are chilling around 40-60% (I have an overclocked 8700K). In my experience, single core performance is still the bottleneck (as far as CPUs are concerned) for gaming.

Factorio is an indie game, I guess it might not be easy for indie developers to make use of multithreading, whereas AAA game developers have entire teams dedicated to engine development and multithreading.

Anyway, traditional graphics APIs like OpenGL are practically single-threaded. Modern APIs like DX12 and Vulkan have been designed with multithreading in mind and support scaling with number of cores much better (with added overhead of having to do manual synchronization).

> AAA game developers have entire teams dedicated to engine development and multithreading

Unity has been introducing a lot of features (Job System, ECS) that make excellent use of parallelism. Additionally, a lot of the engine internals are being rewritten with that as a base (and some of the old features get patched with APIs that allow access from multithreaded jobs). It's a lot of fun when the code you write by default runs on all of the cores, with (almost) none of the usual parallel programming headaches.

Pretty soon you should start seeing all kinds of indie titles making use of those features.

An 8700k has 12 threads. If the game was only capable of using 4 threads effectively, I would expect to see something like 1 thread at 100%, and the other 11 threads at 300/11 = 27%.

If all your threads are sitting at 40-60% you're using more than 4 threads worth of execution... (if all 12 threads were at 50% that would be 6 threads worth).

So, by the numbers you are giving, yes.

Usually operating system rotates threads between cores, so while you might see 60% on every core on average, on a given snapshop there will be 1-2 cores active at 100% while rest idle. Remember that CPU can't really work at 60%, core either works at 100% or sleeps.

the underlying simulation in factorio is pretty difficult to parallelize, since there is so much interdependent state. some systems that don't interact directly (eg, trains and belts) can be parallelized almost trivially, but subdividing these update jobs further is very tricky.

see this dev blog for more info: https://factorio.com/blog/post/fff-215

Yep, games like factorio and dwarf fortress are generally more memory bandwidth limited than direct CPU limited, and it can be very hard to split up those behaviors.

It is exceptionally unlikely that a game is both limited by memory bandwidth and not able to be parallelized further.

You might mean memory latency bound from serial simulations that need to calculate one piece to move on to the next, like an emulator or scripting language.

Gp comment mentions AAA. We PACK the core occupancy and for many titles, it’s essentially a ship requirement.

Remember that both current gen consoles are ~8 core AMD CPUs. Anything that runs on those will have to be pretty good at using all of them

Precisely. Not only that, most games that run on consoles are generally NUMA aware and use NUMA aware algorithms.

No they aren't. There's no NUMA console on the market, why would anything be NUMA aware?

You're kidding me. Half the multithreaded PS4 optimizations I needed to make were related to atomic interlock exchanges over the numa boundary.

The PS4 is described as having 8gb of main memory. Unlike computers and older consoles, there isn't even a distinction between what is "System RAM" and what is "Video RAM". Can you elaborate how that is NUMA?

That's a very simplistic view of the architecture. Consoles in general have multiple CPU complexes and caches that do not straddle the boundary, and also multiple memory buses.

Are you referring to the multiple CCXs as different "NUMA" nodes? Because they aren't, they still share the same memory controller. There isn't a shared cache, true, and that does have performance implications but that doesn't make it NUMA.

If you can point to anything to support your NUMA claim that'd be highly interesting, but all the block charts & teardowns I can find show it's clearly UMA.

Yes, recent games do. For example, Doom Eternal can max out all CPU cores.

Not utilizing all cores fully means that the CPU is more powerful than the game needs, not that the game is unable to exploit many cores.

For example, at 3 GHz and 30 FPS, there are 100 million cycles per frame. If the game requires 250 million cycles per frame spread between a few threads, it will never need more than two cores and a half in aggregate, plus waiting; and with 10 cores used 10% there's more time to wait without dropping frames than with 3 cores over 80% load.

It's sad to see even on HA people have absolutely no idea what they're talking about when it comes to CPUs. Nothing requires multiple cores. Nothing.

That's nitpicking semantics. They mean anything less than a quad core (excepting some hypothetical ultra high clocked single core cpu that doesn't exist) would heavily bottleneck most modern games to the extent that only pretty low end GPUs would even be worth using.

They said "require" as shorthand for that because they (apparently wrongly) expected people to follow the "strongest plausible interpretation" rule.

So the latest games require the latest CPUs? Well, no shit. The points I'm referring to are where the comments above say that games need multi-threading, or need multiple cores. Both are absurd statements. They try hard to do multiple threading only because multiple cores is what they CPU manufacturers are giving us. Nobody wants, much less needs, multiple cores.

CPU manufacturers are giving us multi core CPUs because it's no longer practical (because of heat and power draw) to just keep scaling frequencies. People are saying that you need multi core CPUs because there are no single core CPUs in existence that are fast enough.

You're talking past everyone because you're arguing hypotheticals, and assuming everyone else is also talking about hypotheticals, but they're not.

Just check the original context. "Best single core performance, which is what matters". There are no hypotheticals. Single core performance exists.

Look at the other replies. People who don't understand the difference between concurrency and parallelism. These people actually think multiple cores are a good thing.

What you don't seem to understand is that CPU manufacturers could have scaled up performance while still delivering a single core. They went the multi core route because it's much easier for them.

Their marketing departments have won, though.

No, the went multicore because 5 GHz is the physical limit for modern semiconductor processes. And IPC is also hitting its limits.

It might actually be useful to have a second core, to service hardware and peripherals. This way you'd have smoother performance, because you would not need to flush the cache on every interrupt.

Assuming the same power budget, same cooling, same semiconductor process, both x86, etc. the best single core you could make would lose to just two cores off a desktop chip you can buy today, let alone 8/10/12.

It depends on workloads. Computer graphics and processing work may be easier to remove single-threaded bottlenecks.

The gap is pretty small, even now, and Zen 3 comes out in a few months.

The value proposition of these chips is pretty bad, as well. Enormous power and cooling requirements, short-lived motherboard sockets, and sheer price/performance ratio are all not great in comparison.

Matters for whom? For a lot of use cases (web servers, compiling, databases...) having lots of cores matters (and total = performance of core * number of cores), for others it doesn't.

No, it does not matter. That's a common misconception. If you double your core count you can run double the number of threads in the same amount of time. That's it. If you double your single core speed you can still run double the number of threads in the same amount of time or the same amount of threads in half the time.

Single core performance is always preferable for CPUs.

The CPU manufacturers basically conned everyone into thinking multi-core was "good enough". Software people who knew what they were talking about back in the day called them out on it but nobody listened. Now here we are on Hacker News in 2020 and people still not understanding this.

We all know that a single core with twice the performance and twice the cache space is generally better than two cores (though a sibling comment does raise a good point that poorly written software can lock up an entire core regardless of it's Hz, also some VM scenarios would prefer extra cores over faster cores).

We also all know that a single core with twice the performance and twice the cache space costs a lot more than two cores. It's a lot more expensive than even 3 cores.

I'd rather have 3 4Ghz cores than 1 8Ghz core (except for the novelty value).

We all know that a single core with twice the performance and twice the cache space is generally better than two cores

I'm not sure that's actually true, even if you want performance (although it's dependent on whether your workload can use more than 1 thread, of course): A single core at a higher clock speed might be better if it can hold that clock speed. But the faster you run, the more power you use and the more heat you produce, and worse, the relationship isn't linear. So ex. 1 core at 4ghz won't stay at 4 ghz, where 2 cores at 2 ghz can hold that speed forever.

Right, when I say an xGhz core I'm pretending to live in a simpler world where they can all hold that speed forever. Consider an 8Ghz core to be a core + cooling that can consistently hold a speed twice as fast as the 4Ghz core + cooling can hold.

> We also all know that a single core with twice the performance and twice the cache space costs a lot more than two cores. It's a lot more expensive than even 3 cores.

I'm a programmer, I don't care how much it costs the hardware manufacturer. I want a single core. Multi-threaded programming sucks. I don't care if that's implemented via multiple cores acting together and only presents itself as a single core. I just want a single core.

> I'd rather have 3 4Ghz cores than 1 8Ghz core (except for the novelty value).

I'd much rather avoid multi-threaded programming and get the 8GHz core. But your comment is missing the point, really, which is that single-core performance matters. If the 8GHz core existed then you'd still be able to get 3 8GHz cores. Still want the 3x4GHz?

8Ghz cores do exist if you have enough money to hire someone to deal with the overclocking for you (or enough liquid nitrogen and time to do it yourself).

I, on the other hand, care about the cost of my computers a bit more than that, not having infinite money. Which is why even if 8Ghz cores were commercially available I suspect I would still be buying 3 times as many 4Ghz ones.

A Bulldozer FX barreling down the highway at over 8 GHz is actually still slower than any modern CPU at less than half the clock speed. The latter also doesn't require LN2 cooling and doesn't draw more than 100 W for a single core.

> If the 8GHz core existed then you'd still be able to get 3 8GHz cores.

Well no. Right now you can get ~5GHz cores and they draw close to 300 watts per core, which is why they can't run all cores at 5GHz on threaded programs. For the same amount of power as one core at 5GHz you can get 64 cores at almost 3GHz, e.g. ThreadRipper 3990X.

An 8GHz core would presumably draw 500+ watts per core and maybe even a lot more than that. To get the same performance as the 3990X, you would either need a single 185GHz core (basically impossible) or >23 8GHz cores (expected power draw >11kW). That would cost thousands a year in electricity, but a normal 20 amp household circuit breaker would trip before you hit 2.5kW anyway.

More than that, by the time you write code that can scale to 16+ threads, 64 isn't that much harder, and 256 isn't much harder than that. So get used to it, because in a few years there are going to be 256-core mobile devices and 1024+ core desktops and servers.

globular-toast seems to be arguing past everyone because they're imagining a reality where

a. these hypothetical ultra high clocked single core CPUs actually exist, and

b. they have unlimited spending money and don't care at all about power usage or cooling.

You seem to be arguing about a hypothetical situation where an 8ghz single core CPU is a thing that exists, whereas everyone else is talking about reality. Good luck scaling a single core to match the performance of 16 ~3.5ghz cores (That's a thing that exists for not unreasonable cost in the Ryzen 9 3950x for example)

It's not a hypothetical. Intel delivers the best single core performance and that matters. That's what we're talking about.

So say I'm close to maxing out my 8c/16t CPU, would a better alternative be a 16*4; 64Ghz single core processor? Why?

You wouldn't have true parallelism then, would you? So if you have something, for whatever reason, blocking further processing, the entire computer would lock up. Why is this a better scenario again?

You don't care about parallelism, you care about concurrency. Operating systems have handled that just fine for many decades now.

> You wouldn't have true parallelism then, would you? So if you have something, for whatever reason, blocking further processing, the entire computer would lock up

That doesn't occur because the OS scheduler will eventually pre-empt your thread and swap to another task. You don't really have control over that. All modern OSs use pre-emptive multitasking and there's not a ton you can do to prevent it.

(read: anything in the last 30 years, last cooperative multitasking I remember was MacOS Classic (probably like OS7 or so.)

Single-core processors were the norm up until 15 years ago, and people routinely ran more than one process on them. Yes, we ran Discord (we called it Roger Wilco or Teamspeak back then) and played music in the background too, without 4 dedicated cores for the background tasks.

Yes, in the abstract it would be preferable to have a 64 GHz processor instead of 16 4 GHz processors, because then you can have all that speed devoted to a single task. Context switching is not that expensive (particularly if you have hyperthreads/SMT to soak up the wasted cycles). The physics of transistors make that impossible, but we absolutely would not do any of this multithreading crap if we didn't have to. Single-threaded code is easier to write and usually faster (in terms of less total cycles - multithreaded programs waste extra cycles on synchronization, overhead, spinning for locks, etc that single-threaded programs don't have to).

> (read: anything in the last 30 years, last cooperative multitasking I remember was MacOS Classic (probably like OS7 or so.)

I remember reading about that a while ago. Wasn't everything up to and including Mac OS 9 cooperatively multitasked?

Looks like it was cooperative until OSX actually. I just remembered that it was a loooooong time compared to other desktop OSs.

> With the release of System 7, the MultiFinder extension was integrated with the operating system, and it remains so in Mac OS 8 and Mac OS 9. However, the integration into the OS does nothing to fix MultiFinder's inherent idiosyncrasies and disadvantages.[11] These problems were not overcome in the mainstream Macintosh operating system until the MultiFinder model was abandoned with the move to a modern preemptive multitasking Unix-based OS in Mac OS X.

https://en.wikipedia.org/wiki/MultiFinder

Plenty of embedded systems still use cooperative multitasking.

Turns out this has been tested, and the results are clear: Running a single core 9900k is pretty bad in comparison to 8 heavily downclocked cores on the same CPU. While single threaded tasks are obviously slower, frame rates are much more stable, windows is more usable with 8 cores. Several games simply didn't work with a single core, or took ages to load. Reference: https://youtu.be/feO54CBUJCk

The video you linked is pretty weak; there was (understandably) no performance tuning done on both configurations (Windows scheduler, game scheduling).

https://static.googleusercontent.com/media/research.google.c...

This is because for a fair comparison you need to scale the L1/L2 cache size as well. More cores - more cache. It is also important to not scale below 2 cores, because servicing interrupts causes performance hiccups. It is enough to have the second core heavily downclocked, and you'll still have better performance then with just a single core.

> same amount of threads in half the time

Sure, if you forget all the additional cache evictions, memory reads and writes and TLB flushes caused by all the competing threads on a single core. Not to mention that one shitty bit of code in one thread can poison the cache enough to re-read the data from memory every context switch.

While I agree this post should be downvoted I do think it's worth mentioning at least two different reasons why higher clock speed would push me to intel this generation: AutoCAD and Europa Universalis IV. Those are my two principal demanding softwares where they cannot see any real means of moving past single core for the vast majority of processing.

Depends on workload, and we've seen that with the latest round of AMD offerings. As a gamer, yes, but that's really it.

Are there actually games that take advantage of a CPU this fast? I would imagine that all the game developers would be targeting the more modest hardware that most of their players actually have.

Generally those with the top end CPU have the top end GPU and the top end monitor. In that regard all the game has to do to "take advantage" of the CPU is support high or unlocked framerates and high resolutions.

> Generally those with the top end CPU have the top end GPU and the top end monitor

I sort of doubt this is true, if only for the reason that most people don't buy a new CPU, GPU, and monitor at the same time. monitor and pc are probably going to be on different upgrade cycles, unless the monitor came with the pc (in which case, probably not "top end"). for DIYers, the GPU and CPU+RAM+mobo are likely also on different upgrade cycles.

I bought my current 4K monitor about four years ago, but I ran most games at 1080p until I had enough spare cash to buy a 1080 ti. I finally upgraded my CPU, RAM, and motherboard this year, mainly because I was tired of having 8GB of DDR3.

in any case, it's usually not a rational use of funds to buy the fastest CPU and GPU for a 4K monitor unless your budget is unlimited. with a constrained budget, it's usually better to drop a tier or two on the CPU if it gets you the next higher tier GPU.

Anything high refresh rate(120+Hz) benefits immensely from these high clock rates.

The high clocks result in less pipeline stalls meaning your high frame rates are more achievable as well as significantly reducing the dips (0.1% lows is what every reviewer hates).

This isnt about "average", this is about having the best experience possible, which Intel provides in this very specific scenario.

Intel has three things going for it(in the consumer space), which matter a lot or not at all to different folks:

    - better idle/low usage power consumption than AMD (low load laptop battery life)

    - Intel's QuickSync is fantastic for media encode/decode (NVENC is typically better, AMD is basically non-existent)

   - Intel has the highest clock rates.

Outside of these niches, AMD is dominating at every level of the product stack.

> better idle/low usage power consumption than AMD (low load laptop battery life)

I don't think this point is true anymore for the latest laptop processors.

It's certainly closer than it has ever been, the mobile Ryzen 4000 series is a massive improvement across the board. At the high and medium end, it completely dominates Intel.

Where Intel still rules (in x86 land) is that all day battery life. They're simply better, for now. I think mobile Ryzen 5000 may take over even that niche, but it remains to be seen.

From all the tests I've seen, AMD has a power consumption advantage compared to intel. This directly translates into longer battery life. While there's probably situations where Intel has better battery life due to software maturity, we've already seen tests where in low load situations amd is beating intel. During high load it's not even a competition at this point.

Intel started getting serious about system battery life with Centrino and AMD is still catching up a bit, though they're doing that very rapidly.

EDIT: Celeron -> Centrino

VR games, and simulation games tend to have high single-core CPU speed requirements for smooth play. Mostly though this is due to outdated engines (in the case of sims) or inexperienced/indie devs using premade engines like Unity and Unreal in a way that loads mostly a single core. Some tasks like physics, sound, texture loading is pretty easy to put on separate threads but thats usually a small fraction what bottlenecks a CPU in a game.

Eh, my i5-4440 had zero trouble running current VR games at 90hz, including while doing other things like playing Spotify or running music from a web browser, or even streaming and recording.

Simulation titles and open world titles tend to be very sensitive to per-core performance and memory latency (there is in fact noticeable performance scaling on these titles with faster memory even on Intel architectures - Fallout 4 is up to 20% faster going from DDR4-2133 to DDR4-4000).

https://www.techspot.com/article/1171-ddr4-4000-mhz-performa...

I've seen some people on Reddit running modded Skyrim (can probably throw Fallout 3/4/etc into that bucket as well) who are really mad about the performance of their Zen2 processors. ARMA3 probably runs poorly. That kind of thing.

Also, DAW performance is not very good on Zen.

That said, even in games that use more threads, there is often noticeable performance scaling from having faster per-thread ("single core") performance because there is one thread that is bottlenecking everything else. No real-world game ever has the magical 0% serial code necessary to scale perfectly according to Amdahl's law. It is just a question of whether that scaling starts dropping off at 6 cores, or 8 cores, or maybe 10 cores. Very few games can saturate a 3900X or 3950X yet, maybe Ashes of the Singularity but I doubt much else.

> Also, DAW performance is not very good on Zen.

Why is this? It's something I've heard a lot but I don't understand why. Is it something fundamental about audio, or is it simply the case that The Application With the Mindshare isn't architectured in a way that multithreading works well?

Personally, my day job is working on a program that could support 4-16-64 threads just fine, but since a lot of the core architecture is from the 90s and there's a giant ball of globals, component object model/single threaded apartment spaghetti deep under the hood, multithreading even trivially parallelizable tasks is fraught with peril. Fortunately for my employer, we are an entrenched 800 pound gorilla, and we can skate on momentum while these issues get fixed. So I totally understand if it's the same in a specialized space like DAW.

re: Skyrim. That engine is a fork of a fork of an engine that was written in 1997. Skyrim ran like garbage when it was released in 2011. It has nothing to do with open world or so forth, it's just run of the mill legacy architecture problems. ARMA3 (released 2013) is in a similar boat- it's a very old game engine written by a very small (they're not indie, but they're close) development studio. Both of these studios have the same problem my employer has- they have a bunch of legacy cruft that's difficult to migrate away from.

There's a tipping point somewhere. With two physical cores, you don't gain that much from farming stuff out to the different cores. A lot of multithreaded stuff from that era had a sequential-concurrent model. Your one large task was broken down in a sequential series of subtasks. (usually it was gather input, do AI, do physics, do drawing) Sometimes those subtasks would break out into N threads, which do a small amount of stuff in parallel, then there's a "join the world" event, you move on to the next subtask. Think links of sausages; sometimes it's wide, sometimes it's narrow, but you never have two sausages at the same time. This model is very sensitive to single threaded performance, because all of the join the world events are single threaded, and at the end there's a giant pile of single threaded calls to OpenGL which is a single threaded API.

We're steadily moving away from that. First of all, the game loop went from having a giant mutable ball of state, to having a generational immutable world state. One pile of threads would compute world state generation N+1, and a second giant pile of threads would draw world state generation N. Both would depend on generation N, but since generation N was immutable, that was fine. This can be broken down further- it's fine to generate new AI priorities for gen N+1 using the physics state from gen N, and use the AI priorities defined in gen N to do physics to generate gen N+1. So AI and physics can happen on independent threads. This can be broken down further- chop the world up into zones, and give responsibility for each zone to individual jobs. We're also switching from OpenGL (with its internal state machine, single threaded API) to Vulkan, which has completely blown open the drawing steps. I think Valve did some benchmarking where where the single threaded chunk of OpenGL took 5ms, (which is an eternity) but the single threaded chunk of Vulkan was ~1 microsecond. The 4.999ms of CPU time still exists under Vulkan, it didn't just go away- but now it can happen in parallel on multiple threads. Instead of having 3-20 join the world events each frame, there's only one, and the only thing that happens there is a pointer swap.

The industry is moving away from single threaded engines like ARMA3's and Bethesda's in house engines. For the most part, AAA games since ~5 years ago properly utilize multiple cores. ARMA3 and Skyrim are dinosaurs, and they've aged about as well.

Minecraft comes to mind. People looking to host a server usually need good single core performance depending on how many players there are and mods installed

Simulation games like Factorio, Rimworld, Kerbal Space Program, Dwarffortress etc use 100% of single CPU and <10% of others. In factorio, I can make ginormous factories that are bottlenecked by a single CPU. Sometimes say my factory produces X rockets per game-minute. I make a bigger factory that produces Y rockets per game-minute where Y >> X but since now CPU cannot handle the load I now produce <X rockets per real-time minute. So making my factory bigger was a net negative in terms of rocket per real-minute.

Just the fact that it's yet another socket for basically the same process is insane. On AM4 I've been able to use their low-end to very-high end CPUs for the last several years and most likely will be able to use the ones coming out this year too.

We should all wait for real world testing. IIRC AMD and Intel test their performance differently.

Intel tend to give turbo performance which can only run for so long before heat becomes a problem.

Looks like GN already has a video out, so I imagine the rest of the big hardware channels will follow along quickly. Don't have time to watch GN's video now, but I bet they'll have taken a nice in-depth look at the performance.

I think part of the reason why you may be being downvoted has to do with the tone you're using in making your statement as well as the newness of your account.

Also, though you're statement is technically correct, it fails to account for the nuance that increasingly across all applications, not just gaming, multi-threaded processing performance is becoming the far more important benchmark to look at.

> crushing...

crushing adjective [usually before noun] used to emphasise how bad or severe something is

I had to check the dictionary just in case. And in this case neither was it technically correct, or downvoted because of the tone. I downvoted it because it was factually wrong.

Zen 2 actually has better IPC than Skylake in many cases, on a sustained single thread performance they are likely to be on a similar level despite having a slightly lower clock speed disadvantage on a much lower TDP.

Hardly crushing.

Not really... If you look at the FPS numbers, sure AMD is slightly lower. However AMD can also perform other functions like encoding/decoding. If you want pure FPS, sure Intel will win. For general computing AND gaming, AMD wins every time per dollar.

... for gamers playing single-threaded games.

To be fair, that's exactly the target market for high end desktop CPUs like this. This isn't a datacenter part, and other parallel workloads tend not to make up much share of the personal workstation market.

If you want to max out gaming benchmarks right now, this is your CPU. And there are a decent number of people who do, so heavily tuning existing dies (I mean, let's be honest, this a rebinned and overclocked 10900X) makes sense.

When people say "single-threaded performance" they don't mean literally one single thread will ever be used. The single-core performance is a proxy for performance-per-core and that's a certainly a very important number.

Intel's per-core performance is decently higher in gaming, between their lower latency giving them slightly higher IPC in gaming tasks[1] (as these are latency sensitive) and the much higher all-core clocks they are pushing (at least 10% higher than AMD at present). That still gives them an edge in gaming, although certainly much less of an edge against Zen2 than it was against Zen1 (which was much worse than people were willing to admit at the time, people at the time were benching it with a GTX 1080 (the fastest card available at the time) at 1440p and 4K and claiming there was "no noticeable difference", but faster GPUs showed the weakness).

I think the 10700F looks good, 4.6 GHz all-core 8C16T part for under $300 looks compelling for gaming customers if you can keep it cool. The 10900K fills the "I want the top gaming performance first and foremost, with as many cores as I can get, and I'm not super concerned about budget" but is definitely on the expensive side. Other than that, nothing terribly impressive here IMO, the other chips fall into a range between "not fast enough" and "not cheap enough".

[1] https://www.techspot.com/article/1876-4ghz-ryzen-3rd-gen-vs-...

> The single-core performance is a proxy for performance-per-core

A very bad proxy then, since performance-per-core with multiple cores in use will almost certainly be limited by constraints on (1) memory bandwidth and (2) power/thermals. "Single-core performance" only applies when you're literally pegging one core at 100% cpu.

Well, all I can say is that enthusiasts expend a lot of effort getting per-core performance as close to single-core as they can ;)

Pure single-core turbo is usually a bit higher than all-core turbo, but as a proxy it's surprisingly close. A 9400F (so, no hyperthreading, we are removing that variable) scores 2380 in CB R20 (AVX2 aware). As a 6C, that means its per-core performance is 397. Since single-core is 4.1 and all-core is 3.9, if we adjust the per-core by that amount, we come up with a per-core equivalent of 417. The actual single-core score is 430, so using single-core as a proxy introduces less than 3% expected error to true "per-core" performance. That is the impact of thermals, more cache available to that thread, etc - all of that adds up to less than 3% difference, in a full AVX2 heavy task.

AMD boost clocks are not as neatly defined as Intel but the 3500X has let's say 4.1 single-thread boost (the advertised single-thread boosts tend to be "ephemeral" at best under actual loads) and 3.9 all-core. It scores 2650 all-core, that's 441 per-core, adjusted for speed that's a per-core equivalent of 464. The actual single-core score is 467, so basically dead-nuts on.

https://www.tomshardware.com/news/amd-ryzen-5-3500x-review-e...

AMD people just don't like "single-core" because it's not a metric they currently win in. In practice it correlates pretty damn closely to expected per-core performance, and that is a critical metric that has a world of performance impact on a variety of tasks (Amdahl's law says many real-world tasks are dominated by one bottlenecked thread, the faster you run that one single thread, the faster the whole thing runs).

Once we see AMD move into the open lead in various workloads (which is very possible with Zen3), overnight we're going to see a lot of people suddenly rediscover the merits of empirical testing under non-bottlenecked conditions. The arguments about "well you would need a RTX 3070 running at 1080p" are going to fade away, just like the whining about the irrelevance of "single-core".

----

Generally speaking most home tasks are not memory-bandwidth bound. It depends, but generally they're not. As far as power/thermals, it depends on the board, if you're running a really crappy board with a weak VRM then all bets are off, but in practice it is not a problem with normal workloads. Gaming is not at all intense and can clock high even on some pretty mediocre boards if you've got some airflow. Something like video encoding (lots of AVX2) is the next step more intense, if you are going to sit there all day crushing video and you won't have airflow then yeah, you do need to buy at least something in the $170-200 tier.

Prime95 is not a realistic real world workload and will definitely overheat anything.

They mean game FPS will be bottlenecked by single CPU's speed. E.g. in factorio all logic is single-threaded, so you'll be bottlenecked by single CPU, even though it uses other CPUs for minor tasks.

It is what matters to web browsing performance.

Web browsing is no longer a "light" thing to do. You need solid integer single core computing performance to have a snappy browsing experience.

AFAIK, there is not yet a web browser core that can parallelize tasks in a meaningful way.

Mozilla has been making pretty good progress with parallelization of firefox with their oxidation project. All browsers are splitting different tabs into different processes which means they are taking advantage of multithreading if you have more than one compute intensive tab/window open.

Splitting tabs into separate processes is mainstream these days, but it doesn't really help that much. You only need the focused tab to be snappy.

You only need the focused tab to be snappy, but to let it be snappy you need to keep all the other work away from that core. Gmail updating emails, youtube playing a video in the background, discord pinging chat messages at you, and so and and so forth.

With a modern javascript engine you can throttle the activity of tabs that are not focused. (And browsers do indeed do that. Pretty aggressively, too.)

I wish there was some extension that blocked any non-focused tabs from performing any javascript execution unless I whitelist the domain.

> AFAIK, there is not yet a web browser core that can parallelize tasks in a meaningful way.

Firefox is getting there. The CSS style engine is parallelized already, and graphical compositing+rendering will follow shortly (already enabled experimentally in some configurations). Other parts of the browser will be next, including the DOM.

That sounds interesting. Any links to design documents or something similar?

The overall name of the project is Quantum but you have to dig in a bit to find out about the specific sub projects and how they work or plan to work.

Overview: https://wiki.mozilla.org/Quantum

CSS: https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en...

DOM: https://billmccloskey.wordpress.com/2016/10/27/mozillas-quan...

Rendering: https://www.masonchang.com/blog/2016/7/18/a-short-walkthroug...

I'm well aware of this Rust-based research project. (I thought you were talking about something new. Those pages are 3-4 years old, btw.)

None of this parallelization has found its way into mainstream Firefox afaik.

Stylo shipped a long time ago now, in Firefox 57.

https://wiki.mozilla.org/Oxidation#Rust_Components has a list of what Rust has shipped within Firefox, though most of it has been motivated by safety guarantees rather than parallelism.

Thanks, Sam (!).

"Sam (!)" and a Swedish browser person… wonders who you are

I have a crappy old Celeron 847 laptop, and my browsing experience is very much okay, not that different from even i3-8100. Yeah, I do sometimes hit very heavy sites, like bloomberg.com, but overall, experience is very much satisfactory.

> It is what matters to web browsing performance.

Have a look at the web benchmarks though (starting at Mozilla Kraken 1.1):

https://www.anandtech.com/bench/product/2263?vs=2520

Reply on news.ycombinator.com