• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Figured something out today...

M

MustangWorld

Weaksauce
Joined
Oct 4, 2004
Messages
97
As one of my previous posts stated, I got a new machine at work that chews through QMD cores at around 16 minutes per frame, but my Xeon box would munch on QMDs at 50 minutes per frame per instance (4 instances at once).

I decided to check the logs for something, the SSE2 boost line thing. I noticed the Xeon setup is only getting SSE2 boost, while the new work machine is getting SSE2/SSE3 boost. Could that be yet another reason why the work machine is chewing through these at a nice clip?

Also, It seems that memory bandwidth does play a huge role with the QMDs. I switched 1 instance off the QMDs right now and that cut times down by about 10 minutes per frame per instance :eek: So now its about 40-45 minutes per frame per instance, lol.
 
You're running the console correct? If so, you definitely want to add the -forceasm switch, this will force SSE boost to run no matter what.

 
p[H]ant0m said:
You're running the console correct? If so, you definitely want to add the -forceasm switch, this will force SSE boost to run no matter what.
Click to expand...
Fixed! :)
 
Specificaly what type of machine are you running at work, Amd, Intel, HT yes or no and what speed. If you are running it hyperthreaded are you using two instances. I think that information might clear up somethings if we could get it.

-MN Scout
 
Mohonri said:
Fixed! :)
Click to expand...

Gah, I knew I fumbled something up there! Thanks for the catch!

That's what I get for participating in K*'s ++ fest in Genmay...

 
Work machine is a Dell OptiPlex 170L with a 3.2ghz P4 and 1gig DDR, HT enabled but only 1 instance
 
SSE3 boost? Do AMD chips not get utilized with that yet? I know my Venice has it, but it just says "Extra SSE boost on".
 
Well in the QMD faq I've posted, Stanford openly admits that the Intel compiler they use, works leaps and bounds ahead of anything that AMD's are capable of, so the SSE2 implementation is it Intel-specific.

And as they've stated before, they'd rather get results sooner than later, so that's not a surprising thing they've done.

 
sorry, woops, didnt see your post before I started posting my own.

Bah. That just means my AMD chips have to work that much harder for its ppd though, so, I'm that much more proud. At least, saying that makes it feel better
 
MustangWorld said:
Work machine is a Dell OptiPlex 170L with a 3.2ghz P4 and 1gig DDR, HT enabled but only 1 instance
Click to expand...

I believe that if you have only 1 instance on a hyperthreaded cpu that it actually uses 100% of the cpu but Windows reports it incorrectly. Maybe I'm way off base here. I thought I heard that mentioned somewhere. That atleast would account for the much faster speeds on the same work unit in comparison to your Xeon that has 2 instances per chip.

-MN Scout
 
p[H]ant0m said:
Well in the QMD faq I've posted, Stanford openly admits that the Intel compiler they use, works leaps and bounds ahead of anything that AMD's are capable of, so the SSE2 implementation is it Intel-specific.

And as they've stated before, they'd rather get results sooner than later, so that's not a surprising thing they've done.

Click to expand...

I dont' really know anything about compiling, but couldn't they just compile it a second time using an AMD compiler for the SSE2/3, or would that take a bunch more coding?

-MN Scout
 
QMD FAQ - Stanford said:
#12) What about AMD support? We are currently using the Intel Fortran compiler and libraries. This software intentially runs slowly on AMD CPUs (SSE2 is not supported). While there have been hacks around this issue, such modifications violate Intel's EULA. At FAH, we follow software EULAs and are thus bound to this limitation imposed by Intel.

#13) That's not fair to AMD chips! Yes, it isn't fair and AMD is taking actions against this. We hope that things will change, but our hands are tied here. We could give these WUs to AMD machines, but they would have a much worse points per day (less than half of what one gets on Intel hardware) and would not perform well in general.

#15) Why not just use a compiler that legally supports SSE2 on both Intel and AMD CPUs? Currently, the best compiler (speed wise) for QMD is the Intel compiler (by a factor of 2x). The AMD compiler is pretty good, but is limited (license-wise) to AMD chips; however, it is not as fast or as optimized as the Intel compiler. We have not found a compiler which has no restrictions (runs on both Intel and AMD) which close in speed to that of the Intel or AMD compilers.
Click to expand...

