I believe that we have shown within error tolerance that the "different clients" are very close in performance. (Extensive offline benchmarks have been run that show the clients are within couple percents on the same host). This comparison between Marks HARV and my Thurston is going to show the difference between memory configurations Thurston is running dual channel DDR2-1125MHz, HARV is running single channel DDR2-760.

This is a test of how the clients perform on very similar, yet different hardware. The information should be of use to many with similar configurations.

If I understand your interest, this is the comparison of your Whaleport 0.2 on Thurston to the "SSSE3 Xeon Win32 rev 28 Pre-Release" running on Harv.

In this mid angle range view, the Whaleport running on Thurston has a rather large advantage.

There have been other hints that the Intel Quads running SETI suffer appreciable memory contention, so it should not be too surprising to find a disadvantage to the one running a much slower memory system. If this is really the root of this difference, it would quite likely be even great for very high angle range results. Some of those are on distribution at the moment, so perhaps we'll get to see that comparison some day. (Harv is the limiting factor, Thurston by now has WhalePort0.2X for a wonderfully wide range of Angle Ranges)

---

There have been other hints that the Intel Quads running SETI suffer appreciable memory contention, so it should not be too surprising to find a disadvantage to the one running a much slower memory system. If this is really the root of this difference, it would quite likely be even great for very high angle range results. Some of those are on distribution at the moment, so perhaps we'll get to see that comparison some day. (Harv is the limiting factor, Thurston by now has WhalePort0.2X for a wonderfully wide range of Angle Ranges)

This was my point (different memory latencies, different memory speeds) and this is why you need a direct comparison on the same machine. That said, you need a quad that I just don't have, so my offer to help isn't valid in this case.

---

Your host compares fairly closely to my Lovey. Lovey is an E4500 chip running at 2420Mhz 2MB L2 cache at very nearly the same clock...

???? 2.4GHz 2MB L2 = 3.4GHz 4MB L2?

Excuse me, your host shows this :

Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz [x86 Family 6 Model 15 Stepping 6]

Where do you get 3.4GHz 4MB L2 ??? not from my E4500!

His first posts states it is running at 3.4. How is 2.4 + 2MB L2 == 3.4Ghz + 4MB L2? It is well known that cache has a big impact on perfomance.

That's fine, I just wanted to help determine if the port was Being All It Could Be. Running Windows on my machine is a hassle because I'm relying on other Mac-specific apps for personal use, but if it was going to help other people I figured I'd make an offer, though your response mostly tells me that's not what you're interested in. ;)

You must not understand, I think I have helped very many others, I do not see how your offer can help any further.

Actually again you don't understand. If you want the best comparison possible you test with the least amount of vars changed. In order to do that he is offering a system that is set up to run both OSX and Alex's client and runs Windows as well. It completely takes the HW out of the quation which hasn't yet been done in any of the tests I have read in this thread. Its always "my HW is close".

But at the end of the day if you guys think what you have is good enough ok. I don't see anyone saying you aren't helping out.

Skulltrail isn't available to the public, either. The only hope of response is from people at websites who have preview hardware.

There are now 2 Skulltrail hosts in the top 20 hosts list. I offer my AK_WhalePort to run on them.

Yeah they are probably owned by someone known for not doing more then talking smack. Who? could that be?

'nuf said,
JDWhale

I don't get the attidued when someone is just offering to help because they can eleminate that HW varibale in the comparison between Alex's build and the new Windows optimized builds... That was the big arguement/nerd fight ;) to begin with. Why not just settle it instead of all the guessing?

At the end of the day the APPS will be similar in performance and Windows will win out because of Overclocking.

---

...
SSE4.1 Xeon Win64 rev 32 Pre-Release
SSSE3 Xeon Win64 rev 32 Pre-Release
...

erm ... I didn't build either of those so I can't really vouch for their speed ... I was thinking of the 32 bit builds. I say there might possibly be some issue with those then. RC1's not far off, and the 64 bit versions of those will be built on my own machine.

Jason

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

But at the end of the day if you guys think what you have is good enough ok. I don't see anyone saying you aren't helping out.

