caml_copy_string

caml_copy_string

[Jeffrey Barber]

[-- Attachment #1: Type: text/plain, Size: 142 bytes --]

Is there a way to get a string from C to OCaml without the caml_copy_string
function, or is there a version that doesn't copy the string?

-J

[-- Attachment #2: Type: text/html, Size: 156 bytes --]

Re: [Caml-list] caml_copy_string

[Romain Beauxis]

Le samedi 21 août 2010 18:30:28, Jeffrey Barber a écrit :
> Is there a way to get a string from C to OCaml without the caml_copy_string
> function, or is there a version that doesn't copy the string?

String_val ? :-)

R.

Re: [Caml-list] caml_copy_string

[Mathias Kende]

Le samedi 21 août 2010 à 18:30 -0500, Jeffrey Barber a écrit :
> Is there a way to get a string from C to OCaml without the
> caml_copy_string
> function, or is there a version that doesn't copy the string?

There is no such function in the Caml FFI. You could write one yourself
but then the string must have been specially allocated because you need
to add a one word header to the string and maybe some byte at the end.
So, if you have to exchange strings between OCaml and C, the easiest way
is to always allocate them with the caml_alloc_string function. That way
you can use the pointer returned by String_val in your C code and the
string remains a valid Caml string (except caml does not use zero as the
end of string and will stick to its allocated size).

Mathias

Re: [Caml-list] caml_copy_string

[Till Varoquaux]

In byterun/mlvalues.h

#define Bp_val(v) ((char *) (v))
....
#define String_val(x) ((char *) Bp_val(x))

Doesn't look like String_val is doing much copying to me....


Till

On Sat, Aug 21, 2010 at 7:46 PM, Mathias Kende <mathias.kende@ens.fr> wrote:
> Le samedi 21 août 2010 à 18:30 -0500, Jeffrey Barber a écrit :
>> Is there a way to get a string from C to OCaml without the
>> caml_copy_string
>> function, or is there a version that doesn't copy the string?
>
> There is no such function in the Caml FFI. You could write one yourself
> but then the string must have been specially allocated because you need
> to add a one word header to the string and maybe some byte at the end.
> So, if you have to exchange strings between OCaml and C, the easiest way
> is to always allocate them with the caml_alloc_string function. That way
> you can use the pointer returned by String_val in your C code and the
> string remains a valid Caml string (except caml does not use zero as the
> end of string and will stick to its allocated size).
>
> Mathias
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] caml_copy_string

[Till Varoquaux]

Actually Mathias is spot on: you need your string to be allocated in
the memory region owned by the ocaml GC and tagged properly (that is
wrapped with the correct GC info). After that you can pass it around
in C as a string but you should never resize it. That being said you
only save a call to what existentially is memcpy (unless you need to
malloc your c string): this should be real fast. Are you  sure this is
your bottleneck?

Till

On Sun, Aug 22, 2010 at 1:16 PM, Till Varoquaux <till@pps.jussieu.fr> wrote:
> In byterun/mlvalues.h
>
> #define Bp_val(v) ((char *) (v))
> ....
> #define String_val(x) ((char *) Bp_val(x))
>
> Doesn't look like String_val is doing much copying to me....
>
>
> Till
>
> On Sat, Aug 21, 2010 at 7:46 PM, Mathias Kende <mathias.kende@ens.fr> wrote:
>> Le samedi 21 août 2010 à 18:30 -0500, Jeffrey Barber a écrit :
>>> Is there a way to get a string from C to OCaml without the
>>> caml_copy_string
>>> function, or is there a version that doesn't copy the string?
>>
>> There is no such function in the Caml FFI. You could write one yourself
>> but then the string must have been specially allocated because you need
>> to add a one word header to the string and maybe some byte at the end.
>> So, if you have to exchange strings between OCaml and C, the easiest way
>> is to always allocate them with the caml_alloc_string function. That way
>> you can use the pointer returned by String_val in your C code and the
>> string remains a valid Caml string (except caml does not use zero as the
>> end of string and will stick to its allocated size).
>>
>> Mathias
>>
>> _______________________________________________
>> Caml-list mailing list. Subscription management:
>> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
>> Archives: http://caml.inria.fr
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>

