slate gui slowness needs fixing before proceeding

[Timmy Douglas]

Brian Rice <water at tunes.org> writes:

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

thanks. I made another patch with drop-mark, delete-region, and
kill-line (which for now behaves differently than emacs since it does
drop-mark, end-of-line, and delete-region in one command, which sucks
up the next line I think).

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

hm, this sort of seems like a temporary patch to speed up things but
I'm not sure it is enough. You'd have to try out the UI to see for
yourself, but 2-4x doesn't seem like it will fix the problem. It looks
like it might be the easiest option though. It's weird because
sometimes there are long delays and then the events will all get
processed by the ui fairly quickly (1 sec between typed characters
showing up) compared to the delay before the events registered (like
2-10 sec after the first keypress). But if you try inspector.slate and
try to drag the inspector windows you will go crazy. I guess mouse
motion events really drag it down or something along those lines.


I'm not really that familiar with how slate's compiler/interpreter
works or builds now. I was hoping to find something that would tell me
how mobius/ is built since it's like already slate code and I'm not
sure what can actually build that first stage (which I assume produces
the vm.c file in the base directory). Can someone point me to docs on
how the whole build process works? I think it'd go a long way with
understanding the vm... so far I've just been opening up like millions
of source files but it's hard to get the whole picture from that and
mobius.pdf. 


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


Yeah, there is quite a bit of code in src/mobius/optimizer. So you're
saying none of that is being used at the moment?


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

Sounds like we probably wouldn't have to worry about optimizations
once we got it into llvm's hands. I don't know how good that'd be. I
guess I'd have to spend a week figuring out how the optimization
framework works first.

> 3) Write an inlining bytecode compiler (my idea, would work  
> independently of a JIT) and associated caching/flushing system.

Well I'm pretty new to this stuff so I don't really know what would
get cached and flushed... I went to the library today since I saw you
thought ACD&I(?) was a good book (on some irc conversation a while
back) but they only let me check it out for 2 hours in-library... I
gave up after 30 min since there wasn't much I could do there.

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

ok

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

Well, if he takes the powerpc asm route, I hope there is a way that I
could run it on this old athlon box.

Thanks for the reply.