Rosetta v4.08 x86_64-pc-linux-gnu or Rosetta v4.07 i686-pc-linux-gnu

Message boards : Number crunching : Rosetta v4.08 x86_64-pc-linux-gnu or Rosetta v4.07 i686-pc-linux-gnu

To post messages, you must log in.

AuthorMessage
rjs5

Send message
Joined: 22 Nov 10
Posts: 249
Credit: 7,943,804
RAC: 7,640
Message 90361 - Posted: 16 Feb 2019, 6:44:28 UTC

Minirosetta and Rosetta v4.07 i686-pc-linux-gnu are 32-bit binaries.
I did an objdump on the binaries an the only difference is the "i686" and "x86_64" strings. One binary is 2-bytes larger.
Rosetta v4.08 x86_64-pc-linux-gnu is a 64-bit binary.

I was downloading Minirosetta and Rosetta 4.08 (64-bit) WU and then my machine stopped downloading the 4.08 binaries and started downloading Rosetta 4.07 (32-bit) WU.

Does the researcher specify Rosetta 4.07 or 4.08 ... or does the project code run some detection test on my machine to determine what is supported?
ID: 90361 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Link
Avatar

Send message
Joined: 4 May 07
Posts: 292
Credit: 358,905
RAC: 113
Message 90363 - Posted: 16 Feb 2019, 9:27:54 UTC - in response to Message 90361.  

Does the researcher specify Rosetta 4.07 or 4.08 ... or does the project code run some detection test on my machine to determine what is supported?

The server will send you both to see which one performs better. After 10 valid WUs for each application, most WUs will be assigned to the faster application and only very few to the slower one (just to check it is still slow).
.
ID: 90363 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
rjs5

Send message
Joined: 22 Nov 10
Posts: 249
Credit: 7,943,804
RAC: 7,640
Message 90365 - Posted: 16 Feb 2019, 15:39:50 UTC - in response to Message 90363.  

Does the researcher specify Rosetta 4.07 or 4.08 ... or does the project code run some detection test on my machine to determine what is supported?

The server will send you both to see which one performs better. After 10 valid WUs for each application, most WUs will be assigned to the faster application and only very few to the slower one (just to check it is still slow).


Thanks
Do you know how I get it to execute the benchmark process and chose again OR explicitly override it for 64-bits?
It made the wrong choice because I was messing with the new machine and changing settings that affected the runs.
ID: 90365 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Link
Avatar

Send message
Joined: 4 May 07
Posts: 292
Credit: 358,905
RAC: 113
Message 90366 - Posted: 16 Feb 2019, 16:23:15 UTC - in response to Message 90365.  
Last modified: 16 Feb 2019, 16:24:53 UTC

Well, you can't execute the benchmark since that are all your completed WUs. Whatever you did, will sort itself out with time.
You can force 64-bit only with <no_alt_platform> in cc_config.xml, but I would wait with that and see if the 64-bit application is really faster than the 32-bit, that's not always the case. Just watch the GFLOPS values. If it really is faster, the server will send most WUs to that application anyway, so no really need to do anything.
.
ID: 90366 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
rjs5

Send message
Joined: 22 Nov 10
Posts: 249
Credit: 7,943,804
RAC: 7,640
Message 90367 - Posted: 16 Feb 2019, 17:59:00 UTC - in response to Message 90366.  

Well, you can't execute the benchmark since that are all your completed WUs. Whatever you did, will sort itself out with time.
You can force 64-bit only with <no_alt_platform> in cc_config.xml, but I would wait with that and see if the 64-bit application is really faster than the 32-bit, that's not always the case. Just watch the GFLOPS values. If it really is faster, the server will send most WUs to that application anyway, so no really need to do anything.


I was surprised to see that Rosetta 4.08 is the only 64-bit binary for Linux. Both copies of Minirosetta are 32-bit.
The 32-bit binaries end up with a smaller code footprint and pass parameters on the stack. The parameter list quickly spills to the stack, but they will be in the L1 cache which has a 1-cycle access time.

