Discussion:
slate gui slowness needs fixing before proceeding
(too old to reply)
Timmy Douglas
2006-06-11 19:09:15 UTC
Permalink
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.


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?


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.
Brian Rice
2006-06-11 23:15:03 UTC
Permalink
Post by Timmy Douglas
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.
Post by Timmy Douglas
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.
Post by Timmy Douglas
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.
Mark Haniford
2006-06-12 01:28:28 UTC
Permalink
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.
Post by Brian Rice
Post by Timmy Douglas
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.
Post by Timmy Douglas
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,
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.
Post by Timmy Douglas
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
Brian Rice
2006-06-12 01:38:34 UTC
Permalink
Post by 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.
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?
Post by Mark Haniford
Post by Timmy Douglas
Post by Timmy Douglas
Well, I've added patches to my repos for simple one-way undo and
now
Post by Timmy Douglas
you can type in all the characters fine. The problem is that
there is
Post by Timmy Douglas
no point in going further (selections, copy paste, searching,
kill-line, cleaning up my ugly code, etc) when the current gui
is too
Post by Timmy Douglas
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
Post by Timmy Douglas
the current environment. But enough of the future talk.
Okay. I've pulled these into the site repositories.
Post by Timmy Douglas
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
Post by Timmy Douglas
start from the last 1000 messages on this list, so I thought I'd
start
Post by Timmy Douglas
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,
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.
Post by Timmy Douglas
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
Mark Haniford
2006-06-12 02:43:08 UTC
Permalink
So what is the "real" reason for Lee quitting in the first place?
Maybe if Lee was bestowed the position of "Benevolant Dictator" then
he would come back.

But wasn't Lee the only person working on the VM anyway? Were other
people trying to bogart in on the VM or were their arguments about the
design or what?

I think Slate has some great ideas behind it.
Post by Brian Rice
How can we persuade you to return somehow? Would it need to involve
shedding some of the formalities of a public open-source project?
Brian Rice
2006-06-12 13:53:37 UTC
Permalink
Post by Mark Haniford
So what is the "real" reason for Lee quitting in the first place?
Maybe if Lee was bestowed the position of "Benevolant Dictator" then
he would come back.
The last relevant quotes (over instant messaging) I got from him
about his stance towards the project were:

"i can say with absolute certainty i have no interest in continuing it"

"i'm disinterested in where the project is going and i'm not sure we
are capable of running it together to the mutual benefit of us both"

"as it has been it has been nothing more than parasitic to me"

If I may paraphrase further, basically he did not want to maintain a
public project at all, and only cared about a hobby-level language
+compiler+OS toolchain that ran on bare hardware. He actually
*suggested* that we focus on the IDE to make Slate more useful rather
than fret about performance. I'm not sure how he never took the
performance issue seriously enough to realize that the UI-based IDE
would be unusable without a dynamic inliner.

I am CC'ing him so that he can clarify his stance on this if he wishes.
Post by Mark Haniford
But wasn't Lee the only person working on the VM anyway?
Lee actually didn't originally like the idea of using a VM. I simply
introduced a (buggy) Slate-to-C translator a la Squeak and sketched
out a VM design just to get the ball rolling when we were stuck in a
Common Lisp interpreter. If we hadn't done that, we'd still be there
on CL since he never completed his compiler.

That said, he wrote most of the VM code and wound up maintaining it.
He has a propensity to write pages and pages of really interesting
code with no comments; I spoke with other people he has collaborated
with and they've confirmed this. So it's non-trivial to pick up code
that he wrote and run with it, and he got stuck with what he had
written, with little-to-no desire to do so (apparently).
Post by Mark Haniford
Were other people trying to bogart in on the VM or were their
arguments about the design or what?
Towards the end there was a decent amount of clamoring for
continuation support, which he apparently found unwarranted. He
basically silently refused to code any support for it, while making
hand-waving explanations about how easy it would be to get a subset
of the functionality. At least a few people disagreed with him on the
matter.

No one really criticized or tried to mess with the basic VM design or
such; in fact I think he was its biggest critic.