Re: [Caml-list] caml_copy_string

[Jeffrey Barber]

[-- Attachment #1: Type: text/plain, Size: 2614 bytes --]

No known bottlenecks yet, just making a list of possible bottlenecks so I
can sleep on ways of optimizing them when I get node.ocaml to "feature
complete" status.

For this issue, I'm going to use Mathias's advice for caml_alloc_string and
try two things. I'm going to test giving libevent a custom memory allocator
that uses caml_alloc_string, and the other way is just focus on how I buffer
strings and make a separate read_line that uses caml_alloc.

On Sun, Aug 22, 2010 at 7:42 PM, Till Varoquaux <till@pps.jussieu.fr> wrote:

> Actually Mathias is spot on: you need your string to be allocated in
> the memory region owned by the ocaml GC and tagged properly (that is
> wrapped with the correct GC info). After that you can pass it around
> in C as a string but you should never resize it. That being said you
> only save a call to what existentially is memcpy (unless you need to
> malloc your c string): this should be real fast. Are you  sure this is
> your bottleneck?
>
> Till
>
> On Sun, Aug 22, 2010 at 1:16 PM, Till Varoquaux <till@pps.jussieu.fr>
> wrote:
> > In byterun/mlvalues.h
> >
> > #define Bp_val(v) ((char *) (v))
> > ....
> > #define String_val(x) ((char *) Bp_val(x))
> >
> > Doesn't look like String_val is doing much copying to me....
> >
> >
> > Till
> >
> > On Sat, Aug 21, 2010 at 7:46 PM, Mathias Kende <mathias.kende@ens.fr>
> wrote:
> >> Le samedi 21 août 2010 à 18:30 -0500, Jeffrey Barber a écrit :
> >>> Is there a way to get a string from C to OCaml without the
> >>> caml_copy_string
> >>> function, or is there a version that doesn't copy the string?
> >>
> >> There is no such function in the Caml FFI. You could write one yourself
> >> but then the string must have been specially allocated because you need
> >> to add a one word header to the string and maybe some byte at the end.
> >> So, if you have to exchange strings between OCaml and C, the easiest way
> >> is to always allocate them with the caml_alloc_string function. That way
> >> you can use the pointer returned by String_val in your C code and the
> >> string remains a valid Caml string (except caml does not use zero as the
> >> end of string and will stick to its allocated size).
> >>
> >> Mathias
> >>
> >> _______________________________________________
> >> Caml-list mailing list. Subscription management:
> >> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> >> Archives: http://caml.inria.fr
> >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> >> Bug reports: http://caml.inria.fr/bin/caml-bugs
> >>
> >
>

[-- Attachment #2: Type: text/html, Size: 3624 bytes --]

Re: [Caml-list] caml_copy_string

[Florent Monnier]

Le dimanche 22 août 2010 01:30:28, Jeffrey Barber a écrit :
> Is there a way to get a string from C to OCaml without the caml_copy_string
> function, or is there a version that doesn't copy the string?

an alternative method is to provide a string from ocaml to c then c fills this 
buffer, then you can save allocations by reusing the same buffer, see:

ocamlopt -o test.opt main.ml main_stub.c

$ time ./test.opt 1
44 seconds elapsed

$ time ./test.opt 2
21 seconds elapsed

========================

#include <string.h>
#include <caml/mlvalues.h>
#include <caml/alloc.h>
#include <caml/fail.h>

static const char *str = "the walking camel";
static const int len = 18;

CAMLprim value ml_mystr1(value unit) {
    return caml_copy_string(str);
}

CAMLprim value ml_mystr2(value ml_buf) {
    int buf_len = caml_string_length(ml_buf);
    if (len > buf_len) caml_failwith("buffer overflow");
    memcpy(String_val(ml_buf), str, len);
    return Val_int(len);  /* len chars were written in the buffer */
}

========================

external mystr1: unit -> string = "ml_mystr1"
external mystr2: string -> int = "ml_mystr2" "noalloc"

let n = 1_000_000_000

let test1() =
  for i = 1 to n do
    let _ = mystr1 () in ()
  done

let test2() =
  let buf = String.create 100 in
  for i = 1 to n do
    let _ = mystr2 buf in ()
  done

let () =
  match Sys.argv.(1) with
  | "1" -> test1()
  | "2" -> test2()
  | _ -> assert false

========================

-- 
Regards
Florent

Re: [Caml-list] caml_copy_string

[Stéphane Glondu]

Le 23/08/2010 14:09, Florent Monnier a écrit :
>> Is there a way to get a string from C to OCaml without the caml_copy_string
>> function, or is there a version that doesn't copy the string?
> 
> an alternative method is to provide a string from ocaml to c then c fills this 
> buffer, then you can save allocations by reusing the same buffer, see: [...]

You can also wrap your C pointer into bigarrays.

-- 
Stéphane

Re: [Caml-list] caml_copy_string

[Florent Monnier]

Le lundi 23 août 2010 14:59:19, Stéphane Glondu a écrit :
> Le 23/08/2010 14:09, Florent Monnier a écrit :
> >> Is there a way to get a string from C to OCaml without the
> >> caml_copy_string function, or is there a version that doesn't copy the
> >> string?
> > 
> > an alternative method is to provide a string from ocaml to c then c fills
> > this buffer, then you can save allocations by reusing the same buffer,
> > see: [...]
> 
> You can also wrap your C pointer into bigarrays.

with a ba buffer speed is close than with a string buffer
but with ba allocs it is very slow:

$ ocamlopt -o test.opt bigarray.cmxa main.ml main_stub.c 

$ time ./test.opt 1
44 seconds elapsed

$ time ./test.opt 2
21 seconds elapsed

$ time ./test.opt 3
3 minutes 28 seconds elapsed
(208 seconds elapsed)

$ time ./test.opt 4
25 seconds elapsed

========================

#include <string.h>
#include <caml/mlvalues.h>
#include <caml/alloc.h>
#include <caml/fail.h>
#include <caml/bigarray.h>

static const char *str = "the walking camel";
static const int len = 18;

CAMLprim value ml_mystr1(value unit) {
    return caml_copy_string(str);
}
CAMLprim value ml_mystr2(value ml_buf) {
    int buf_len = caml_string_length(ml_buf);
    if (len > buf_len) caml_failwith("buffer overflow");
    memcpy(String_val(ml_buf), str, len);
    return Val_int(len);
}

CAMLprim value ml_mysba1(value unit) {
    long dims[3];
    dims[0] = len;
    return caml_ba_alloc(CAML_BA_UINT8 | CAML_BA_C_LAYOUT, 1, NULL, dims);
}
CAMLprim value ml_mysba2(value ba) {
    unsigned char *ptr;
    int ba_size = caml_ba_byte_size(Caml_ba_array_val(ba));
    if (len > ba_size) caml_failwith("buffer overflow");
    ptr = Caml_ba_data_val(ba);
    memcpy(ptr, str, len);
    return Val_int(len);
}

========================

external mystr1: unit -> string = "ml_mystr1"
external mystr2: string -> int = "ml_mystr2" "noalloc"

type ba_string =
  (char, Bigarray.int8_unsigned_elt, Bigarray.c_layout) Bigarray.Array1.t

external mysba1: unit -> ba_string = "ml_mysba1"
external mysba2: ba_string -> int = "ml_mysba2" "noalloc"

let n = 1_000_000_000

let test1() =
  for i = 1 to n do
    let _ = mystr1 () in ()
  done

let test2() =
  let buf = String.create 100 in
  for i = 1 to n do
    let _ = mystr2 buf in ()
  done

let test3() =
  for i = 1 to n do
    let _ = mysba1 () in ()
  done

let test4() =
  let bstr = Bigarray.Array1.create Bigarray.char Bigarray.c_layout 100 in
  for i = 1 to n do
    let _ = mysba2 bstr in ()
  done

let () =
  match Sys.argv.(1) with
  | "1" -> test1()
  | "2" -> test2()
  | "3" -> test3()
  | "4" -> test4()
  | _ -> assert false

========================

-- 
Regards
Florent

Re: [Caml-list] caml_copy_string

[Romain Beauxis]

Le lundi 23 août 2010 07:09:05, Florent Monnier a écrit :
> an alternative method is to provide a string from ocaml to c then c fills
> this  buffer, then you can save allocations by reusing the same buffer,
> see:

This is a good idea but I would be a little bit suspicious about using 
"noalloc". Even if it works in your tests, this options is very delicate to 
use with the Gc, and may segfault in some cases.

Beside, I think that the benefit of noalloc have to be traded off with the 
complexity of the function in terms of elementary instructions.


Romain

Re: [Caml-list] caml_copy_string

[Florent Monnier]

Le lundi 23 août 2010 22:24:48, Romain Beauxis a écrit :
> Le lundi 23 août 2010 07:09:05, Florent Monnier a écrit :
> > an alternative method is to provide a string from ocaml to c then c fills
> > this  buffer, then you can save allocations by reusing the same buffer,
> 
> > see:
> This is a good idea but I would be a little bit suspicious about using
> "noalloc". Even if it works in your tests, this options is very delicate to
> use with the Gc, and may segfault in some cases.

could you develop? which cases?


-- 
Regards
Florent

Re: [Caml-list] caml_copy_string

[Till Varoquaux]

On Tue, Aug 24, 2010 at 10:21 AM, Florent Monnier
<monnier.florent@gmail.com> wrote:
> Le lundi 23 août 2010 22:24:48, Romain Beauxis a écrit :
>> Le lundi 23 août 2010 07:09:05, Florent Monnier a écrit :
>> > an alternative method is to provide a string from ocaml to c then c fills
>> > this  buffer, then you can save allocations by reusing the same buffer,
>>
>> > see:
>> This is a good idea but I would be a little bit suspicious about using
>> "noalloc". Even if it works in your tests, this options is very delicate to
>> use with the Gc, and may segfault in some cases.
>
> could you develop? which cases?

IIRC noalloc calls release the ocaml lock. This means that the runtime
can run at the same time as the c call and the GC migh collect your
string or move it along. Quick rule if thumb is: you are allocating
your string so you should not use noalloc.
Till
>
>
> --
> Regards
> Florent
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] caml_copy_string

[Anil Madhavapeddy]

On 24 Aug 2010, at 15:52, Till Varoquaux wrote:

> On Tue, Aug 24, 2010 at 10:21 AM, Florent Monnier
> <monnier.florent@gmail.com> wrote:
>> Le lundi 23 août 2010 22:24:48, Romain Beauxis a écrit :
>>> Le lundi 23 août 2010 07:09:05, Florent Monnier a écrit :
>>>> an alternative method is to provide a string from ocaml to c then c fills
>>>> this  buffer, then you can save allocations by reusing the same buffer,
>>> 
>>>> see:
>>> This is a good idea but I would be a little bit suspicious about using
>>> "noalloc". Even if it works in your tests, this options is very delicate to
>>> use with the Gc, and may segfault in some cases.
>> 
>> could you develop? which cases?
> 
> IIRC noalloc calls release the ocaml lock. This means that the runtime
> can run at the same time as the c call and the GC migh collect your
> string or move it along. Quick rule if thumb is: you are allocating
> your string so you should not use noalloc.

That's not quite right; "noalloc" calls do not have the OCaml runtime in a functioning state at all since the instructions to set it up are not emitted by ocamlopt.

See [1] for Xavier Leroy's explanation on the matter, which I've quoted below:

> Yes.  Actually, it is forbidden to call any function of the OCaml
> runtime system from a noalloc function.
> 
> Explanation: ocamlopt-generated code caches in registers some global
> variables of importance to the OCaml runtime system, such as the
> current allocation pointer.
> 
> When calling a regular (no-"noalloc") C function from OCaml, these
> global variables are updated with the cached values so that everything
> goes well if the C function allocates, triggers a GC, or releases the
> global lock (enabling a context switch).
> 
> This updating is skipped when the C function has been declared
> "noalloc" -- this is why calls to "noalloc" functions are slightly
> faster.  The downside is that the runtime system is not in a
> functioning state while within a "noalloc" C function, and must
> therefore not be invoked.
> 
> The cost of updating global variables is small, so "noalloc" makes
> sense only for short-running C functions (say, < 100 instructions) like
> those from the math library (sin, cos, etc).  If the C function makes
> significant work (1000 instructions or more), just play it safe and
> don't declare it "noalloc".
> 

[1] http://caml.inria.fr/pub/ml-archives/caml-list/2010/03/2e386c384c04f4a424acc44a1fae3abd.en.html

-anil

Re: [Caml-list] caml_copy_string

[Romain Beauxis]

Le mardi 24 août 2010 10:22:48, Anil Madhavapeddy a écrit :
> That's not quite right; "noalloc" calls do not have the OCaml runtime in a
> functioning state at all since the instructions to set it up are not
> emitted by ocamlopt.
> 
> See [1] for Xavier Leroy's explanation on the matter, which I've quoted
> below:

That's right. Therefore, calling caml_copy_string in noalloc mode is probably 
not a good idea..


Romain

Re: [Caml-list] caml_copy_string

[Florent Monnier]

Le mardi 24 août 2010 17:35:15, Romain Beauxis a écrit :
> Le mardi 24 août 2010 10:22:48, Anil Madhavapeddy a écrit :
> > That's not quite right; "noalloc" calls do not have the OCaml runtime in
> > a functioning state at all since the instructions to set it up are not
> > emitted by ocamlopt.
> > 
> > See [1] for Xavier Leroy's explanation on the matter, which I've quoted
> > below:
> 
> That's right. Therefore, calling caml_copy_string in noalloc mode is
> probably not a good idea..

but no-one told to do so

there was a boxed value provided to the noalloc function,
but this function does not call caml_copy_string at all

-- 
Regards
Florent

Re: [Caml-list] caml_copy_string

[Romain Beauxis]

Le mercredi 25 août 2010 14:16:30, Florent Monnier a écrit :
> > That's right. Therefore, calling caml_copy_string in noalloc mode is
> > probably not a good idea..
> 
> but no-one told to do so
> 
> there was a boxed value provided to the noalloc function,
> but this function does not call caml_copy_string at all

That's right, sorry for that. 

However, the function that has noalloc still has one call to 
caml_string_length and also a memcpy that depends on the pointer associated to 
the string value (String_val).

It seems to me that in both case, the C function may be "tricked" by the Gc, 
for instance if it reorganizes the memory, leaving the original pointer given 
to the C function pointing to a space in memory that no longer contains the 
allocated string.

For such things as strings and more generally pointers linking to underlying 
structures in memory, I think it is wise to use CAMLparamX and register the 
value so that it is not touched by the Gc during the C call.

Also, you may want to try to register the value as global root. However, we've 
had problems with this approach as well, though I do not recall exactly why. 

Finally, even if you do not release the global lock in the function 
(caml_enter_blocking_section), still, calling for instance caml_string_length 
may trigger a Gc recollection.

Now, I may be wrong. In this case, I hope someone can correct me :)


Romain

Re: [Caml-list] caml_copy_string

[Goswin von Brederlow]

Florent Monnier <monnier.florent@gmail.com> writes:

> Le dimanche 22 août 2010 01:30:28, Jeffrey Barber a écrit :
>> Is there a way to get a string from C to OCaml without the caml_copy_string
>> function, or is there a version that doesn't copy the string?
>
> an alternative method is to provide a string from ocaml to c then c fills this 
> buffer, then you can save allocations by reusing the same buffer, see:

Even better as buffer, for when you have a C function that takes a while
and should use caml_enter/leave_blocking_section(), is a Bigarray. The
data part of a bigarray is allocated outside the GC heap and remains
fixed.

MfG
        Goswin