Re: [sage-devel] SAGE_NUM_THREADS

By the way, we might want to modify sage.parallel.ncpus.ncpus for Python 3.13 to use process_cpu_count instead of cpu_count, since as of Python 3.13, this is what Python's multiprocessing package does. On Wednesday, March 12, 20

Re: [sage-devel] SAGE_NUM_THREADS

I just bumped it in https://github.com/sagemath/sage/pull/39680 Please review. On Tue, Mar 11, 2025 at 8:30 PM John H Palmieri wrote: > > I think the problem is Sphinx: my guess is that when the Sphinx version got > bumped in https://github.com/sagemath/sage/pull/39577, sphinxcontrib-htmlhelp >

Re: [sage-devel] SAGE_NUM_THREADS

By the way, does anyone knows why src/sage/lfunctions/zero_sums.pyx has it's own ncpus() defined, as well as a global cdef NCPUS. This looks like there was more code that was replaced by sage.parallel.ncpus.ncpus in a very light-touch way. On Tue, Mar 11, 2025 at 7:40 PM John H Palmieri wrote:

Re: [sage-devel] SAGE_NUM_THREADS

I think the problem is Sphinx: my guess is that when the Sphinx version got bumped in https://github.com/sagemath/sage/pull/39577, sphinxcontrib-htmlhelp also needed a bump. If I look at the Sphinx build log, I see: spkg-pipinst] ERROR: Could not find a version that satisfies the requirement s

Re: [sage-devel] SAGE_NUM_THREADS

I see this too (I'm using OS X, don't know the situation for other platforms). I think the problem is somehow with Python3. If I modify the src/bin/sage-env script (which is where SAGE_NUM_THREADS gets read and perhaps modified) to directly run the script sage-num-threads.py, I get an error, an

Re: [sage-devel] SAGE_NUM_THREADS

For 10.5 with python 3.12.5, sage.parallel.ncpus.ncpus() is 1 without giving a value to SAGE_NUM_THREADS and 16 if sage is opened as "SAGE_NUM_THREADS=16 sage". For 10.6.beta9 (python 3.13.2), the value is always one; in another computer 10.6.beta9 is using python 3.12.5 and the value is alway

Re: [sage-devel] SAGE_NUM_THREADS

On Mon, Mar 10, 2025 at 4:28 AM enriqu...@gmail.com wrote: > > If I set the variable SAGE_NUM_THREADS to a number of cores before opening a > sage session (command line or jupyterlab) there is a different behaviour in > 10.5 and in 10.6beta; > parallel computation can be done in 10.5, there is n

[sage-devel] SAGE_NUM_THREADS

If I set the variable SAGE_NUM_THREADS to a number of cores before opening a sage session (command line or jupyterlab) there is a different behaviour in 10.5 and in 10.6beta; parallel computation can be done in 10.5, there is no effect in the beta version (I do not know when it started to fail).