The last that I heard, Lee was learning his father's real estate
business and selling real estate in/near Las Vegas. I suggested a few
open positions for the type of work he was doing with Slate, but it
didn't interest him. He probably makes good money and is totally
wasting his technical talent (or not - he occasionally just
contributes to a few projects as a donor).
Post by Mark Haniford
I think Slate has some great ideas behind it.
Post by Brian Rice
How can we persuade you to return somehow? Would it need to involve
shedding some of the formalities of a public open-source project?
--
-Brian
http://tunes.org/~water/brice.vcf
Timmy Douglas
2006-06-14 05:04:32 UTC
Permalink
Post by Brian Rice
Post by Mark Haniford
But wasn't Lee the only person working on the VM anyway?
Lee actually didn't originally like the idea of using a VM. I simply
introduced a (buggy) Slate-to-C translator a la Squeak and sketched
out a VM design just to get the ball rolling when we were stuck in a
Common Lisp interpreter. If we hadn't done that, we'd still be there
on CL since he never completed his compiler.
Was the reason behind making a VM because it's easier to make? I'm not
really up-to-date with the good-sides of VMs other than portability
and maybe simplicity, but it's probably too late to argue one way or
another with that.
Post by Brian Rice
Post by Mark Haniford
Were other people trying to bogart in on the VM or were their
arguments about the design or what?
Towards the end there was a decent amount of clamoring for
continuation support, which he apparently found unwarranted. He
basically silently refused to code any support for it, while making
hand-waving explanations about how easy it would be to get a subset
of the functionality. At least a few people disagreed with him on
the matter.
Well, I took a look at "Continuations, concurrency, yada yada..." It
seems like he was looking for a good idiom for continuations to
represent. I can't really argue for them though since I've never
really used them (the call/cc type at least). oh well
Brian Rice
2006-06-14 06:58:18 UTC
Permalink
Post by Timmy Douglas
Post by Brian Rice
Post by Mark Haniford
But wasn't Lee the only person working on the VM anyway?
Lee actually didn't originally like the idea of using a VM. I simply
introduced a (buggy) Slate-to-C translator a la Squeak and sketched
out a VM design just to get the ball rolling when we were stuck in a
Common Lisp interpreter. If we hadn't done that, we'd still be there
on CL since he never completed his compiler.
Was the reason behind making a VM because it's easier to make? I'm not
really up-to-date with the good-sides of VMs other than portability
and maybe simplicity, but it's probably too late to argue one way or
another with that.
1) Tiny: Common Lisp images are huge - 3 Mb at the minimum. The Slate
VM starts at 32kb if you build it minimally.
2) Simple: Implements only the PMD dispatch algorithm plus basic
memory, control-flow, and operations.
3) Portable: We generate ANSI C (vm.c and vm.h) and specialize to
POSIX/Win32/etc. as is suitable.

Also, it is the minimal way in which Slate system code could be
written in Slate - self-hosting was a major plus for us, to get an
idea of what the next stage problems would be in terms of using Slate
for systems code. It also *is* faster than the Common Lisp interpreter.
Post by Timmy Douglas
Post by Brian Rice
Post by Mark Haniford
Were other people trying to bogart in on the VM or were their
arguments about the design or what?
Towards the end there was a decent amount of clamoring for
continuation support, which he apparently found unwarranted. He
basically silently refused to code any support for it, while making
hand-waving explanations about how easy it would be to get a subset
of the functionality. At least a few people disagreed with him on
the matter.
Well, I took a look at "Continuations, concurrency, yada yada..." It
seems like he was looking for a good idiom for continuations to
represent. I can't really argue for them though since I've never
really used them (the call/cc type at least). oh well
Yeah, but at issue was the fact that he resisted email interchange of
any kind - his replies only dampened further discussion. I wound up
writing emails for him, most of the time.

--
-Brian
http://tunes.org/~water/brice.vcf
Timmy Douglas
2006-06-12 05:36:22 UTC
Permalink
Post by Brian Rice
Post by Timmy Douglas
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).
Post by Brian Rice
Post by Timmy Douglas
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,
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.
Post by Brian Rice
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?
Post by Brian Rice
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.
Post by Brian Rice
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.
Post by Brian Rice
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
Post by Brian Rice
Post by Timmy Douglas
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.
Tony Garnock-Jones
2006-06-12 10:24:16 UTC
Permalink
Post by Timmy Douglas
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.
It sounds like there's something rotten in the interface to SDL, rather
than basic slowness of Slate... well, I'd be surprised if it was Slate
since I've always been pleasantly surprised at the speed of the system
in general. Perhaps there's something sub-par in the polling logic?