A 64-bt version will always be faster if compiled properly, unless you aggressively inline functions. The larger code footprint is causing front-end icache miss stalls.
I want to see how hard it is to modify the source to redefine their 3-dimensional "vector" object into a 4-dimensional vector so they can use packed SSE or AVX. Right now all Rosetta computation uses scalar operations.

thanks again.
ID: 90367 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Profile [VENETO] boboviz

Send message
Joined: 1 Dec 05
Posts: 848
Credit: 3,057,981
RAC: 1,735
Message 90384 - Posted: 18 Feb 2019, 8:12:43 UTC - in response to Message 90367.  
Last modified: 18 Feb 2019, 8:13:16 UTC

I was surprised to see that Rosetta 4.08 is the only 64-bit binary for Linux. Both copies of Minirosetta are 32-bit.

I noted this (thanks to you) almost 2 years ago. Nothing has changed.
Today 98% of Windows runs 64 bit version.

A 64-bt version will always be faster if compiled properly, unless you aggressively inline functions. The larger code footprint is causing front-end icache miss stalls.
I want to see how hard it is to modify the source to redefine their 3-dimensional "vector" object into a 4-dimensional vector so they can use packed SSE or AVX. Right now all Rosetta computation uses scalar operations.

You are doing what, in Italy, we call "opera meritoria" (something like "meritorious work").
But sometimes, here in Rosetta@Home, seems to be like Don Quixote of la Mancha, who "tilting at windmills".
ID: 90384 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
rjs5

Send message
Joined: 22 Nov 10
Posts: 249
Credit: 7,943,804
RAC: 7,640
Message 90389 - Posted: 18 Feb 2019, 21:39:33 UTC - in response to Message 90384.  

I was surprised to see that Rosetta 4.08 is the only 64-bit binary for Linux. Both copies of Minirosetta are 32-bit.

I noted this (thanks to you) almost 2 years ago. Nothing has changed.
Today 98% of Windows runs 64 bit version.

A 64-bt version will always be faster if compiled properly, unless you aggressively inline functions. The larger code footprint is causing front-end icache miss stalls.
I want to see how hard it is to modify the source to redefine their 3-dimensional "vector" object into a 4-dimensional vector so they can use packed SSE or AVX. Right now all Rosetta computation uses scalar operations.

You are doing what, in Italy, we call "opera meritoria" (something like "meritorious work").
But sometimes, here in Rosetta@Home, seems to be like Don Quixote of la Mancha, who "tilting at windmills".




minirosetta_3.78_x86_64-pc-linux-gnu is a 32-bit binary even though the name implies it is 64-bit. Seems curious that they would build and deploy TWO binaries with only different names. The only difference in the 2 binaries is a different text name in the binary. I wonder if someone goofed on the compile options.

It is beginning to appear that BOINC is becoming too successful and the projects are having a hard time utilizing the compute power. The server infrastructure is creaking under the pressure.
ID: 90389 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Jim1348

Send message
Joined: 19 Jan 06
Posts: 272
Credit: 6,742,838
RAC: 22,620
Message 90390 - Posted: 18 Feb 2019, 22:00:30 UTC - in response to Message 90389.  

It is beginning to appear that BOINC is becoming too successful and the projects are having a hard time utilizing the compute power. The server infrastructure is creaking under the pressure.

That is my observation too, especially with GPU projects. But any number of CPU projects are having a hard time getting the work out the door, or returned again as the case may be.
That may be one reason why the Rosetta people are not chomping at the bit for code optimizations; they can barely handle what they have already.

It is causing me to think twice about my own upgrade plans. The Ryzen 3000 looks very nice, but maybe I will wait for the 4000; similarly when upgrading my GPUs.
ID: 90390 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Profile [VENETO] boboviz

Send message
Joined: 1 Dec 05
Posts: 848
Credit: 3,057,981
RAC: 1,735
Message 90391 - Posted: 19 Feb 2019, 9:57:20 UTC - in response to Message 90390.  

That may be one reason why the Rosetta people are not chomping at the bit for code optimizations; they can barely handle what they have already.

I don't know if their infrastructure is stressed or not, but it seems me strange.
They changed the servers less than 2y ago.
ID: 90391 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Jim1348

