The protocol code for the majority of jobs (and all the test jobs) hasn't changed. BUT, for this cyclic peptide error, the developer did not check his code into the main source repo as he should have long ago. In an effort to save time a while ago, we incorporated his code before he checked it in under the understanding he would check it in soon after, which he didn't. But on a positive note, he is busy trying to make and characterize his cyclic peptide designs now.

For the 3.62 update, I reverted the windows application back to the 32bit non-sse build, and also reverted the linux application to the 32bit build (for the 64bit apps). There was a significant fraction of errors which prompted the change. We will do another update soon related to the "Option matching -relax:cyclic_peptide not found in command line top-level context" errors.

What is the gain in going native 64-bit? I would've thought that going SSE2 would bring a higher gain than 64-bit (I've always associated the 64-bit to better memory addressing, rather than increased computation speed).

I don't understand.
The ralph/rosetta 64 bit app we are actually using is not "native"?

I did turn on SSE for the windows build.

Just a curiosity: which version of SSE for win? 2? 3? 4.1???

I think it's only SSE "1" so far. No errors except for a few WUs that failed immediately, but it doesn't appear to be a SSE-related problem.

My WUs with SSE

SSE was introduced in 1999 with the Pentium-3 CPU and SSE2 was introduced in 2001 with the Pentium-4 CPU and only extended SSE. If something works under SSE, then it will work under SSE2 UNLESS it is a Pentium-3-era CPU.

The project will get more work done by sacrificing the Pentium-3 cycles (making SSE2 the minimum) and optimizing for SSE2+.

Once you get to SSE2, you will only get minor improvements, probably just a couple %, by going to the trouble of pushing the SSE/AVX envelop.

Since R@H is compiling an running in SCALAR mode which crunches only 1 64-bit value in the 128-bit dual 64-bit XMM registers, there is much more to gain by closely examining the source code and understanding what is preventing the compilers from VECTORIZING the code. If you can use BOTH 64-bit fields in the XMM registers, you get 2x performance increase. You crunch two, 4, 8, ... floating point values in the same time as 1.

This is also the reason that there is no GPU version and can NEVER be a GPU version until this is fixed .... IF the source can be changed to vectorized.


Starting from a generic, crappy 32-bit i386 version, .....
you get 80% of the scalar performance by just generating a 64-bit version.
you get the other 20% of scalar performance by messing with compiler options .... but at a high portability cost.

The next barrier after a 64-bit version should be SSE2.
The next barrier after 64-bit, SSE2 is VECTOR .... NOT .... SSE3, SSE4, AVX, ...

I did turn on SSE for the windows build.

Just a curiosity: which version of SSE for win? 2? 3? 4.1???

I just updated the minirosetta_beta app. I did not include SSE linux builds since it will require more testing. I did turn on SSE for the windows build. The latest linux SSE3 test was causing a significant amount of failures.

We don't have much time/resources to test these optimizations and it would be great of any of you would like to volunteer to help. As stated before, we can provide the source, build instructions, and tests. If you are interested please contact me directly at dekim AT u.washington.edu

<core_client_version>7.6.6</core_client_version>
<![CDATA[
<message>
(unknown error) - exit code -1 (0xffffffff)
</message>
<stderr_txt>
[2015- 8-28 16:50:38:] :: BOINC:: Initializing ... ok.
[2015- 8-28 16:50:38:] :: BOINC :: boinc_init()
BOINC:: Setting up shared resources ... ok.
BOINC:: Setting up semaphores ... ok.
BOINC:: Updating status ... ok.
BOINC:: Registering timer callback... ok.
BOINC:: Worker initialized successfully. 
command: projects/ralph.bakerlab.org/minirosetta_beta_3.61_windows_x86_64.exe -run:protocol relax -ex1 -ex2aro -in:file:boinc_wu_zip FFF_939e816d73e5d4a3e6faf001ad588d96_hh5_Wed_Jun__3_15_28_03_PDT_2015.zip -in:file:s 00001.pdb -in:file:native 00001.pdb -in:file:fullatom -relax::default_repeats 15 -out:file:silent default.out -out:file:silent_struct_type score -silent_gz -relax:cyclic_peptide -mute all -nstruct 10000 -cpu_run_time 3600 -checkpoint_interval 120 -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -run::rng mt19937 -constant_seed -jran 3184233
Registering options.. 
Registered extra options.
Initializing broker options ...
Registered extra options.
Initializing core...
Initializing options.... ok 
Options::initialize()
Options::adding_options()
Options::initialize() Check specs.
Options::initialize()  End reached
ERROR: Option matching -relax:cyclic_peptide not found in command line top-level context

</stderr_txt>
]]>