Personally now that a good model for what is going on is available, I hope Bernd, et al actaully fix the credits. Initially they said they couldn't because they weren't sure what was going on exactly. We now have a good model to describe the behavior and allow adjustments to be made.
Personally now that a good model for what is going on is available, I hope Bernd, et al actaully fix the credits. Initially they said they couldn't because they weren't sure what was going on exactly. We now have a good model to describe the behavior and allow adjustments to be made.
If we are talking about "fixing" credits, then if we really want to harp on cross-project parity, then there really needs to be intra-project parity before contemplating how to match up with another project... To get approximately equivalent credit per cpu second on Windows vs. Linux, one has to be running a "power users" application that equates to the current "official" Linux application (Windows 4.26 app vs. Linux 4.20 app). When you compare Linux 4.27 vs. Windows 4.26, the huge gap in performance comes into play again in favor of Linux.
So, if there is an urge to "fix" credits, then if one wanted to be "fair", then there'd need to be differing credits depending on the application platform. Doing that though would ruffle feathers and have the Linux/Mac folk complaining that someone using Windows is "getting more".
My vote: Don't "fix" credits until application differences have been minimized.
I vote for credit fix, but OS based credits would be a bad idea IMO, change credits every time theres a new app?
Differences in performance between OS could very well tip out in favor of Windows if we look at the average since S5R3 start. GNU/Linux was suffering from the 4.02 app for a long time, the performance disadvantage compared to Windows was so big at the time that Windows will have to be slower for a long time still to make up for it. At the time Linux 8 core systems was falling like rocks on the Top Computers list.
I vote for credit fix, but OS based credits would be a bad idea IMO, change credits every time theres a new app?
Differences in performance between OS could very well tip out in favor of Windows if we look at the average since S5R3 start. GNU/Linux was suffering from the 4.02 app for a long time, the performance disadvantage compared to Windows was so big at the time that Windows will have to be slower for a long time still to make up for it. At the time Linux 8 core systems was falling like rocks on the Top Computers list.
S5R2 had an AMD/Windows penalty built into it for the entire run. The only way to partially defeat that penalty was to use a hex editor and modify the binary so that it didn't have "AuthenticAMD" in the binary (AuthenticABC was generally the used "fix", but as long as it wasn't AuthenticAMD, it was fine).
Anyway, looking at things and trying to "right them" based on the past is the WRONG way to do things. Things should be right and only right. As an extreme example of something here in the United States, look at Affirmative Action or hiring quotas (now) as the attempt to "fix" the notion of slavery/discrimination. The only true way to actually fix the situation is to change the hearts and minds of people that every person is a person and that they should all be given the same respect.
Rigging things to benefit one particular group is not the right approach, be that rigging it for the majority or rigging it for the minority. This is why I said that the application differences should be minimized first. As it stands right now, 4.15 vs. 4.20 has 4.15 (Windows) at a 15-20% disadvantage. Sure, the disadvantage would still be there if everyone's credit was adjusted, but reducing the disparity should at least be an equivalent goal, if not a higher goal, particularly with all the noise from David Anderson as of late...
Personally now that a good
)
Personally now that a good model for what is going on is available, I hope Bernd, et al actaully fix the credits. Initially they said they couldn't because they weren't sure what was going on exactly. We now have a good model to describe the behavior and allow adjustments to be made.
RE: Personally now that a
)
If we are talking about "fixing" credits, then if we really want to harp on cross-project parity, then there really needs to be intra-project parity before contemplating how to match up with another project... To get approximately equivalent credit per cpu second on Windows vs. Linux, one has to be running a "power users" application that equates to the current "official" Linux application (Windows 4.26 app vs. Linux 4.20 app). When you compare Linux 4.27 vs. Windows 4.26, the huge gap in performance comes into play again in favor of Linux.
So, if there is an urge to "fix" credits, then if one wanted to be "fair", then there'd need to be differing credits depending on the application platform. Doing that though would ruffle feathers and have the Linux/Mac folk complaining that someone using Windows is "getting more".
My vote: Don't "fix" credits until application differences have been minimized.
I vote for credit fix, but OS
)
I vote for credit fix, but OS based credits would be a bad idea IMO, change credits every time theres a new app?
Differences in performance between OS could very well tip out in favor of Windows if we look at the average since S5R3 start. GNU/Linux was suffering from the 4.02 app for a long time, the performance disadvantage compared to Windows was so big at the time that Windows will have to be slower for a long time still to make up for it. At the time Linux 8 core systems was falling like rocks on the Top Computers list.
Team Philippines
RE: I vote for credit fix,
)
S5R2 had an AMD/Windows penalty built into it for the entire run. The only way to partially defeat that penalty was to use a hex editor and modify the binary so that it didn't have "AuthenticAMD" in the binary (AuthenticABC was generally the used "fix", but as long as it wasn't AuthenticAMD, it was fine).
Anyway, looking at things and trying to "right them" based on the past is the WRONG way to do things. Things should be right and only right. As an extreme example of something here in the United States, look at Affirmative Action or hiring quotas (now) as the attempt to "fix" the notion of slavery/discrimination. The only true way to actually fix the situation is to change the hearts and minds of people that every person is a person and that they should all be given the same respect.
Rigging things to benefit one particular group is not the right approach, be that rigging it for the majority or rigging it for the minority. This is why I said that the application differences should be minimized first. As it stands right now, 4.15 vs. 4.20 has 4.15 (Windows) at a 15-20% disadvantage. Sure, the disadvantage would still be there if everyone's credit was adjusted, but reducing the disparity should at least be an equivalent goal, if not a higher goal, particularly with all the noise from David Anderson as of late...
RE: Einstein@Home server
)
RE: Einstein@Home server
)
RE: RE: Einstein@Home
)
Yeah, it's pretty amazing. At the time of year when people normally shut down their computers, Einstein is hitting new Teraflops records.
RE: Einstein@Home server
)
RE: RE: Einstein@Home
)
Einstein@Home server status as of 7:24 PM UTC on Saturday, 26 July 2008
floating point speed 188.2 TFLOPS
;);)
Einstein@Home S5R3 WU
)
Einstein@Home S5R3 WU generation completed in 317 days.