Over 6 years ago, i asked if it is possible to have a multi-thread R@H app, and Rocco said:

Multi-threading would be a headache to support for no practical gain. Protocols typically function by taking a single structure through a series of steps, which means there's choke points which would limit the speed increase you'd get from multithreading.

But, during these years we have a lot of improvements in multi-core cpu (like Intel I9, Ryzen, Threadripper, etc) and, new Rosetta code has this function:

Rosetta's core and database modules are now threadsafe, permitting development of multi-threaded protocol

Interesting!

---

Over 6 years ago, i asked if it is possible to have a multi-thread R@H app, and Rocco said:

Multi-threading would be a headache to support for no practical gain. Protocols typically function by taking a single structure through a series of steps, which means there's choke points which would limit the speed increase you'd get from multithreading.

But, during these years we have a lot of improvements in multi-core cpu (like Intel I9, Ryzen, Threadripper, etc) and, new Rosetta code has this function:

Rosetta's core and database modules are now threadsafe, permitting development of multi-threaded protocol

Interesting!

There are many things the developers say when they don't want to be bothered. 8-)

Simply redefining their 3-dimensional coordinate system would allow the compilers to use parallel register operations instead of scalar. For ALL machines they support, it means loading and operating 2-pairs of dimension coordinates instead of 3-scalar dimensions. There are 50% fewer loads (3 to 2). 50% fewer floating point operations (3 down to 2).

This also explains why I saw the dramatic increase in the amount of Rosetta 4.07 time in spin loops waiting on a resource. I spent 15 years as a SW Performance Engineer working on a LARGE application that used locks to protect data and locks can destroy performance if not handled properly. I expect a number of mistakes to be re-discovered by the Rosetta team.

There are many things the developers say when they don't want to be bothered. 8-)

We volunteers give our time and resource to this project, so we have the right to disturb the developers :-)

This also explains why I saw the dramatic increase in the amount of Rosetta 4.07 time in spin loops waiting on a resource.

:-(

I spent 15 years as a SW Performance Engineer working on a LARGE application that used locks to protect data and locks can destroy performance if not handled properly. I expect a number of mistakes to be re-discovered by the Rosetta team.

I think this is a great project. But i don't understand why not improve it...

---

There are many things the developers say when they don't want to be bothered. 8-)

We volunteers give our time and resource to this project, so we have the right to disturb the developers :-)

This also explains why I saw the dramatic increase in the amount of Rosetta 4.07 time in spin loops waiting on a resource.

:-(

I spent 15 years as a SW Performance Engineer working on a LARGE application that used locks to protect data and locks can destroy performance if not handled properly. I expect a number of mistakes to be re-discovered by the Rosetta team.

I think this is a great project. But i don't understand why not improve it...

One can estimate the client computer equipment power consumption and then make some conservative estimates of the wattage that would be saved if Rosetta improved its performance by 10%, 20%, ... One can then estimate the client utility costs and how much the same work would cost them with improved performance. These calculations also apply to the U of Washington utility bill.

One can estimate the client computer equipment power consumption and then make some conservative estimates of the wattage that would be saved if Rosetta improved its performance by 10%, 20%, ... One can then estimate the client utility costs and how much the same work would cost them with improved performance. These calculations also apply to the U of Washington utility bill.

I agree, but Rosetta is already cpu-intensive, so if they publish multithread/SSEx/Avx/whatsoever apps, i think it's not a problem.
And i want to decide how to use my cpu, even if it consumes more.

---

One can then estimate the client utility costs and how much the same work would cost them with improved performance. These calculations also apply to the U of Washington utility bill.

I don't think utility bill is a problem
11.3 milion dollars for IPD

---

No news from this side of development??
New cpu (intel and amd) are great in multithread....
And also c++ has new features about multithread/concurrency and C++ 20 concurrency

---