slate gui slowness needs fixing before proceeding

[Mark Haniford]

This seems to be the second time that someone has had to stop work on
the gui because of the slowness of Slate.  It might be time to ask Lee
to come back and work on the compiler/JIT stuff.  Time keeps on
marching by and it's not waiting for Slate.

On 6/11/06, Brian Rice <water at tunes.org> wrote:
>
> On Jun 11, 2006, at 12:09 PM, Timmy Douglas wrote:
>
> > Well, I've added patches to my repos for simple one-way undo and now
> > you can type in all the characters fine. The problem is that there is
> > no point in going further (selections, copy paste, searching,
> > kill-line, cleaning up my ugly code, etc) when the current gui is too
> > slow to type in. I guess my ideal path after those features to the
> > text buffer would be to modify demo/inspector.slate to elegantly edit
> > the current environment. But enough of the future talk.
>
> Okay. I've pulled these into the site repositories.
>
> > So I'd like to take a look at speeding up (or something to speed up
> > the GUI portion) of slate, but the only real dealings I have with
> > compilers are from when I wrote a tiger compiler in sml (following
> > appel's book for a class). Anyways, I didn't see any hint of where to
> > start from the last 1000 messages on this list, so I thought I'd start
> > a thread. So what are the options?
>
> I've discussed this off-list with someone who was going to work on
> it, but I haven't heard back from him after initial email exchanges.
> I've CC'd him just to get some basic communication re-established,
> hopefully. The options that we went over were:
>
> 1) Improve/port the experimental_jit.c. It already gives a 2-4x
> speedup. The problem is that it does no dynamic inlining, so that the
> huge message-send layering which is the majority of the performance
> problem is not taken care of.
> 2) Fix/complete Lee's optimizing compiler framework. This has a
> couple of sub-options.
>   The direct option is to finish his x86 code generator, figure out
> how to link it with the image, etc. Basically lots of stuff that I
> have no idea how to do, and I don't know if I can get him to come
> back to do it (although I'd try if enough people asked... or maybe
> they should try themselves).
>   The other option is to add a back-end target to LLVM from the IR
> code. This is slightly problematic because Lee wrote the IR to use
> SSU (single static usage) instead of SSA (single static assignment)
> form, which are inversions of each other from a data-flow
> perspective. Other than that, Lee's framework does "speak" LLVM at
> least from the abstract perspective.
> 3) Write an inlining bytecode compiler (my idea, would work
> independently of a JIT) and associated caching/flushing system.
> 4) Translate the VM into a direct-threaded style, which Eliot Miranda
> endorsed at Smalltalk Solutions this year when I spoke with him. It
> makes inlining much easier and has other benefits in terms of
> architectural/code-manipulation simplifications.
>
> > In about a week, I'm going to get more busy though since another
> > summer class will start, but until then, I should have time to get
> > something done.
>
> That likely won't be enough time to accomplish a deep change, but
> some sketch code to start with would be feasible. Slate's VM
> structure is pretty simple and malleable. All the bytecode-related
> code is in vm.slate, for example.
>
> I hope that David won't mind, but I've attached his initial VM
> proposal email from a couple of months ago.
>
>
>
>
> If anyone wants to discuss this intensively, I recommend Skype or IM.
> My ID there is "water451" and my IM identifiers are in my signature
> vCard.
>
> --
> -Brian
> http://tunes.org/~water/brice.vcf
>
>
>
>
>