Second thoughts about MONO

There is an error in your script.


Should be...

stuff = (stuff = []) + stuff + llList2CSV([object_title, NULL_KEY, count]);

Oops. I'll edit that... it's a transcription error. The results do appear to stand though -- I'd be interested what results others get with this and different examples. My point is that e.g. generating mandelbrot sets and quantum physics wave functions are waaaay faster but 99.9999999% of scripts don't do these kinds of manipulations.

Thanks for pointing out the error

/esc

I was worried it might affect runtime speed.

The big problem is that in LSL lists and strings are immutable. There just isn't much you can do about that without doing an extensive overhaul to how LSL works. I believe at this point it would be better (and easier) to rewrite LSL from the ground up then to try and fix LSL or shoe horn in new features. I think C# would be a better idea.

Uh-huh....so instead of potentially needing to re-compile all scripts, content makers would have to go back and re-WRITE all of their scripts in C#?

Yeah, that's gonna be a real easy sell for LL.

A lot of content creators might just stop. Granted, most scripters do have C/C#/C++ experience, but then again, I don't (unless Java counts). There's a definite risk of losing a lot of content, not to mention content creators, if they did that, especially if they move over and make the new VM the default one in the future. And that's before even getting into how difficult implementing that would be. You simply can't make large-scale changes like that, it's better to just make small changes that preserve compatibility, even if they're not the most efficient methods.

The current method for doing things is probably the best. It allows people to cross-compile their scripts easily, and makes it easy for us to do these tests to determine how efficient the LSL-Mono VM will be.

