AMD FX-8320E Performance On Linux

[oleid]

As for Rust, Rust has a long way to go to compete against D. Perhaps due to it's use of LLVM, binaries compiled in Rust today are a magnitude slower than the same code written in D. I also find that in Rust I have to write twice as many lines of code to achieve the same thing in D -- not to mention the fact that a line of Rust is more verbose than a line in D. The standard library is still a complete mess in 1.0 Alpha, and the documentation is, honestly, hard to read and comprehend at times. Rust's debugger is also completely unhelpful nine times out of ten with excessively verbose errors that lack a simple explanation. As a result, it's much harder to learn Rust than it is to learn D -- especially if you already have experience with C-like languages.

Rust being slow is simply not true. Have a look at the language shootout : http://benchmarksgame.alioth.debian.org/u64/rust.php

It's about as fast as gcc compiled C and I highly doubt that D is faster. The two cases where it's slower are a bit unfair. N-body uses intrinsics in C and the dna test only compares the regex library.

The standard library being a complete mess is highly exaggerated. It's not stable, yet, but will be in a few weeks.

[CrystalGamma]

If one is not sure what to think about a cpu company why not just ask Wikipedia about it.

http://en.wikipedia.org/wiki/FMA_instruction_set

AMD FMA4 :
"FMA4 is the full version"
"Reduces the load register by non-destructive four-operand form (in the case of FMA4)"
(copy translate from the german article)

Intel FMA3:
"FMA3 requires, however, that the destination register is one of the operand registers, and this will be overwritten." (copy translate from the german article)

So in fact Intel is selling SHIT to the people only because they do not want pay license tax to AMD.

And then the people blaming AMD for having a poor SIMD unit power because they only see the only 4 simd units but blend out any benefit of the AMD SIMD units like FMA4.

In superscalar out-of-order processors (like most CPUs are these days) it comes down to the same because in those architectures you are basically just shuffling register names about.
It's basically a) having to code an extra destination register name every time (FMA4) vs. b) having to code another MOV if you want to use a value twice. Doesn't really do much either way ...

[Kivada]

I'm quite pleased running the FX-8350 with 32GB DDR3 1866 on the 990FX Gigabyte UD3 Board.

Building the entire source tree of LLVM/Clang-Clang Extra/LLDB/Compiler-RT/Test-Suites/LLVM Docs-Unit Tests-Examples/Clang-Docs-Unit Tests-Examples/Libc++/Libcxabi [Everything but LLD/Polly enabled] in release mode for X86 averages around

12 minutes, 40 seconds.

And that's just via a standard Seagate 2TB 7200RPM HDD 64MB Cache and not the SSD.

Use the SSD and it's drastically shorter.

That's using all 8 cores.

I'd love to see a comparison between several AMD FX/AMD APUs with Intel from the i3 to the Xeon.

Let's see just where they fall, and then graph those against current prices to garner a bang for your buck comparison.

Try one of those M.2 SSDs in a 4x PCIe adaptor card with a high I/Ops drive, it'll shorten those times even more.

[Marc Driftmeyer]

Try one of those M.2 SSDs in a 4x PCIe adaptor card with a high I/Ops drive, it'll shorten those times even more.

That or just use one of the PCIE slots available for something like:

http://www.newegg.com/Product/Product.aspx?Item=N82E16820249053

The boot drive is the SATA SSD Plextor M5 Pro 128 MB: http://www.newegg.com/Product/Produc...82E16820249032

The pricing has leapt for the M5 Pro so when I switch I'll jump to the Plextor M6e Black Edition, when I rebuild a split build of Debian Sid/Experimental and FreeBSD 10.2.

[Marc Driftmeyer]

Rust being slow is simply not true. Have a look at the language shootout : http://benchmarksgame.alioth.debian.org/u64/rust.php

It's about as fast as gcc compiled C and I highly doubt that D is faster. The two cases where it's slower are a bit unfair. N-body uses intrinsics in C and the dna test only compares the regex library.

The standard library being a complete mess is highly exaggerated. It's not stable, yet, but will be in a few weeks.

You keep championing D. I'll stick to C11 and future updates.