These are their official reasons, it seems that its not a matter of them doing it, its a licensing issue and speed issue.

 
I wont second-guess or try to compile my own client or anything; got my fill of that crap with Gentoo..

emerge xorg
emerge firefox
emerge gaim
emerge system
emerge world


emerge DEATH
 
I remember when that intel compiler issue and AMD came out on the front page. It is really too bad that Intel cripples the AMD part. Thanks p[h]ant0m for finding that link.

-MN Scout
 
MN Scout said:
I remember when that intel compiler issue and AMD came out on the front page. It is really too bad that Intel cripples the AMD part. Thanks p[h]ant0m for finding that link.

-MN Scout
Click to expand...

Yeah, its a pretty sucky situation, as AMD's would probably handily stomp the Intel's if they could get it compiled. Hopefully in time, a compromise can be hashed out as more and more of us are going to A64's and X2's, and that's alot of power that would benefit these high power Units.


 
MN Scout said:
I believe that if you have only 1 instance on a hyperthreaded cpu that it actually uses 100% of the cpu but Windows reports it incorrectly.
Click to expand...
This is more or less the right way of thinking about it. Hyperthreading is a trick where one process uses the CPU, and while it's waiting on data from memory (memory is way, way slower than on-chip cache) the other process takes over. This helps only a little, since FAH is mostly limited by CPU speed. And on QMDs, the memory bandwidth is so much of an issue that it doesn't help any - one process runs out of stuff to do, and the other is also waiting on data.

Hope that helps clarify things; if mikeblas stops by, though, I'm sure he'll give a far better description of it ;)

And CaptRingold:
Code: 
~# emerge DEATH
Calculating dependencies
emerge: there are no ebuilds to satisfy "DEATH".
~ # emerge --search DEATH
Searching...
[ Results for search key : DEATH ]
[ Applications found : 2 ]

*  games-action/deathchase3d
      Latest version available: 0.9
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 574 kB
      Homepage:    [url]http://www.autismuk.freeserve.co.uk/[/url]
      Description: A remake of the Sinclair Spectrum game of the same name
      License:     GPL-2

*  games-fps/ut2004-deathball
      Latest version available: 2.3
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 100,499 kB
      Homepage:    [url]http://www.deathball.net/[/url]
      Description: UT2004 - Death Ball mod
      License:     freedist
Yeah, I'm switching to Debian. Real Soon Now.

 
Yeah, I'm seeing a huge grop in times by only running two instances on the dual xeon. QMD times were cut in half by running two QMDs, two non-advmethods. I'm thinking of just running the two QMD instances for now...
 
unhappy_mage said:
This is more or less the right way of thinking about it. Hyperthreading is a trick where one process uses the CPU, and while it's waiting on data from memory (memory is way, way slower than on-chip cache) the other process takes over. This helps only a little, since FAH is mostly limited by CPU speed. And on QMDs, the memory bandwidth is so much of an issue that it doesn't help any - one process runs out of stuff to do, and the other is also waiting on data.

Click to expand...

Actually, you are a bit wrong there. Hyperthreading really is a trick and/or hack. The way it works is it simulates a second CPU because of the long ass pipleline of the P4. Because of that long pipeline a branch misprediction kills the efficiency. In order to speed things up a bit, the virtual CPU will allow a second thread to also be run to keep the pipeline full even with branch mispredictions. This is why in most cases you won't see more than a 15% increase by running two clients on a Hyperthreading enabled P4.

What I do with mine at work is run one instance with bigpackets (I won't touch QMD's since it's my work machine) and a second instance with timeless WU's that only uses 15% CPU. This way, the client doing normal/bigpacket WU's doesn't take much of a hit most times when processing since it's set to 100% in the client while the second instance is only using 15% which equates approximately to the advantage of Hyperthreading. Hopefully that makes sense.

I will say that if my work P4 is running two tinkers (1 regular and one timeless) both clients take a performance hit. If the first instance is running on an SSE usable core, the second instance will run normally. If the first instance is running a tinker, the second instance with the timeless tinker takes a performance hit since both are trying to use the same parts of the CPU at the same time.

 
You must log in or register to reply here.
Back
Top