Dylan's future 
Author Message
 Dylan's future


   I think one thing people are looking for in this argument thread is a
   way to specify to the Dylan implementation that certain data should be
   stored immediately, rather than by reference.  Dylan already does this
   implicitly for objects that are (1) immutable, (2) have identity
   independent of address, and (3) fit in a single Q.  Presumably the
   third restriction could be relaxed if the typing of the "container"
   (slot, collection element, ...) is sufficiently specified so as to
   know how much space should be allocated.  Perhaps the second could be
   relaxed if the programmer makes a promise to the language system (via
   declaration) that he does not care about the identity of the object or
   that the object has no identity other than by virtue of it being a
   member of the collection it is stored in for example.  Perhaps the
   programmer could merely provide a method on == for some such objects.

To fully relax (3) you the procedure call/return conventions need to know the
width of an object. Stalin, a compiler for Scheme that is available free from
my home page,

- automatically determines which objects are immutable [(1) above] and which
  are not, without any declarations and

- automatically determines which objects have identity independent of address
  [(2) above] (i.e. which objects are never mutated and never compared using
  EQ?), without any declarations.

And since can generate custom procedure call/return conventions on a per
procedure/procedure-call basis it unboxes *all* fixed-size immutable data:
fixnums, characters, floats, doubles, complex numbers, pairs, and structures.
It does this both for call/return and for flattening nested data.

    Jeff (home page http://www.*-*-*.com/ ~qobi)
--

    Jeff (home page http://www.*-*-*.com/ ~qobi)



Wed, 14 Apr 1999 03:00:00 GMT  
 Dylan's future


   To fully relax (3) you the procedure call/return conventions need to know
   the width of an object. Stalin, a compiler for Scheme that is available
   free from my home page,

   - automatically determines which objects are immutable [(1) above] and
     which are not, without any declarations and

   - automatically determines which objects have identity independent of
     address [(2) above] (i.e. which objects are never mutated and never
     compared using EQ?), without any declarations.

   And since can generate custom procedure call/return conventions on a per
   procedure/procedure-call basis it unboxes *all* fixed-size immutable data:
   fixnums, characters, floats, doubles, complex numbers, pairs, and structures.
   It does this both for call/return and for flattening nested data.

That sounds impressive. If it works as well as you say, then a Stalin-like
compiler for Dylan could be usable for high performance computing without
any additional type information added to the language. I wonder if Dylan
compilers will ever have such agressive optimization.

Do you have a document which describes how your compiler works? I could only
find the source on your page.

-- Brian



Fri, 16 Apr 1999 03:00:00 GMT  
 Dylan's future

    From: qobi (Jeffrey Mark Siskind)
    Date: 26 Oct 1996 04:28:15 GMT


       I think one thing people are looking for in this argument thread is a
       way to specify to the Dylan implementation that certain data should be
       stored immediately, rather than by reference.  Dylan already does this
       implicitly for objects that are (1) immutable, (2) have identity
       independent of address, and (3) fit in a single Q.  Presumably the
       third restriction could be relaxed if the typing of the "container"
       (slot, collection element, ...) is sufficiently specified so as to
       know how much space should be allocated.  Perhaps the second could be
       relaxed if the programmer makes a promise to the language system (via
       declaration) that he does not care about the identity of the object or
       that the object has no identity other than by virtue of it being a
       member of the collection it is stored in for example.  Perhaps the
       programmer could merely provide a method on == for some such objects.

    To fully relax (3) you the procedure call/return conventions need to know the
    width of an object. Stalin, a compiler for Scheme that is available free from
    my home page,

    - automatically determines which objects are immutable [(1) above] and which
      are not, without any declarations and

    - automatically determines which objects have identity independent of address
      [(2) above] (i.e. which objects are never mutated and never compared using
      EQ?), without any declarations.

    And since can generate custom procedure call/return conventions on a per
    procedure/procedure-call basis it unboxes *all* fixed-size immutable data:
    fixnums, characters, floats, doubles, complex numbers, pairs, and structures.
    It does this both for call/return and for flattening nested data.

Qobi's Scheme compiler is pretty damned impressive, in my opinion.
However, as far as I understand, it is heavily based on "batch
compiling" the _entire_ program.  The Dylan language requires
compilation on a per-library basis (where the final program is
composed of a set of linked-up libraries), but it seems to me that
Stalin would, in effect, require an FFI barrier between each
separately compiled library.  The performance impact of this is not
clear to me, but I bet it's not small.



Sat, 17 Apr 1999 03:00:00 GMT  
 Dylan's future



Quote:
>Qobi's Scheme compiler is pretty damned impressive, in my opinion.
>However, as far as I understand, it is heavily based on "batch
>compiling" the _entire_ program.  The Dylan language requires
>compilation on a per-library basis (where the final program is
>composed of a set of linked-up libraries)....

  This is where the sealing constructs play a very important role. For
  if something is sealed then you have seen the "entire" program for
  certain inferences you might wish to make. Couple this with inert domains
  (allow reuse of the superclasses, but seal off this specific path) and the
  intralibrary optimizations should be significant.

  Since the libraries (and modules) you need only process all down to
  to the current one to and pass along the inference information from above
  the closed world is essential known for those classes, functions that can't
  be extended anymore.

  The "open" constructs in the library won't be helped very much.
  [ Perhaps a linker assoicated optimizer can fix these up a bit...]

  Anotherdownside is that your back into C,C++ batch mode edit,compile,run
  ...or.. you keep lots of dependancy and incremental anaylsis info around.
  However, sifting through all of that could take as long as simply
  recompiling that library under certain circumstances.

Quote:
>Stalin would, in effect, require an FFI barrier between each
>separately compiled library.  The performance impact of this is not
>clear to me, but I bet it's not small.

  Perhaps this would only invovle objects moving in/out of the
  heap as you crossed library boundaries (which is sort of FFI I guess).

  And if speed is of the absolute essence then a WPO (whole program
  optimizer) could swallow the whole program.... this may be nontrival
  in time/resources. ( any dynamic calls that create new clases and/or
  modifies generic methods is likely to make the WPO "unhappy" ).

 P.S. the other problem is that I doubt there are very many 250,000 line
        Scheme programs ( with the implication that with increase in line
        numbers comes increase in types/classes/procedures ) that can be
        thrown at Stalin to see what happens...
        Is the type inference  time/space linear with respect to these
        constructs or polynomial or ...eeekkk... exponential?
        Many type inferencing approaches explode on large polymorphic
        programs.

--

Lyman S. Taylor              "We are Microsoft.  

                                  resistance is futile.  
                                        Prepare to be assimilated."
                                .sig seen while netsurfing the Internet.



Sat, 17 Apr 1999 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Dylan's future

2. Dylan's Future?

3. Design Patterns (was Re: Dylan's Future?)

4. Dylan's Future? / How to save Dylan at this late...

5. (fwd) harlequin's dylan-corba mailing list switching to MIT's info-dylan

6. Future of Dylan?

7. Future of Dylan?

8. Future of Dylan

9. Future of Dylan?

10. Future of Harlequin Dylan

11. About the future of Dylan

12. XPOST: About the future of Dylan

 

 
Powered by phpBB® Forum Software