If you are curious, you might install a VM and then install Mint on it. You can compare the performance of the 32-bit windows binary with the 64-bit Linux version. The last time I tried this, the VM was about 10% faster.

Thanks. I know it is hard to measure on Rosetta, which is why I asked.

---

While we are on the subject, I am presently on Win7 64-bit. But I could go to Linux Mint 18 when it comes out. Is there an advantage?

8-} hit POST instead of PREVIEW ...


If you are curious, you might install a VM and then install Mint on it. You can compare the performance of the 32-bit windows binary with the 64-bit Linux version. The last time I tried this, the VM was about 10% faster.

Why isn't there a 64-bit Windows version again?

---

While we are on the subject, I am presently on Win7 64-bit. But I could go to Linux Mint 18 when it comes out. Is there an advantage?

8-} hit POST instead of PREVIEW ...


If you are curious, you might install a VM and then install Mint on it. You can compare the performance of the 32-bit windows binary with the 64-bit Linux version. The last time I tried this, the VM was about 10% faster.

Why isn't there a 64-bit Windows version again?

I think 64-bit support was added to Visual Studio 2005. Windows 32-bit was all Rosetta could build before 2005.

Rosetta would still have to build a 32-bit Windows version for all the 32-bit systems running Rosetta and I suspect that early 64-bit Windows versions were not faster, so why bother. That "2005 finding" probably still circulates in developer circles today.


The much more interesting question is:
"How do you tell if one Rosetta binary "A" is faster or slower than another Rosetta binary "B"?"


That is a VERY tough problem to solve and past decisions have been wrong.
I still think that a 64-bit binary should be faster than a 32-bit version, but my empirical results have not shown that for Rosetta.

While we are on the subject, I am presently on Win7 64-bit. But I could go to Linux Mint 18 when it comes out. Is there an advantage?

8-} hit POST instead of PREVIEW ...


If you are curious, you might install a VM and then install Mint on it. You can compare the performance of the 32-bit windows binary with the 64-bit Linux version. The last time I tried this, the VM was about 10% faster.

Why isn't there a 64-bit Windows version again?

I think 64-bit support was added to Visual Studio 2005. Windows 32-bit was all Rosetta could build before 2005.

Rosetta would still have to build a 32-bit Windows version for all the 32-bit systems running Rosetta and I suspect that early 64-bit Windows versions were not faster, so why bother. That "2005 finding" probably still circulates in developer circles today.


The much more interesting question is:
"How do you tell if one Rosetta binary "A" is faster or slower than another Rosetta binary "B"?"


That is a VERY tough problem to solve and past decisions have been wrong.
I still think that a 64-bit binary should be faster than a 32-bit version, but my empirical results have not shown that for Rosetta.

Is it possible to get a "test" WU (or bunch of them) that have a certain limit to the amount of models it'll produce and a fixed seed number, so that everytime you execute it, it run thru the same energy pathway, creating the same models, etc. Then run this "test" WU thru different binaries... and compare.

---

Yes rjs5, I was going to make the same suggestion as Chilean. Creating a benchmark WU for various types, and running each for a given number of models in a given environment and comparing CPU and wall-clock time would seem to be the only means of pinning down performance. Have you been able to create such WUs that you can reuse time and again? I should think you could do so just by capturing the downloads. And DK could help you get a complete set of all of the various types. Remind him that BOINC server has means of assigning tasks to specific hosts (although, come to think of it, that may require settings they would not be using, perhaps they could send to you via Ralph).

---

Rosetta Moderator: Mod.Sense

Yes rjs5, I was going to make the same suggestion as Chilean. Creating a benchmark WU for various types, and running each for a given number of models in a given environment and comparing CPU and wall-clock time would seem to be the only means of pinning down performance. Have you been able to create such WUs that you can reuse time and again? I should think you could do so just by capturing the downloads. And DK could help you get a complete set of all of the various types. Remind him that BOINC server has means of assigning tasks to specific hosts (although, come to think of it, that may require settings they would not be using, perhaps they could send to you via Ralph).

I asked David for just that when I started my performance work.

He provided me two workloads. I like the jobs to run long enough to spend lots of time in the compute sections so the measurements are representative of the job. It took a couple of emails to make my "fixed amount of work" request clear.

Rosetta is a "fixed time" project. You tell Rosetta how long you want each job to take and the job terminates when the time is reached OR the task reaches completion. This makes it virtually IMPOSSIBLE for the Rosetta volunteer to really tell the difference between machines.

I still haven't been able to figure out what is a "good" or "bad" Rosetta job result. 8-) I think the "fixed time" model is just wrong ... just my opinion as a performance engineer. I would prefer the jobs be issued without the timer .... as long as they finish. It would not take long to figure out the Rosetta pf* jobs are long and the rb* jobs shorter.


That said, if anyone has a Rosetta workload that is typical of their work AND can be configured to run about 1 hour, I would be happy to add it to my performance analysis work. Just message me and we can figure out how to transfer the files.

Yes, you'd also either have to run a fixed number of models, or double check how many models your benchmark ran (I'd think DK has ways to do that too). The current settings were setup to help users control when their machines were running, not as a performance benchmark. Ultimately, a user compares machines by granted credit, and RAC. But those are relative to BOINC's benchmarks and to other user's results. So, yes, a moving target so far as trying to measure performance traits of one run to another.

---

Rosetta Moderator: Mod.Sense

I like the jobs to run long enough to spend lots of time in the compute sections so the measurements are representative of the job. It took a couple of emails to make my "fixed amount of work" request clear.

Rosetta is a "fixed time" project. You tell Rosetta how long you want each job to take and the job terminates when the time is reached OR the task reaches completion. This makes it virtually IMPOSSIBLE for the Rosetta volunteer to really tell the difference between machines.

I don't think they'll make big changes to rosetta infrastructure now, with the beginning of CASP12.

---

That said, if anyone has a Rosetta workload that is typical of their work AND can be configured to run about 1 hour, I would be happy to add it to my performance analysis work. Just message me and we can figure out how to transfer the files.

I like testing new sw. What do you need? A VM with linux?

---

That said, if anyone has a Rosetta workload that is typical of their work AND can be configured to run about 1 hour, I would be happy to add it to my performance analysis work. Just message me and we can figure out how to transfer the files.

I like testing new sw. What do you need? A VM with linux?

thanks much!
I was soliciting workloads from developers/researchers too. 8-)

When isolating performance problems, you start with the program to optimize. That program will expose bottlenecks in the code path but not in areas of Rosetta that are not executed.

If a Rosetta developer or user supplies me with his sample workload, then the bottlenecks affecting his work will be exposed and possibly optimized. He gets results faster.

Yes, I should think you need a task for each of the various protocols. Ideally a task that is created to terminate after a fixed number of models are completed (or least ends before the runtime preference). I'm not certain how many protocols there are.

---

Rosetta Moderator: Mod.Sense

... this may be due to some backed-up submissions, but it's still cool to see... compute power clocking in at 407 TeraFLOP/S today! Almost halfway to a PetaFLOP..

... this may be due to some backed-up submissions, but it's still cool to see... compute power clocking in at 407 TeraFLOP/S today! Almost halfway to a PetaFLOP..

I don't know if it is a new Charity Engine campaign or these are optimizations...

---

Optimizations, as they are made, do not really reflect in the project TFlops estimate. This because in the end, the estimate is based on the BOINC benchmark and number of hours running. Not trying to be negative about optimization. Just pointing out that you will not see it in this way. Granted credit is based on the number of models completed, and yes, with optimizations, you'll tend to complete more models per unit time... but so will everyone else. So you're credit and therefore TFlops impact should only prove that the BOINC benchmark differs from a Rosetta workload.

Yes, there have been over 1000 new users per day for a couple of weeks now, and over 2000 today. The only time I've seen numbers like that was when Charity Engine was actively serving Rosetta tasks. This past week has also been some of the only times I've seen the server status page show over a million tasks in progress. I saw 1.6m one day. Then an hour later it was down to 300,000. Another hour later, was probably over a million again. That's a LOT of work moving around.

---

Rosetta Moderator: Mod.Sense

Check that, over 3,500 new hosts today!

---

Rosetta Moderator: Mod.Sense

Yes, there have been over 1000 new users per day for a couple of weeks now, and over 2000 today. The only time I've seen numbers like that was when Charity Engine was actively serving Rosetta tasks. This past week has also been some of the only times I've seen the server status page show over a million tasks in progress. I saw 1.6m one day. Then an hour later it was down to 300,000. Another hour later, was probably over a million again. That's a LOT of work moving around.

:-O

Ready for Casp!!! :-)

---

Optimizations, as they are made, do not really reflect in the project TFlops estimate. This because in the end, the estimate is based on the BOINC benchmark and number of hours running. Not trying to be negative about optimization. Just pointing out that you will not see it in this way. Granted credit is based on the number of models completed, and yes, with optimizations, you'll tend to complete more models per unit time... but so will everyone else. So you're credit and therefore TFlops impact should only prove that the BOINC benchmark differs from a Rosetta workload.

Yes, there have been over 1000 new users per day for a couple of weeks now, and over 2000 today. The only time I've seen numbers like that was when Charity Engine was actively serving Rosetta tasks. This past week has also been some of the only times I've seen the server status page show over a million tasks in progress. I saw 1.6m one day. Then an hour later it was down to 300,000. Another hour later, was probably over a million again. That's a LOT of work moving around.

So, the only way to "see" whatever speed-up comes from new application optimizations is our RAC?

---

No, host RAC suffers the same fate as the project TFlops (which is essentially the aggregation of all of the host RACs). This is part of why rjs5 has been saying it is difficult to estimate how a given improvement might actually effect overall efficiency.

It's sorta like a factory that makes candy bars. And the same number of bars come off the line each day, only now several varieties are slightly larger than they used to be. But that's really hard to tell because on different days, the production consists of differing ratios of any of the ten kinds of candy bars the factory makes.

Optimizations will be a great thing, and will certainly help the science behind the project, but you won't see a blip on a chart. In fact, part of what rjs5 has been asking for is a computational run, that can be repeated, to MAKE a chart, so there is something to compare to after making some changes. But even then all you can say is that one sample set, for a specific type of candy bar, is now showing an x% increase in average size. But it is possible that the change has adverse side effects on the other candy bar types, or on system environments that differ from that used for the measurements. The answer to any performance question is always "it depends".

---

Rosetta Moderator: Mod.Sense

400Tflops!

Server Status as of 24 Apr 2016 2:38:57 UTC
[ Scheduler running ]
Total queued jobs: 2,347,476
In progress: 692,514
Successes last 24h: 372,980
Users (last day ) : 807,306 (+2475)
Hosts (last day ) : 1,721,021 (+2585)
Credits last 24h : 41,980,059
Total credits : 42,338,375,367
TeraFLOPS estimate: 419.801

if this results partly the effort from ris thanks ! :D

400Tflops!
if this results partly the effort from ris thanks ! :D

Now over 450!!

---