[Ecls-list] ECL behavior on some array related code

[Jeronimo Pellegrini]

Hi,

I have checked out the most recent development sources of ECL from
git (the latest changeset I have is 
69399234506b8a4ecf540effe70bc1a5b86f34cc, "Missing definition for
CHARACTER-DESIGNATOR."

So -- I ran the Spartns [0] test suite with ECL and all tests pass;
then I ran the (silly/pseudo) benchmarks and, well, the good part
is that for most benchmarks (except one) ECL is more than twice
faster than what it used to be one year ago! :-)

But there's also a problem:

The benchmarks will run nicely on all sparse vector/matrix
representation functions, but will crash on the dense array
benchmark.

The funny thing is:

- With (safety 2) (debug 0) (speed 3), it won't crash. And it will
  not signal any errors either. The program just runs until the end
  normally;

- With ((safety 0) or (safety 1)) and (debug 0) (speed 3), it crashes
  with an "access to an invalid or protected memory address.";

- The code runs with (safety 0) (debug 0) (speed 3) on all other
  supported Common Lisps (everyone except Corman and maybe a few others)

What is somewhat suspicious is that it doesn't signal any errors 
or warnings with (safety 2) but crashes with (safety 1) and below.

Here's what happens:

Plain array (SET)

Detected access to an invalid or protected memory address.
Available restarts:

1. (RESTART-TOPLEVEL) Go back to Top-Level REPL.

Broken at SI:BYTECODES. [Evaluation of: (RUN-ARRAY-SET)] In: #<process SI:TOP-LEVEL 0000000000743f60>.
 File: #P"/home/jeronimo/work/mono/info.aleph0.lisp.spartn/benchmark.lisp" (Position #NIL)
SPARTNS>> 

The code for the benchmark is on the Spartns site [0]. I usually run
it like this:

(progn
  (load "spartns-packages.lisp")
  (load "utils.lisp")
  (load "spartns.lisp")
  (load "benchmark.lisp"))


One other curious thing is that ECL got slower on one single benchmark:
accessing sparse vectores represented as "index/value" pairs, doing
binary search (it's the "CVECTOR GET/SET" benchmark). ECL used to take
77 seconds there, now it's over 130. (But it is tremendously faster on
all other benchmarks).

J.

[0] http://aleph0.info/spartns/