If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Some of the initial performance reports where very negative but this looks very good to me for a generation one processor. There is good reason now to save a few bucks going AMD as the performance penalty isn't overwhelming

It will be especially interesting to see more testing with different configurations of the processors. We simply don't have the experience to imply anything about cache trade offs as the architecture is so new.

The other thing to realize is that there has likely been little in the way of Bulldozer specific optimizations in these tests. That would be switches for the compilers. Even though some OS optimization has been done that doesnt preclude any other improvements specific to Bulldozer. In the end AMD could be sitting pretty with a hardware revision and some optimized compiler technologies.

Comment

In any case, a direct comparison of "4 threads across 4 modules" against "4 threads crammed into 2 modules" might be interesting to see how much Bulldozer's modules actually lose over discrete cores by sharing certain parts of the CPU pipeline.

Yes, that's all i was getting at. Maybe scaling would be worse, or maybe better, but it would have been an interesting test to see exactly what does happen. It might even tell us something about the BD architecture.

Comment

CMP is the stupid idea AMD ever bring to life but only because the humanity isn't ready yet.
they should better build native 8core cpus like the AMD Opteron 6128, 8x 2.00GHz for the am3 socket.
the Humans are not ready yet for the Truth about SMP vs CMP vs HT
in my point of view the humans are not ready for out of order cpus.
we need a LAW to Force "in order" cpu architecture to Stop the stupidness of the humans.

I think thread count should be a value that can be determined by the actual tests (some other tests have no justification for such manipulation) AND the processor since some processor improve their results when loading more threads and some others don't

I think thread count should be a value that can be determined by the actual tests (some other tests have no justification for such manipulation) AND the processor since some processor improve their results when loading more threads and some others don't

Whenever you see results like that it means there is a problem with the benchmark. Either the code is written poorly, or the threads are blocked by I/O. In the latter case, obviously changing the disk subsystem will change the result, and then you no longer have a meaningful benchmark of CPU performance. In the former case, you have some other block on a shared resource. It might be valid still as a benchmark, if the contended resource is the same on all test platforms.

Comment

Last sentence on page 3 says:
"With eight threads (fully utilizing the FX-8150), the improvement was 6.05x over the single-core result while the Opteron 2394 was at 8.02x and the Core i7 990X at 6.11x."

However, 6.05x is the improvement for 6 threads, the one for all 8 threads was 7.44x