bugs: Don't require client knowledge of flattened representations.

[libale.git] / bugs / issue-d0797684fabf05af24e73639e0ce5e30a145a3c5.yaml

--- !ditz.rubyforge.org,2008-03-06/issue 
title: "Split both data and code into two sections (e.g., by file separation): common (or shared) and client (i.e., host)."
desc: |-
  Rather than pursuing the current approach of having host code incrementally (or
  so) feeding source into an aggregate of compilable text, instead isolate the
  shared part of code from that specific only to the client, so that this shared
  part can be processed (at compile time) into representations appropriate for
  both client (i.e., OpenCL "host") and any compute servers (i.e., OpenCL
  devices).
  
  In this way, the question of exactly how inclusions and compilation (for
  processing by OpenCL) should occur can be worked out independently from the
  normal processes of declaring data structures and code.
  
  A possible drawback to the above might be limiting the extensibility into
  further clients of this library (either client libraries or end-user
  applications), but it should still be possible to provide for this while
  preserving the above separation internally (e.g., by offering routines for this
  purpose).
  
  Another way of viewing this is that the fundamental functionality available
  within and outside of the library need not change, but that source might be
  rearranged to allow for a more straightforward representation for the sake of
  internal implementation of the library, possibly with external benefits as well
  (e.g., if the API header were adjusted to expose a limited subset API for use
  with compute servers (devices)).
type: :task
component: libale
release: 0.0.0
reporter: David Hilvert <dhilvert@auricle.dyndns.org>
status: :unstarted
disposition: 
creation_time: 2009-10-10 23:26:08.168811 Z
references: []

id: d0797684fabf05af24e73639e0ce5e30a145a3c5
log_events: 
- - 2009-10-10 23:26:47.592939 Z
  - David Hilvert <dhilvert@auricle.dyndns.org>
  - created
  - Add task for splitting between common (client and compute server) and client-specific code.
- - 2009-10-10 23:44:24.896284 Z
  - David Hilvert <dhilvert@auricle.dyndns.org>
  - commented
  - |-
    Note that exposing a limited subset API for use with compute devices might
    well be more properly viewed as a bug than as a feature (although it could be
    the latter).  In any case, it is likely that this will occur for the convenience
    of implementation, since the types (or some subset) will be needed on the side of
    the compute server, and adding #ifdefs (or #ifs or so) to the header is likely
    the most convenient manner of accomplishing this.
- - 2009-10-10 23:57:18.054878 Z
  - David Hilvert <dhilvert@auricle.dyndns.org>
  - commented
  - |-
    Other resources to look at in this area (client/server separation), but
    probably for implementations far more general than currently appearing within
    Libale, would include CORBA at least, and possibly things such as dbus, to the
    extent that they specify client/server relationships.  (X might also be
    relevant, especially as it predominantly involves such relationships within the
    same machine.)  One area to look at, for example, would be the IDL of CORBA.
    It should be noted, however, that since everything within Libale is currently
    implemented internally in C, all of the above would probably be overkill at the
    moment.  In the case of CORBA, there is a data parallel spec that could be
    looked at (again, probably for something more general than would be needed
    here).
    
    All of the above might be useful were there to be interest in directly
    accessing the Libale server side (OpenCL compute contexts) from external
    libraries or applications.
    
    Relevant links might include:
    
    http://www.omg.org/technology/documents/formal/data_parallel.htm
    http://dbus.freedesktop.org/doc/dbus-faq.html
    http://developer.gnome.org/doc/guides/corba/html/book1.html
