As exciting as a 2-fold speedup for a sequence of 2 operations goes, this might be a good time to mention that it's often much more important to optimize the serial code first.

For example, if the computation amounts to just adding up pairwise produces of multiples of tau[i](t)*tau[j](t) then perhaps the coefficients could be abstracted away from the symbolic factors, and a purely floating-point scheme devised (which has the potential to be much faster).

What are you trying to accomplish (in words, please).  What do you mean to express by A1 = b where A1 is a 3x3 Matrix and b is a Vector?

@Cavemaann Your latest attachment had the expression f which simplified to -sinh(alpha*L)*sin(alpha*L) = 0 . Are you saying you disagree with roots of that occuring at alpha*L=n*Pi?

Or are you saying that you want some other kind of plot for f=0? And if so, then what kind of plot?

Your example works for me.

display3d_ac.mw

What is inside your custom initialization of Maple? What happens if you launch without it?

@Cavemaann Aren't the roots just multiples of Pi?

K4square_equal_K2square_ac.mw

@tomleslie This is perhaps interesting to someone generally concerned with low- vs high-level parallelization in Maple.

But I fear that it risks muddying the waters for the OP, since the addition of many numeric values, or other arithmetic calls, is not the primary concern. (AFAICT the member vv cooked up the addition of many sin calls just because it is a black box which he could easily make as expensive as wanted.) 

I suspect that there could also be non-negligible differences in comparison of such a variety of approaches according to whether the calculation is exact rational, software floating-point, or hardware floating-point.

The OP (as per usual, and unhelpfully) has not disclosed details of the actual computations performed by his function calls f(x1,x2,x3,...) and g(x1,x2,x3,...). So we cannot tell if they would be susceptible to improvement via low-level multi-threading. We also cannot tell if they are even thread-safe, or call anything which is thread-blocking (like an external, compiled, numeric integration function). In the worse cases, a lack of thread-safety could result in invalid results or even a crash.

I think that your reponse can remind us of an aspect that is sometimes overlooked: In Maple it is often the case that the performance of a serial calculation can be significantly improved, and often it is beneficial to focus on optimizing the serial calculation foremost, before trying to parallelize.

(Hence my suggestion above, to use the Grid package.)

@vv You may compare with Grid:-Seq.

You could also wrap the f(i) calls in evalhf and remove the evalf. Remember table of evalf might play some part.

Also possible is Threads:-Task model

nb. I suspect you deliberately use :-add instead of Threads:-Add because you want an expensive serial `f`. Makes sense.

General control of other worksheets (from within a given worksheet) is not possible.

There are limited tools for querying particular formulas from another Worksheet/Document (if the formula is attached to a GUI Equation Label). And there are limited tools for getting a "return value" from another Worksheet.

But you cannot generally set the state of another worksheet.

I am going to stress that it is unhelpful for you to not describe carefully what your goal is here.

If you simply want to be able to share/get procedures/operators/expressions amongst sessions then Library archives might suffice. Its difficult to know whether you are asking for significantly more than that, because you've given so few details.

@mehdibaghaee Your supposition that computations can generally be "shared" is false. Most cannot. That is true both in Maple and elsewhere.

Suppose that you buy a garage containing 10 cars, each of which can go 100mph.  That won't provide you with a way to go anywhere you want at more than 100mph (and, of course, not at 1000mph either).

What is the justification behind your expectation that a general computation (which may only be computable with some steps done in serial) be able to use 100% of the resources of a multi-core CPU?

@Christopher2222 

Using MS-Word like that also seems to introduce carriage-return into the end-of-line characters on each line. That's a common MS-Windows effect which seems like an unnecessary if mostly harmless alteration.

But I agree, it's nice know that Maple alone can sometimes recover all the Input. Unfortunately we are still seeing the occasional report from a Danish student where either use of Danish language or use of large drawing canvas corrupts the worksheet in such a way that only manual editing can attain the maximal recovery of material.

In fact it's only the last Output that presents the GUI a problem in this case, hence my first upload.

Why didn't you make the free upgrade from Maple 18.00 to 18.02?

@Christopher2222 That was not my point.

Any call like :-diff(...) is always possible as a way to use the global diff command.

My point was that the user may not be expecting the full set of command-name rebindings due to loading the whole Physics package. For most users in most situations, it would be more prudent to either:

• load only the one command via with(Physics, diff) 
• use the export with its full explicit name Physics:-diff(...) 

@Christopher2222 I expect that less surprises would occur from not loading the whole Physics package, and simply calling it as,

Physics:-diff(...);

where, of course, the arguments are filled in appropriately.

@waseem Please read my comments carefully, at least once.