I can't say for sure, of course, since I've been concentrating on other
aspects of the system and haven't tried the SDL interfaces for a long,
long time!
Post by Timmy Douglas
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.
Try the Self papers:

http://citeseer.ist.psu.edu/chambers92design.html
http://citeseer.ist.psu.edu/chambers91making.html
http://citeseer.ist.psu.edu/hlzle94adaptive.html
http://citeseer.ist.psu.edu/chambers90iterative.html

They changed my life ;-)
Post by Timmy Douglas
Well, if he takes the powerpc asm route, I hope there is a way that I
could run it on this old athlon box.
One important aspect of a direct-threaded design, ISTM, is the
instruction encodings... if someone can design a fixed-width "VLIW"
format for direct-threaded bytecodes, then the same architecture ought
to be able to apply to x86 as well as PPC.

Tony
Nick Forde
2006-06-12 12:27:32 UTC
Permalink
Post by Tony Garnock-Jones
Post by Timmy Douglas
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.
It sounds like there's something rotten in the interface to SDL, rather
than basic slowness of Slate... well, I'd be surprised if it was Slate
since I've always been pleasantly surprised at the speed of the system
in general. Perhaps there's something sub-par in the polling logic?
I haven't tried the SDL interface but you can get a very rough idea
of the basic VM performance by running 'make benchmark' and
comparing the results to those at: http://shootout.alioth.debian.org/
Last time I tried this the results were unfortunately not good :-(

The source for these tests can be found in test/benchmark and there is
some documentation in doc/benchmarks.txt.

Nick.
Brian Rice
2006-06-12 13:27:18 UTC
Permalink
Post by Nick Forde
Post by Tony Garnock-Jones
Post by Timmy Douglas
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.
It sounds like there's something rotten in the interface to SDL, rather
than basic slowness of Slate... well, I'd be surprised if it was Slate
since I've always been pleasantly surprised at the speed of the system
in general. Perhaps there's something sub-par in the polling logic?
I haven't tried the SDL interface but you can get a very rough idea
of the basic VM performance by running 'make benchmark' and
comparing the results to those at: http://shootout.alioth.debian.org/
Last time I tried this the results were unfortunately not good :-(
*ahem* Just to be pedantic, that's not the VM's performance, that's
the VM+image's performance. There are a lot of message sends that
happen for basic control-flow operations, for example, or even for
just executing a non-literal (argument to a method) block.

That said, the VM design is rather naive and could be much better,
but not by the order of magnitude that the shootout benchmarks are.
The performance problem we have relates to the Strongtalk design - we
just have no inlining compiler to rely on.
Post by Nick Forde
The source for these tests can be found in test/benchmark and there is
some documentation in doc/benchmarks.txt.
--
-Brian
http://tunes.org/~water/brice.vcf
Nick Forde
2006-06-12 13:57:09 UTC
Permalink
Post by Nick Forde
Post by Timmy Douglas
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.
It sounds like there's something rotten in the interface to SDL, rather
than basic slowness of Slate... well, I'd be surprised if it was Slate
since I've always been pleasantly surprised at the speed of the system
in general. Perhaps there's something sub-par in the polling logic?
I haven't tried the SDL interface but you can get a very rough idea
of the basic VM performance by running 'make benchmark' and
comparing the results to those at: http://shootout.alioth.debian.org/
Last time I tried this the results were unfortunately not good :-(
*ahem* Just to be pedantic, that's not the VM's performance, that's the
VM+image's performance. There are a lot of message sends that happen
for basic control-flow operations, for example, or even for just
executing a non-literal (argument to a method) block.
For most of the benchmarks that is indeed true. However, I added an extra
primitive to the VM to trace PSInterpreter_[re]sendMessage*() calls only
during the body of the benchmarks. I found that in some of the simple tight
loop tests the number of message sends wasn't excessive but most of the
execution time was in their dispatch. These benchmarks still fared poorly
when compared to the shootout results.
That said, the VM design is rather naive and could be much better, but
not by the order of magnitude that the shootout benchmarks are. The
performance problem we have relates to the Strongtalk design - we just
have no inlining compiler to rely on.
I think you're right and agree that this is where the biggest
performance gains can be had.

Nick.
Brian Rice
2006-06-12 14:02:47 UTC
Permalink
Post by Timmy Douglas
Post by Brian Rice
Post by Timmy Douglas
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!
Post by Timmy Douglas
Post by Brian Rice
Post by Timmy Douglas
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,
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.
Post by Timmy Douglas
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.
Post by Timmy Douglas
Post by Brian Rice
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).
Post by Timmy Douglas
Post by Brian Rice
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.
Post by Timmy Douglas
Post by Brian Rice
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.
Post by Timmy Douglas
Post by Brian Rice
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
Post by Brian Rice
Post by Timmy Douglas
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
Brian Rice
2006-06-12 14:10:20 UTC
Permalink
Post by Brian Rice
Post by Timmy Douglas
Post by Brian Rice
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.
There are also several text files with notes on his design decisions
in doc/*.txt.

--
-Brian
http://tunes.org/~water/brice.vcf
Timmy Douglas
2006-06-14 04:21:34 UTC
Permalink
Post by Brian Rice
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.
The main thing I was looking for would be something like this (which
is pure guessing now since I haven't had much time to look into it):

1. vm.c and vm.h is downloaded from the tunes site (why isn't it in
the darcs directory instead?). It is some sort of minimal slate
interpreter which uses <insert something about alpha vm boot
image?> and reads the special slate files:
src/mobius/vm/bootstrap.slate and blah and outputs another vm.c
file.

2. The new vm.c file is compiled with your c compiler into the final
slate vm and then your image is built using that VM and the files
blah blah blah and saved to slate.image.


It'd be nice if you could go into more details with the files used and
what they do in a line of text if ever get time.

The readme has a lot of files in it that don't exist anymore.
Brian Rice
2006-06-14 07:05:47 UTC
Permalink
Post by Timmy Douglas
Post by Brian Rice
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.
The main thing I was looking for would be something like this (which
1. vm.c and vm.h is downloaded from the tunes site (why isn't it in
the darcs directory instead?). It is some sort of minimal slate
interpreter which uses <insert something about alpha vm boot
src/mobius/vm/bootstrap.slate and blah and outputs another vm.c
file.
vm.c and vm.h are only versioned in the alpha/ branch, and even then
they are dubious since the order of C functions generated from Pidgin
translation is somewhat non-deterministic, thereby raising the level
of noise in version diff's. It is far easier to use wget or rely on
the tarballs (which I automate generation of) or releases (which are
just versioned tarballs with documentation) to automatically include.
Post by Timmy Douglas
2. The new vm.c file is compiled with your c compiler into the final
slate vm and then your image is built using that VM and the files
blah blah blah and saved to slate.image.
There is also a new vm.h file which is also generated from the same
definitions used for vm.c.

By default, actually, the new files will be vm.new.c and vm.new.h
(the NEWVARIANT Makefile variable will be introduced shortly to
parametrize the ".new" part - right now, only the VARIANT Makefile
variable exists to specify what to start with for the VM/image core).

Did you not read what's in the INSTALL file? "Extending Slate" covers
the basics of this.
Post by Timmy Douglas
It'd be nice if you could go into more details with the files used and
what they do in a line of text if ever get time.
Please ask specifically what the INSTALL file does not address.
Post by Timmy Douglas
The readme has a lot of files in it that don't exist anymore.
No, it does not. Please be specific about the discrepancies and I
will address them immediately via corrective patches.

Otherwise, make sure to indicate that you are talking about, say, a
released Slate version as compared to a current darcs repository,
since there is a huge difference over the last several months.

--
-Brian
http://tunes.org/~water/brice.vcf
Timmy Douglas
2006-06-14 15:12:36 UTC
Permalink
Post by Brian Rice
Post by Timmy Douglas
Post by Brian Rice
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.
The main thing I was looking for would be something like this (which
1. vm.c and vm.h is downloaded from the tunes site (why isn't it in
the darcs directory instead?). It is some sort of minimal slate
interpreter which uses <insert something about alpha vm boot
src/mobius/vm/bootstrap.slate and blah and outputs another vm.c
file.
vm.c and vm.h are only versioned in the alpha/ branch, and even then
they are dubious since the order of C functions generated from Pidgin
translation is somewhat non-deterministic, thereby raising the level
of noise in version diff's.
Yeah, these looked autogenerated to me but I didn't know what they
were coming from until I read the makefile. I guess I missed that part
in the "Build Requirements" (maybe I was tempted to skim over it since
it sort the title comes off as a system requirements section). My
fault.
Post by Brian Rice
It is far easier to use wget or rely on the tarballs (which I
automate generation of) or releases (which are just versioned
tarballs with documentation) to automatically include.
ok
Post by Brian Rice
Post by Timmy Douglas
2. The new vm.c file is compiled with your c compiler into the final
slate vm and then your image is built using that VM and the files
blah blah blah and saved to slate.image.
There is also a new vm.h file which is also generated from the same
definitions used for vm.c.
By default, actually, the new files will be vm.new.c and vm.new.h
(the NEWVARIANT Makefile variable will be introduced shortly to
parametrize the ".new" part - right now, only the VARIANT Makefile
variable exists to specify what to start with for the VM/image core).
ok
Post by Brian Rice
Did you not read what's in the INSTALL file? "Extending Slate" covers
the basics of this.
"Extending Slate" points me to src/mobius/vm/post-bootstrap.slate and
tells me how to extend or build a new VM. Since I would be more
interested in knowing how the VM works or how it is built, I'd like to
sort of have an overview on how 'make newboot' works rather than the
commands I type in to generate a new image.
Post by Brian Rice
Post by Timmy Douglas
It'd be nice if you could go into more details with the files used and
what they do in a line of text if ever get time.
Please ask specifically what the INSTALL file does not address.
I don't know, maybe I'm approaching this the wrong way and I should
grep for 'generate' in the mobius directory for something that
specializes on VM definitons. I thought there would be something to
tell me what actually generated the first vm.c that's in the alpha
repository and then that src/mobius/vm/build.slate or whatever
actually generates a vm.new.c/h file, which is compiled again. I don't
think I would have guessed that from this:

VM define: #new -> (VM Definition newNamed: 'vm.new') generate.

since this is my first time looking at the bootstrapping level of a
system I guess there were a lot of gaps that weren't already filled by
experience so maybe that's why I didn't think the docs had everything.
Post by Brian Rice
Post by Timmy Douglas
The readme has a lot of files in it that don't exist anymore.
No, it does not. Please be specific about the discrepancies and I
will address them immediately via corrective patches.
The readme mentions:

src/mobius/bootstrap/ - Bootstrap code, for the future run-time
builds.

src/mop/ - Meta-object protocol.

which don't exist in my repository. Sorry I guess 'a lot' was the
wrong word here.
Post by Brian Rice
Otherwise, make sure to indicate that you are talking about, say, a
released Slate version as compared to a current darcs repository,
since there is a huge difference over the last several months.
I'm just using slate/main from darcs, I don't know if I should be
looking at other stuff or not.
Brian Rice
2006-06-15 02:12:23 UTC
Permalink
I didn't have this email account accessible at work today, so this
reply has been delayed...
Post by Timmy Douglas
Post by Brian Rice
Post by Timmy Douglas
1. vm.c and vm.h is downloaded from the tunes site (why isn't it in
the darcs directory instead?). It is some sort of minimal slate
interpreter which uses <insert something about alpha vm boot
src/mobius/vm/bootstrap.slate and blah and outputs another vm.c
file.
vm.c and vm.h are only versioned in the alpha/ branch, and even then
they are dubious since the order of C functions generated from Pidgin
translation is somewhat non-deterministic, thereby raising the level
of noise in version diff's.
Yeah, these looked autogenerated to me but I didn't know what they
were coming from until I read the makefile. I guess I missed that part
in the "Build Requirements" (maybe I was tempted to skim over it since
it sort the title comes off as a system requirements section). My
fault.
Post by Brian Rice
Did you not read what's in the INSTALL file? "Extending Slate" covers
the basics of this.
"Extending Slate" points me to src/mobius/vm/post-bootstrap.slate and
tells me how to extend or build a new VM. Since I would be more
interested in knowing how the VM works or how it is built, I'd like to
sort of have an overview on how 'make newboot' works rather than the
commands I type in to generate a new image.
Okay, that's a good point. I'll put something together tonight.
Post by Timmy Douglas
Post by Brian Rice
Post by Timmy Douglas
It'd be nice if you could go into more details with the files used and
what they do in a line of text if ever get time.
Please ask specifically what the INSTALL file does not address.
I don't know, maybe I'm approaching this the wrong way and I should
grep for 'generate' in the mobius directory for something that
specializes on VM definitons. I thought there would be something to
tell me what actually generated the first vm.c that's in the alpha
repository and then that src/mobius/vm/build.slate or whatever
actually generates a vm.new.c/h file, which is compiled again.
VM define: #new -> (VM Definition newNamed: 'vm.new') generate.
since this is my first time looking at the bootstrapping level of a
system I guess there were a lot of gaps that weren't already filled
by experience so maybe that's why I didn't think the docs had
everything.
Hm, well, no, it doesn't provide much information, but the #generate
method is also in that file... anyway, you have to recurse to learn
this stuff as it is.

Here's the rough summary:
The VM is built by constructing a definition expressed with object
structure. The basics are outlined as VM Definition which lists the
sources it's built from and then includes the primitive functions
that are exposed as its interface (the primitives) to the image.
*Unfortunately*, the structure of the objects used to generate the C
sources is held elsewhere, basically by the Pidgin generator (src/
mobius/c/ generator.slate and cr.slate have most of it). But
basically there are objects describing every type and function in the
VM, which are held together in a module and processed as a whole to
perform a little type-inference and flattening from methods to
functions. The creation of this module from the reading of the source
pidgin files (src/mobius/vm/*/*.slate) is the first phase, and the
second is to process these to generate C sources.

The image is then constructed in terms of interfacing with this
definition of the VM as a bunch of live Slate objects in the image.
Image Definition describes what sources constitute the core image
creation code, along with a pointer to the desired VM Definition and
administrative details like endianness and filename. The VM and
Images interface in terms of an array called the specialOops in the
image and SpecialOopsArray in the VM. This tells the VM where the
critical object pointers are that it needs for primitives, so that
the VM and image link together at startup in order to run together.
Image creation then consists of parsing and compiling the sources
from the files listed into one huge bytecode method which is the sole
non-special bit of content in the Slate core image. The image is then
arranged to run this method when it is started. The method, of its
own nature, when run will then perform all of the actions that the
code in those Slate files would do... it's just frozen and replayed
for that empty environment, to build it from scratch constructively.

The images that the bootstrap puts out are those core images, which
is why the default "make" target runs the vm with the relevant image
and then tells it to save itself at the end, so that the huge
constructor method has already run and now you just have instant
startup.

Whew - that's the bootstrap as-is (it has evolved quite a bit from a
bunch of custom scripts - by no means should you consider any of the
things I'm describing as desirable as conceptual end-goals). Okay, so
how does that strike you? How / in what form would you like that
related in the included documentation (or at least persisted on the
wiki)?
Post by Timmy Douglas
Post by Brian Rice
Post by Timmy Douglas
The readme has a lot of files in it that don't exist anymore.
src/mobius/bootstrap/ - Bootstrap code, for the future run-time
builds.
src/mop/ - Meta-object protocol.
which don't exist in my repository. Sorry I guess 'a lot' was the
wrong word here.
src/mop/ was removed since the contents didn't gel and form anything
useful. The idea was to have slot meta-objects and so forth but we
just hadn't found them compelling (or easy to implement, in the case
of meta-level lookup overrides) yet.