- - 2009-10-11 01:02:22.744954 Z
  - David Hilvert <dhilvert@auricle.dyndns.org>
  - commented
  - |-
    For specifics of OpenCL capabilities for the purposes of splitting code, the
    spec would be the thing to reference.  E.g., something will have to be devised
    for sorting and aggregating sources into a program, which could probably be
    done explicitly via a separate include file (much as ALE's d2.cc and d3.cc
    aggregate namespace files in a manner recognizing dependencies).  Beyond this,
    nothing new should be incurred from the proposed change.  (E.g., recursion is
    not supported, but this introduces no new obstacles under the proposed
    approach.)  Latest spec as of 16 May 2009 is here:
    
    http://www.khronos.org/registry/cl/specs/opencl-1.0.43.pdf
    
    (For a slide presentation of why GPU and compiler technology don't always mesh
    very well, the following might be of interest (although much of this will
    ideally be addressed by OpenCL):
    
    http://www.cs.unc.edu/Events/Conferences/GP2/slides/Cooper.pdf
    
    The following is a much better overview of current technologies:
    
    http://www.hpccommunity.org/blogs/bearcat/multi-core-gpu-background-77/
    
    Unfortunately, none of the above address the issue of sharing of data
    structures or objects in a constructive manner.  Fortunately, all seem to
    suggest OpenCL (or something like it) as the most feasible current approach.
- - 2009-10-11 04:23:45.681282 Z
  - David Hilvert <dhilvert@auricle.dyndns.org>
  - commented
  - |-
    Consider that, in addition to client-specific code, and shared code, it would
    probably be worthwhile to also provide for server-specific code (i.e., code
    specific to the compute device), as various idioms appropriate for the compute
    device (e.g., 'kernel' and other attributes, OpenCL built-in functions, etc.)
    may not be appropriate for compilation targeted to the client (OpenCL host).
- - 2009-10-11 04:34:21.081366 Z
  - David Hilvert <dhilvert@auricle.dyndns.org>
  - commented
  - |-
    Note that separation of client, server, and common code could be achieved by
    directory (e.g., server/, client/, common/), filename component (e.g., -server,
    -client, -common), or by preprocessor conditionals (as will likely be done for
    the API header file), among other methods.
    
    Other names for labeling server code might include 'kernels', 'device'
    (which?), or 'cl'; other names for client code might include 'host' (after
    OpenCL).
    
    The client/server terminology seems to follow the X Window System model, which
    might be appropriate, especially if computation is eventually distributed over
    cluster or grid platforms.
- - 2009-10-11 12:45:25.752974 Z
  - David Hilvert <dhilvert@auricle.dyndns.org>
  - commented
  - |-
    As a refinement to the above suggestion, consider the following:
    
    If maintenance of a separate file for explicitly indicating dependencies among
    sources is necessary (as it would be for the proposed shared-code approach
    under a library, such as OpenCL, that does not currently provide for separate
    translation units), then such dependencies could also be indicated by calling a
    sequence of initializations, one per file, according to the method of
    incremental aggregation currently conceived (via ale_eval or equivalent).  The
    most obvious differences in implementation between the current approach (of
    aggregation of code text at runtime) and the above-proposed approach (of
    aggregation of code text at compile time) is that in the current approach, code
    sharing is limited mostly to data structures (via the current macro
    definitions), as no provision is currently made for sharing other kinds of
    code, whereas the above-proposed approach would immediately provide for
    complete sharing (via common files).
    
    Unfortunately, it's not immediately clear that the above-proposed approach is
    better than an approach that does not share code.  In particular, the current
    choice of data-type sharing over code sharing seems, on the face of it, a good
    one.  Much of the code between host (or client) and device (or server) domains
    is not naturally shared, whereas data types can be.  To establish a large
    shared body of code would require that a fair amount of code be usable in both
    domains.  (E.g., simple routines for accessing data in a canonical way, or
    preserving some invariant during data modification, might be appropriate for
    sharing.) If, on the other hand, the degree of sharing is small, then adding a
    new structure of managing sharing through files might be more complex than
    necessary.  Furthermore, if compilation of server code occurs at run-time (as
    may be common under most OpenCL installations), then excessive sharing of code
    might impose a run-time penalty.
    
    Given this, the best argument for sharing of code via files might be a more
    natural syntax for data structure definition.  In particular, it would no
    longer be necessary to define these via the macro processor.  Furthermore, the
    sorts of lightweight operations (simple access and modification) indicated
    above would now be possible.  Another advantage to having a separate file for
    shared code would be avoiding the need for separate consideration of each data
    structure (or each macro declaration).
    
    Instead of something like this:
    
    foo.c:
    
    ALE_...(... data_struct_1 ...)
    ALE_...(... data_struct_2 ...)
    ALE_...(... data_struct_3 ...)
    
    void init_foo() {
        ale_eval( ... data_struct_1 ... data_struct_2 ... data_struct_3 ...)
    }
    
    bar.c:
    
    init_foo();
    
    We get the more natural representation:
    
    foo-shared.c:
    
    struct N1 { ... };
    struct N2 { ... };
    struct N3 { ... };
    
    libale-server.c:
    
    Where Nx may include a macro element (e.g., ALE_...(data_struct_1)), and where
    libale-server may ultimately be processed, if desired, by a call to ale_eval().
    
    Hence there is a consolidation of data structure definitions on the server
    side, in addition to provisions for code sharing.  Maintaining a wrapped
    runtime option for structure definition (via ale_eval or otherwise) would
    probably be good, however, for the purposes of supporting client code or client
    libraries.
- - 2009-10-11 13:10:51.957739 Z
  - David Hilvert <dhilvert@auricle.dyndns.org>
  - commented
  - |-
    Note that the empty line following 'libale-server.c' in my most recent comment
    should have read '#include "foo-shared.c"'.
- - 2009-10-11 14:28:17.840394 Z
  - David Hilvert <dhilvert@auricle.dyndns.org>
  - commented
  - |-
    Consider that, if preprocessor macros were used for implementing the sorts of
    methods for accessing and modifying data described, then it should be possible
    to implement these in a manner efficient for both client and server
    implementations, hence strengthening the case for a body of shared code (in
    addition to shared data types) between client and server.
    
    (Note from examples in the OpenCL spec that preprocessor conditionals can be
    used a fair amount for kernel definitions.  This sort of code is probably the
    sort that would not be good for sharing with the client.  On the other hand, a
    kernel could efficiently make use of macros defined in a separate, shared
    file.)
- - 2009-10-11 15:27:41.066320 Z
  - David Hilvert <dhilvert@auricle.dyndns.org>
  - commented
  - |-
    Consider that the most straightforward approach to partition and naming of
    files would probably be the following:
    
    Create a new header file for source files currently defining shared data types,
    and move the structure part of the definition into the header file.  Header
    file naming follows the usual C convention, so that, e.g., image.c will now
    have an associated file image.h.  (Since certain data type details, such as
    memory allocation, are currently executed only by the host, these need not be
    moved.)  One benefit of such division may be relieving src/libale.h of its duty
    as a repository of miscellaneous definitions.
    
    Name files containing code specific to a compute device with the qualifier -cl,
    so that, e.g., image.c gains a counterpart image-cl.c.  (This bit is fairly
    obvious, and not immediately relevant to the question of file separation of
    shared code.)  Handling of the transfer of .h and -cl.c files to the OpenCL API
    will likely occur through a process including compile-time translation into a
    form allowing use with either direct OpenCL API calls or (more likely) a Libale
    intermediate call (e.g., ale_eval), as well as the actual execution of such
    calls at runtime.  Hence, a further translation step beyond standard C
    preprocessing should probably be added at compile time, perhaps very simple
    (e.g., converting a file to a quoted C string, and either including this string
    within some new named function or assigning it to a variable that can then be
    referenced by other library code).
- - 2009-10-11 15:55:54.298156 Z
  - David Hilvert <dhilvert@auricle.dyndns.org>
  - commented
  - |-
    Consider that, since things like ale_eval definitions might occur within code
    evaluated at runtime (e.g., defining MAP_PIXEL and such for image code), such
    code could either be stored separately (e.g., image-ale.c separate from
    image-cl.c), or the two could be stored together (e.g., in the case that the
    file will be processed by ale_eval; an appropriate name might be image-rt.c,
    for runtime).
    
    In the best of scenarios, it will be possible to implement MAP_PIXEL directly
    in the OpenCL language, so that the above is not necessary.  If this is not
    sufficient, however, some additional layer (e.g., m4 or a similar processor)
    might be used by ale_eval.
- - 2009-10-17 01:31:26.090103 Z
  - David Hilvert <dhilvert@auricle.dyndns.org>
  - commented
  - |-
    Consider the following fairly straightforward argument in favor of the proposed
    .h (header) separation, in addition to .c source separation:
    
    As previously conceived, the only separation in files for the CL program would
    be as a .c file, with, e.g., structure definition occurring via variables or
    functions generated by macros.  The revised approach (using an additional .h
    file) may be seen as more convenient, as macros are not required for this, as
    outlined in earlier comments.  This is, however, the lesser concern at the
    moment.
    
    More to the point, compilation is currently failing on the src/align.c file, with
    first error occurring at a structure making reference to an elem_bounds_t type 
    from the transformation class.  In order to reference this structure from align.c,
    an inclusion of some sort will be necessary.
    
    Preserving the current file structure, options would be either of include/ale.h
    and src/libale.h, but neither of these are ideal.  Better would be to associate
    the structure definition more tightly; else, structure definitions would be
    distributed somewhat haphazardly between these files and the .c files according
    to whether they were used elsewhere.
    
    (Note that there are currently efforts for automatic parallelization within
    GCC, under the Graphite framework, but that efforts toward integration with an
    OpenCL backend are apparently not being made at the moment.  One possibility
    would be to use either something similar to OpenMP (as Graphite may ? ), an
    extension to this, or a separate syntax (as I had suggested on the mailing
    list) to indicate areas that should be parallelized for an OpenCL backend
    specifically.)
    
    (A further alternative would be to await a hardware (e.g., Larrabee) or
    software (e.g., OpenCL alternative or successor) solution more suited to
    automatic methods.  Binary translation based on QEMU might be one very general
    possibility, but probably more challenging than even a compiler [e.g., GCC]
    approach, the advantage of these over the current approach being largely
    cleanness and generality, which might lead to greater maintainability in the
    long run.)
- - 2009-10-17 02:28:18.322606 Z
  - David Hilvert <dhilvert@auricle.dyndns.org>
  - commented
  - |-
    The following might be worth looking at:
    
    http://portal.acm.org/citation.cfm?id=1504194
- - 2009-10-18 01:36:20.217266 Z
  - David Hilvert <dhilvert@auricle.dyndns.org>
  - commented
  - |-
    Rather lengthy discussion regarding OpenCL and OpenMP can be found here:
    
    http://forums.amd.com/forum/messageview.cfm?catid=390&threadid=119644
    
    This discussion references the earlier-linked paper.  There is also an
    (apparently) proprietary compiler linked from this discussion having a CUDA
    (also proprietary) back-end, but nothing obvious currently available with an
    OpenCL back-end, or otherwise suitable as a standard replacement for direct
    OpenCL coding.
- - 2009-10-20 14:41:03.658982 Z
  - David Hilvert <dhilvert@auricle.dyndns.org>
  - commented
  - |-
    Note that kernel and hardware mechanisms (esp. page faulting and caching) are
    probably the correct approach to pointer sharing, and that it would probably be
    best in the long run for either (a) GPUs to adopt a hardware memory management
    approach, or (b) GPUs to be sufficiently integrated with CPUs such that memory
    management can be shared between the two.  (One might think that Intel would
    capitalize on this idea sooner rather than later -- they seem to be postponing
    this until Larrabee finally ships instead of planning something sooner; despite
    their existing integrated graphics line, they have as yet made no annoucements
    on GPGPU advances taking advantage of more uniform memory management between
    the processors.)
    
    Given all of the above, while a compiler solution is likely possible to some
    extent, and might work for ALE, the difficulty of working out special cases
    such as void pointers and casting suggests that finding a long-term maintainer
    for such a solution within the GCC maintainer community might be a bit
    difficult.  (Where void pointers and casting are exactly the sorts of things
    that hardware facilities could trivially cope with, but compiler features might
    struggle with.)  For now, management of pointers within Libale via the OpenCL
    API might continue to be acceptable, but a hardware solution should probably be
    looked for in the long run.
git_branch: