Slate's slowness impeding UI/IDE development

[Brian Rice]

On Jun 11, 2006, at 6:28 PM, Mark Haniford wrote:

> 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.

I agree; this observation has been impressed on me since the moment  
he declared his lack of enthusiasm.

I just want this project to work and do useful things for people. I'd  
sacrifice quite a bit of control to achieve that.

To Lee:
  How can we persuade you to return somehow? Would it need to involve  
shedding some of the formalities of a public open-source project?

> 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.

--
-Brian
http://tunes.org/~water/brice.vcf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/slate/attachments/20060611/224fc857/PGP.pgp