80k integrals benchmark file

[Qian Yun]

This file's data comes from Nasser:

https://www.12000.org/my_notes/CAS_integration_tests/reports/summer_2024/DATA_BASE/indexchapter1.htm#x2-10001

In the attachment, is a file containing 80327 integrals,
the integrals are sorted by its computation time.
(Due to randomness, this number is just for reference.)
The first column is the time in microsecond.
You can use "bunzip2 integ_benchmark.data.bz2" to unzip it,
and use
"cat integ_benchmark.data | cut -d ' ' -f 2 > integ_benchmark.input"
to get the input file.

The first thousands of lines can be used as benchmark
for long running sessions, and the last thousands of lines
can be profiled to point directions for future optimization.



As an example, here is a benchmark to illustrate the effects
of kernel cache recycle:
(With ")boot writeHistModesAndValues() == nil" defined.)

The first column is the top n lines from the benchmark file.
Second column is time spent by current HEAD.
Third column is time spent by current HEAD with kernel cache
recycle patch.
Fourth column is time spend by fricas-1.3.13.

5k 3.5 3.4 5.2
10k 11.8 9.5 17.1
15k 26.0 18.5 38
20k 52.0 31.5 70
25k 95 45 136
30k 168 67 208
35k 290 84 415

At 35k, profiler shows time spent in triage$Kernel:
64.6% 15.7% 71.6%

Some conclusions:

1. The recent optimizations in EXPR and SMP give a linear
time save of 30%.

2. To insert into the never shrinking kernel cache, is quadratic,
and dominates the total time when session runs longer.

Kernel cache recycle is effective for long running sessions.

- Qian

[Waldek Hebisch]

On Mon, Aug 03, 2026 at 05:13:38PM +0800, Qian Yun wrote:
>
> Kernel cache recycle is effective for long running sessions.

Recycling kernels usualy helps, that is clear. Discussion that
we had was about details of the tuning.

You may also try the following function and some its variations:

test_kernels(n : Integer, m : Integer) : List(Expression(Integer)) ==
res : List(Expression(Integer)) := []
e1 := []$List(OutputForm)
for i in 1..n repeat
m1 := random(m)
o := m1::OutputForm
s := script('x, [[o], e1, e1, e1])$Symbol
k := s::Expression(Integer)
cons(k, res)
res

FYI, on the first run I get:

r1 := test_kernels(100000, 25000);
Compiling function test_kernels with type (Integer, Integer) -> List
(Expression(Integer))

Type: List(Expression(Integer))
Time: 37.00 (EV) + 0.04 (GC) = 37.05 sec

Second run is much faster (about 1.70s), after few runs it stabilises
at about 0.27s.

Runtime clearly grows nonlinearly (probably quadratically) with
increasing parameters. But stabilised behaviour indicates that
it should be quite a bit faster if we implemented change that
you suggested, that is skipping linear search when we know that
binary search can not miss.

You can also try some variation, say adding test for odd m1 before
'cons' in the function, so that half of created kernels immediately
becomes garbage (in function above there all kernels are live).
Also, to test impact of garbage collection we should allocate
enough data before or during test.

--
Waldek Hebisch

[Qian Yun]

That is a different optimization.

For kernel cache recycle patch, the first and subsequent runs
are all 4.5s.

> You can also try some variation, say adding test for odd m1 before
> 'cons' in the function, so that half of created kernels immediately
> becomes garbage (in function above there all kernels are live).

I guess "cons(k, res)" should be "res := cons(k, res)".

> Also, to test impact of garbage collection we should allocate
> enough data before or during test.
>

In extremely cases, where the temporary kernels can get reused
during later computation, like this case, kernel cache recycle
can have negative effects. But it can be minimized by tuning
the threshold for recycle.

- Qian