From 1d2d6fd4c7b02ea4ee9ff4d3324da0e73b88957e Mon Sep 17 00:00:00 2001
From: David Hilvert <dhilvert@auricle.dyndns.org>
Date: Sun, 11 Oct 2009 12:45:37 +0000
Subject: [PATCH] bugs: Refine further the conception of the proposed
 file-based shared-code approach.

Ditz-issue: d0797684fabf05af24e73639e0ce5e30a145a3c5
---
 ...e-d0797684fabf05af24e73639e0ce5e30a145a3c5.yaml | 76 ++++++++++++++++++++++
 1 file changed, 76 insertions(+)

diff --git a/bugs/issue-d0797684fabf05af24e73639e0ce5e30a145a3c5.yaml b/bugs/issue-d0797684fabf05af24e73639e0ce5e30a145a3c5.yaml
index 901f3ea..6c33dbd 100644
--- a/bugs/issue-d0797684fabf05af24e73639e0ce5e30a145a3c5.yaml
+++ b/bugs/issue-d0797684fabf05af24e73639e0ce5e30a145a3c5.yaml
@@ -127,4 +127,80 @@ log_events:
     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.
 git_branch: 
-- 
2.11.4.GIT