AMD - Piledriver chitchat

[DanceswithUnix]

Now down to a mere £630, obviously a bargain as they had 7 in stock before so seem to have sold 2

http://www.aria.co.uk/SuperSpecials/...roductId=56227

Edit to add: Ooh, Ebuyer have 9 in stock now, another one to have an occasional peek at.

http://www.ebuyer.com/538278-fx-9590...-fd9590fhhkwof

[teppic]

AMD execs are probably having a bet on how many get sold. Probably a bell goes off at HQ every time one goes

[DanceswithUnix]

AMD execs are probably having a bet on how many get sold. Probably a bell goes off at HQ every time one goes

Lol, there could be an app for that. I think "Ker-ching!" would work

[watercooled]

I see Canuks have a review, that is the first decent one I have seen:

http://www.hardwarecanucks.com/forum...iver-5ghz.html

Yeah the price seems out of line with its capabilities. Canuks refer to is as a high leakage part, hence the bonkers TDP. Looks like this is like that overclockers only part that AMD did a few years ago that way given to some top overclockers and not actually available to buy. The difference is you can buy this one.

Edit to add: If the price is high because of availability, then it might come down over time.

What is, IMO, more interesting about that review, is how well the 8350 is still holding up against even i7 Haswell when it comes to multithreaded benchmarks like compression/video encoding/etc, and still roughly equalling, if not surpassing, the more closely priced i5 in less-well-threaded apps and games (besides Skyrim obviously).

IMO it would have made more sense to give the 9590 a name distinct from the FX brand, to avoid the negative publicity from people assuming it's something it isn't.

[CAT-THE-FIFTH]

http://www.playstationlifestyle.net/...netside-2-dev/

It looks like the PS2 engine is going to get an update to make it thread better because of the PS4 version.

[DanceswithUnix]

http://www.playstationlifestyle.net/...netside-2-dev/

It looks like the PS2 engine is going to get an update to make it thread better because of the PS4 version.

Is it just me that read that title as "Developers can't architect properly threaded system" and kind of switched off?

I mean, they are saying they have to do this for AMD users but I suspect if they get this right then it will go like stink on an i5.

Why do some devs find threads so hard? I seem to find two types:

1/ Threads are complicated and break my code. I am scared of them, and will use a few where they are really easy and don't help much. One big spin lock so they block each other as much as possible should keep it stable.
2/ Threads are great! Every single line of code should have its own thread, coz if 10 threads is good then 1000000 threads must be better right?

*sigh*

[scaryjim]

... 2/ Threads are great! Every single line of code should have its own thread, coz if 10 threads is good then 1000000 threads must be better right?

This is the right answer, yeah? Please tell me this is the right answer....

[DanceswithUnix]

This is the right answer, yeah? Please tell me this is the right answer....

Part of me thinks that it would be amusing to reply "Wrong answer" by splitting each letter into a single post giving you a large overhead on switching between posts and collating the answer. However I am not that mean, and the people who we really need to understand still wouldn't get it

Edit to add: Thanks for the chuckle though, I needed that.

[watercooled]

I've not read the whole thing yet, some details about VI over at SA: http://semiaccurate.com/2013/08/07/a...aii-in-hawaii/

[scaryjim]

Edit to add: Thanks for the chuckle though, I needed that.

You're welcome And hey, at least I didn't insist you did it in Java, too

I'll be honest though, modern computers still aren't great at dealing with very large numbers of threads. I did a throwaway bit of code recently for generating dummy medical files, and they make sense to do heavily threaded (one thread for each person, as their records don't affect each other) and I found that each thread was so memory intensive that the whole thing started grinding past a few thousand threads in flight. Ended up having to dispatch them in blocks to get a performant system. So many issues getting heavily threaded code right

[watercooled]

It can pay to read and take into account the number of threads available on the system. You might get better utilisation with two threads per core, but beyond that efficiency often starts dropping off.

[scaryjim]

meh, I was blocking by the thousand, but all the calcs were fairly simple. It would probably have been better done for GPU compute, but it would've taken far longer just to learn how to program for the GPU than it did to write, edit, rewrite and optimise it in Java. Hurrah for laziness

[teppic]

Whenever I use benchmarks to show multithreaded performance on Piledriver I get told I'm cherry picking (despite never being met with benchmarks that show otherwise). I just saw this one, which is really cherry picking - but just as valid as those ridiculous SuperPI benchmarks.

[DanceswithUnix]

You're welcome And hey, at least I didn't insist you did it in Java, too

I'll be honest though, modern computers still aren't great at dealing with very large numbers of threads. I did a throwaway bit of code recently for generating dummy medical files, and they make sense to do heavily threaded (one thread for each person, as their records don't affect each other) and I found that each thread was so memory intensive that the whole thing started grinding past a few thousand threads in flight. Ended up having to dispatch them in blocks to get a performant system. So many issues getting heavily threaded code right

I blame part of the problem on whoever came up with the phrase "lightweight threads". They are only lightweight compared to forking a whole new operating system process, they still have to be scheduled, they still have a start end end cost, they use resources.

It sounds like one or two worker threads per CPU would have worked best for you, and some method of distributing the work to those threads.

Whenever I use benchmarks to show multithreaded performance on Piledriver I get told I'm cherry picking (despite never being met with benchmarks that show otherwise). I just saw this one, which is really cherry picking - but just as valid as those ridiculous SuperPI benchmarks.

More valid than SuperPi isn't hard tbh

In a past job SHA1 was actually very important to me, but I would have thought I was in a very small minority there!

[scaryjim]

It sounds like one or two worker threads per CPU would have worked best for you, and some method of distributing the work to those threads.

Maybe, and if I ever have the misfortune to need to take a programming job to put food on the table again, I'll brush up on threading properly.

In a past job SHA1 was actually very important to me, but I would have thought I was in a very small minority there!

Last I read about SHA1 was people slating it (and all "fast" hashing algorithms) as a method for "securely" storing passwords. Not one to argue with stackoverflow, I implemented SHA512 instead, but I've yet to determine whether it'll matter performancewise in my web app...

[watercooled]

Sha-512 is also a fast hashing algorithm, if speed is a concern you ideally want to either use a few thousand rounds of a SHA algorithm (like Debian does by default), or use a slower algorithm like bcrypt. And always use a strong salt where possible, it defeats rainbow tables and makes mass-bruteforce attacks far harder - you have to run through the attacks separately for each salt rather than being able to try against everything you can fit in memory.

Moving from SHA-1 to SHA-512 wont really help in terms of speed; they're both designed to be very fast as they're used for a shed load of applications, many of which require a lot of data to be hashed with minimal computational impact.

However, the SHA-1 algorithm is somewhat dented as there are a few published academic attacks, so using an improved algorithm would be advisable based on that, but then newer algorithms haven't had people trying to attack them for as long, so aren't as 'proven' as older ones.