slate gui slowness needs fixing before proceeding

[Brian Rice]

On Jun 11, 2006, at 10:36 PM, Timmy Douglas wrote:

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

Got it. Thanks!

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

Yeah, I never thought that it would.

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

The code that "make newboot" calls (mentioned in INSTALL) is in src/ 
mobius/vm/build.slate and then there's src/mobius/vm/bootstrap.slate  
and so forth. src/mobius/init.slate shows the load order needed to  
build up a working VM+image bootstrapper. The README maps out the  
contents of the directories of the Slate repositories.

That said, a guide to Slate's build system is certainly warranted.  
I'll think about how to start one, but suggestions are also welcome.

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

Yes. He worked on it for about four years in various incarnations and  
never hooked it up to test it, other than the IR front-end in tests  
that were local to his setup (i.e. he never published them).

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

Yeah, it's at least a medium-sized task. Compiler-coding familiarity  
helps quite a bit but Lee made his own decisions for his own reasons  
that have to be divined from the source.

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

Advanced Compiler Design & Implementation only covers advanced back- 
end optimizations and intermediate-form representation choices. It's  
the basis for a lot of Lee's work in that area.

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

We could probably easily lift it up to C level, if not Pidgin.

--
-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/20060612/56e71b1e/PGP.pgp