CLIM mail archive
[Prev][Next][Index][Thread]

Re: reducing time overhead of text display (in 1.1)

  To: kanderso@BBN.COM, SWM@stony-brook.scrc.symbolics.com, clim@BBN.COM, 
      pkarp@ai.sri.com
  Subject: reducing time overhead of text display (in 1.1) 
  From: "Albert G. Boulanger" <aboulanger@BBN.COM>
  Sender: aboulang@BBN.COM
  Reply-to: aboulanger@BBN.COM
  Date: Wed, 22 Dec 93 14:50:51 EST
  
  
  Ken quotes Gregor:
  
     Of course, we're not going to redesign CLIM, now, except incrementally.
     But, we need to work together on these issues.  I think Gregor said, "the
     one thing you can't hide behind a layer of abstraction, is a performance
     problem".  
  
  
  Well, this is my quote of the day!
  
  Seriously, I do not think that this quote is totally true. I am a bit
  surprised that nobody is making use of lisp's abstraction power to
  *leverage* efficiency. Yes, one would like a environment like Clim

Well, people like Gregor are.  The idea behind the MOP is to provide
flexibility, abstraction, and performance.  Xerox's recent work in compile
time MOP's is very interesting.

  where the programmer cost of doing some fairly hairy GUI stuff is
  easy, but the code has little *explicit* representation of the notions
  of development cycle vs use cycle. Now, if one had to choose a
  language for doing such an explicit representation, would Lisp not be
  high on one's list of choices? What I am saying is that one can hide
  performance issues of development cycle with abstraction. But the
  there is an onus for good user cycle performance on the GUI
  infracstructure at the end. This infracstructure support for
  performance may need something as radical as Dylan, but I think we can
  do things to help our *current* Lisp situation.
  
  In a lot of ways, this train of thought has lead me to be interested
  in building Lisp-base re-engineering tools for languages -- including
  dusty-deck Fortran code. This is an area where some of the performance
  issues discussed can be well separated without a lot of major
  infracstructure development for Lisp itself, but still utilizing
  Lisp's power of abstraction.
  
  Once I know how to spit out high-performance re-engineered Fortran or
  C code, I can begin to take the lessons learned and apply them to Lisp
  itself ;-).
  
I have an interesting paper by Richard Fateman and others, "Fast
Floating-Point Processing in Common Lisp".  It not only talks about Lisp
performance, but describes a Fortran -> Lisp translator.

k
Main Index | Thread Index