Most bang for buck - CPU tasks?

I think Tom M means the separate CPU apps of e@h. I would say: O3MD1 is less rewarded than FGRP5 and BRP4X64. I can't tell if BRP4X64 or FGRP5 gives better credit payout. They are almost the same and runtimes of tasks also differ to some extent. Finished FGRP5 results often stay "pending" for weeks. Often second task of a workunit exceeds deadline; has to be resend; deadline is longer: 2 weeks instead of 1 week for BRP4X64). So RAC for FGRP5 can only be compared to BRP4X64 after running it for some weeks.

If they only take 1/3 longer, than you will achieve highest RAC by O3MD1. You have to try it on your hardware. It depends on the CPU type.

On my old computer O3MD1 tasks (1000 credits) take 100 to 150 % longer than BRP4X64 (500 credits) tasks. These tasks even seem to stress the CPU more than BRP4X64 or FGRP5. Core temperature rises higher when running same number of O3MD1 tasks compared to FGRP5 or BRP4X64. Runtimes are also 50 to 100 % longer than FGRP5 (693 credits). So for me running O3MD1 reduces RAC remarkably while it was the highest when only running a mix of FGRP5 and BRP4X64 on all cores. But I don't care. E@h's scheduler decides my task mix. My computer also lacks the memory to run O3MD1 on more than half of the cores. So I can't test it.

Be careful with the number of O3MD1 tasks you pull. I let my 24GB 12c/24t system pull O3MD1 tasks and it is running out of memory as each task is using 1.8GB. In my case this means 10 out of 20 threads are able to be used due to lack of memory

Your Ryzen 5 2400 GE is a quad-core CPU supporting 8 threads (Intel called the feature HyperThreading, don't know about AMD). Each of 4 physical cores contains a number of Function Units (FU), e.g. 1: integer&SSE_ADD, 2: integer&SSE_ADD&FP_ADD, 3: integer&FP_MUL&SSE_MUL/DIV, 4: load_memory 5: store_mem, ...

A reorder buffer is upstream in front of the FUs. There, the micro-operations (µOps) of the active threads are pre-sorted in such a way that as many FUs as possible can be used in parallel (e.g. 2 integer µOps, 1 FP & 1 integer, or 1 load & 1 FP, ...). For floating point multipy and divide there is usually only one FU. So a physical core can run two integer ops or two FP add ops in parallel, but not two FP multiply.

My example is from an old Intel Core Nehalem micro architecture that I remember:

Intel Nehalem arch - Nehalem (microarchitecture) - Wikipedia

Current AMD Zen micro architecture offers way more µOps in parallel, 4 Integer (ALU),2 load/store, 4 FP of which 2 FP MUL...

Zen microarchitecture - Zen (1st gen) - Wikipedia

Reason: 64-bit FP multiplier hardware requires a large number of logic gates (chip area). Now it depends on the specific CPU (which generation of Intel or AMD micro architecture: how many and which type of FUs per physical core). And it depends on the running threads, which µOps the CPU cores are capable to execute in parallel. O3MD1 app (Gravitational Wave O3) appears to be a very demanding app that probably uses FP_MUL ops extensively. This means that maybe 6 of these threads cannot run in parallel on 4 physical cores. Some MUL or DIV ops have eventually to be executed sequentially. Then threads are slowed down as soon as #threads > #phys. CPU cores. But it is possible that a different mix of einstein threads (different apps, e.g. BRP4X64, FGRP5) results in a better utilization of virtual threads (available FUs) offered by the phys. cores. One has to try it out for each CPU micro architecture. (e.g. limiting max number of concurrent task of specific science app via BOINC's client configuration; limiting number of CPU cores to use (client conf.) as you did: 6 of 8 = 75% of (virtual) CPU cores  ... "CPU cores" is a misleading term; it's: "threads")

e.g.: app_config.xml in project's directory:

<app_config>
   <app>
      <name>einstein_O3MD1</name>
      <max_concurrent>3</max_concurrent>
    </app>
</app_config>

BRP7 alias "MeerKAT" is GPU only at the moment: and only ATI and Nvidia apps available;