Actually, I did, because he started this thread saying he was going to keep the exes to himself until he was like king of the world or some nonsense. It's purely for selfish reasons he's not helping out everyone, just his chosen buddies. Like I said before, I have no need for this, all the Windows users with Core-based CPUs could be helping this project out A WHOLE LOT MORE than they are. If all he did was fix compiler errors, then OF COURSE everything will validate, so there's no reason to sit on it. Rather, I said he's not interested in helping people out because it satisfies his e-peen, and if he was interested in helping folks, he'd distribute the client. Alex Kan just wanted people to download his clients when he first released them at the MacNN forums. Everyone grab it and let him know how it goes. JDWhale is very different - he's doing a fraction of the work (fixing compiler errors is nowhere near the work that Alex did, let's be honest) and hording it where the original author said PLEASE DOWNLOAD AND TEST IT. Very different people, and Alex should be admired for what he did for hte Mac community. JDWhale is just riding his coattails.

And if he decides not to release it because I made a stink, I'd apologize to the thousands of people that could make SETI@home better by using it.

---

People, Please understand there are legal [licensing] and financial issues involved with any software release, open source / free software or not.

Thankyou

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

And if he decides not to release it because I made a stink, I'd apologize to the thousands of people that could make SETI@home better by using it.

Wont happen, so dont worry. The release will happen when its ready, and that looks like 1 May at this stage. We just have to sit back & wait until it is ready.... I have tried begging for the RC1 pre-release but it didnt work lol

---

Excuse me, your host shows this :

Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz [x86 Family 6 Model 15 Stepping 6]

It doesn't show the overclocked speed.

edit: and if you bothered looking at the WU's you could see the times are FANTASTIC and about 45-50% faster than your 2.42GHz Core2 with the 2MB L2 cache. If my CPU is really running at 2.4GHz, then your Windows client isn't nearly as fast as you think it is. But it's not and your client is fine on your limited test farm. I was trying to give a larger point of reference and have an EXACT COMPARISON to an OS X box so you could REALLY see how it performed. You said no, you don't want my help and that's fine. Windows is a PITA for me to run anyway.

You are correct, I apologize. I missed the original reference that your MAC was OC'd and thus not a close compare with Lovey, my E4500. I would hate to cause you a PITA by offering you to switch to Windows for a test. I know that if I had a Mac desktop I wouldn't want to "downgrade" either. Peace.

BTW - I think we have the "Hardware out of the question" with the Mac Pro 8-core X5365 runs by UL1.

Cheers,
JDWhale

---

But at the end of the day if you guys think what you have is good enough ok. I don't see anyone saying you aren't helping out.

Actually, I did, because he started this thread saying he was going to keep the exes to himself until he was like king of the world or some nonsense. It's purely for selfish reasons he's not helping out everyone, just his chosen buddies. Like I said before, I have no need for this, all the Windows users with Core-based CPUs could be helping this project out A WHOLE LOT MORE than they are. If all he did was fix compiler errors, then OF COURSE everything will validate, so there's no reason to sit on it. Rather, I said he's not interested in helping people out because it satisfies his e-peen, and if he was interested in helping folks, he'd distribute the client. Alex Kan just wanted people to download his clients when he first released them at the MacNN forums. Everyone grab it and let him know how it goes. JDWhale is very different - he's doing a fraction of the work (fixing compiler errors is nowhere near the work that Alex did, let's be honest) and hording it where the original author said PLEASE DOWNLOAD AND TEST IT. Very different people, and Alex should be admired for what he did for hte Mac community. JDWhale is just riding his coattails.

And if he decides not to release it because I made a stink, I'd apologize to the thousands of people that could make SETI@home better by using it.

If I remember correctly JD is using the free 30 day trial version of Intels compiler. If so this means to keep legal he cannot distribute the code.

But at the end of the day if you guys think what you have is good enough ok. I don't see anyone saying you aren't helping out.

Actually, I did, because he started this thread saying he was going to keep the exes to himself until he was like king of the world or some nonsense. It's purely for selfish reasons he's not helping out everyone, just his chosen buddies. Like I said before, I have no need for this, all the Windows users with Core-based CPUs could be helping this project out A WHOLE LOT MORE than they are. If all he did was fix compiler errors, then OF COURSE everything will validate, so there's no reason to sit on it. Rather, I said he's not interested in helping people out because it satisfies his e-peen, and if he was interested in helping folks, he'd distribute the client. Alex Kan just wanted people to download his clients when he first released them at the MacNN forums. Everyone grab it and let him know how it goes. JDWhale is very different - he's doing a fraction of the work (fixing compiler errors is nowhere near the work that Alex did, let's be honest) and hording it where the original author said PLEASE DOWNLOAD AND TEST IT. Very different people, and Alex should be admired for what he did for hte Mac community. JDWhale is just riding his coattails.

And if he decides not to release it because I made a stink, I'd apologize to the thousands of people that could make SETI@home better by using it.

You are entitled to your opinions. As anyone who has followed this thread knows, I have made my opinions known and do not accept any credit for the brilliant code assembled by Alex, I only answered a couple challenges by attempting to port his code to build/run under Windows. I am sorry that your opinions of me are so negative.

That said, I'm curious if you have experimented and tried to run the "xeon" client for OS-X. The results in doing so with the Windows builds of the code have showna valuable performance boost on nearly all Core2 hosts tested so far.

I don't even know if the "xeon" client will run on your Core2 host, thus I pose the question. It might be possible that the code that Alex built is so customized to the Mac that the crew at Lunatics could learn some more if you tried and posted your results.

We are all in this project together, aren't we?

Cheers,
JDWhale

---

I run the Xeon client exclusively because my FSB more matches that of a Xeon machine than a Core2Duo Mac (since they're laptop CPUs). Alex's Xeon port hasn't been updated since October 7, and Harpertown Mac Pros didn't come out until sometime after that. Low End Mac says Harpertowns came out January 8, 2008, so we're talking about a 3-month difference.

I suppose I could switch to the Core2 version and see if there's a performance loss. I have no idea what compiler switches he used between the different versions, though I do know that compiler flags are the only differences.

---

I run the Xeon client exclusively because my FSB more matches that of a Xeon machine than a Core2Duo Mac (since they're laptop CPUs). Alex's Xeon port hasn't been updated since October 7, and Harpertown Mac Pros didn't come out until sometime after that. Low End Mac says Harpertowns came out January 8, 2008, so we're talking about a 3-month difference.

I suppose I could switch to the Core2 version and see if there's a performance loss. I have no idea what compiler switches he used between the different versions, though I do know that compiler flags are the only differences.

From what I can see you are running the "Core 2" client, but of course I'm wrong quote often. I agree with you that it is the "#define compiler conditionals" that make the differences and alter the same source code to compile differently for each version. It sure is hard to read the first time through, if you know what I mean.

OK... The reason I asked was when I look at the "version" line in stderr for your Mac E6600 I see this

Version info: OS X SSSE3 (Intel, Core 2-optimized v8-nographics) V5.13 by Alex Kan

This line only gets to stderr in the version of the Alex code I have when the "#define" for "USE_I386_XEON" is not enabled. When both "USE_I386_CORE2" and "USE_I386_XEON" are #defined, then you get the message

Version info: OS X SSSE3 (Intel, Xeon-optimized v8-nographics) V5.13 by Alex Kan

When both these directives we see the "xeon" message to std error and performance boost on all Core2 hosts.

This is why I ask if you have tried the "xeon" client. Does what I'm saying make any sense.

BTW - I haven't had the opportunity to try the code on a Harpertown yet, let alone a Mac Pro 8-core Harpertown. My first guess is that the Harpertown on OS-X will outperform on VHAR, but will underperform slightly on mid-angle ARs. Possible because the CPUs were released too late for Alex to optimize in time.

Cheers,
JDWhale

---

From what we've discovered and has been shown in the extensive amount of data collected and presented, your T8300 host might benefit slightly from running the Xeon optimized v-8 client rather than the Core2 client you are currently using. Try it, you might like it ;-)

{under the category of "I knew if I posted to this thread, I'd get sucked in somehow"}

That's an interesting proposition and I think I'll take you up on it. That computer (an early '08 MacBookPro) was set to NNT about an hour ago. It'll probably take 48 hours for it to go through the cache and then I'll install AK's Xeon v8.

Now...where can I get the data vac to track the couple of hundred tasks the MBP has in cache/turned in?

QS

---

<snip>
BTW - I think we have the "Hardware out of the question" with the Mac Pro 8-core X5365 runs by UL1.

Cheers,
JDWhale

Just to reiterate this point, since there seems to be some confusion since my last post. The whole basis of my post here was that the results came from the same hardware i.e. UL1's Mac Pro 8-core X5365.

As an aside, in all the data that I have been collecting lately, I have not come across an 8-core that comes anywhere near a Conroe quaddie on a "per core" basis when they are running the same "Xeon" optimised App (and when I say "anywhere near" I mean 30 - 40% advantage for the quaddie!). But since I don't have control of all the variables I can't say whether this is an effect of different clocks, cache contention, or other factors. Just reporting what I am seeing.

F.

---

I believe that we have shown within error tolerance that the "different clients" are very close in performance. (Extensive offline benchmarks have been run that show the clients are within couple percents on the same host). This comparison between Marks HARV and my Thurston is going to show the difference between memory configurations Thurston is running dual channel DDR2-1125MHz, HARV is running single channel DDR2-760.

This is a test of how the clients perform on very similar, yet different hardware. The information should be of use to many with similar configurations.

If I understand your interest, this is the comparison of your Whaleport 0.2 on Thurston to the "SSSE3 Xeon Win32 rev 28 Pre-Release" running on Harv.

In this mid angle range view, the Whaleport running on Thurston has a rather large advantage.

There have been other hints that the Intel Quads running SETI suffer appreciable memory contention, so it should not be too surprising to find a disadvantage to the one running a much slower memory system. If this is really the root of this difference, it would quite likely be even great for very high angle range results. Some of those are on distribution at the moment, so perhaps we'll get to see that comparison some day. (Harv is the limiting factor, Thurston by now has WhalePort0.2X for a wonderfully wide range of Angle Ranges)

Yes, this is exactly the hosts & clients I wanted to see. When I first hinted at this match up, I didn't know that Mark had hobbled his Q6600s memory and thought the matchup would be much more even. I think that I agree with your prediction, there will be even more significant disparity on VHAR WUs.

Lesson to all being made at msattler expense. Optimize your memory. I think this is one place that the Macs have advantage over other PCs. The MACs are built to specification, whereas many of our "other" hosts are just thrown together without tuning the components. (Sorry Mark).

Regards,
JDWhale

---

hmmmm...that can't be right. I'll look when I get home. I've been wrong once or twice (I guess this would make three times, not bad for my 30 years on earth...LOL)

---

This was my point (different memory latencies, different memory speeds) and this is why you need a direct comparison on the same machine. That said, you need a quad that I just don't have, so my offer to help isn't valid in this case.

Actually, the interested parties' specific declared interest for the Thurston/Harv comparison was in looking for the effect of the memory differences. If you meant that particular comparison would better be done on a single host by changing memory components and parameters while keeping the ap and usage environment constant, I'd agree, but your suggestion implies you think the particular question they are pursuing should not be pursued.

There is more than one agenda for the participants in this thread. My personal interest is to provide support for higher SETI compute productivity on Windows hosts, just possibly by providing useful information to the developers, more likely by helping people make good choices for their machines, and most likely by playing a bit part in advance publicity that might help uptake after release.

I, personally, have zero interest in the "how close to the Mac" question. Others do, but legitimate contributions to the thread are not restricted to that point.

---

{under the category of "I knew if I posted to this thread, I'd get sucked in somehow"}

That's an interesting proposition and I think I'll take you up on it. That computer (an early '08 MacBookPro) was set to NNT about an hour ago. It'll probably take 48 hours for it to go through the cache and then I'll install AK's Xeon v8.

Now...where can I get the data vac to track the couple of hundred tasks the MBP has in cache/turned in?

QS

It's running. I'll let you know what the baseline looks like.

F.

---

That's an interesting proposition and I think I'll take you up on it. That computer (an early '08 MacBookPro) was set to NNT about an hour ago. It'll probably take 48 hours for it to go through the cache and then I'll install AK's Xeon v8.

You can just install the client without waiting for it to finish the downloaded WU's - just shut down the BOINC Manager, grab the Xeon client, and stick it in /Library/Application Data/BOINC data/projects/setiathome.berkeley.edu and overwrite what's there. If, in fact, I installed the wrong client for this trip down SETI lane on this machine, that's what I'll be doing around 4PM central when I get home from work (not that I'm working much today as it is).

And then, for some reason, reinstall BOINC. I'm sure it's related to what permissions need to be set on the newly-added files, but I found the easiest way to get it working right is just reinstall over the top of what's there. It was never a problem in Tiger, but it is in Leopard for me.

I, personally, have zero interest in the "how close to the Mac" question. Others do, but legitimate contributions to the thread are not restricted to that point.

You should probably have at least some interest on how it compares to the Mac version - if for some reason with Windows port was lagging behind on the same hardware, that means there's still a problem somewhere. If it ends up being faster overall, that's great news for whoever gets to use it, because right now Alex Kan's client is the fastest one available. Something even faster would be great news for Windows users once it's available.

---

@QSilver,
Here's what your T8300 is doing at the moment:


Direct Link.

I'll add you to my monitoring list and post updates when there is anything to report, if that is OK by you?

I am curious to see whether the "Xeon effect" is ubiquitous.

F.

---