src/mobius/bootstrap/ also existed but was wiped out since the
contents were trivial and noisy.

Perhaps I'll note both of these as temporarily defunct or something.
I'll patch it as soon as I decide about that. Thanks for mentioning
these.

--
-Brian
http://tunes.org/~water/brice.vcf
Brian Rice
2006-06-15 04:06:38 UTC
Permalink
Post by Timmy Douglas
Post by Brian Rice
vm.c and vm.h are only versioned in the alpha/ branch, and even then
they are dubious since the order of C functions generated from Pidgin
translation is somewhat non-deterministic, thereby raising the level
of noise in version diff's.
Yeah, these looked autogenerated to me but I didn't know what they
were coming from until I read the makefile. I guess I missed that part
in the "Build Requirements" (maybe I was tempted to skim over it since
it sort the title comes off as a system requirements section). My
fault.
I'll try to rename/split the section to indicate that better.
Suggestions (or patches) are welcome.

--
-Brian
http://tunes.org/~water/brice.vcf
Timmy Douglas
2006-06-15 05:00:10 UTC
Permalink
Post by Brian Rice
I didn't have this email account accessible at work today, so this
reply has been delayed...
The VM is built by constructing a definition expressed with object
[snip]
thanks. awesome. I copied this verbatim into my local repository as
doc/bootstrap.txt. I think I might play around with it before I record
anything though. I also made a readme file for the doc directory that
covers some of the files in there.