Send message
Joined: 19 Jan 06
Posts: 272
Credit: 6,742,838
RAC: 22,620
Message 90392 - Posted: 19 Feb 2019, 11:42:11 UTC - in response to Message 90391.  

I don't know if their infrastructure is stressed or not, but it seems me strange.
They changed the servers less than 2y ago.

Their servers may be OK, but there is more to it than that. They need the work generators and more importantly the scientists. There may be times that they just run out of work to do. There is nothing wrong with that. They don't exist to provide us with work; we are here to help them. But it is just another illustration that there may be more crunchers than needed at any given moment.

We don't really know where the limitations are by the way. They don't bother to tell us. So one speculation is as good as another.
ID: 90392 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Profile [VENETO] boboviz

Send message
Joined: 1 Dec 05
Posts: 848
Credit: 3,057,981
RAC: 1,735
Message 90393 - Posted: 19 Feb 2019, 12:50:52 UTC - in response to Message 90392.  
Last modified: 19 Feb 2019, 12:52:30 UTC

We don't really know where the limitations are by the way. They don't bother to tell us. So one speculation is as good as another.


I agree with you. Maybe it's a problem of work generation or others.

And I don't like the lack of communication of this project

Returning to the argument of thread: why not create 64 native app? Seems, reading r5js, this is not SO difficult.
ID: 90393 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
rjs5

Send message
Joined: 22 Nov 10
Posts: 249
Credit: 7,943,804
RAC: 7,640
Message 90395 - Posted: 19 Feb 2019, 16:06:49 UTC - in response to Message 90393.  

I frequently find myself thinking ... "why did the project devote time to that instead of ...?"
Maybe it makes sense if you have a better view of what they are doing. Maybe not. 8-)

LACK OF COMMUNICATION ...
It seems like all their moderators are closely related to the project. It should be fairly easy to recruit some volunteer MODERATORS or people who agree to handle many of the routine comments on the boards. Some of these volunteers could even generate some extra financial support for the project. Many US companies have employee benefits that match cash donations to schools and charities (like U of Washington). Many of these companies will also match volunteer time with cash called a "Matching Volunteer Grant". I retired from a company that extends these benefits to retirees. In theory, I could submit the number of hours that I contribute to Rosetta for a "matching gift". My company matches volunteer time at a rate of $10/hour. A $10 to $20 hourly match rate is common. Apple matches $50 per volunteer hour currently.
https://doublethedonation.com/matching-gifts/apple-inc


APPLICATION BINARIES ...
It seems to me, the biggest problem is how the Rosetta Project "spends" its limited human resources. It may be a problem with matching their "people skill sets" with the "development wish list" and with the available time of those people.

Their efforts to "hyper optimize" the binary by pulling functions "inline" is based on running 1 copy on a large, idle machine. The result is "sub optimized" results when running 2 or more WU on a machine that strain a critical resource .. like the instruction cache. I am running 36 copies on a machine and the negative impact of inlining functions is pretty obvious.

Climateprediction@home has WU that run for hundreds of hours, but they "checkpoint" and trickle up the results 12 times during the run. You get partial credit even if the WU aborts deep into execution. That seems like an execution model Rosetta could consider. Rosetta chops up a long running WU and broadcasts the pieces to many machines. If they ran multiple pieces of that one WU on the same machine in parallel, you would only need 1 database file to share and the overall size of the execution footprint would be smaller.

Etc, etc, ...



We don't really know where the limitations are by the way. They don't bother to tell us. So one speculation is as good as another.


I agree with you. Maybe it's a problem of work generation or others.

And I don't like the lack of communication of this project

Returning to the argument of thread: why not create 64 native app? Seems, reading r5js, this is not SO difficult.
ID: 90395 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Profile Chilean
Avatar

Send message
Joined: 16 Oct 05
Posts: 693
Credit: 22,044,417
RAC: 1,407
Message 90396 - Posted: 19 Feb 2019, 16:41:55 UTC - in response to Message 90367.  

