3 ms·
I'd rather have more cache than less. There are some corner cases where things will go wrong that we can dig up I'm sure, but generally, most tasks will execute
by rektide 4y ago
I'd rather have more cache than less. There are some corner cases where things will go wrong that we can dig up I'm sure, but generally, most tasks will execute at least as fast as they would have without the lopsided extra cache, and some will operate faster.
There's definitely a lot of iteration & growing in here we could do to get better here. Yet... it feels like searching for problems to worry about some tasks running faster than they would have before (but not all tasks). In most deployment models, it should be fine. I think, for now, this slightly favors two use cases: one big monolith running on all cores, which will let work get consumed as it's ready. Or divide your workers onto the different chiplets, and use a good load balancing strategy that is somehow utilization aware.
Personally I'm lacking in Fear, Uncertainty or Doubt over this making things worse.
- jackmott42 4y agoThe benchmarks show it making plenty of things worse in the non gaming domain on this particular CPU. On a server cpu that is running lower clocks anyway, probably near impossible for it to hurt.
- AnonCoward42 4y agoJust a small reminder that the CCD with V-Cache has way lower boost clocks and therefore performs worse in almost everything beside gaming. For casual use this is irrelevant I think, but it is still significant in many workloads. The only workload I know where V-Cache benefits more than it is hurt by lower boost clocks is gaming. The advantage of the dual CCD design is that this only/mostly hurts in highly threaded workloads at least.