As far as the wiki goes, maybe it'd be better to just leave future
plans there. I think if the docs get spread out over too many places
you start to have places where it lags behind. The tutorial is
starting to look a little dated to me, but I think it might just be
better to clean that up later (because if things go well maybe there
would be a gui to interact with instead of a repl).
Matt Revelle
2006-06-15 11:44:30 UTC
Permalink
There isn't much here: http://slate.infogami.com/, but some of the
examples (file streams, strings) could be moved to the official wiki
and used as a basis for a second tutorial that shows off Slate idioms
for common tasks.
Post by Timmy Douglas
Post by Brian Rice
I didn't have this email account accessible at work today, so this
reply has been delayed...
The VM is built by constructing a definition expressed with object
[snip]
thanks. awesome. I copied this verbatim into my local repository as
doc/bootstrap.txt. I think I might play around with it before I record
anything though. I also made a readme file for the doc directory that
covers some of the files in there.
As far as the wiki goes, maybe it'd be better to just leave future
plans there. I think if the docs get spread out over too many places
you start to have places where it lags behind. The tutorial is
starting to look a little dated to me, but I think it might just be
better to clean that up later (because if things go well maybe there
would be a gui to interact with instead of a repl).
Brian Rice
2006-06-13 07:51:16 UTC
Permalink
Post by Brian Rice
Post by Timmy Douglas
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-
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.
Post by Timmy Douglas
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
David Gilmore
2006-06-16 11:19:11 UTC
Permalink
Greetings,