Well, you can't execute the benchmark since that are all your completed WUs. Whatever you did, will sort itself out with time.
You can force 64-bit only with <no_alt_platform> in cc_config.xml, but I would wait with that and see if the 64-bit application is really faster than the 32-bit, that's not always the case. Just watch the GFLOPS values. If it really is faster, the server will send most WUs to that application anyway, so no really need to do anything.


I was surprised to see that Rosetta 4.08 is the only 64-bit binary for Linux. Both copies of Minirosetta are 32-bit.
The 32-bit binaries end up with a smaller code footprint and pass parameters on the stack. The parameter list quickly spills to the stack, but they will be in the L1 cache which has a 1-cycle access time.

A 64-bt version will always be faster if compiled properly, unless you aggressively inline functions. The larger code footprint is causing front-end icache miss stalls.
I want to see how hard it is to modify the source to redefine their 3-dimensional "vector" object into a 4-dimensional vector so they can use packed SSE or AVX. Right now all Rosetta computation uses scalar operations.

thanks again.


I have nothing to add, but I started reading your post and when it started going over my head I went "yo this dude knows his stuff...", then I saw the username and said "of course, it's rjs5" lol
ID: 90396 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Profile dcdc

Send message
Joined: 3 Nov 05
Posts: 1615
Credit: 57,525,735
RAC: 45,732
Message 90401 - Posted: 20 Feb 2019, 22:03:38 UTC

My guess is that the researchers are funded to work on specific research outcomes, rather than the infrastructure (in this case, BOINC) so BOINC/R@H falls between the gaps with no one with any allotted time to do work on the infrastructure or interact with the community etc.

If just really like to know what their ideal situation weeks be- less computer power, more power, more RAM, more funding for the platform, less computer power most of the tube but with occasional peaks?

Also, like most people, I don't generally comment on the science updates posted by the lab members on here, I really like reading them to get a feel for what's being run on my machines. From their side it probably looks like no one is interested, but for me that's definitely not the case.
ID: 90401 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Profile dcdc

Send message
Joined: 3 Nov 05
Posts: 1615
Credit: 57,525,735
RAC: 45,732
Message 90402 - Posted: 20 Feb 2019, 22:09:10 UTC - in response to Message 90395.  
Last modified: 20 Feb 2019, 22:10:11 UTC

There's only mod.Sense who is a volunteer and so isn't paid by the bakerlab, bit has done an incredible job of keeping this place in order for many years, with waaay more patience dealing with all types of people on the forum than I would ever have had.

David Kim also post occasionally, but less so recently and usually only about tech stuff like hardware issues.
ID: 90402 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
rjs5

Send message
Joined: 22 Nov 10
Posts: 249
Credit: 7,943,804
RAC: 7,640
Message 90404 - Posted: 21 Feb 2019, 16:22:29 UTC - in response to Message 90402.  

There's only mod.Sense who is a volunteer and so isn't paid by the bakerlab, bit has done an incredible job of keeping this place in order for many years, with waaay more patience dealing with all types of people on the forum than I would ever have had.

David Kim also post occasionally, but less so recently and usually only about tech stuff like hardware issues.


Agree about mod.Sense and David. I have worked with David off line several times and he has been quite knowledgeable and helpful. I have usually talked about performance issues, but the last time was to give him a fix for the Ubuntu 18.04 glibc problem that caused WU to abort. David cleaned up my fix and built the Linux Rosetta 4.08 64-bit version.

The Rosetta developers have been repeatedly skeptical about my performance improvement estimates. That is not a surprise. Developers are sensitive about their work and frequently think they know more than they do. I had to explain to many compiler developers why their "really neat improvement" was not going to make the impact they forecast. The application developers are farther away from performance problems than the compiler developers.

I thought I would look at Rosetta code and see what they have done during the last two years and maybe run some experiments.

... Chilean ... you know more than you think. As with most topics, terminology is the barrier. Start another thread if you have a question and I will see if I can answer.
ID: 90404 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote

Message boards : Number crunching : Rosetta v4.08 x86_64-pc-linux-gnu or Rosetta v4.07 i686-pc-linux-gnu



©2019 University of Washington
http://www.bakerlab.org