[Discuss] Next AMD FX-8120 update

3 views
Skip to first unread message

ma...@mohawksoft.com

unread,
Mar 18, 2012, 8:34:13 AM3/18/12
to dis...@blu.org
I finally got my AMD FX-8120 8 core system and have migrated to it. My old
system, an AMD Athlon Dual Core, 8G RAM is now powered off waiting for a
new job. My initial problem was a bad motherboard and my biggest obstacle
to migration was wife and family and the responsibilities there of.

So, quick summary:
AMD FX-8120 8 core CPU
16 Gig RAM
1TB Boot drive (new)
1.5TB Data drive (removed from previous machine)
Ubuntu 12.04

My first impression was that it is not much faster than the old Dual Core
Athlon when running a single task, but that turned out to be false. It
does seem faster than the previous machine. I only have anecdotal
information.

Does anyone know of a good Linux benchmark?

At work we have IBM servers using XEON Westmere processors, running
similar clock speeds, the inexpensive AMD calculated SHA1 hashes faster
than the XEON. I was surprised.

The big win, of course, is multiple processes and threads. With the extra
RAM, I am able to create good sized virtual machines with multiple CPUs.

The processor itself is interesting. It isn't quite "8" true processors,
but it isn't quite as useless as Intel's "Hyperthreaded" cores either. I
will need to find time time to really test it.

_______________________________________________
Discuss mailing list
Dis...@blu.org
http://lists.blu.org/mailman/listinfo/discuss

Jerry Feldman

unread,
Mar 18, 2012, 8:23:13 AM3/18/12
to dis...@blu.org
Generally, we used to turn off hyperthreading. Hyperthreading gives you
extra pseudo cores, but they are not real cores.

--
Jerry Feldman <g...@blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66 C0AF 7CEA 30FC 3BC1 EB90


ma...@mohawksoft.com

unread,
Mar 18, 2012, 10:06:49 AM3/18/12
to ma...@mohawksoft.com, dis...@blu.org
Here is an output from sysbench:

FX-8120:
markw@snoopy:~$ sysbench --test=cpu --cpu-max-prime=20000 --num-threads=8 run
sysbench 0.4.12: multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 8

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
total time: 3.2178s
total number of events: 10000
total time taken by event execution: 25.7120
per-request statistics:
min: 2.23ms
avg: 2.57ms
max: 4.94ms
approx. 95 percentile: 2.71ms

Threads fairness:
events (avg/stddev): 1250.0000/1.87
execution time (avg/stddev): 3.2140/0.00

AMD Phenom(tm) II X4 925 Processor
markw@huey:~$ sysbench --test=cpu --cpu-max-prime=20000 --num-threads=4 run
sysbench 0.4.10: multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
total time: 8.3527s
total number of events: 10000
total time taken by event execution: 33.4005
per-request statistics:
min: 3.28ms
avg: 3.34ms
max: 10.62ms
approx. 95 percentile: 3.35ms

Threads fairness:
events (avg/stddev): 2500.0000/35.81
execution time (avg/stddev): 8.3501/0.00

Jerry Feldman

unread,
Mar 18, 2012, 9:39:27 AM3/18/12
to dis...@blu.org
MArk,
Can you run the same test (1 thread per real core) on the Xeons with
hyperthreading turned off.

Richard Pieri

unread,
Mar 18, 2012, 12:02:32 PM3/18/12
to blu (blu)
What you will typically find is that if your threads are CPU bound then you will see better performance over the long term with HT disabled. The reason is that the phantom CPUs that HT provides need to share cache and memory bandwidth and there is some extra switching overhead. The upshot is that if you have 1 CPU with 2 HT threads and 4 CPU-bound jobs to run, the total time to run all 4 jobs will be less with HT disabled. As an aside for anyone running a Condor pool, disabling HT is recommended for this reason.

On the other hand, if you are not CPU-bound across all of your threads, or in environments where concurrency is more important than throughput, then HT may be a win.

AMD's Bulldozer architecture has less resource contention than Intel's HT implementations (less overhead) but two threads on 1 core still have to share some resources and you will usually see results similar to what I described.

--Rich P.

Tom Metro

unread,
Mar 18, 2012, 4:49:28 PM3/18/12
to L-blu
ma...@mohawksoft.com wrote:
> I finally got my AMD FX-8120 8 core system and have migrated to it.

I see that Micro Center has this CPU on sale for $180 this week...


> Does anyone know of a good Linux benchmark?

If you are more interested in comparing the new server vs. the old
server, rather than against some common standard, then you'll get the
most meaningful results by using some actual applications. So for
example, Postfix or Apache or whatever. You'll need some synthetic data
or a stressing tool to create a load.

-Tom

--
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/

Richard Pieri

unread,
Mar 18, 2012, 5:09:24 PM3/18/12
to L-blu
On Mar 18, 2012, at 4:49 PM, Tom Metro wrote:
>
> example, Postfix or Apache or whatever. You'll need some synthetic data
> or a stressing tool to create a load.