My name is David Gilmore. I have been following the Slate project
for some time, and have decided that I am finally in a position to be
of some assistance. I apologize for not having been able to do more
before now. I also apologize for my delayed participation in this
thread, but I am in the field away from the internet.

I believe that the Slate Language is a very powerful idea, but
certain bottlenecks are holding it back from meeting its potential.
I have had some discussions with Brian about what needs to be done to
resolve these issues.

There are basically 3 ways to make Slate go faster:

1. Optimize Message Sends. This includes streamlining the message-
send code (which is difficult because it has to do many checks) and
method lookups from a cache (which is faster, but still involves
checks). Polymorphic inline caches is one strategy for doing this
which involves caching multiple versions of methods based on the
types of the participants.

2. Run compiled code rather than interpreted. This avoids the
overhead of bytecode decoding and offers the possibility of various
code optimizations, but is quite complex and offers little speedup
for message sends. There are several ways to do this:
a) on-demand compiler (called explicitly by the programmer and
stored to a file or image.
b) native-code just-in-time compiler (JIT). A method is compiled to
native code when it is called for the first time and then stored in a
cache.
c) threaded-code JIT: When a method is called for the first time,
the bytecodes are decoded to a jump-table which links to a series of
bytecode handlers implemented in assembly language. This is almost
as fast as unoptimized native code.

