Aquinus
Resident Wat-man
- Joined
- Jan 28, 2012
- Messages
- 13,153 (2.87/day)
- Location
- Concord, NH, USA
System Name | Apollo |
---|---|
Processor | Intel Core i9 9880H |
Motherboard | Some proprietary Apple thing. |
Memory | 64GB DDR4-2667 |
Video Card(s) | AMD Radeon Pro 5600M, 8GB HBM2 |
Storage | 1TB Apple NVMe, 4TB External |
Display(s) | Laptop @ 3072x1920 + 2x LG 5k Ultrafine TB3 displays |
Case | MacBook Pro (16", 2019) |
Audio Device(s) | AirPods Pro, Sennheiser HD 380s w/ FIIO Alpen 2, or Logitech 2.1 Speakers |
Power Supply | 96w Power Adapter |
Mouse | Logitech MX Master 3 |
Keyboard | Logitech G915, GL Clicky |
Software | MacOS 12.1 |
FPU performance is lacking because doing floating point math is by definition, harder to do than integer math and requires more circuity and more hardware. AMD shared the FPU because integer cores tend to get used more often. It's really that simple.I know why I keep screwing that up. Because it makes more sense to share ALUs and not FPUs. FPU performance tends to be lacking in processors where ALU performance does not, so it would make sense that AMD would not share FPUs. I am consistently wrong because AMD is consistently wrong. Instead of focusing on improving areas where performance was weak, they went with what was cheap. You're probably facepalming me and pass that facepalm to AMD.![]()
Characters are integers too, so string operations are done in the ALU. I think you're underestimating how much is done on integer cores. In fact you don't even need an FPU because you can do floating point math on an integer ALU.Most is integer because most involve memory pointers and addresses but that doesn't really matter because a CPU is always only as good as its weakest link.
Minecraft isn't using more than 4 threads to calculate position information and I'm willing to bet it uses single precision not doubles for such calculations because such exactness isn't required. Most games have little use for double-precision as it gets you very little and takes more memory and time to calculate.Games rely heavily on floating-point and some are even using doubles (64-bit floating point) like Minecraft for position data. That's not something that can be farmed out to the GPU because it is constantly being checked and updated and a hell of a lot of variables are based off of it.
Like AutoCAD? You mean applications that in many cases are already accelerated by GPUs? I should note that GPUs also don't strictly do floating point math, they do integer math too. Just because it runs on the GPU doesn't mean it does floating point math. Just wanted to make that clear too because many scientific applications might prefer fixed point numbers over floats for the sake of maintaining exact precision.There's also model animations that are extremely FPU heavy.
I seriously doubt that every instruction is going to be one floating point operation after another. If it's doing that kind of mass processing, a GPU would be useful. Once again, I think this is a testament to how much you're underestimating how much integer math is done in most applications, even 3D ones.If a game is running on two virtual cores and they both feed to the same FPU, that FPU can understandably cause the game to slow down.
That's a fuddish statement and I will explain why. BOINC (in particular WCG,) provides workloads of all different kinds. So while one WU might have a lot of floating point math, another one might use purely integer math because sometimes the error introduced when using floats is unacceptable so fixed point math (with integers,) makes more sense. So to me, this statement just makes me want to facepalm because there is absolutely nothing that indicate that all projects through BOINC are strictly floating point in nature. That's an over-generalization.Another example: I have BOINC running all of the time which is extremely FPU intensive. If a BOINC task were running at high priority on one virtual cores and something else (like a game) was running at normal priority on the other virtual core, that other program will have virtually no FPU work computed. If that software was waiting for an FPU computation to finish (like a game), it would lock up. If that same scenario were run on an actual octo-core, there would be little to no impact (software would not lock up).
Then we agree to disagree because in reality, most operations being carried out are integer in nature so, unless you're crunching floating point numbers, it won't be a big deal. They have more dedicated parts than shared parts which is why I think your statement is wrong. They're not slower, they're shared and quite frankly if you have an 8c AMD CPU, you still can do 4 floating point ops at once which is no less impressive than the Phenom II which also had 4 FPUs, the difference is that you only had 4 integer ALUs instead of 8.So I'd argue they are not octo-cores. They are quad-cores with semi-symmetrical multithreading.
If your measure for "cores" is by how many FPUs it has, then you've already forgotten what the purpose of a CPU is.