I like using HandBrake to do video encodes as a general benchmark. HandBrake will use as many threads as the system reports as usable and it mixes both CPU-bound and IO-bound threads.

--Rich P.

Jerry Feldman

unread,
Mar 18, 2012, 6:18:49 PM3/18/12
to dis...@blu.org
On 03/18/2012 12:02 PM, Richard Pieri wrote:
> What you will typically find is that if your threads are CPU bound then you will see better performance over the long term with HT disabled. The reason is that the phantom CPUs that HT provides need to share cache and memory bandwidth and there is some extra switching overhead. The upshot is that if you have 1 CPU with 2 HT threads and 4 CPU-bound jobs to run, the total time to run all 4 jobs will be less with HT disabled. As an aside for anyone running a Condor pool, disabling HT is recommended for this reason.
>
> On the other hand, if you are not CPU-bound across all of your threads, or in environments where concurrency is more important than throughput, then HT may be a win.
>
> AMD's Bulldozer architecture has less resource contention than Intel's HT implementations (less overhead) but two threads on 1 core still have to share some resources and you will usually see results similar to what I described.
In Toronto they always turn off HT. I ran a quick test and found that
the RiskWatch application runs better with no HT. There is certainly
some benefit to HT under some circumstances.

ma...@mohawksoft.com

unread,
Mar 18, 2012, 6:59:57 PM3/18/12
to Jerry Feldman, dis...@blu.org
> On 03/18/2012 12:02 PM, Richard Pieri wrote:
>> What you will typically find is that if your threads are CPU bound then
>> you will see better performance over the long term with HT disabled.
>> The reason is that the phantom CPUs that HT provides need to share cache
>> and memory bandwidth and there is some extra switching overhead. The
>> upshot is that if you have 1 CPU with 2 HT threads and 4 CPU-bound jobs
>> to run, the total time to run all 4 jobs will be less with HT disabled.
>> As an aside for anyone running a Condor pool, disabling HT is
>> recommended for this reason.
>>
>> On the other hand, if you are not CPU-bound across all of your threads,
>> or in environments where concurrency is more important than throughput,
>> then HT may be a win.
>>
>> AMD's Bulldozer architecture has less resource contention than Intel's
>> HT implementations (less overhead) but two threads on 1 core still have
>> to share some resources and you will usually see results similar to what
>> I described.
> In Toronto they always turn off HT. I ran a quick test and found that
> the RiskWatch application runs better with no HT. There is certainly
> some benefit to HT under some circumstances.

The problem isn't with hyperthreads per se' it is a problem with system
schedulers not knowing the difference or how to use them. Hyperthreads are
sort of a micro-NUMA environment. Sometimes, it is best to put a HT
semi-core to sleep instead of using it because there is no appropriate job
for it to run and running another job would affect its peer.

One of the things I was concerned about the FX-8120 was the shared
resources of the cores. So far it doesn't seem too bad. Even though core
pairs share a numeric processor and some caching, they seem to schedule
fairly well independently.

So, like I said, they aren't truly full cores, but they don't seem
similarly limited.

> --
> Jerry Feldman <g...@blu.org>
> Boston Linux and Unix
> PGP key id:3BC1EB90
> PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66 C0AF 7CEA 30FC 3BC1 EB90
>
>

Tom Metro

unread,
Mar 18, 2012, 11:20:14 PM3/18/12
to L-blu
Richard Pieri wrote:
> Tom Metro wrote:
>> ...Postfix or Apache or whatever. You'll need some synthetic data

>> or a stressing tool to create a load.
>
> I like using HandBrake to do video encodes as a general benchmark.
> HandBrake will use as many threads...

That's great, but my point was that if the machine is going to be
deployed as a mail or web server, those are the types of loads you want
to benchmark with.

For a CPU like the AMD FX-8120 I know I'd personally be more interested
in seeing how it scales when handling multiple web server VMs than video
transcoding.

-Tom

--
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/

Jerry Feldman

unread,
Mar 19, 2012, 9:14:11 AM3/19/12
to dis...@blu.org
This is true. For our products, HT tends to reduce performance, but for
some situations, HT tends to improve performance. I would still be
interested in running a benchmark with HT turned off at work, just to
compare the Intel processors. I know there is considerable differences.

Richard Pieri

unread,
Mar 19, 2012, 10:23:36 AM3/19/12
to dis...@blu.org
On 3/18/2012 11:20 PM, Tom Metro wrote:
> That's great, but my point was that if the machine is going to be
> deployed as a mail or web server, those are the types of loads you want
> to benchmark with.

True enough. But then, the typical mail or web server tends to see very
spiky load patterns and it tends to be I/O-bound rather than CPU-bound.
At that point you should look at seek times and IOPS and possibly I/O
cache rather than CPU performance. You should also look at how your
data is stored since that can have more of an impact on performance than
the hardware.

--
Rich P.

Reply all
Reply to author
Forward
0 new messages