3. Eliminate Message Sends altogether. The cleanliness of the
language design allows the user to think of everything in terms of
objects participating in message sends. This is efficient for
humans, but not for computers. If the system can translate message-
sends to straight c-calls or insert the code directly into the
calling method, then dramatic speed boosts can be made in code which
is constantly calling tiny methods. These speedups are possible even
if an interpretive VM is used. The catch is that this can only be
done where the system can determine at compile time the types of the
various objects involved in the call.

Of these possibilities, I feel that the best "bang for the buck"
speedup potential for Slate is number 3. Number 1 is actually fairly
well done in the Slate VM currently. Regarding number 2, Lee's JIT
project yielded about 2x speed boost. There are a number of other
things which could be done to improve this, but it looks as if Slate
would still be slow because of exorbitant message-passing overhead.
An alternative to enhancing Lee's JIT would be to implement a
threaded-code interpreter which wouldn't have to be too complex.

So what is the best way to implementing the elimination of Message
Sends? That is the job of the optimizer code within the Slate VM.
This code needs to be understood, tested, and filled out. The
optimizer takes its input from the output of the Slate lexer and
parser in the form of syntax trees. It should then be able to walk
through the code and determine if the types of a message-send can be
known in advance either by programmer specification or type
inference. If it can, then it will replace the call with the syntax
tree of the called method. This is code-inlining.

This code is difficult to test because it can yield very complex tree-
structures. I feel that the best way to debug this code is to
resurrect the old Lisp-based VM and update it to run the current
slate libraries. LispWorks Personal is a free development
environment which is very nice and has a step-debugger and tools for
graphical presentation of tree structures. It does have a limited
heap-size so I that might become a problem. The Lisp VM code is very
nicely written and is only 7,000 lines including a slate->lisp
translator. The translated code can then be natively compiled.
Methods can be implemented in Slate or Lisp and FFI is available
through lisp.

I do not propose the use of the Lisp VM as a replacement of the C-
based VM, but it can be a useful test-bed for development of
components which can then be integrated into the C VM. It can also
be useful for a project which integrates Slate and Lisp code.

With the Lisp VM, the lisp language essentially becomes the
"bytecode" for system, but this is something which is visual,
tweakable, and debuggable. After success with Lisp, different
backends can be developed to produce Slate bytecodes compatible with
the current C VM, as well as LLVM bytecodes which would utilize the
LLVM engine to produce high-quality, optimized native-code. These
would not be dependent on the lisp environment.

I don't have all of the answers, but I am engaged in the process of
figuring this thing out. I hope that others will take an interest in
this and take it farther than I am able.

I am involved in several projects and I am notorious for having a
somewhat slow multi-tasking cycle so I apologize in advance for not
always being totally responsive, but I always come back to good
ideas, and I have come back to Slate repeatedly because it is
definitely a good idea, and will continue to do so.

David Gilmore
Matt Revelle
2006-06-20 01:14:11 UTC
Permalink
Others may have seen this, but a HLVM project ( http://hlvm.org/ ) was
started recently. Its goal is to provide a general bridge between
dynamic languages and the LLVM.

It doesn't have much to offer Slate yet, but from the site HVLM will
be "[a] complete language designer's toolkit for creating new
programming languages easily. To define a new language, language
designers simply write a plugin that describes the language to HLVM
and how to translate the grammar productions into HLVM's comprehensive
Abstract Syntax Tree (AST). After that, HLVM handles all aspects of
code generation, bytecode storage, JIT execution or interpretation,
and native compilation."
Post by David Gilmore
I do not propose the use of the Lisp VM as a replacement of the C-
based VM, but it can be a useful test-bed for development of
components which can then be integrated into the C VM. It can also
be useful for a project which integrates Slate and Lisp code.
With the Lisp VM, the lisp language essentially becomes the
"bytecode" for system, but this is something which is visual,
tweakable, and debuggable. After success with Lisp, different
backends can be developed to produce Slate bytecodes compatible with
the current C VM, as well as LLVM bytecodes which would utilize the
LLVM engine to produce high-quality, optimized native-code. These
would not be dependent on the lisp environment.
Loading...