@Glowing I have Windows 10 Home version 1903.

Maybe that "totally safe" utility turned off your hyperthreading?

@Glowing The examples of Christian Wolinski and Axel Vogt above show that it clearly makes a difference whether you use a decimal point. In particular, it changes the order that things are added. Floating-point addition is not associative. Operations between exact rationals get done first.

@tomleslie 

Tom,

What the OP is trying to achieve: My guess is that this is one of those ubiquitous ODE BVPs in nano-magneto fluid dynamics.  (We've been getting I guess about two such questions a week for years now.) It appears that the OP is trying solve it by the Homotopy Perturbation Method, which is a series solution approximation technique for BVPs. I am just guessing.

@Glowing My Resource Monitor (through Windows Task Manager) shows 97% - 100% processor utilization, and my cputime/realtime is about 6 with numcpus = 8. I have Intel Core i7 - 7700HQ @ 2.80 GHz.

I also just ran a similar test for another Question using Grid, and I got a ratio of 5.6. You can see in my Answer to "Grid Toolbox C Compile".

@erik10 Yes, sprintf can be used wherever the syntax expects a string. I used it because I wanted a consistent 3-character width (including the white space) for each number. Still, the width varies a small amount because times is not a fixed-width font.

@Rouben Rostamian  Doesn't the flexibility of the rope have something to do with it? I see no parameter for it.

It seems odd to me that the y-coordinate of the free end is constant. Is that correct?

@vv The command plots:-inequal can handle intersections, unions, and combinations thereof; although it's true that by  using the list/set syntax common to most plotting commands you'll just get an intersection. For a combination of intersections and unions, see the last example on the ?inequal help page.

@vv Yes, certainly it's hopeless for expressions containing user-defined numeric functions that don't control error.

@vv The part that I didn't understand (but now do) was why this doesn't work:

Digits:= 10: #Or just accept the default.
evalf[2](evalf[Digits](p2-p1));

The reason is that Digits = 2 inside the outer evalf.  But if Digits is copied to another variable, that variable won't be changed by the outer evalf.

I'm working on a method to ameliorate the catasthropic cancellation without requiring the user to figure out the number of digits required to do that.

@Carl Love Aha! I figured out how your sigfig works. Each nested level of evalf temporarily changes the value of the global environment variable Digits. I've been trying to figure that out for years, so thanks for the inspiration. With that in mind, here's a reasonable version of sigfig:

sigfig:= proc(e::uneval, d1::posint, d2::posint:= :-Digits)
    evalf[d1](evalf[d2](eval(e)))
end proc:

Usage:

​​​​​​sigfig(p2 - p1, 2);

or if perhaps more precision is required to get the internal computation right:

sigfig(p2 - p1, 2, 2*Digits);

@acer Thank you for teaching me about that difference. Yes, I was mixing up multithreading and hyperthreading.

Do you see any way that Maple could be at fault?

@Glowing Your sigfig trick is very interesting. I can't figure out why it works, but it does work! In particular, I don't understand why using a new variable, Digits0, is any different than using Digits itself.

@Glowing Any ratio greater than 1 shows that there is some hyperthreading. If your O/S is not scheduling optimally or if there's contention over memory caches, etc., it's not Maple's fault. Your ratio is about 4. A factor-of-4 improvement can hardly be characterized by "the benefit of hyperthreading really disappears." Was your computer performing any significant tasks unrelated to Maple at the same time?

@Glowing I don't see any problem in your test run. The hyperthreading performance looks great.

@shkarah I see that someone deleted your Question from today, probably because they thought that it was too similar to this one. The difference that I saw was that in the new Question, you attached code that showed the derivation of Eqs 17-19 from Eq 16. I want to let you know that your derivation was totally correct! The only problem was applying dsolve to Eqs 17-19 in a loop with assign. By simply replacing assign with an equivalent usage of eval, I got dsolve to produce the correct solutions. Here is my worksheet. The only change that I made to your code is that I replaced your last line with my last 4 lines.
 

Download HomotopyPerturbation.mw