[profoundWHALE]

Rust being slow is simply not true. Have a look at the language shootout : http://benchmarksgame.alioth.debian.org/u64/rust.php

This is like finding out that a Toyota/Honda is slightly slower than a Formula 1 racer. Their progress is simply incredible.

It's about as fast as gcc compiled C and I highly doubt that D is faster. The two cases where it's slower are a bit unfair. N-body uses intrinsics in C and the dna test only compares the regex library.

The standard library being a complete mess is highly exaggerated. It's not stable, yet, but will be in a few weeks.

D is fast, there's a lot of benchmarks around that show that. But, as someone else here said:

The best point I have encountered of Rust versus D, and I admit it's a powerful argument, is that in Rust everything is immutable by default and you have to do extra work to deal with mutable state. I think that's fantastic, and I wish D had it.

D was meant to be the successor that C++ should have been, Rust seems to have the same goal, so I'd consider them as friendly competitors.

[Michael_S]

This is like finding out that a Toyota/Honda is slightly slower than a Formula 1 racer. Their progress is simply incredible.

Well, one of the two primary authors of D, Walter Bright, wrote a C++ compiler. That's what motivated him to create something to replace C++. So it's not that much of a surprise that he knows performance. I'm sure there are similar incredibly bright people behind Rust, but I haven't followed the language as closely. Still, the Mozilla 'Servo' web browser project is, as far as I know, the biggest factor driving Rust development and vice versa. The performance pressure on Firefox these days is enormous, so it's no surprise the developers are really focused on great speed and memory efficiency with Rust.

D is fast, there's a lot of benchmarks around that show that. But, as someone else here said:

D was meant to be the successor that C++ should have been, Rust seems to have the same goal, so I'd consider them as friendly competitors.

Sounds good to me. I won't be sad if either one becomes wildly popular. I have nothing against Rust. But I happened to pick up the D Programming Language book a few years back. It's written by Andrei Alexandrescu, the other major D language author, and it was really easy for me to follow. Plus it was littered with Calvin & Hobbes references, puns, and silly jokes like a demonstration of Euclid's algorithm (for greatest common divisor) with the footnote "Somehow, Euclid's algorithm always manages to make its way into good (ahem) programming books". So I'm more of a fan of D, if only because I stumbled across it earlier.

[profoundWHALE]

Sounds good to me. I won't be sad if either one becomes wildly popular. I have nothing against Rust. But I happened to pick up the D Programming Language book a few years back.

I'm also a little biased towards D. I didn't exactly find one or the other first, but at the time, Rust was still a little uncertain, and D, as well as it's creator (like you said) have a proven track record. If I remember correctly, he wrote his own C++ compiler and it ended up being the fastest compiler around. (If it's anything like dmd, it'll have ridiculously fast compile times, and slower execution, so in D, most people seem to use dmd for testing code when they're compiling lots, but when they want to start putting out the final version, they use ldc or gdc, although ldc seems to be the faster execute of the two.)

Also, D is fast, sometimes faster than C which is practically the gold standard for top performance. Rust making it as close as they have to C is very impressive. D sometimes surpassing C is astounding. At least, this is the way I saw it.

[Kivada]

That or just use one of the PCIE slots available for something like:

http://www.newegg.com/Product/Product.aspx?Item=N82E16820249053

The boot drive is the SATA SSD Plextor M5 Pro 128 MB: http://www.newegg.com/Product/Produc...82E16820249032

The pricing has leapt for the M5 Pro so when I switch I'll jump to the Plextor M6e Black Edition, when I rebuild a split build of Debian Sid/Experimental and FreeBSD 10.2.

Thats not upgradeable for the future, the chips are soldered in place and may have onboard RAID chip weirdness as has happened in the past with PCIe SSD cards. Most high end systems now have M.2 SSD card slots these days and as we saw in CES this year theres a few companies now selling them in adaptor cards, these M.2 SSDs are as fast as most of the PCIe SSD cards.

[drSeehas]

Also, you shouldn't touch the HT clock, while it does increase the CPU's clock, it also increases the southbridge's and northbride's clocks. ...

The HT clock has no relation to the southbridge.