nVidia F@H ??

[GLeeM]

"I would of thought that if you optimise any program to use SSE2 etc that you'd want to benchmark it with SSE2 on to be able to see the difference ,& not hide it.Or have I missed something?"

At the time there were still lots of CPUs without SSE/SSE2.

If WUs were benchmarked on CPU with SSE2 turned on, then all the older computers would get bad PPD. In effect, you got a bonus if had a CPU with SSE2. This seemed fair - the newer computer gets more science done and should get more points per day.

So at the time, all WUs were benchmarked with SSE turned off. This was the "Standard".

Because the QMDs were only sent to P4 CPUs that had SSE2, it didn't seem fair to use the Standard way of benchmarking. They got a 2X BigWU bonus plus the SSE2 bonus (the QMDs heavily used SSE2). On my P4 Northwood 3.0 @ 3.3 I got 125 ppd on regular WUs, on the QMDs I got 450 ppd.

 

[biodoc]

Originally posted by: 7im
Sid,

If Stanford did not try to make QMDs work on AMD chips, then how did Stanford know the AMD science libraries made the QMDs run so much slower on both the AMD and Intel chips? How did they know the AMD libraries disabled SSE2 on the Intel chips just like the Intel libraries disabled SSE2 on the AMD chips? Both Intel and AMD play dirty.

The decision was simple, run the faster libraries, which also happened to match the largest demographic of fah contributor. It was a no-brainer.

snip

It was pretty simple actually. Intel provided Stanford with their Fortran compiler & libraries with the stipulation that the SSE2 extensions be disabled if run on an AMD chip (I wonder why?)

Here's some quotes from a thread at Folding-community.org:

"Intels get them when AMDs don't becasue the QMD core is compiled with Intel's Fortran compiler. The compiler works such that it does not allow AMD CPUs to run the resultant binary with full assembly optimizations. To disable this function would constitute a violation of the compiler's EULA. Without the optimizations it's not really worth giving them to AMd CPUs becasue it runs so slow."


"Intel compiler is only small part of the issue. Largest part of the issue are the Intel libraries:Link"

A link to the thread (our friend 7im posted in this thread too) is Here

 

[Assimilator1]

Sid
Fair enough.

7im
Ah that's a different link(the thread) ,I'll have a read through that thanks.
Re your 2nd link ,I read the entire thing twice & came to the conclusion it was talking about ATI stuff mainly

"...and perhaps most importantly, much better driver support (we've fixed most if not all of the bugs leading to driver incompatibilities)."

This is in reference to ATI,Mac & PS3 from what the 1st & 2nd paragraph says.

So here's what I've been alluding to for a while. With the help of ATI and people in the FAH team ...., we've got some nice new software to demo, including

Anyway I'll read that thread link & see what it says about G80

Gleem
Got ya

Biodoc
Makes sense to me (did anyway) :thumbsup:

 

[7im]

Originally posted by: biodoc

Originally posted by: 7im
Sid,

If Stanford did not try to make QMDs work on AMD chips, then how did Stanford know the AMD science libraries made the QMDs run so much slower on both the AMD and Intel chips? How did they know the AMD libraries disabled SSE2 on the Intel chips just like the Intel libraries disabled SSE2 on the AMD chips? Both Intel and AMD play dirty.

The decision was simple, run the faster libraries, which also happened to match the largest demographic of fah contributor. It was a no-brainer.

snip

It was pretty simple actually. Intel provided Stanford with their Fortran compiler & libraries with the stipulation that the SSE2 extensions be disabled if run on an AMD chip (I wonder why?)

Here's some quotes from a thread at Folding-community.org:

"Intels get them when AMDs don't becasue the QMD core is compiled with Intel's Fortran compiler. The compiler works such that it does not allow AMD CPUs to run the resultant binary with full assembly optimizations. To disable this function would constitute a violation of the compiler's EULA. Without the optimizations it's not really worth giving them to AMd CPUs becasue it runs so slow."

What's your point Doc?

The compilers and libraries from AMD contained the same stipulations against running SSE2 on Intel chips. (I wonder why?) :roll:

 

[Assimilator1]

lol ,his point was explaining why Intels had the advantage on QMDs

What I don't get is why QMD SSE2 optimised for Intels by Intel libraries is faster (as you'd expect), yet AMD optmised libraries for AMDs is slower!

 

[7im]

A1,

Intel has several years of experience with compilers over AMD, and Intel has a whole division dedicated to developing and supporting the compilers and science libraries they sell as Retail Products. Historically, AMD hasn't had the revenue streams to match Intel's efforts in the ancillary products like software. That's why even the AMD software ran slower on AMD chips that typically outperformed (at the time) the Intel chips.

Feel free to fact check my "press releases" however you wish.

 

[biodoc]

Originally posted by: 7im
A1,

Intel has several years of experience with compilers over AMD, and Intel has a whole division dedicated to developing and supporting the compilers and science libraries they sell as Retail Products. Historically, AMD hasn't had the revenue streams to match Intel's efforts in the ancillary products like software. That's why even the AMD software ran slower on AMD chips that typically outperformed (at the time) the Intel chips.

