How do the cores in an AMD Bulldozer module compare to Intel HTT virtual cores and two separate cores, in terms of multitasking performance

Huh, I could tell you the story but you are going to hate it and I'm going to hate writing it :-)

Short version - Win10 screwed up everything it could and is in perpetual state of starving cores due to systemic problem known as cpu oversubscription (way too many threads, no one can ever service them, something is choking at any point, forever). That's why it desperately needs these fake CPU-s, shortens base scheduler timer to 1 ms and can't let you have parking anything. It would just scorch the system. Open Process Explorer and add up the number of threads, now do the math :-)

CPU Sets API was introduced to give at least some fighting chance to those who know and have the time to write the code to wrestle the beast. You can de-facto park fake CPU-s by putting them in a CPU-Set that you won't give to anyone and create default set to throw it to piranhas. But you can't do it on client sku-s (you could technically, it's just not going to be honored) since kernel would do into panic state and either totally ignore CPU Sets or some other things are going to start crashing. It has to defend system's integrity at any cost.

The whole state of affairs is by and large a tabu since it would require major rewrites and everyone culling the no of frivolous threads and admitting that they messed up. Hyperthreads actually have to be permanently disabled (they heat up cores under real load, degrade performance and destabilize HTM - the principal reason why it never became mainstream). Big SQL Server shops are doing it as a first setup step and so is Azure. Bing is not, they run servers with de-facto client setup since they'd need much more cores to dare to switch. The problem percolated into Server 2016.

SQL Server is the sole real user of CPU Sets (as usual :-), 99% of perf-advanced things in Win has always been done just for SQL Server, starting with super efficient memory mapped file handling that kills people coming from Linux since they assume different semantics).

To play with this safely you'd need 16 cores min for a client box, 32 for a server (that actually does something real :-) You have to put at least 4 cores in default set so that kernel and system services can barely breathe but that's still just a dual core laptop equivalent (you still have perpetual choking), meaning 6-8 to let the system breathe properly.

Win10 needs 4 cores and 16 GB to just barely breathe. Laptops get away with 2 cores and 2 fake "CPU-s" if there's nothing demanding to do since their usual work distribution is such that there's always enough things that have to wait anyway (long queue on memaloc "helps" a lot :-).

This is still not going to help you with OpenMP (or any automatic parallelization) unless you have a way of telling it explicitly to use your CPU Set (individual threads have to be assigned to CPU Set) and nothing else. You still need process affinity set as well, it's precondition for CPU Sets.

Server 2k8 was the last good one (yes that means Win7 as well :-). People were bulk loading a TB in 10 min with it and SQL Server. Now people brag if they can load it in one hour - under Linux :-) So chances are that the state of affairs is not much better "over there" either. Linux had CPU Sets way before Win.

Ratio of latencies is not ratio of speeds, e.g. having half latency does not mean having double speed. It has a few percent affection on speed.
Given that we are comparing same types of memory (e.g. DDR vs DDR), clock rate is the primary factor of speed while timing (CAS latency,...) is the secondary one.
Even now, Intel traditionally makes better memory controllers than AMD. Ryzen competes well in performance with Core i, however, I don't know how much its (on die) memory controller is approved.