Re: [sldev] Re: LSL and geometry hierarchy issues

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [sldev] Re: LSL and geometry hierarchy issues

Argent Stonecutter
Mark Meijer:
> Actually I think Lua would be a brilliant candidate. I don't know
> where you got the idea that it's heavy.

Remember the constraints scripts run under.

First, concurrency.

In a typical application where these scripting languages are used you  
typically have to deal with a few hundred concurrently executing  
scripts at the most. In SL, you have thousands... it's not unknown  
for a single avatar to have a thousand active scripts. That means  
that a context switch between one script at the lest can not be  
significantly more expensive than a subroutine call.

Second, migration.

When a macro avatar with several hundred scripted prims crosses a sim  
border, every one of those scripts has to be serialized, copied to  
the new sim, restored, and restarted. The easiest and most efficient  
way to do this is to use relative pointers for everything, and have  
the virtual machine operate on that basis... then the memory image is  
automatically serialized. But converting an existing VM for do that,  
even in part, is daunting. It's hard enough that when I was faced  
with doing so last year (for Tcl) I bailed, and decided to use  
absolute offsets for shared memory segments... and even then it took  
me six months just to track down all the bugs caused by losing track  
of whether a pointer to a shared object or not and calling the wrong  
free().

Adding object-orientation makes the problem ten times harder, simply  
because of all the extra indirection that goes on.

And that's all ignoring the realtime issue... there's a classic hard-
realtime deadline: a script can't be allowed to run over the end of a  
physics frame.

So when I say "heavyweight", I'm talking about in relation to an  
extremely hard set of requirements to meet. I mean "if you can't  
imagine running this on an Apple II ... or at most a PDP-11... it's  
probably too heavy".

Taran Rampersad writes:
> Honestly, I think that there needs to be more of a framework and API
> solution with different languages available to utilize hooks.

If you have several thousand scripts running in multiple external  
interpreters, using something like message passing (even in shared  
memory) to communicate with the physics simulator, I don't think  
you'll end up with as responsive an environment as you do in SL now.

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [sldev] Re: LSL and geometry hierarchy issues

Argent Stonecutter
Taran Rampersand:
> Ouch. Hadn't factored in the CLI environment snapshots. I'd love to  
> see
> Forth implemented, but then - people are asking for OO for a  
> reason, and
> eventually something OO will have to come into play.

You don't need an OO runtime to write OO code or even run an OO  
language. That's the trap that all the hardware guys fell into in the  
'80s, with TRON and the Intel iAPX432 and the Symbolics LISP engine.  
Trying to design an ABI around language requirements, even to a  
lesser extent, ended up causing problems - consider the VAX with its  
myriad stack frame formats, even the Intel x86 segmentation and the  
Sparc register windows.

Now imagine a low level runtime, like for a Forth threaded runtime or  
one of the minimal Schemes - remember, your base Scheme (SIOD) or  
Lisp 1.5 isn't object oriented in the same sense as Java or  
Smalltalk, they just have the tools that make objects just fall out  
of a minimal discipline. You can create a "compiler" that's no more  
complex than a HLL runtime interpreter, that takes something like the  
Forth fragment I posted earlier or something like

