slate gui slowness needs fixing before proceeding

[Brian Rice]

On Jun 11, 2006, at 4:15 PM, Brian Rice wrote:
> On Jun 11, 2006, at 12:09 PM, Timmy Douglas wrote:
>> 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.
>
> <Slate VM Proposal.txt>

He (David) replied off-list again today. He's been busy but has made  
progress, and has spent time learning Lee's optimizer code as well as  
the more mundane stuff. I'll encourage him to make his work available  
so that at least it can be learned from, and hopefully improved upon.

--
-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/20060613/e15b532c/PGP.pgp