Yes, LSL is inefficient. Yes, LSL does not have some features (arrays, objects) that you might find in other languages. However, all too often the problem tends to be that some scripters simply don't bother trying to keep their scripts efficient because their attitude is "it's a faulty language so it's not my fault." Of course, I'm not talking about most of the people who post here (I've seen plenty of posts on squeezing as much efficiency out of scripts as possible), but I *have* spoken to scripters in-world who were quite brazen about that attitude and were certain that mono would save them. Quite frankly, I don't think that mono will fix poor coding.

And back to the topic at hand, my tests so far haven't found any differences in script time between the LSL-compiled versions of our products and mono-compiled versions, at least in mono sims. I'm quite skeptical that mono is going to increase efficiency much for us, but then again, our scripts are pretty damned efficient anyways.

Also, on a related note, what's with the "EPS" replacing "IPS" values? I know IPS was never a perfect way of measuring lag or efficiency, but it was very useful for comparing some types of objects, especially things like guns where you have a short period of intense script activity, rather than a long period of fairly latent activity. Is EPS supposed to just be a way of equalizing comparisons between the two machines? I've been using script time as a measurement as I'm not 100% certain how to look at this new feature?

The thing I keep coming back to, having worn a compiler design hat for a period in my dark past, is that there really isn't a whole lot of room to optimize. Yes, LSL was a hack form the get-go, but it was probably a lot more efficient than people were giving it credit for. Going from an interpreted bytecode language to one which can(does?) perform JIT compiling on bytecode, there's only so much optimization that can be done.

Generally, besides ditching the interpreter code itself (which is actually probably fairly simple, using table lookups for speed), interpreted -> compiled code obtains the largest speed advantages only in a certain small subset of possible use cases, most often in terms of iterated structures (ie, loops). In linear code which isn't repeated more often than 1-2% of total execution time, you won't note much difference, and you may actually note a slowdown, because of some particular overhead which the compiled version may have that the interpreted version has already taken care of by design.

There is also a large chunk of LSL functionality which is not tied to the execution speed of the language itself, but to sim<->viewer communications or sim<->database communications, et cetera.

As a result, a lot of the claimed "220 times speed increase" anecdotes are for EXCEEDINGLY NARROW use cases, compared to the overall use base. The vast majority won't see much of that speed increase at all, which is why I wish Babbage and Periapse would have advised caution when reporting results instead of being disingenuously enthusiastic about them.

Not at all. The Mono VM opens the door to supporting multiple languages simultaneously, all of which compile to the same underlying virtual machine instruction set. So there's no need to assume OLD scripts would have to be recompiled. However, it is quite possible that NEW features might be provided an interface in a new, more robust language (e.g. C#) and not in LSL.

I think a point that is being missed in this discussion of timers being slower or causing more lag or what not, is that you aren't going to notice a performance hit as a general end-user walking through a sim for the very simple fact that if 1 function out of the 1000s of others runs 5% slower, while the rest are running 100%+ faster... its going to counter-balance that and you will only notice an overall increase because the available resources the sim has to dedicate to running scripts increases significantly with that load being reduced on a broader spectrum.

You can't look at it and go "OH timers run 5% slower its going to destroy SL." look at the whole picture before you scream the sky is falling.

Frankly, it took 3 years to get to this point. I wouldn't start expecting CIL compilers for other languages for over a year... probably more.

/esc

Probably. But it DOES look likely that that is the next direction scripting will be heading for, however long it takes. I can wait, though I make no promises to do so patiently.

/me nods

However, it does strike me that javascript may be the best choice. I mean this is the 3d web 'n' all.

/esc

But I didn't do that! LOL

I just re-read what I posted (to make sure) and my "big picture" point is that event scheduling in general seems to be the issue - which affects a lot more than llSetTimerEvent().

best,
/esc

Ummmm, I think that you may be missing the larger point that a number of people are making here. It is only a few functions that will be running noticeably faster. Mostly these will be math-intensive loops that have generally been avoided in SL so far. Many ordinary scripts simply won't run any faster under mono than they do under LSL.

Numerous scripters here have been reporting that scripts haven't been running faster, and in some cases may be running slower on mono.

Now, in the future, the switch to mono will have an impact if it opens the door for math-intensive processes that previously would have lagged or crashed a sim. There's also the possibility that the new VM will make some interoperability issues easier, although who knows. However, much of the lag that scripts cause is due to script-simulator interaction.






Hehehe, "disingenuously enthusiastic" is such a wonderful term. But seriously, it kinda bothers me, for two reasons:

Firstly, because there are all sorts of idiots who buy the hype and are going to start pressuring scripters to switch to mono immediately even if it's buggy. Then they're going to think that mono means they can wear whatever scripted attachments they want without causing any lag....and then of course blame it on anyone else because *of course* their scripts are all mono so they CAN'T be laggy.

Secondly, it really makes me question their integrity and/or competence. They probably know better, so moreso integrity. I get that it's just a PR thing, but I don't remember Sidewinder saying anything that disingenuous during the H4 rollout. It actually makes me less interested in recompiling my scripts to mono.

The actual design of the LSL VM is pretty good, there was a lot of good thinking that went into it and that does show in it's efficiency. The big problem with LSO is that it has never been rebuilt from the ground up. LSO was built once and only had new features shoehorned in, meanwhile LSL got rewritten from the ground up resulting in LSL2.

Don't get me wrong, I'm not advocating that LSL should be dropped, only that LL could do a lot more for the community by not having to spend time reinventing the wheel. Let people who want to use LSL use LSL but free the rest of us from the hell of LSL.

Escort: There are lots of CLI languages, even Javascript.
http://en.wikipedia.org/wiki/CLI_Languages
http://en.wikipedia.org/wiki/Managed_JScript

P.S. Java is a C style language, C# and Java share the same roots and many of the same design ideals. C# was M$'s response to Java, they were able to learn from some of Sun's mistakes.

Uhh, I don't think I missed that point at all, since it is pretty much verbatim what I said. O.o

I'm pointing out what a general consensus of scripters are finding out now versus what LL has been saying about it from the beginning.



I know, it is the source material from which I am drawing these conclusions.



Those people already exist with just LSL. They will still get the same response from scripters they always received: "TINSTAAFL, now deal with it".



I don't think integrity or competence is the issue in this case (though, at times, competence clearly IS one of their primary issues in a great number of things they screw up; they would claim they were "learning" things that they REALLY should have learned before they ever entered the job market in the first place, but that's neither here nor there). What I think is the real issue is that they ate too much of their own dog food. Yes, people can become fanbois of their own efforts and hype, and ego can get a little bit out of control.

That's actually not too uncommon in the industry. There are some parts of a language, usually on the executable / object / target representation side, which don't change a whole lot, even though the language itself changes significantly. As you get closer to the metal, you have fewer and fewer people who understand why certain things are done a certain way, so even if there is cruft in there, few people have the time, knowledge, or mandate to tread only where angels dare.



I don't care if it is dropped or not, really. Well, except that my binaries will still need it to run at all, without a system-wide backend conversion.

