[Caml-list] bigarrays and toplevel on Win32?

[Caml-list] bigarrays and toplevel on Win32?

[Chris Hecker]

I can not seem to get the bigarray module to work at the toplevel, no matter what I do.  I've got both ocamlc and ocamlopt apps building and working fine using bigarrays.

I've built my own toplevel in a number of different ways, including 

ocamlmktop -o ba.exe bigarray.cma

with and without 
bigarray.lib, -custom, #load-ing before use, and a bunch of other stuff.

I always get "The external function `bigarray_get_1' is not available".  I must be doing something stupid and wrong.  Any ideas?

Chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] bigarrays and toplevel on Win32?

[Xavier Leroy]

> I can not seem to get the bigarray module to work at the toplevel,
> no matter what I do.  I've got both ocamlc and ocamlopt apps
> building and working fine using bigarrays.
> I always get "The external function `bigarray_get_1' is not
> available".  I must be doing something stupid and wrong.  Any ideas?

This is a known bug in OCaml 3.00.  A simple fix is described here:

    http://caml.inria.fr/bin/caml-bugs/fixed?id=94

and of course this will be fixed in OCaml 3.01.

Concerning bounds checks for bigarray accesses: you are correct that
the current implementation always perform them, there is no equivalent
to Array.unsafe_{get,set}, and the -unsafe flag simply doesn't apply
to bigarrays.

The party line on unsafe array accesses is unclear: on the one hand,
we do not want to encourage their use, as it can break type safety and
dramatically reduce the safety of the programs; on the other hand,
they are handy when benchmarking against C or Fortran :-)

I'll keep that in mind for 3.02.

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] bigarrays and toplevel on Win32?

[Chris Hecker]

>This is a known bug in OCaml 3.00.  A simple fix is described here:
>  http://caml.inria.fr/bin/caml-bugs/fixed?id=94
>and of course this will be fixed in OCaml 3.01.

Ack, sorry, the one place I didn't look was the bug list.  Sorry to waste your time.

>The party line on unsafe array accesses is unclear: on the one hand,
>we do not want to encourage their use, as it can break type safety and
>dramatically reduce the safety of the programs; on the other hand,
>they are handy when benchmarking against C or Fortran :-)

I'd like to have the choice.  I prefer unsafe_get/unsafe_set to -unsafe because it lets me choose where to be risky.  

It doesn't actually look like it would be too hard for me to make -unsafe work in the source (adding the unsafe_(set|get) would be harder, it seems).  Couldn't I just have ccmgen.ml's bigarray_indexing function not generate Ccheckbound ops if Clflags.fast is set?

>I'll keep that in mind for 3.02.

Cool.  Is there an autmated or semi-automated way to do these primitive additions, or do you manually do it?

Chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] bigarrays and toplevel on Win32?

[Brian Rogoff]

On Mon, 5 Mar 2001, Chris Hecker wrote:
> >The party line on unsafe array accesses is unclear: on the one hand,
> >we do not want to encourage their use, as it can break type safety and
> >dramatically reduce the safety of the programs; on the other hand,
> >they are handy when benchmarking against C or Fortran :-)
> 
> I'd like to have the choice.  I prefer unsafe_get/unsafe_set to -unsafe
> because it lets me choose where to be risky.  

It puts the annotation directly in the source code, so if you change your
mind or want to experiment you have to change the source. You have control 
over where to be risky by using top level modules. With extra work, you
could recover the same level of control using this approach. 

I think it's cleaner to push this issue as much as possible to the
compiler and rely on compiler options, otherwise the language will need to
have unsafe_everything operations for every possible op that you want fast. 

On a related issue, it might be nice to put Obj.magic in all it's guises
into a suitably disgustingly named module (Unsafe_operations?) so people
aren't tempted to use it just to pass the typechecker ;-)

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] bigarrays and toplevel on Win32?

[Bruce Hoult]

>The party line on unsafe array accesses is unclear: on the one hand,
>we do not want to encourage their use, as it can break type safety and
>dramatically reduce the safety of the programs; on the other hand,
>they are handy when benchmarking against C or Fortran :-)

We've got a benchmark over at Gwydion Dylan that does a simpleminded 
Sieve of Eratosthenes

   <http://www.ccc.de/cgi-bin/cvsweb/gd/examples/sieve-mark/>

