Thats an excellent reason to parallelise. That should be in the help file on Maple. These procedures would be mighty powerful if they are safe and consistent and have cheap overhead. Even still they'd be safer, more consistent and have cheaper overhead than something that I'm likey to code with the current tools. I think I am scrapping most of the code that I've been using and am just going to use the Threads:-Map command to build the sets I want (by iteration, hence Threads:-Seq is inappropriate), to calculate the data I need and to test for the conditions that I want. Easy (-ish).

Aren't the arguments entered into Threads:-Add calculated in a single thread? If so, then why not add the numbers as they are calculated?

p2 := proc (A)
   local i, j, k, l, m, n, fullL, c, comb;
   m, n := op(1, A);
   fullL := [seq(i, i = 1 .. n)];
   c := 0;
   for k to n do
      comb := combinat:-choose(fullL, k);
      for l to nops(comb) do
         c := c+(-1)^k*mul(add(A[i, j], j in comb[l]), i = 1 .. m)
      od;
   od;
end proc:
M := Matrix(15, (i, j) -> i+j):
p2(M);
-416483579190482716042690560000
 

Wow, a whole post about my problems. That makes them seem really huge :(

I've tried to use only very simple functions like adding, multiplying and testing if x<y but I also use convert, evalf[15], ListTools:-Search, gcd, union and some Array manipulations. A big worry is gcd as I think thats where I can trace my error from and the Array manipulations seem to screaming out to be locked.

I fear that even a single Mutex in the most obvious place to lock will make parallelisation next to pointless. You see, it reads info from an Array, does the bulk of the calculations and then it puts some improved data back into the same Array entry so most of the calculations would be done in a lock.

I'm definitely getting bad garbage collection. I have varied my base case size and the only one I've gotten to work at all is the smallest possible which assumably produces the most overhead. With the others, Maple has a go at them and breaks quickly (loses the kernel without telling me usually).

View 13174_GiugaPara2 ann.mw on MapleNet or Download 13174_GiugaPara2 ann.mw
View file details

If you want to have a look, there it is. The problem doesn't take any specialised knowledge really, just some basic number theory. I'm looking for the smallest number, n, whose prime factorisation is square free, normal and has s-1/n as an integer where s is the sum of the reciprocals (and hence bigger than 1). Normal in this sense is defined as gcd(p-1,q)=1 for all prime factors p and q. The technique used is a branch and bound scheme which are the poster boys of parallelisation in optimisation mathematics. This problem is about Giuga's Prime Number Conjecture and is explained in Experimentation in Mathematics by Borwein, Bailey and Girgensohn. Google books has only one relevant page missing but reading my annotations in the file pretty much covers it.

If you're running out of posts about Maple, then posts about any parallelisation is almost certainly a novelty and might lead the way for future parallelisation blogs which will become more and more popular as parallelisation becomes more common.

I started reading your blog when you had only a couple of posts and have been anxious to read nearly every blog since. Each time you post I get new ideas on how to possibly improve my project. The thing is, I don't know if the limits I've reached in Maple are Maple's limits, limits imposed by my coding or the problem's limits.

For instance, when I run my project in serial with a single processor, the problem of size 90 will take 25 minutes to do, while in parallel (8 processors) it's taking much longer to complete but is reaching the 16Gb of memory limit much earlier. Is Maple being too careful in safing variables and not smart enough in recycling memory? In smaller sized instances, I'm randomly getting errors that the serial version does not get. These are coming from a perceivably thread safe area. Should I trust what Maple does parallelised in with Tasks or should I make sure a variable is thread safed (by locking with mutex) when in doubt?

So I want to know

• How thread safe is thread safe? i.e. Will it jeopardise the trustworthyness of my results from a mathematicians standpoint?
• How much processing and memory is used for scheduling and thread safing in the Tasks package? Should I just learn to use the other packages if Maple can't schedule quick enough? Is there a way I can tell Maple how to schedule the Tasks?
• What is the limit in the kernel's capabilities to multithread? Why I can't get 800% cpu usage?
• What can I do to decrease memory usage if I need to access large arrays but different threads don't affect the same part of the array?
• Is there a list of "thread safe", "not thread safe" and "maybe thread safe" procedures and techniques?
• Is there somewhere/ someone I could go to if I want parallelisation help for my particular problems?

I like the examples you give your posts and those in Maple's help but I would like to see other people's variations. Its always good when someone tries to break your examples. Also some slightly more complicated examples. That way I might find something closer to what I'm doing.