Feel free to fact check my "press releases" however you wish.

Ok 7im, I'll try to make my point but first let me set the stage. We have 3 players in this soap opera:

1) Crunchers: We are the source of computational power that is essential for the success of the Stanford scientific effort or any other DC project. We enjoy the team and individual competition and the fact that we are supporting research. A certain percentage of us also like an edge. If crunchers are running intel hardware and a project is giving bonus points for intel cpu support, then they will have a strong urge to transfer to that project.

2) Stanford: They need massive amounts of computational power for their research. For this type of project, there can never be enough. They are competing with other DC projects for our computational support.

3) Corporations: The players for this DC project are Sony (PS3 support), Intel (CPUs), Apple (MacOS support) & of course ATI (GPU support). What are they looking for? I'm not completely sure but probably "bragging rights" and a marketing edge over competitors. Certainly AMD vs Intel has always been a hot topic in the DC forums. Perhaps they are keen on supporting basic research too.

Anyway the common denominator here is competition.

To give Stanford credit, they are looking outside the box for more computational power. The source code for NV and ATI GPU drivers is not in the public domain so they needed a partner to develop this rich source of computational power. ATI is also looking forward to develop their GPU technology as future CPUs for scientific computation applications. This is probably why AMD "bought" them and together they will release their "massively parallel" processor soon (firestream). This is good news for the scientific/engineering community but the initial cpu price will be $2,000. Bottom line: Stanford gets an exclusive source of additional computational power.

Same thing with the sony/PS3. Stanford has an exclusive source of additional computational power and Sony has a marketing edge(?).

7im, I don't have a problem with the above collaborations.

The intel/QMD issue is a bit more complicated. As 7im said, AMD was kicking Intel's butt at that time. On most DC projects at that time, AMD was king. Intel clearly wanted a situation where their processors were faster on at least one DC project. Intel offered their superior fortran compiler/libraries to Stanford but only if they agreed to turn off SSE2 optimization
if used on an AMD CPU. The result would be good for Intel. They would have bragging rights on at least one DC project. What would Stanford get out of this? The vast majority of the Crunchers out there were running Intel CPUs. Again, Stanford was desperate for more computational power. To attract more intel crunchers, they gave huge bonus points for QMD WUs! Advantage Stanford over other DC projects. Sure, they lost some AMD crunchers (minority) but on the whole, they got what they wanted: more computational power.

Im sorry, IMHO this Intel/Stanford/QMD situation was really low ball tactics! If Intel was really interested in supporting only the science, they would have offered the compiler/libraries with no strings attached. Stanford would have increased their computational power overall, but they wouldn't have a path to attract crunchers from other projects.

Ok, back to the NV GPU client Holiday gift promised by Stanford. Come on Stanford, tell us exactly what's going on. They can't develop a client without NV's full support (they need the source code for their drivers). Stanford clearly wants and needs NV expertise. They probably want funding from NV too.

Does NV want to collaborate with Stanford? Stanford already has an agreement with ATI which is their top competitor. NV knows they will not be dealing with "boy scouts". There is also the possibility that the ATI/Stanford agreement is mutually exclusive. If that's the case, then don't expect an NV client in the near future.

Bottom line: IMHO, Stanford is leading us on with NV support. Don't expect a client until you see the NV corporate logo on the F@H website!

 

[Assimilator1]

Good post :thumbsup:

7im
I see ,thanks & yes I remember now hearing about that as far back as the original 3D Now in the K6-2s

 

[GLeeM]

"Intel offered their superior fortran compiler/libraries to Stanford but only if they agreed to turn off SSE2 optimization if used on an AMD CPU."

biodoc, thanks for the eyeopening explaination.

I have to apologize to Sid and others for not fully understanding their frustration and pushing the "company line", slap me with a trout

___________________________________________

Some people were moving QMDs to AMD cpus because they could get better ppd that way. I wonder what kind of ppd the AMDs would have gotten with SSE2 optimizations turned on.

Non-disclosure agreements (or whatever they are called) stink.

 

[Insidious]

Heya GleeM... You do so much for F@H here.... you don't ever have to apologize to me for anything. :beer:

I'm not sure it was Stanford that turned off the SSE2 ops. I think that may have been a 'feature' of the Intel/AMD stuff and neither would allow Stanford to circumvent it without being considered in violation of their respective EULAs. I think Stanford just wasn't willing to write a client for each type of processor.

But again, my gripe wasn't so much that there was only an Intel client.. it was all about the ridiculous scoring and leaving people making just as much personal sacrifice of resources to F@H with MUCH less acknowledgment (points).
I also took exception with the Stanford F@H developers for trying to keep AMD users from quitting by making false (as proven by history) claims that a second, AMD client was going to be developed.

Same is true in present day SMD scoring methods. While originally, you had to run Linux to do SMP and that was maybe worth some additional attaboy (points) since now your computer is basically useless.... (Linux hardware support is borked) but at present, a windows client is available with little 'sacrifice' but SMP WUs are still given the huge bonus....
At least this time, Stanford has refrained from lying to users not getting so much credit. They can make their participation choices without that unscrupulous info.

:beer:

-Sid

 

[7im]

Originally posted by: Insidious

I'm not sure it was Stanford that turned off the SSE2 ops. I think that may have been a 'feature' of the Intel/AMD stuff and neither would allow Stanford to circumvent it without being considered in violation of their respective EULAs. I think Stanford just wasn't willing to write a client for each type of processor.

...
I also took exception with the Stanford F@H developers for trying to keep AMD users from quitting by making false (as proven by history) claims that a second, AMD client was going to be developed.

Same is true in present day SMP scoring methods. While originally, you had to run Linux to do SMP and that was maybe worth some additional attaboy (points) since now your computer is basically useless.... (Linux hardware support is borked) but at present, a windows client is available with little 'sacrifice' but SMP WUs are still given the huge bonus....
At least this time, Stanford has refrained from lying to users not getting so much credit. They can make their participation choices without that unscrupulous info.

:beer:

-Sid

I agree with Sid on that first point. Both AMD and Intel were playing dirty :evil:, and both disabled SSE2 support for the other chip in their code LONG before Stanford purchased an "off the shelf" copy of the compilers and libraries. NO special arrangements were made just to run QMDs. There was no conspiracy Doc.


I have to disagree with your second point Sid. You'd have to show me the post where you claim Stanford lied about saying they would develop a seperate AMD client, and then didn't do anything. As I recall, they said they would look in to making an AMD client for QMDs, and they did make a client internally, and they found it ran much slower, so why bother to go through the full development and testing cycle to release a client with no performance gains. Stanford was very upfront about that info, and I think you or GLeeM linked to that info a few posts back. If they didn't make an AMD based client with AMD libraries (at least internally), how did Stanford know the both the Intel and AMD clients ran slower with AMD libraries? Guess that shoots down your claim Stanford lied as you claim.


Why does everyone say the SMP benchmarks are so outrageous? Please consider...

The CPU client benchmark is 110 PPD on a 2.8 GHz P4, or ~220 PPD for bonus work units like Big WUs. So on a Big WU, the CPU client gets 78.57 PPD/GHz/core.

The SMP client benchmark is 1760 PPD on a 4 core Mac at 2.33 GHz (dual C2Ds). So that comes out to 188.84 PPD/GHz/core (as all SMP WUs are Big WUs, so this is the same basis for comparison).

Wow, the SMP client bonus is a whopping 2.4 times as many points as the CPU client. And only because the SMP client uses a lot more system memory, larger downloads/uploads, and that has to run nearly 24/7 to meet the very short deadlines. And don't forget the SMP client crashes on any network change or weak WIFI signal, and doesn't restart that well, or that crashes a 2nd SMP client if you happen to have the hardware to run 2 SMP clients. Some call it a fair trade, some may not.

But wait! When you factor in that the SSE speed of the Core 2 Duos in that SMP benchmark system are 2 times faster than the P4 (the advantage is the SSE speed, because the clock speeds aren't that different) so that core for core, the SMP client is only really given a .4 times advantage over the equivalent CPU client benchmark.

Double WOW! 4/10ths of a bonus per processor given to the SMP client benchmark over the CPU client benchmark. Yes, that "huge" bonus is completely outrageous. :roll:

 

[Insidious]

HiYa 7im

You got bored didn't ya?

If I remember right, you thought the QMD scoring was hunky dory too... Are we to be aghast that you can't see anything wierd here either?

Sorry to pick on the F@H peeps, I guess I left the rose colored glasses in my other pants.

-Sid

:beer:

 

[biodoc]

Hey 7im,

How 'bout we give this a rest for the Holiday season?

Actually, why don't you join us for the F@H TeAm Anandtech Holiday race?

I'm sure those guys at Ars Technica wouldn't mind if you set your clients to TeAm 198 for just one month!

 

[7im]

Originally posted by: Insidious
HiYa 7im

You got bored didn't ya?

If I remember right, you thought the QMD scoring was hunky dory too... Are we to be aghast that you can't see anything wierd here either?

Sorry to pick on the F@H peeps, I guess I left the rose colored glasses in my other pants.

-Sid

:beer:

I visit a lot of forums, bored or otherwise occupied.

My rose colored glasses are better than the AMD green ones you wear. All you gripe about is a year of QMDs and yet you ignore that AMD chips cleaned up on points for several years previously in the project. That's a rather one-sided view, IMO, and a bad case of sour grapes. Let me know when you want to talk about current events, or when your vintage improves. :wine:

7im

 

[Insidious]

A quick trip to the opthamologist and you will clearly see that I have a consistant history of bitching about each scoring inequity I see and have been on the long end as well as the short. I guess you just didn't notice.... but that would be, uh, inconvenient wouldn't it?

(holiday snip)
.
.
(/holiday snip)

-Sid

(are you just playing a the hunch that my teammates haven't seen my posts at your place about it over the last several years? Don't sell them short. I fold with an amazing bunch of people who I have great respect for)