Re: Maxima and thread safety

Fateman mentions normal-form calculations in another email. These
continue to be slow using symbolic methods. Polynomial multiplication
(with truncation) is a bottleneck, I think.

Leo

On Tue, Jun 09 2026, Stavros Macrakis <[email protected]> wrote:

> I would be interested to hear from the community about problems they've
> tackled with Maxima where compute time was the primary challenge.
>
> Then we could think about helping to make them faster, whether by
> parallelization, new Maxima functionality, improved Maxima algorithms,
> improved application code, or some other approach. Or maybe suggesting some
> other, more suitable, tool.
>
>
> On Tue, Jun 9, 2026 at 12:42 PM David Scherfgen via Maxima-discuss <
> [email protected]> wrote:
>
>> Yes, but we try it with the ..._threads.lisp file. The one you tried uses
>> multiple processes, which are completely isolated from each other.
>>
>> Leo Butler <[email protected]> schrieb am Di., 9. Juni 2026, 18:25:
>>
>>> Hi David,
>>>
>>> I cannot reproduce your crash using `distribute_over_tranches_mt.lisp'
>>> from Michel's github repo.
>>>
>>> I played around with the number of threads (1, 4, 8) and your example
>>> works
>>> fine and it clearly is using multiple threads.
>>>
>>> Leo
>>>
>>> Maxima-version: "branch_5_49_base_416_g162a6093a_dirty"
>>> Maxima build date: "2026-06-08 12:29:08"
>>> Host type: "x86_64-unknown-linux-gnu"
>>> Lisp implementation type: "SBCL"
>>> Lisp implementation version: "2.6.4.debian"
>>> User dir: "/dev/null"
>>> Temp dir: "/tmp"
>>> Object dir:
>>> "/home/butlerlt/maxima/sandbox/git/maxima-code/binary/branch_5_49_base_416_g162a6093a_dirty/sbcl/2_6_4_debian"
>>> Frontend: false
>>>
>>>
>>> On Tue, Jun 09 2026, David Scherfgen via Maxima-discuss <
>>> [email protected]> wrote:
>>>
>>> > Hi Michel,
>>> >
>>> > You might add this to your examples:
>>> >
>>> > distribute_over_tranches(
>>> >   '(block(
>>> >       [x_n: float(N), x_next, i],
>>> >       for i : 1 thru 1000 do (
>>> >           x_next: 0.5 * (x_n + N / x_n),
>>> >           x_n: x_next
>>> >       ),
>>> >       x_n)),
>>> >   N, 1000, 16);
>>> >
>>> > Nothing fancy, it's Newton's algorithm to compute the square root, with
>>> a
>>> > fixed number of iterations, just for demonstration purposes.
>>> > Note that I have done everything possible to make sure that the
>>> variables
>>> > x_n, x_next, i are local, by using a block.
>>> > But yet, the calculation crashes as soon as one uses more than 1 thread.
>>> > So, the situation is even more delicate than I thought.
>>> >
>>> > Best regards
>>> > David
>>> >
>>> > Am Di., 9. Juni 2026 um 16:45 Uhr schrieb Michel Talon <
>>> > [email protected]>:
>>> >
>>> >> I have updated the README in
>>> >>
>>> >> https://github.com/mtalon/mtalon/tree/master/mtalon/maxima-parallel
>>> >>
>>> >> to reflect David insightful examples.
>>> >>
>>> >> Finally "distribute_over_tranches_thread.lisp" is another way to
>>> >> achieve the same parallelism, using threads in just one Unix
>>> >> process. Here we use the sbcl threading support. For sufficiently
>>> >> independent computations one may expect to get correct behaviour.
>>> >> However if threads modify the internal state of maxima chaos can
>>> >> occur. Examples have been provided by David Scherfgen, notably:
>>> >> distribute_over_tranches('(concat('v, i) :: i), i, 10000, 16)$
>>> >> which under the hood affect the global variable $values, so at the end
>>> >> one gets length($values) different from 10000. The problem is that
>>> special
>>> >> variables with global extent are not bound in thread local storage, but
>>> >> can be read and modified independently by all threads. But they are not
>>> >> protected by a mutex.
>>> >> A small lisp program which  shows the behavior of such special global
>>> variables is:
>>> >>
>>> >> ;;; We are in main thread
>>> >> (defparameter *x* 0)
>>> >> (format nil "~a" *x*)    ;;; value of global *x* in main thread
>>> >> (let ((*x* 1))
>>> >> a  (format t "~a ~%" *x*)  ;;; value of *x* in main thread TLS
>>> >>   (sb-thread:make-thread (lambda ()   ;;; spawning new thread
>>> >>                         (format t "~a ~%" *x*) ;;; value of *x* in new
>>> thread, the global one.
>>> >>                         (setq *x* 3)
>>> >>                         (format t "~a ~%" *x*) ;;; altered value of
>>> *x* in new thread
>>> >>                         "Sorry! *x* in main thread is not isolated.")))
>>> >> (format nil "~a" *x*)     ;;; The global value of *x* has been altered
>>> in main thread
>>> >>
>>> >> However i still believe that the threading program may be very useful
>>> to distribute a bunch of "ordinary standard"
>>> >> computations over the many cores of modern processors.  For example
>>> running the same computation a hundred of times for
>>> >> different values of parameters which may take hours of compute time,
>>> will be scaled down basically by the number of cores.
>>> >> Fortunately special variables bound locally in a let form or similar
>>> (this being called dynamically bound) get bound in TLS
>>> >> (thread local storage) which isolates them from thread to thread, so
>>> that most parts of maxima can still work OK.
>>> >>
>>> >>
>>> >> Le 07/06/2026 à 16:55, David Scherfgen a écrit :
>>> >>
>>> >>
>>> >> Unfortunately, Maxima has many hidden side effects that are surprising
>>> to
>>> >> the average user. The following innocent looking example simply creates
>>> >> Maxima variables v1, v2, v3, ..., v10000 in 16 parallel threads:
>>> >>
>>> >> --
>>> >> Michel Talon
>>> >>
>>> >> _______________________________________________
>>> >> Maxima-discuss mailing list
>>> >> [email protected]
>>> >> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>> >>
>>> >
>>> > _______________________________________________
>>> > Maxima-discuss mailing list
>>> > [email protected]
>>> > https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>> >
>>>
>>> --
>>> ---
>>> Best regards,
>>> Dr Butler
>>
>> _______________________________________________
>> Maxima-discuss mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>

-- 
---
Best regards,
Dr Butler
_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss