Vlyn

Where do you find that this CPU “only has 6 3D cores”?

It's common knowledge. 7800X3D = 8 3D cores, 7900X3D = 6 3D cores and 6 normal cores (= 12), 7950X3D = 8 3D cores and 8 normal cores (= 16).

So if you mostly game and don't need the CPU for productivity tasks you should 100% grab the 7800X3D. If you need a lot of cores then grab the 7950X3D. The 7900X3D is garbage in the middle.

Someone already pointed out that a 4090 is a massive upgrade over a 4080, no clue what benchmarks you looked at.

So another suggestion: Why pick a 7900X3D? It's the worst of both worlds. It only has 6 3D cores for gaming, which might not be enough in the near future (Look up performance benchmarks between a 5600X vs a 5800X for example, there are already games that benefit from more than 6 cores).

If gaming is a focus: Pick a 7800X3D so you get a full 8 3D cores to work with. If productivity is a focus (with gaming on top) splurge for a 7950X3D. You're already spending an insane amount of money, you might as well get a decent CPU.

Besides that: You are wasting a ton of money on the SSDs. Grab a fast one like that for your Windows drive and for gaming, but for storage there's much cheaper options (that still deliver 3-6 GB/s, if you even need that). 128 GB of RAM is excessive too, except you have a very clear use-case for it.

That's an interesting thought!

Like Asian earwax is super dry and flaky, while European earwax looks like yellow green toxic goop.

So you have different genes and on top of that different diets (I had Indian neighbors once, you could smell the curry in the entire hallway of the building 24/7. But they obviously use a ton of spices when cooking).

As a central European Caucasian guy I personally start to smell really bad without deodorant just after a day or so. No matter how often I shower or what I eat. I also tried to switch to deodorant without aluminum and that didn't work out at all :-/

Ever left the house? You'll change your opinion right quick when you're behind a random guy in the grocery store and you get a strong whiff of sour milk that has been out in the sun for a week.

Thank god for deodorant (and regular showers).

Ever thought it might be the game? Maybe the current GPU driver has a bug there?

I found a lot of issues with Snowrunner black screening on start. The fix here is to run it in fullscreen instead of borderless.

Can you try to play the game in fullscreen mode and see if it still crashes? If you use FreeSync it could be connected with that too.

Darn. Maybe try switching off "fast boot" for Windows and doing a proper restart? That option (which is on by default) broke my installation once. Also had crashes that I couldn't fix, disabled that, restarted, problem solved.

When they initially announced the game as open world I was hyped. Let me describe what I thought it would be:

You leave the city and get put into an open instance (same like now), but the environment is randomly generated every time. Which means you actually run out and explore, find cellars, random dungeons, random bosses, ..

And with level scaling everything you find is the right amount of challenge, so you don't run out of content.

If we go with that, maybe they could add a feature like maps where you explore the uncharted wilds out of a border town.

And do sfc /scannow

It's pretty fast and Windows usually finds borked files. Reinstalling Windows might be better, but it's annoying.

TDD is great when you have a very narrow use case, for example an algorithm. Where you already know beforehand: If I throw A in B should come out. If I throw B in C should come out. If I throw Z in an error should be thrown. And so on.

For that it's awesome, which is mostly algorithms.

In real CRUD apps though? You have to write the actual implementation before the tests. Because in the tests you have to mock all the dependencies you used. Come up with fake test data. Mock functions from other classes you aren't currently testing and so on. You could try TDD for this, but then you probably spend ten times longer writing and re-writing tests :-/

After a while it boils down to: Small unit tests where they make sense. Then system wide integration tests for complex use-cases.

Definitely try a BIOS update first, Ryzen did a massive amount of bug fixes and optimizations with each version. After the BIOS update also make sure to get the current chipset drivers from AMD!

But be very careful when selecting your BIOS update, there might be later versions where they removed support for older Ryzen CPUs (as space is limited). So check the notes if they say anything like "removed support for Ryzen 2000 series", but I think B450 should be safe for your CPU.

If your PSU is broken your computer would go 100% dark (or straight up restart).

Multi-threading is difficult, you can't just slap it on everything and call it a day.

There are languages where it's easier (Go, Rust, ..) but parallelism is an advanced feature. Do it wrong and you get race conditions or dead locks. There is a reason you learn about this later in programming, but you do learn about it (and get to use it).

When we're being honest most programmers work on CRUD applications, which are highly sequential, usually waiting on IO and not CPU cycles and so on. Saving 2ms on some operations doesn't matter if you wait 50ms on the database (and sometimes using more threads is actually slower due to orchestration). If you're working with highly efficient algorithms or with GPUs then parallelism has a much higher priority. But it always depends on what you're working with.

Depending on your tech stack you might not even have the option to properly use parallelism, for example with JavaScript (if you don't jump through hoops).

At this point you're just arguing to argue. Of course this is about the math.

This is Amdahl's law, it's always about the math:

https://upload.wikimedia.org/wikipedia/commons/thumb/e/ea/AmdahlsLaw.svg/1024px-AmdahlsLaw.svg.png

No one is telling students to use or not use parallelism, it depends on the workload. If your workload is highly sequential, multi-threading won't help you much, no matter how many cores you have. So you might be able to switch out the algorithm and go with a different one that accomplishes the same job. Or you re-order tasks and rethink how you're using the data you have available.

Practical example: The game Factorio. It has thousands of conveyor belts that have to move items in a deterministic way. As to not mess things up this part of the game ran on a single thread to calculate where everything landed (as belts can intersect, items can block each other and so on). With some clever tricks they rebuilt how it works, which allowed them to safely spread the workload over several cores (at least for groups of belts). Bit of a write-up here (under "Multithreaded belts").

Teaching software development involves teaching the theory. Without that you would have a difficult time to decide what can and what can't benefit from multi-threading. Absolutely no one says "never multi-thread!" or "always multi-thread!", if you had a teacher like that then they sucked.

Learning about Amdahl's law was a tiny part of my university course. A much bigger part was actually multi-threading programs, working around deadlocks, doing performance testing and so on. You're acting as if the teacher shows you Amdahl's law and then says "Obviously this means multi-threading isn't worth it, let's move on to the next topic".