Browse thread
How to read different ints from a Bigarray?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2009-10-28 (15:17) |
From: | Sylvain Le Gall <sylvain@l...> |
Subject: | Re: How to read different ints from a Bigarray? |
On 28-10-2009, Goswin von Brederlow <goswin-v-b@web.de> wrote: > Sylvain Le Gall <sylvain@le-gall.net> writes: > >> Hello, >> >> On 28-10-2009, Goswin von Brederlow <goswin-v-b@web.de> wrote: >>> Hi, >>> >> >> Well, we talk about this a little bit, but here is my opinion: >> - calling a C function to add a single int will generate a big overhead >> - OCaml string are quite fast to modify values >> >> So to my mind the best option is to have a buffer string (say 16/32 >> char) where you put data inside and flush it in a single C call to >> Bigarray. >> >> E.g.: >> let append_char t c = >> if t.idx >= 64 then >> ( >> flush t.bigarray t.buffer; >> t.idx <- 0 >> ); >> t.buffer.(t.idx) <- c; >> t.idx <- t.idx + 1 >> >> let append_little_uint16 t i = >> append_char t ((i lsr 8) land 0xFF); >> append_char t ((i lsr 0) land 0xFF) >> >> >> I have used this kind of technique and it seems as fast as C, and a lot >> less C coding. >> >> Regards, >> Sylvain Le Gall > > This wont work so nicely: > > - Writes are not always in sequence. I want to do a stream access > too where this could be verry effective. But the plain buffer is > more for random / known offset access. At a minimum you would have > holes for alignment. > > - It makes read/write buffers complicated as you need to flush or peek > the string in case of uncommited changes. I can't do write-only > buffers as I want to be able to write a buffer and then add a > checksum to it in my application. The lib should not block that. > I was thinking to pure stream. It still stand with random access but you don't get a lot less C function call. You just have to write less C code. > > I also still wonder how bad a C function call really is. Consider the > case of writing an int64. > > Directly: You get one C call that does range check, endian convert and > write in one go. > > Bffered: With your code you have 7 Int64 shifts, 8 Int64 lands, 8 > conversions to int, at least one index check (more likely 8 to avoid > handling unaligned access) and 1/8 C call to blit the 64 byte buffer > string into the Bigarray. Not at all, you begin to break your int64 into 3 int (24bit * 2 + 16bit) and then 7 int shift, 8 int land. You can even manage to only break into 1 or 2 int. And off course, you bypass index check. > PS: Is a.{i} <- x a C call? Yes. Regards, Sylvain Le Gall