[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #58957] [octave forge] (sparsersb) Failure to
From: |
Markus Mützel |
Subject: |
[Octave-bug-tracker] [bug #58957] [octave forge] (sparsersb) Failure to install and crash in function |
Date: |
Mon, 2 Nov 2020 04:54:41 -0500 (EST) |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36 Edg/86.0.622.56 |
Follow-up Comment #66, bug #58957 (project octave):
I locally removed the change from comment #61 and added the sed command from
comment #64 (see attachment). I also reverted the local change we made to the
build rule for librsb and recompiled Octave 6 for Windows.
With that change, `pkg test sparsersb` no longer crashes Octave.
So I believe, we can use that as a (temporary) fix.
However, there is lots of output in the command window during the test. The
output wasn't captured in the diary (and it is a pain to copy many lines of
text from the command window on Windows). So, to show just a small portion:
..s\sparsersb-1.0.8\x86_64-w64-mingw32-api-v55\sparsersb.cc-tst Will
autotune matrix: 100 x 100, type D, 4000 nnz, 40 nnz/r, 21 subms, 16 lsubms,
2.4160 bpnz.
10 iterations (4 th.) took 0.001013s; avg 0.0001013s ( +/- 99.98/900.00 %);
best 1.525e-08s; worst 0.001013s; std dev. 0.0003039 (taking best).
Reference operation time is 1.52477e-08 s (5.247e+05 Mflops) with 4 threads.
Starting merge (same threads) based auto-tuning procedure (transA=N, nrhs=1)
(max 6 steps, inclusive 3 grace steps) on: 100 x 100, type D, 4000 nnz, 40
nnz/r, 21 subms, 16 lsubms, 2.4160 bpnz (tpop: 1.525e-08 Mflops: 0.000)
Merge (16 -> 10 leaves) took w.c.t. of 0.001001s, ~0s of computing time (of
which 0s sorting, 0s analysis)
10 iterations (4 th.) took 0.002015s; avg 0.0002015s ( +/- 99.99/402.72 %);
best 1.524e-08s; worst 0.001013s; std dev. 0.000403 (taking best).
Reference operation time is 1.52431e-08 s (5.248e+05 Mflops) with 4 threads.
After merge step 1: tpop: 1.524e-08 s ~Mflops: 0.000 nsubm:10 otn:4
Applying merge (16 -> 10 leaves, 4 th.) yielded NEGLIGIBLE change (1th in a
row) (old/new=1.00030x): 1.525e-08s -> 1.524e-08s, so IGNORING this instance.
Merge (10 -> 7 leaves) took w.c.t. of 0s, ~0s of computing time (of which 0s
sorting, 0s analysis)
10 iterations (4 th.) took 0.000999s; avg 9.99e-05s ( +/- 99.98/900.00 %);
best 1.526e-08s; worst 0.000999s; std dev. 0.0002997 (taking best).
Reference operation time is 1.52622e-08 s (5.242e+05 Mflops) with 4 threads.
After merge step 2: tpop: 1.526e-08 s ~Mflops: 0.000 nsubm:7 otn:4
Applying merge (10 -> 7 leaves, 4 th.) yielded NEGLIGIBLE change (2th in a
row) (old/new=0.99905x): 1.525e-08s -> 1.526e-08s, so IGNORING this instance.
Merge (7 -> 4 leaves) took w.c.t. of 0s, ~0s of computing time (of which 0s
sorting, 0s analysis)
10 iterations (4 th.) took 0.00101s; avg 0.000101s ( +/- 99.98/900.00 %);
best 1.904e-08s; worst 0.00101s; std dev. 0.0003031 (taking best).
Reference operation time is 1.9043e-08 s (4.201e+05 Mflops) with 4 threads.
After merge step 3: tpop: 1.904e-08 s ~Mflops: 0.000 nsubm:4 otn:4
Applying merge (7 -> 4 leaves, 4 th.) yielded SLOWDOWN (1th of 3 tolerable) of
1.249x: 1.525e-08s -> 1.904e-08s.
Merge (4 -> 1 leaves) took w.c.t. of 0s, ~0s of computing time (of which 0s
sorting, 0s analysis)
10 iterations (4 th.) took 0s; avg 0s ( +/- -inf/ nan %); best 1.908e-08s;
worst 0s; std dev. 0 (taking best).
Reference operation time is 1.90848e-08 s (4.192e+05 Mflops) with 4 threads.
After merge step 4: tpop: 1.908e-08 s ~Mflops: 0.000 nsubm:1 otn:4
Applying merge (4 -> 1 leaves, 4 th.) yielded SLOWDOWN (2th of 3 tolerable) of
1.252x: 1.525e-08s -> 1.908e-08s.
Merged all the matrix leaves: no reason to continue merging.
A total of 4 merge steps (of max 6) (16 -> 1 subms) took 0.105s (of which
0.017s partitioning, 0s I/O); computing times: 0s in par. loops, 0s sorting,
0s analyzing)
Total merge + benchmarking process took 0.105s, equivalent to
6886154.6/6886154.6 new/old ops (0.001005s for 1 clones -- as 65907.4/65907.4
ops, or 65907.4/65907.4 ops per clone), SPEEDUP of 1.000x (NO SPEEDUP)
Merging based autotuning FAILED (=NO SPEEDUP); let's try splitting then...
Is this to be expected?
If it isn't we should probably follow up on a new bug report.
Additionally, there is one failing BIST:
>>>>> processing
D:\SVN\Octave\test\octave-2020-11-02-10-17-w64_librsb\octave-2020-11-02-10-17-w64\mingw64\share\octave\packages\sparsersb-1.0.8\sparsersbtg.m
***** test
assert( length( sparsersbtg () ) >= 57846 )
assert( length( sparsersbtg ([1,1,1,1,1,1]) ) >= 11218 )
assert( length( sparsersbtg ([1,1,1]) ) >= 11218 )
assert( length( sparsersbtg ([1]) ) == 0 )
!!!!! test failed
invalid empty index expression
To reproduce:
>> length( sparsersbtg () )
error: invalid empty index expression
error: called from
sparsersbtg at line 96 column 8
Should I open a separate report for this, too?
(file #50189)
_______________________________________________________
Additional Item Attachment:
File name: bug58957_librsb_double_free.patch Size:2 KB
<https://file.savannah.gnu.org/file/bug58957_librsb_double_free.patch?file_id=50189>
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?58957>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/