This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gsl Development Query


Well, Gerard gave me a really long answer/comment and I appreciate it. I
may have some reply on other parts of it in a few days but for now I will
stick with the first couple of paragraphs since that is what interests me
mostly.

First I would like to point out some differences between what I perceive
you are doing and what VSIPL did. VSIPL is a specification. The intent from
the beginning was to get multiple vendors to supply their own optimized
VSIPL libraries for their own product. What I perceive GSL is doing is a
single library, not a specification. You don't expect anybody else to take
your document and write another version of GSL, at least I don't think you do.

So when VSIPL meets we have several vendors who participate and are
interested in not doing anything they don't need to in order to keep their
implementation cost down. So a lot of functionality you have in GSL was not
put in VSIPL. So I guess what I want is to have a clean interface between
VSIPL and GSL so that I can recover some of the functionality that the
vendors did not want. 

>> Part of the specification
>> is the interface which allows people to bring data into or export data from
>> VSIPL.
>
>This is an important point. It may be that data interchange
>is issue number one for this kind of library. Certainly I
>feel that it is the number one issue for vector/matrix/etc
>implementations in numerical libraries. No library can
>afford to act as an island fortress. As a general comment,
>I think that generic programming (which for all practical
>purposes means algorithm templates in C++) offers the

Just a warning. I don't really know very much about C++ and I like C a lot.
I can see a need to learn more about C++ and from time to time make an
effort, but so far I have not been convinced it is better than C. When I
actually learn it no doubt I will come around.

>best hope at this point for freeing ourselves from
>the details of data representations, in the wide sense.
>I see no real solution, when restricted to the context
>of a C library like GSL; we just have to find the right
>compromise, given the right set of restrictions on
>the problem domain.
>

Well I am not sure what you are talking about below, so I will go into some
detail as to how  VSIPL would interface to GSL. Right now I think VSIPL
should interface fine to GSL, so hopefully if you understand a little more
you wont change something to screw it up.
 
>By the way, I looked at the VSIPL draft to see what
VSIPL 1.0 is actually final now. It is available on the Documents page of
the VSIPL site. On that page you will find something called, I think, "The
basics requirements document". You might want to read that instead. It is
short, and covers most of how VSIPL is supposed to work. Depending on when
you read the Draft VSIPL may have changed a lot from what you read.

>you were doing about this, but I wasn't sure what
>the appropriate section was. From what I did see,
>I guessed that your block/view separation was the
>key to data interchange, allowing conformant views
>to be layered over imported data blocks. Is this
>what you meant, or did you have something more
>specific in mind?
>

First of all in VSIPL a view is always bound to a block. The blocks in GSL
just seem to be a place to keep your memory storage until your ready to
destroy it. In VSIPL blocks are more important. To find the begining of
your view in GSL you store a pointer to the beginning of data. In VSIPL we
store an offset into the block. The vendor may do other stuff under the
covers, but what the user sees is an offset. 

How a block in VSIPL is implemented is vendor dependent, and the blocks are
incomplete typedefs. For instance what a user sees in the vsipl header file
is something like

struct vsip_blockobject_f;
typedef struct vsip_blockobject_f vsip_block_f;

for a real block of type float. The vendor has a complete type definition,
of course, but he does not give that to the user. What the user gets is a
set of VSIPL defined functions to create and manipulate the block. "Views"
(vector views, matrix views) on the block are treated the same way.

struct vsip_vviewobject_f;
typedef struct vsip_vviewobject_f vsip_vview_f;

So to create a vector you could do

vsip_block_f *a_block = vsip_blockcreate_f(N,VSIP_MEM_NONE);
vsip_vview_f *a_view = vsip_vbind_f(a_block,0,1,N);

So a_view is a vector of length N, stride 1, and offset into the block of 0.

Since a_view is nice and compact we could have done the same thing with a
convenience function
vsip_vview_f *a_view = vsip_vcreate_f(N,VSIP_MEM_NONE);

Now the problem is that all this stuff is opaque. Vendors want to own the
data. Memory management was a big problem for the forum in the beginning,
and the fix was to abstract memory away from the hardware by using the
block concept along with abstract data types and incomplete typedefs.

So how does the user get data in and out of VSIPL? Well we defined some
special functions to do this. By the way, for the stuff above there is no
legal way in VSIPL for a user to get a pointer to the actual data storage
for the block.

What VSIPL does is define a blockbind function. What blockbind does is to
associate some regular memory with a VSIPL block. Then both VSIPL and the
user can get to that memory. However VSIPL insists on owning any memory it
might use, so we added functions to admit the block (and memory) to VSIPL
and a release function to give ownership of the data back to the user.
Admit and release are important. VSIPL does not necessarily use the user
memory in the expected way. It may not use it at all. The purpose of admit
and release is to force data consistency between the block and the memory
during a state transition.

So if you wanted a gsl vector, and a vsipl vector on the same data space
you could do (I don't know much about gsl so there may be an error here)

gsl_vector *a_gsl_vview = gsl_vector_alloc(N);
vsip_block_d *a_vsipl_block = vsip_blockbind_d(
        a_gsl_vview->block->data, N, VSIP_MEM_NONE);
vsip_vview_d *a_vsipl_vview = vsip_vbind_d(a_vsipl_block, 0, 1 , N);

To make a_vsipl_vview usable by VSIP (and make sure the data agrees with
a_gsl_vview) I would do

vsip_blockadmit_f(a_vsipl_block,VSIP_TRUE);

Once VSIPL is done and I want to do something with gsl (I should not use
the GSL vector while the associated data is admited) I would do
vsip_blockrelease_f(a_vsipl_block,VSIP_TRUE);


NOTE: It is not a mistake when I attach VSIPL to the data in the GSL block
instead of the GSL view. You don't want the same data segment attached to
two different VSIPL blocks. This is one of the problems I have with the way
GSL did this, but it appears that you can with a little care create
matching gsl and VSIPL views for any number of subviews on the original
data set. VSIPL uses an offset to do this. VSIPL views are more flexible
than GSL views, so not any VSIPL view is mapable to a GSL view, but with
knowledge of both libraries it seems to be pretty reasonable to use them
together, at least at first glance.

So, by now your probably really confused. I just hope I wasn't. If you have
any questions let me know.

                 Randy Judd.
       



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]