From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id C1E95BC37 for ; Wed, 28 Oct 2009 16:38:03 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0CAL4B6ErU4368kWdsb2JhbACBT5lwAQEBAQkLCgcTA744AoQ9BIFh X-IronPort-AV: E=Sophos;i="4.44,640,1249250400"; d="scan'208";a="49407536" Received: from moutng.kundenserver.de ([212.227.126.188]) by mail4-smtp-sop.national.inria.fr with ESMTP; 28 Oct 2009 16:38:02 +0100 Received: from office1.lan.sumadev.de (dslb-094-219-209-052.pools.arcor-ip.net [94.219.209.52]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0M4Vnk-1MFlOn1SIO-00ybBg; Wed, 28 Oct 2009 16:38:01 +0100 Received: from [192.168.5.104] (dslb-094-219-209-052.pools.arcor-ip.net [94.219.209.52]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id E2DA4C0E8E; Wed, 28 Oct 2009 16:38:00 +0100 (CET) Subject: Re: [Caml-list] How to read different ints from a Bigarray? From: Gerd Stolpmann To: Goswin von Brederlow Cc: caml-list@inria.fr In-Reply-To: <87eiond3of.fsf@frosties.localdomain> References: <87eiond3of.fsf@frosties.localdomain> Content-Type: text/plain Date: Wed, 28 Oct 2009 16:43:00 +0100 Message-Id: <1256744580.4181.54.camel@flake.lan.gerd-stolpmann.de> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+AZN6wBmqJ4PKIQ0oeWp6SzjCr5SrIGzfRCEJ 8VvEjZkmYvxtFY2vqq7zXg9+smfx0U1wzDpXlfaNkqnM1V0Kg7 oU8FrRprHIYYM7IuOAzOA== X-Spam: no; 0.00; bigarray:01 gerd:01 stolpmann:01 gerd:01 buffer:01 elt:01 bigarray:01 buf:01 buf:01 elt:01 endian:01 byte:01 endian:01 elegantly:01 stubs:01 Am Mittwoch, den 28.10.2009, 14:54 +0100 schrieb Goswin von Brederlow: > Hi, > > I'm working on binding s for linux libaio library (asynchron IO) with > a sharp eye on efficiency. That means no copying must be done on the > data, which in turn means I can not use string as buffer type. > > The best type for this seems to be a (int, int8_unsigned_elt, > c_layout) Bigarray.Array1.t. So far so good. > > Now I define helper functions: > > let get_uint8 buf off = buf.{off} > let set_uint8 buf off x = buf.{off} <- x > > But I want more: > > get/set_int8 - do I use Obj.magic to "convert" to int8_signed_elt? > > And endian correcting access for larger ints: > > get/set_big_uint16 > get/set_big_int16 > get/set_little_uint16 > get/set_little_int16 > get/set_big_uint24 > ... > get/set_little_int56 > get/set_big_int64 > get/set_little_int64 > > What is the best way there? For uintXX I can get_uint8 each byte and > shift and add them together. But that feels inefficient as each access > will range check and the shifting generates a lot of code while cpus > can usualy endian correct an int more elegantly. > > Is it worth the overhead of calling a C function to write optimized > stubs for this? > > And last: > > get/set_string, blit_from/to_string > > Do I create a string where needed and then loop over every char > calling s.(i) <- char_of_int buf.{off+i}? Or better a C function using > memcpy? > > What do you think? A C call is too expensive for a single int (and ocamlopt). The runtime needs to fix the stack and make it look C-compatible before it can do the call. Maybe it's ok for an int64. Can you ensure that you only access the int's at word boundaries? If so, it would be an option to wrap the same malloc'ed block of memory with several bigarrays, e.g. you use an (int, int8_unsigned_elt, c_layout) Bigarray.Array1.t when you access on byte level, but an (int32, int32_unsigned_elt, c_layout) Bigarray.Array1.t when you access on int32 level, but both bigarrays would point to the same block and share data. This is trivial to do from C, just create several wrappers for the same memory. The nice thing about bigarrays is that the compiler can emit assembly instructions for accessing them. Much faster than picking bytes and reconstructing the int's on the caml side. However, if you cannot ensure aligned int's the latter is probably unavoidable. Btw, I would be interested in your aio bindings if you do them as open source project. Gerd -- ------------------------------------------------------------ Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------