While our Dylan code is currently a bit slower than C (about 11%), 
the presence or absence of array bounds checking makes almost no 
difference at all on modern superscalar CPUs such as the P6 (P-Pro, 
PII, PIII) or PowerPC G3/G4.

   Five Hundred Thousand Integer Sieve
   ===================================

   Implementation           Seconds
   --------------           -------
   C                           0.33
   Dylan w/o bounds checks     0.37
   Dylan w/ bounds checks      0.38
   Python w/ 'for' loops      11.40
   Python w/ 'while' loops    15.03
   Perl 5                     24.58


   Five Million Integer Sieve of Eratosthenes
   ==========================================

   Implementation           Seconds
   --------------           -------
   C                           3.90
   Dylan w/o bounds checks     4.33
   Dylan w/ bounds checks      4.35
   Python w/ 'for' loops     FAILED (massive swapping)
   Python w/ 'while' loops   156.83
   Perl 5                    FAILED (bad vector representation?)

-- Bruce

-------------------------------------------------------

The Dylan code is below. The other language implementation can be 
found in the CVS (via the web as above, or from 
:pserver:anoncvs@berlin.ccc.de:/home/cvsroot

define constant $fixed-bound = 500000;

define constant <int-vector> =
   limited(<simple-vector>, of: <integer>, size: $fixed-bound);

define function main()
   let vec :: <int-vector> = make(<int-vector>, fill: 0);

   for (i from 0 below vec.size)
     vec[i] := i + 1;
   end for;

   vec[0] := 0;
   let prime-count = 0;

   for (i from 1 below vec.size)
     if (vec[i] ~= 0)
       prime-count := prime-count + 1;
       let prime = i + 1;
       for (j from (i + prime) below vec.size by prime)
         vec[j] := 0;
       end for;
     end if;
   end for;

   format("There are %d primes less than or equal to %d.\n",
          prime-count, $fixed-bound);
end function main;

main();
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] bigarrays and toplevel on Win32?

[John Prevost]

>>>>> "xl" == Xavier Leroy <Xavier.Leroy@inria.fr> writes:

    xl> The party line on unsafe array accesses is unclear: on the one
    xl> hand, we do not want to encourage their use, as it can break
    xl> type safety and dramatically reduce the safety of the
    xl> programs; on the other hand, they are handy when benchmarking
    xl> against C or Fortran :-)

Think of it less as an "unsafe array access" and more of "license to
turn a given set of exceptions into core dumps in exchange for
efficiency."  ;)

John.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] bigarrays and toplevel on Win32?

[Dan Grossman]

John Prevost wrote:
> 
> >>>>> "xl" == Xavier Leroy <Xavier.Leroy@inria.fr> writes:
> 
>     xl> The party line on unsafe array accesses is unclear: on the one
>     xl> hand, we do not want to encourage their use, as it can break
>     xl> type safety and dramatically reduce the safety of the
>     xl> programs; on the other hand, they are handy when benchmarking
>     xl> against C or Fortran :-)
> 
> Think of it less as an "unsafe array access" and more of "license to
> turn a given set of exceptions into core dumps in exchange for
> efficiency."  ;)
> 
> John.

No.  If I could be guaranteed a core dump on my first out-of-bounds access,
I would be fine with this.  It's why my C code sometimes doesn't check for
null before dereferencing a pointer.  But with arrays, you can silently
corrupt arbitrary memory.  Maybe your program crashes later.  Maybe it ends
up deleting all your files.  Maybe it never tells you that it computed the
wrong answer.

What I would be okay with was doing the bounds-check and exiting (or core
dumping if you prefer) on out-of-bounds.  This still gives an optimizer some
leeway because array-intensive code will have fewer exception-causing
instructions.

--Dan

-- 
| Dan Grossman     www.cs.cornell.edu/home/danieljg H:607 256 0724 |
| 5157 Upson Hall  danieljg@cs.cornell.edu          O:607 255 9834 |
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] bigarrays and toplevel on Win32?

[John Prevost]

>>>>> "dg" == Dan Grossman <danieljg@cs.cornell.edu> writes:

    dg> No.  If I could be guaranteed a core dump on my first
    dg> out-of-bounds access, I would be fine with this.  It's why my
    dg> C code sometimes doesn't check for null before dereferencing a
    dg> pointer.  But with arrays, you can silently corrupt arbitrary
    dg> memory.  Maybe your program crashes later.  Maybe it ends up
    dg> deleting all your files.  Maybe it never tells you that it
    dg> computed the wrong answer.

    dg> What I would be okay with was doing the bounds-check and
    dg> exiting (or core dumping if you prefer) on out-of-bounds.
    dg> This still gives an optimizer some leeway because
    dg> array-intensive code will have fewer exception-causing
    dg> instructions.

You have a good point here--I was just being cheeky.

I really look at the unsafe array operations as akin to the unsafe
magic cast operation.  None of them are appropriate for everyday
use--but if I go over a small piece of code with a fine-toothed comb
and prove to my satisfaction that everything is correct, it's
worthwhile to have them.  They're not the most ideologically sound
tools available, but I appreciate that O'Caml tends to balance
ideology with practicality more often than the other guys seem to.

John.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr