The difference because of OS in Einstein is an Einstein problem. Full Stop. And I sincerely hope that they are doing everything to make Win, and other OS, SSE2 versions soon.
Urm... OS differences, generally, though not always, stem from compiler differences. Would you wish somehow to decree that the world should not be populated with compilers producing code of varying efficiency for this particular task?
Or, if you recognize the folly of that, would you ask the project deliberately to avoid use of more efficient compilation than the worst (including not just the compiler but the myriad elements of variety in how they can be used: special directives, switches, and all the rest).
I'd think effort on efficiency improvement should mostly be dedicated to the most productive avenues--highest return in total project computation by hour of programming investment, dollar of tools, risk of error... This would not naturally lead to exact equivalent productivity across all platforms, and forcing it to would necessarily reduce output--dramatically if pursued with real zeal.
The speed difference between Linux app versions and Windows app versions is only to a lesser degree a question of SSE2 support. As you can see from the diagrams posted here, the SSE versions of Win and Linux apps show a speed difference as well.
The major difference here is that the two versions (Win/linux)use different "generations" of the optimized assembler code.
The latest version was only ported to "gcc Syntax" (shortly before there was a "code freeze" on the apps to prepare for S5R4). The plan is to use a gcc variant for Windows apps as well as soon as possible, allowing to use the same source as for Linux and OSX-intel. Any more effort put into the MS Visual Studio specific code will be more or less wasted as it is (hopefully) a dead end to be sealed off soon.
The difference because of OS in Einstein is an Einstein problem. Full Stop. And I sincerely hope that they are doing everything to make Win, and other OS, SSE2 versions soon.
Urm... OS differences, generally, though not always, stem from compiler differences. Would you wish somehow to decree that the world should not be populated with compilers producing code of varying efficiency for this particular task?
Or, if you recognize the folly of that, would you ask the project deliberately to avoid use of more efficient compilation than the worst (including not just the compiler but the myriad elements of variety in how they can be used: special directives, switches, and all the rest).
I'd think effort on efficiency improvement should mostly be dedicated to the most productive avenues--highest return in total project computation by hour of programming investment, dollar of tools, risk of error... This would not naturally lead to exact equivalent productivity across all platforms, and forcing it to would necessarily reduce output--dramatically if pursued with real zeal.
Don't disagree with anything you have said, but it has been noted that 'nix version of S5R3 power apps and S5R4 are more efficient than the equivalent win versions. And it has also been noted that the 'nix ver is SSE2 and the win ver SSE.
I wouldn't know as a h/ware engineer which is the best compiler or if there is much difference between compilers, except from what is said on Seti and at work were both groups say, at the moment, the Intel compiler is best, even for AMD cpu's.
edit] even as I typed Bikeman had provided most of the answers. Thanks.
The speed difference between Linux app versions and Windows app versions is only to a lesser degree a question of SSE2 support. As you can see from the diagrams posted here, the SSE versions of Win and Linux apps show a speed difference as well.
The major difference here is that the two versions (Win/linux)use different "generations" of the optimized assembler code.
The latest version was only ported to "gcc Syntax" (shortly before there was a "code freeze" on the apps to prepare for S5R4). The plan is to use a gcc variant for Windows apps as well as soon as possible, allowing to use the same source as for Linux and OSX-intel. Any more effort put into the MS Visual Studio specific code will be more or less wasted as it is (hopefully) a dead end to be sealed off soon.
CU
Bikeman
Correct me if I am wrong then. Hopefully SOONER rather than later the windows client will use the gcc variant and SSE2 and while it may not be completely on parity to linux code it should close the gap. Whatever that gap is will be the best that can be done to put both platforms on as nearly equal footing as possible. Hopefully it will close the gap enough that it's within a tolerance range that those using windows won't feel like they are being screwed over.
At that point how einstein relates to other projects could be judged. In my mind of equality of credit accross projects would go something like this..
einstein@home = 2 units @12 hrs each for total credit in 24 hours is 300
seti@home = 6 units @4 hrs each for a total credit of 300
CPDN = 1 trickle at 24 hours for a total credit of 300.
That is just an example. The number of units and credit per unit as well are just an example and may or may not even come close to what each project does. My point is that regardless how many units you are able to process in a 24 hour period and the value placed on each would equal the same amount at a 24 hour period. This is assuming that the computers using this method are exactly the same regardless of what OS they are using. I am not stupid to the point that if I run a single core AMD @ say 2.4MHZ and joe 6 pack is using the top of the line Intel quad that he is going to process more units than I do and receive more credit. If I wish to compete with Joe 6 pack then I should go and get a top of the line Intel quad. And If I want to blow him away I might go get 5 or 6 quads.
I need to think more on the cross project parity before finishing this post. Will do that later after I have had my coffee and my brain gets unfoggy.
The speed difference between Linux app versions and Windows app versions is only to a lesser degree a question of SSE2 support. As you can see from the diagrams posted here, the SSE versions of Win and Linux apps show a speed difference as well.
The major difference here is that the two versions (Win/linux)use different "generations" of the optimized assembler code.
The latest version was only ported to "gcc Syntax" (shortly before there was a "code freeze" on the apps to prepare for S5R4). The plan is to use a gcc variant for Windows apps as well as soon as possible, allowing to use the same source as for Linux and OSX-intel. Any more effort put into the MS Visual Studio specific code will be more or less wasted as it is (hopefully) a dead end to be sealed off soon.
CU
Bikeman
Hopefully this will cause the apps performance to fall in line with each other. I'm willing to even be pursuaded to think 10% variance is "ok", but I'd rather see it come down to within 5%.
If on any project identical systems, including OS, should be getting the same credits for identical work. If not then there is a problem and I agree it should be investigated and solved.
I don't even ask for it to be "the same". I'm even willing to say "close enough". If my system processes taks in 20,000 seconds, while the Linux side (if I had one) were to process in 19,000 seconds (95% of the time for the Windows environment), then I'm ok with that. If, on the other hand, it is shown that the Linux side takes only 16,000 seconds (75%), that's when I start saying that things aren't quite right...and would start thinking about looking for a project that performed better for my system.
Quote:
I don't know Cosmology at all. So first question is, are their credits calculated by benchmark (BM) * time, and if so what are the BM figures for the other computer?
Cosmology is a utter mess. It is fixed credit per task. All tasks get 70 credits, no matter what kind of system they are, what BOINC version is used, nor the amount claimed. The Project Scientist essentially stated today that they had been offering more because there might be problems along the way that would cause people to get no credit. Prior to the past month, that situation had not happened. People from the "there must be 'parity' between projects" camp used the fact that there hadn't been a major issue as a virtual club to beat on the project for granting "too much". Now there are some instances where MANY users may have processed hundreds, even thousands, of tasks not even "for the science", but essentially "for the bit bucket", as they got zero credit for the work and Ben, the Project Scientist, has indicated that the afore "over-generous" awards will offset the gooseggs...
Quote:
Don't try comparing computers by BM scores, Pappa on SetiB has a Athlon X2 6000+ with BM's very similar to my quad, but processing times are 86hrs for his and 38hrs for mine doing astropulse units.
...and this is why any "cross-project parity" scheme based on benchmarks is flawed. All that taking a huge sample is attempting to do is to mask the underlying problem with the metric...
Nothing I say really matters. It will be done. Perhaps once the dust settles, maybe someone will look more towards a current-based solution rather than relying on a design from the past that doesn't appear to have been sound...
I started running Einstein S5R4 on a WinXP virtual machine, processor is Intel E2140 at 2.8GHz, should have a result or 2 tomorrow. So far it doesnt seem to be as much as 10% slower than Linux SSE2 but its very different frequency and the sequence numbers are not so close. How important are sequence numbers for S5R4 runtimes?
Silvers, what VM did you use that had significant overhead? Im running this test now on VMWare WS 6.03, overhead is so small it can be disregarded i think.
I started running Einstein S5R4 on a WinXP virtual machine, processor is Intel E2140 at 2.8GHz, should have a result or 2 tomorrow. So far it doesnt seem to be as much as 10% slower than Linux SSE2 but its very different frequency and the sequence numbers are not so close. How important are sequence numbers for S5R4 runtimes?
Silvers, what VM did you use that had significant overhead? Im running this test now on VMWare WS 6.03, overhead is so small it can be disregarded i think.
6.02...with an Ubuntu 7.04 and 7.10 guest. Paravirtualization support was at experimental stage, and the experiment failed for me. If I enabled paravirtualization, which was supposed to speed things up, making it closer to actually running native, the VM would be about 4-6 times slower than without paravirtualization...
As for the frequency / sequence numbers, unknown as yet...
How important are sequence numbers for S5R4 runtimes?
As for the frequency / sequence numbers, unknown as yet...
How much do sequence numbers matter? About this much:
:-)
Seriously , this is a chart mapping runtime for a single sky-point (minus initialization time) on z-axis across the sky (declination and right ascension on x- and y- axis).
This was performed on a Core Duo Macintosh (should be comparable to Linux SSE2 code).
Absolute minimum runtime is 46 seconds,
absolute maximum is at 71 seconds,
But this is only an upper limit for runtime variation because in a WU, there will be several hundred skypoints and they cannot all be at the absolute minimum or absolute maximum.
I'd guesstimate that the real-life observed runtime variation in the frequency range near 140 Hz for complete workunits should be more like
(maximum runtime) ~ 1.4 x (minimum runtime)
Under the assumption that all WUs contain the same number of skypoints (as they did approximately in S5R4, no idea whether this still holds in S5R4 tho).
Under the assumption that all WUs contain the same number of skypoints (as they did approximately in S5R4, no idea whether this still holds in S5R4 tho).
I forgot to look at the units completed to see if they all had the same number of sky points or not. But the same system is claiming a variety of figures that coralate to time to process. The results can be seen HERE
Also, Brian I hope your dad's surgery went smoothly and successfully and that he has a speedy recovery
[edit] I just checked the skypoints and all of them have a different number of skypoints. Looks like a variety in the 700's.
RE: The difference because
)
Urm... OS differences, generally, though not always, stem from compiler differences. Would you wish somehow to decree that the world should not be populated with compilers producing code of varying efficiency for this particular task?
Or, if you recognize the folly of that, would you ask the project deliberately to avoid use of more efficient compilation than the worst (including not just the compiler but the myriad elements of variety in how they can be used: special directives, switches, and all the rest).
I'd think effort on efficiency improvement should mostly be dedicated to the most productive avenues--highest return in total project computation by hour of programming investment, dollar of tools, risk of error... This would not naturally lead to exact equivalent productivity across all platforms, and forcing it to would necessarily reduce output--dramatically if pursued with real zeal.
Just to correct one
)
Just to correct one misunderstanding.
The speed difference between Linux app versions and Windows app versions is only to a lesser degree a question of SSE2 support. As you can see from the diagrams posted here, the SSE versions of Win and Linux apps show a speed difference as well.
The major difference here is that the two versions (Win/linux)use different "generations" of the optimized assembler code.
The latest version was only ported to "gcc Syntax" (shortly before there was a "code freeze" on the apps to prepare for S5R4). The plan is to use a gcc variant for Windows apps as well as soon as possible, allowing to use the same source as for Linux and OSX-intel. Any more effort put into the MS Visual Studio specific code will be more or less wasted as it is (hopefully) a dead end to be sealed off soon.
CU
Bikeman
RE: RE: The difference
)
Don't disagree with anything you have said, but it has been noted that 'nix version of S5R3 power apps and S5R4 are more efficient than the equivalent win versions. And it has also been noted that the 'nix ver is SSE2 and the win ver SSE.
I wouldn't know as a h/ware engineer which is the best compiler or if there is much difference between compilers, except from what is said on Seti and at work were both groups say, at the moment, the Intel compiler is best, even for AMD cpu's.
edit] even as I typed Bikeman had provided most of the answers. Thanks.
RE: Just to correct one
)
Correct me if I am wrong then. Hopefully SOONER rather than later the windows client will use the gcc variant and SSE2 and while it may not be completely on parity to linux code it should close the gap. Whatever that gap is will be the best that can be done to put both platforms on as nearly equal footing as possible. Hopefully it will close the gap enough that it's within a tolerance range that those using windows won't feel like they are being screwed over.
At that point how einstein relates to other projects could be judged. In my mind of equality of credit accross projects would go something like this..
einstein@home = 2 units @12 hrs each for total credit in 24 hours is 300
seti@home = 6 units @4 hrs each for a total credit of 300
CPDN = 1 trickle at 24 hours for a total credit of 300.
That is just an example. The number of units and credit per unit as well are just an example and may or may not even come close to what each project does. My point is that regardless how many units you are able to process in a 24 hour period and the value placed on each would equal the same amount at a 24 hour period. This is assuming that the computers using this method are exactly the same regardless of what OS they are using. I am not stupid to the point that if I run a single core AMD @ say 2.4MHZ and joe 6 pack is using the top of the line Intel quad that he is going to process more units than I do and receive more credit. If I wish to compete with Joe 6 pack then I should go and get a top of the line Intel quad. And If I want to blow him away I might go get 5 or 6 quads.
I need to think more on the cross project parity before finishing this post. Will do that later after I have had my coffee and my brain gets unfoggy.
RE: Just to correct one
)
Hopefully this will cause the apps performance to fall in line with each other. I'm willing to even be pursuaded to think 10% variance is "ok", but I'd rather see it come down to within 5%.
Brian
RE: If on any project
)
I don't even ask for it to be "the same". I'm even willing to say "close enough". If my system processes taks in 20,000 seconds, while the Linux side (if I had one) were to process in 19,000 seconds (95% of the time for the Windows environment), then I'm ok with that. If, on the other hand, it is shown that the Linux side takes only 16,000 seconds (75%), that's when I start saying that things aren't quite right...and would start thinking about looking for a project that performed better for my system.
Cosmology is a utter mess. It is fixed credit per task. All tasks get 70 credits, no matter what kind of system they are, what BOINC version is used, nor the amount claimed. The Project Scientist essentially stated today that they had been offering more because there might be problems along the way that would cause people to get no credit. Prior to the past month, that situation had not happened. People from the "there must be 'parity' between projects" camp used the fact that there hadn't been a major issue as a virtual club to beat on the project for granting "too much". Now there are some instances where MANY users may have processed hundreds, even thousands, of tasks not even "for the science", but essentially "for the bit bucket", as they got zero credit for the work and Ben, the Project Scientist, has indicated that the afore "over-generous" awards will offset the gooseggs...
...and this is why any "cross-project parity" scheme based on benchmarks is flawed. All that taking a huge sample is attempting to do is to mask the underlying problem with the metric...
Nothing I say really matters. It will be done. Perhaps once the dust settles, maybe someone will look more towards a current-based solution rather than relying on a design from the past that doesn't appear to have been sound...
I started running Einstein
)
I started running Einstein S5R4 on a WinXP virtual machine, processor is Intel E2140 at 2.8GHz, should have a result or 2 tomorrow. So far it doesnt seem to be as much as 10% slower than Linux SSE2 but its very different frequency and the sequence numbers are not so close. How important are sequence numbers for S5R4 runtimes?
Silvers, what VM did you use that had significant overhead? Im running this test now on VMWare WS 6.03, overhead is so small it can be disregarded i think.
Team Philippines
RE: I started running
)
6.02...with an Ubuntu 7.04 and 7.10 guest. Paravirtualization support was at experimental stage, and the experiment failed for me. If I enabled paravirtualization, which was supposed to speed things up, making it closer to actually running native, the VM would be about 4-6 times slower than without paravirtualization...
As for the frequency / sequence numbers, unknown as yet...
RE: RE: How important
)
How much do sequence numbers matter? About this much:
:-)
Seriously , this is a chart mapping runtime for a single sky-point (minus initialization time) on z-axis across the sky (declination and right ascension on x- and y- axis).
This was performed on a Core Duo Macintosh (should be comparable to Linux SSE2 code).
Absolute minimum runtime is 46 seconds,
absolute maximum is at 71 seconds,
But this is only an upper limit for runtime variation because in a WU, there will be several hundred skypoints and they cannot all be at the absolute minimum or absolute maximum.
I'd guesstimate that the real-life observed runtime variation in the frequency range near 140 Hz for complete workunits should be more like
(maximum runtime) ~ 1.4 x (minimum runtime)
Under the assumption that all WUs contain the same number of skypoints (as they did approximately in S5R4, no idea whether this still holds in S5R4 tho).
CU
Bikeman
RE: Under the assumption
)
I forgot to look at the units completed to see if they all had the same number of sky points or not. But the same system is claiming a variety of figures that coralate to time to process. The results can be seen HERE
Also, Brian I hope your dad's surgery went smoothly and successfully and that he has a speedy recovery
[edit] I just checked the skypoints and all of them have a different number of skypoints. Looks like a variety in the 700's.