(state default '(
  (event state_entry '(
   (cond (eq owner (llGetOwner)) ... ]

These languages have, in common, the fact that it's really easy to  
compile other code into them. They are also high enough level that  
you don't need a validator: you can build a hard sandbox into the  
runtime.

So then the client would compile your LSL into Forth or Scheme. If  
you wanted to write in the new underlying language directly, you'd do  
that. And you wouldn't need much of a library facility to create a  
canned "SL-Lua" or "SL-Ruby" runtime that you could call out to from  
the script, that wouldn't need to be replicated on the sim.

Much safer than Mono. Much faster than LSL, especially for people who  
could work in the native language.

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [sldev] Re: LSL and geometry hierarchy issues

Taran Rampersad
Argent Stonecutter wrote:
> You don't need an OO runtime to write OO code or even run an OO
> language. That's the trap that all the hardware guys fell into in the
> '80s, with TRON and the Intel iAPX432 and the Symbolics LISP engine.
> Trying to design an ABI around language requirements, even to a lesser
> extent, ended up causing problems - consider the VAX with its myriad
> stack frame formats, even the Intel x86 segmentation and the Sparc
> register windows.
Right, I'm with you.

>
> Now imagine a low level runtime, like for a Forth threaded runtime or
> one of the minimal Schemes - remember, your base Scheme (SIOD) or Lisp
> 1.5 isn't object oriented in the same sense as Java or Smalltalk, they
> just have the tools that make objects just fall out of a minimal
> discipline. You can create a "compiler" that's no more complex than a
> HLL runtime interpreter, that takes something like the Forth fragment
> I posted earlier or something like
>
> (state default '(
>  (event state_entry '(
>   (cond (eq owner (llGetOwner)) ... ]
>
> These languages have, in common, the fact that it's really easy to
> compile other code into them. They are also high enough level that you
> don't need a validator: you can build a hard sandbox into the runtime.
>
> So then the client would compile your LSL into Forth or Scheme. If you
> wanted to write in the new underlying language directly, you'd do
> that. And you wouldn't need much of a library facility to create a
> canned "SL-Lua" or "SL-Ruby" runtime that you could call out to from
> the script, that wouldn't need to be replicated on the sim.
I like this. Really.
> Much safer than Mono. Much faster than LSL, especially for people who
> could work in the native language.
Anything named after a kissing disease is suspect in my book (and I said
as much to de Icaza at LinuxWorld in 2005). Reinventing .Net never made
sense to me, but that is a separate topic. Too much FOSS politics
involved in YAAL (Yet Another Abstraction Layer).

Lisp is really what I would like to develop in for larger projects in a
3d environment. Problem is that Lisp just never became 'popular' - no
marketing engine behind it. Sort of like Forth. Meanwhile, Logo had
better advertising (and THAT statement is for the older audience).

--
Taran Rampersad
[hidden email]

http://www.knowprose.com
http://www.your2ndplace.com
http://www.opendepth.com
http://www.flickr.com/photos/knowprose/

"Criticize by Creating" - Michelangelo
"The present is theirs; the future, for which I really worked, is mine." - Nikola Tesla

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [sldev] Re: LSL and geometry hierarchy issues

Mark Meijer-4
In reply to this post by Argent Stonecutter
On 21/01/2008, Argent Stonecutter <[hidden email]> wrote:
> Mark Meijer:
> > Actually I think Lua would be a brilliant candidate. I don't know
> > where you got the idea that it's heavy.
>
> Remember the constraints scripts run under.

All valid points, no doubt about it. And I'll have to admit that Lua
bytecode is not exactly known for being concise. But all things
considered, I still think Lua is a great candidate.


> First, concurrency.
>
> In a typical application where these scripting languages are used you
> typically have to deal with a few hundred concurrently executing
> scripts at the most. In SL, you have thousands... it's not unknown
> for a single avatar to have a thousand active scripts. That means
> that a context switch between one script at the lest can not be
> significantly more expensive than a subroutine call.

There are several ways in which concurrency of the level you describe
can be addressed with Lua, be it with built-in language features, a
cleverly programmed host, 3rd party libraries, or any combination
thereof. Depending on how you do it, even context switches may be a
non-issue.


> Second, migration.
>
> When a macro avatar with several hundred scripted prims crosses a sim
> border, every one of those scripts has to be serialized, copied to
> the new sim, restored, and restarted. The easiest and most efficient
> way to do this is to use relative pointers for everything, and have
> the virtual machine operate on that basis... then the memory image is
> automatically serialized. But converting an existing VM for do that,
> even in part, is daunting. It's hard enough that when I was faced
> with doing so last year (for Tcl) I bailed, and decided to use
> absolute offsets for shared memory segments... and even then it took
> me six months just to track down all the bugs caused by losing track
> of whether a pointer to a shared object or not and calling the wrong
> free().

Lua's VM would probably not need a lot of modification to support
this, if at all. Although I do think it will require a bit of code on
top of the core engine. And there is probably more than one way of
achieving this too. On the level of the VM, on the level of what is in
Lua called an environment, on the level of coroutines. Or even just a
simple custom table or datatype that houses everything you need, which
is a snap to add in Lua. With a little work, depending on the approach
taken, you can serialize the lot of it and re-instantiate it without
any real problems. What I'm not sure about is how it all would work
with Lua's garbage collector, but that's just because I'm not up to
date on how that thing works these days and I know there have been
some changes.


> Adding object-orientation makes the problem ten times harder, simply
> because of all the extra indirection that goes on.

Lua on itself is not an object oriented language, but it has a bunch
of meta features which enable the use of - among other things - object
orientation. And again, it allows this (and is actually done by lots
of people) in various different ways. So you can use OO, or not, as
you please, and the beauty of this is that it doesn't matter to the
underlying system. If you have a VM that can run the core Lua
language, and you can do this concurrently and serialize all over the
place and whatnot, all that (object orientation, and whatever else you
do with it) will automatically be supported. Because those meta
features are a handful of relatively simple, integral facilities of
the Lua language. A lot of the nice things you can do with Lua are, at
least in part, due to those meta facilities. They can be (and in fact
are extensively) used to add any number of features to your Lua
environment, without changing the core language, and therefore without
affecting the underlying system.


> And that's all ignoring the realtime issue... there's a classic hard-
> realtime deadline: a script can't be allowed to run over the end of a
> physics frame.

Depending on the taken approach to concurrency and a properly
sandboxed scripting environment, a Lua host can excercise a great deal
of control over who gets to run when and for how long. Lua is not
something I associate with hard-realtime problems, but neither is SL.
And if all else fails, creating a custom extension that handles this
specifically for SL should not be too difficult. At least in
comparison to many other scripting engines.
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [sldev] Re: LSL and geometry hierarchy issues

Taran Rampersad
In reply to this post by Argent Stonecutter
Argent Stonecutter wrote:
> Mark Meijer:
>> Actually I think Lua would be a brilliant candidate. I don't know
>> where you got the idea that it's heavy.
>
> Remember the constraints scripts run under.
>
> First, concurrency.
Yeah! another person said it!

> Taran Rampersad writes:
>> Honestly, I think that there needs to be more of a framework and API
>> solution with different languages available to utilize hooks.
>
> If you have several thousand scripts running in multiple external
> interpreters, using something like message passing (even in shared
> memory) to communicate with the physics simulator, I don't think
> you'll end up with as responsive an environment as you do in SL now.
I agree with you. That tangent of conversation was really to find the
middle ground of the present situation. I do like your thought on the
Lisp, though I have twisted it to MultiLisp.

As a sidenote, this is really an engaging conversation and is probably
the most fun I've had with hackspeak in the last 8 years. Its a lot more
fun when talking about what OTHER people should do. lol

--
--
Taran Rampersad
[hidden email]

http://www.knowprose.com
http://www.your2ndplace.com
http://www.opendepth.com
http://www.flickr.com/photos/knowprose/

"Criticize by Creating" - Michelangelo
"The present is theirs; the future, for which I really worked, is mine." - Nikola Tesla

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters