[sldev] Opening the server source?
Dzonatas
dzonatas at dzonux.net
Tue Jul 3 10:50:59 PDT 2007
I've benchmarked fast compilations. One of the first steps to speed-up
up compilations tremendously is to use a fully mapped and state written
LR parser. When you use bison/yacc, you get as far as the tables being
generated. Bison/yacc also has the rarely used features to map all the
states and put it in a very nicely detailed output format. Those state
maps can be used to design a highly efficient parser. One that can
compile on-the-fly much faster than the default, the straight bison/yacc
created look-up table. For one, you get the full C/C++ compiler
optimization with the specially designed state maps for which the
default created look-up table prevents.
It appears hinted on Babbage's website that the ability to compile
scripts under VS, or such, would be possible in-order to better optimize
the executable. I highly doubt there real is any time savings for such
import process in comparison to what a faster parser can do. Especially,
when it comes time where one would like to take those same scripts and
allow them to work efficiently on sims that don't speak Mono.
I heard a rumor that Sun wanted to offer a Java enabled SL sim, but I
haven't heard of the LSL to Java compiler.
The only reason why you really want to keep these executables
pre-compiled is to hide the source. In thinking in terms of a sim that
might be running a business that does tons of monetary transactions in a
day, I highly doubt that sim would want something like Mono or Java
compiled programs on its sim because Mono and Java feature unmanaged
pointers for their speed. Not only is that a disaster waiting to happen,
I bet it takes more time to try to validate unmanaged pointers than it
would to compile on-the-fly the right way without any unmanaged pointers.
Oh wait, these are just fictional businesses, like I'm just a fictional
peon.
Chance Unknown wrote:
> i thought the point was that the bytecodes stored with the scripts
> would be in CIL (or MSIL for gates fanboys), allowing the binary image
> to be transported around without the need to recompile it.
>
> wasnt that the ooooooo thing babbage linden was working on?
>
> On 7/3/07, Dzonatas <dzonatas at dzonux.net> wrote:
>>
>> LOL not even. It can be completely transparent, if desired, all in
>> SL. Just
>> like Mono enabled sims, it would be limited to those, however.
>>
>> One feature I've had built-in to Atomatrix from the start is the
>> ability to
>> compile on-the-fly (or just-in-time). A simple flag that an LSL
>> script is
>> compilable and validated is all that is needed to effectively handle
>> on-the-fly compilation. It validation tracking is needed, we could add
>> resources to track origination of the validator, like a PGP stamp.
>>
>> This is a very useful tool. For example, lets say I want to take a
>> script
>> compiled in LSL, to a sim that uses Mono and use it there. It would
>> recompile when it arrives at that sim.
>>
>> Same thing for the event to take that Mono-compiled LSL script or to
>> a sim
>> that uses Atomatrix. When it arrives, it gets recompiled.
>>
>> That way each sim can easily use the best local implementation and not
>> worry about foreign compilations.
>>
>> =)
>>
>>
>>
>> Chance Unknown wrote:
>> So are you suggesting we need visual studio to script our prims now?
>> Um no
>> thanks, ill stick with SL.
>>
>>
>> On 7/3/07, Dzonatas < dzonatas at dzonux.net> wrote:
>> > Adam Frisby wrote:
>> > > Argent Stonecutter wrote:
>> > >> IN fact you've got an LSL to Mono compiler on your disk right now.
>> > >
>> > > We do? I thought LL were keeping that internal since it's
>> > > simulator-only stuff?
>> > >
>> >
>> > Kewl! I could make a LSL to Atomatrix compiler.
>> >
>> > Mono/.NET and Sun's Java are nice, but they fall short of the more
>> > advanced object-orientated systems. Mono/.NET and Java are more of a
>> > object-oriented program language rather than an object-orientated
>> > program environment.
>> >
>> > --
>> > Power to Change the Void
>> > _______________________________________________
>> > Click here to unsubscribe or manage your list subscription:
>> >
>> /index.html
>> >
>>
>>
>>
>> --
>> Power to Change the Void
>
>
--
Power to Change the Void
More information about the SLDev
mailing list