[SAGA-RG] Python bindings: Buffer class issue

Andre Merzky andre at merzky.net
Wed Nov 18 14:49:52 CST 2009


> A dedicated Buffer class MAY be added to a new version of the bindings
> for Python 3.x. Reasons:

MAY -> SHOULD ?

Otherwise: +1

A.


Quoting [Mathijs den Burger] (Nov 18 2009):
> Subject: Re: [SAGA-RG] Python bindings: Buffer class issue
> From:    Mathijs den Burger  <mathijs at cs.vu.nl>
> To:      Andre Merzky        <andre at merzky.net>
> Cc:      Manuel Franceschini <livewire at koltern.com>, SAGA-RG <saga-rg at ogf.org>
> Date:    Wed, 18 Nov 2009 14:04:56 +0100
> 
> On Sat, 2009-11-14 at 12:04 +0100, Andre Merzky wrote:
> 
> > > The real question is: which use cases are we trying to optimize? What
> > > will SAGA Python apps do with binary data?
> > 
> > The primier use asking for optimized I/O on streams and files are
> > visualization use cases (you should know *those* use cases, right?
> > ;-)  So, an application is repeatedly readong a couple of megabyte
> > or so from a stream or a file, into a memory buffer, at say 2*30fps,
> > to run some algorithm on the data (say isosurfacer).  
> > 
> > Now, in the simple case your kernel allocates memory for the read
> > you request, and reads data into that memory.  Later, that data is
> > copied into your application memory so your app can access the data.
> > 
> > The buffer object allows to allocate the memory in the application,
> > and to pass the buffer down to the kernel, so that it can read data
> > directly into the buffer (zero copy: no need to copy it again).
> >
> > I have no idea how prevalent that use case and similar ones are for
> > the python community we are targeting, so its very hard to argue for
> > or against that optimization.  Zero Copy is in general useful in
> > other use cases, too, but again, it is hard to guesstimate the gain
> > without any specific use case to  discuss.
> 
> OK, time to wrap up. I propose to NOT include a 'Buffer' class in the
> SAGA bindings for Python 2.x (i.e. >= 2.2). Instead of buffers we'll use
> strings. Reasons:
> 
> 1. it is hard to express in Python 2.x (no native 'byte' type, no
> 'readinto' with a buffer to a pointer, etc.)
> 
> 2. current users of the C++ Python wrapper do not seem to miss it
> 
> 3. the number of use cases for buffers is fairly low (GFD.70 and GFD.71
> both contain the word 'buffer' only once!)
> 
> 4. it requires less changes to the C++ Python wrapper code
> 
> 
> A dedicated Buffer class MAY be added to a new version of the bindings
> for Python 3.x. Reasons:
> 
> 1. Python 3.x does have a native 'byte' type and methods like 'readinto'
> 
> 2. New users may desire it
> 
> 
> Sounds reasonable?
> 
> best,
>  Mathijs
> 
> 



-- 
Nothing is ever easy.


More information about the saga-rg mailing list