In some ways, a focused, interpreted VM-based scripting language can still operate faster than the Mono implementation, so I would not just pan it out-of-hand. I also don't buy into the "reinventing the wheel" argument in the vast majority of cases. Making a better wheel, more suitable to task, or even simply learning how to to make the best wheel, all are excellent justifications for "reinventing" it.

Also, be careful what you wish for... some of us consider C++/C# a "hell" in and of itself, and would rather not trade one "hell" for another one.



..and make plenty more of their own.

Sorry, was responding to user Little Ming, whose quote was included in my post.

Yeah C++ is it's own variety of Hell no argument there. C# thankfully is nowhere near as insane (I truly hate C/C++ dependencies), sure it has it's quirks but every language does.

The great thing about C/C++ is that it makes you feel like a "leet haxor" even when you are achieving nothing. Or, in an alarming number of cases, *less than nothing*. So unfortunately it's a tool that's used widely and inappropriately by the self-impressed "hardcore"...

"C++ is primarily a systems programming language and its inbuit types reflect that"

Who said that? Why, not me of course, it was said by Bjarne Stroustrup (the inventor of C++).

/esc

I emphasized the critical part in this exceptional commentary that illustrates elegantly the point I wanted to convey. Programming language tends to influence us in ways we never really imagined, just like real language does.

It's something to think about the next time you are typing in a block of rather complex code. "Why am I doing it this way?"

I access my brain using pointers =)

Although most serious work that I've done has only ever been in Java and PHP, I'm quite fond of C++ as it lets me mix object-oriented design, with super-optimal programming such as the ability to provide hints to the compiler, yet still have portable code.

Of course it's a nightmare to get to grips with unless you learn it properly, as you can't just jump into a block of code and hope to understand it, as C has a lot of useful, but confusing symbols everywhere. It also doesn't hold your hand like C# and Java do, this means you have to be more careful as you program, but means you don't lose performance or memory to support exception handling you don't need and things like that.

If I got this right, given that scripts are compiled at the client, then what will be available in the next client open source release of indra should be enough to determine how to generate the bytecode required to bind to the now-complete(?) SL library calls currently used by the mono implementation of LSL... so, if I'm right, adding a new language could shortly be undertaken as a community effort/open source? Again, if I'm getting this correctly, then all that would be necessary for LL to do is to allow/add a bytecode-only upload.

Am I missing something here or is this broadly correct?

/esc

As far as I can recall, MONO code is compiled on the server and bytecode uploads have specifically been blocked, I cant quote my sources on the latter but it was in some early discussion of MONO. Legacy LSL will still be compiled on the client but to the old LSL run-time and new LSL (is there such a beast?) will compile on the server as if being compiled to mono. I did ask in the Rolling Restart thread if there was a new implementation of the Legacy LSL compiler/Run-time but did not get an answer.

Oooo.. you're gonna be in a world of hurt if you ever dereference NULL.



Most of the latest 3rd-gen languages have all the same capabilities. "holding your hand" doesn't necessarily mean loss of performance or memory, as you can turn off features you aren't using.

What you describe about the symbols I see as part of the problem. For example, I can jump into any Object Pascal program and rather quickly understand what is going on (unless the programmer went FAR out of his way to obfuscate it; a problem which no language can help with), since the quantity of symbols used, especially in an overloaded fashion, is quite minimal by comparison.

I find it rather funny, though, that one of the big upcoming features in Delphi is "operator overloading" and generics.

All this talk of potential languages and I hardly ever see Pascal mentioned. Where's the love! Don't know about anyone else but I can't code more than a handful of lines of C++ without introducing darn bugs, where as with Pascal I often write a whole page or two of code without a mistake. Of all the languages Pascal is the one I make least mistakes with. Paradoxically I prefer the syntax C++/Java/C# languages but I still think Pascal is worth considering. It's just a more inviting language to use IMHO, which is why it's (or was anyway, not sure what they use at colleges these days, anyone?) so heavily used to teach fundamentals at colleges. I think it would encourage more users to get their hands dirty scripting instead of catering to seasoned programmers.

Actually I'll push the boat out and suggest Pop-11 too. It's mainly an AI language but I used it for other things too. The reason it would lend itself to SL is because of its excellent pattern matching, and I liked the way it handled looping through lists too, and given SL code makes use of lists heavily the pattern matching would be an ideal extention. Never going to happen though

EDIT: wowahh, Talarus was reading my mind as I wrote that! Get out of my head.

/54/d3/279226/1.html#post2128416

I'm making that T-shirt now - I hope I won't have to wear it