Yes, but the handcoded SSE stuff was improved again near the end of S5R3, but that latest improvement didn't yet make it into the Windows built. This is work in progress. Also the Linux version has an executable that is built for SSE2, while the Windows app has only variants for SSE and non-SSE.
Let's not forget that K8 is really quite old an architecture by now, it competed (and very well indeed!!) against Pentium III and Pentium 4, but is no match for recent (say) Intel Core2 chips.
Ok, thx for the fast answer :)
Of course the K8 is old nowadays, but the Core2 should not be nearly twice as fast :)
But anyways, I guess the missing SSE2 code explains it.
I'm collecting Primegrid and Docking data on the Q6600 to create a comparison, but have enough Boincsimap work to show what I'm seeing as the differences between intel and AMD.
On Boinc Simap the average cpu seconds is:
Q6600 2065
9950one 2243
9950two 2287
9600 2492
X2 6000 2115
X2 5200 2253
X2 4800 2484
3700 2833
As you can see, the "ole" K8 X2 6000 performs nearly as well core to core.
The difference is a couple minutes on a 40 min wu, not anywhere near the 6hr vs 9 hr I see at Einstein.
Unless someone has an idea of why the Einstein wus are going to comp error immediately, even at stock speeds on the 9950's, I guess we should just wait a day or so and let the clients work and return some samples. I have a 1.5 day cache, so it shouldn't take long. Also, I've re allowed docking and Primegrid on the Q6600 and suspended Einstein, so samples can be gathered.
[edit, reread some posts]NO the TLA bug fix is not in effect.
You might check to see if the 32-bit emulation code is installed on your Ubuntu 64 systems. For some reason, they didn't make it installed as a default.
Einstein runs as a 32-bit app. It isn't written for 64-bit (yet).
You have to install the 32 bit compatibility libs on your 64 bit Linux, as the Einstein app currently is 32 bit only on both Windows and Linux. This can be done via the package management mechanism of your Linux distribution, I think it's "sudo apt-get install ia32-libs" for ubuntu.
Good Luck
Bikeman
It's installing something(I ran that command from terminal). Now to wait until I get get more work and see.
Let's not forget that K8 is really quite old an architecture by now, it competed (and very well indeed!!) against Pentium III and Pentium 4, but is no match for recent (say) Intel Core2 chips.
Correction:
K8 dominated over P4 and anything older than it up until the Prescott revisions (faster FSB, 800 vs. 533) at about 3.2-3.4GHz when a P4 would about pull even, and that is only because K8 wouldn't clock that high.
My complaint, that was also brought up by someone else, is Windows vs. Linux. You have a 175 running Linux. I have an overclocked 3700+. The nominally clocked 3700+ is really just one core of a 175. I'm bringing my system on here for a few tasks, just to show the large delta in performance, which I think will be on the order of 20-25%...and bear in mind my system is overclocked...
Good luck with that. I tried that about a year ago with very poor results. I was using a VMware workstation (6.0.2, I think) with an Ubuntu 7.04 and 7.10 guest. Performance was in the tank due to overhead from the VM.
I'd be interested though if you have better luck...since this disparity has been around for almost 2 years now...
But you can't be sure to be able to show the delta with just a few tasks, because the runtime variation of units themselves is about the same as the performance delta between Windows and Linux, ca 20 - 30% . It's not disputed that this delta exists. I understand that the devs are now quite close to replace the MS compiler with a GCC variant for Windows as well and that will make it much easier to bring Linux and Win apps to the same codebase. Stay tuned.
But anyway I don't want to hijack Astro's thread which is on AMD vs Intel, not Linux vs Windows :-).
I read Astro's results from BOINCsimap and I think they are indeed comparatively favorable for the AMDs. There are even a few AMD boxes under the TOP 20 hosts at BOINCSimap, something unusual these days.
Does anybody know what kind of computation BOINCSIMAP does (is it more integer arithmetic, memory intensive data shuffling or floating point arithmetic?).
But anyway I don't want to hijack Astro's thread which is on AMD vs Intel, not Linux vs Windows :-).
Fair enough, but there still could be an AMD penalty just for running Windows. The binary has the "AuthenticAMD" string in it. Since nobody ever answered whether or not this impacts peformance, I'll test that along with the disparity between the Win and Linux apps...
I'm saying I think Einstein rates as a 'tier one' project, and was saddened that to add credit, I'd have to suffer what appears to me to be a disparity much larger than I see at other projects. I was wondering if this were seen by everyone, or even known about, and if it was known, was there something being done to make me not feel like I'm wasting time attaching with AMD processors. Bikeman asked for details. Details which I don't have readily available, but am now collecting. To fix an ailment, one must first realize there's a problem, then ID the problem, then finally fix the problem.
To be honest, I have the impression that even if a disparity exists, Einstein probably still pays better than some of the projects I'm running, so it's not like it'd hurt my RAC or anything. At Docking I'm getting exactly what the Boinc benchmark scoring system dictates, so who knows, if I just left them (the amd processors) attached, my RAC may even increase. LOL It would just bug me to know I wasn't getting the max performance that it appears I should be getting, and that's based upon the performance of the processors on other projects.
I was wondering if this were seen by everyone, or even known about, and if it was known, was there something being done to make me not feel like I'm wasting time attaching with AMD processors.
Here:
AMD running Windows - At least a 20% penalty vs. Linux
AMD vs. Intel in the same performance class - unknown. The tricky part is coming up with a proper comparison class, or even a speed in a particular class.
Anyway, the gap has not decreased for AMD/Windows vs. AMD/Linux since you posted some comparisons for me some time ago. In fact, I personally think the gap widened some with S5R4. That issue though affects all processors running the Windows app. What I don't know is if it impacts AMD any more than Intel...
RE: Yes, but the handcoded
)
Ok, thx for the fast answer :)
Of course the K8 is old nowadays, but the Core2 should not be nearly twice as fast :)
But anyways, I guess the missing SSE2 code explains it.
Maybe I'll try a Linux VM later ^^
cheers
Opteron
I'm collecting Primegrid and
)
I'm collecting Primegrid and Docking data on the Q6600 to create a comparison, but have enough Boincsimap work to show what I'm seeing as the differences between intel and AMD.
On Boinc Simap the average cpu seconds is:
Q6600 2065
9950one 2243
9950two 2287
9600 2492
X2 6000 2115
X2 5200 2253
X2 4800 2484
3700 2833
As you can see, the "ole" K8 X2 6000 performs nearly as well core to core.
The difference is a couple minutes on a 40 min wu, not anywhere near the 6hr vs 9 hr I see at Einstein.
Other samples to follow when it gets some done.
RE: Unless someone has an
)
You might check to see if the 32-bit emulation code is installed on your Ubuntu 64 systems. For some reason, they didn't make it installed as a default.
Einstein runs as a 32-bit app. It isn't written for 64-bit (yet).
[edit]See this thread.
Seti Classic Final Total: 11446 WU.
RE: You have to install the
)
It's installing something(I ran that command from terminal). Now to wait until I get get more work and see.
thanks
tony
RE: Let's not forget that
)
Correction:
K8 dominated over P4 and anything older than it up until the Prescott revisions (faster FSB, 800 vs. 533) at about 3.2-3.4GHz when a P4 would about pull even, and that is only because K8 wouldn't clock that high.
My complaint, that was also brought up by someone else, is Windows vs. Linux. You have a 175 running Linux. I have an overclocked 3700+. The nominally clocked 3700+ is really just one core of a 175. I'm bringing my system on here for a few tasks, just to show the large delta in performance, which I think will be on the order of 20-25%...and bear in mind my system is overclocked...
RE: Maybe I'll try a Linux
)
Good luck with that. I tried that about a year ago with very poor results. I was using a VMware workstation (6.0.2, I think) with an Ubuntu 7.04 and 7.10 guest. Performance was in the tank due to overhead from the VM.
I'd be interested though if you have better luck...since this disparity has been around for almost 2 years now...
But you can't be sure to be
)
But you can't be sure to be able to show the delta with just a few tasks, because the runtime variation of units themselves is about the same as the performance delta between Windows and Linux, ca 20 - 30% . It's not disputed that this delta exists. I understand that the devs are now quite close to replace the MS compiler with a GCC variant for Windows as well and that will make it much easier to bring Linux and Win apps to the same codebase. Stay tuned.
But anyway I don't want to hijack Astro's thread which is on AMD vs Intel, not Linux vs Windows :-).
I read Astro's results from BOINCsimap and I think they are indeed comparatively favorable for the AMDs. There are even a few AMD boxes under the TOP 20 hosts at BOINCSimap, something unusual these days.
Does anybody know what kind of computation BOINCSIMAP does (is it more integer arithmetic, memory intensive data shuffling or floating point arithmetic?).
CU
Bikeman
RE: But anyway I don't want
)
Fair enough, but there still could be an AMD penalty just for running Windows. The binary has the "AuthenticAMD" string in it. Since nobody ever answered whether or not this impacts peformance, I'll test that along with the disparity between the Win and Linux apps...
I'm at work, can't type
)
I'm at work, can't type much.
I'm saying I think Einstein rates as a 'tier one' project, and was saddened that to add credit, I'd have to suffer what appears to me to be a disparity much larger than I see at other projects. I was wondering if this were seen by everyone, or even known about, and if it was known, was there something being done to make me not feel like I'm wasting time attaching with AMD processors. Bikeman asked for details. Details which I don't have readily available, but am now collecting. To fix an ailment, one must first realize there's a problem, then ID the problem, then finally fix the problem.
To be honest, I have the impression that even if a disparity exists, Einstein probably still pays better than some of the projects I'm running, so it's not like it'd hurt my RAC or anything. At Docking I'm getting exactly what the Boinc benchmark scoring system dictates, so who knows, if I just left them (the amd processors) attached, my RAC may even increase. LOL It would just bug me to know I wasn't getting the max performance that it appears I should be getting, and that's based upon the performance of the processors on other projects.
RE: I was wondering if this
)
Here:
AMD running Windows - At least a 20% penalty vs. Linux
AMD vs. Intel in the same performance class - unknown. The tricky part is coming up with a proper comparison class, or even a speed in a particular class.
Anyway, the gap has not decreased for AMD/Windows vs. AMD/Linux since you posted some comparisons for me some time ago. In fact, I personally think the gap widened some with S5R4. That issue though affects all processors running the Windows app. What I don't know is if it impacts AMD any more than Intel...
Real AMD vs. Intel disparity == Astropulse