« HTTP Out | Main | Locales, Boundaries and Portals »

June 11, 2006

Comments

ironperth

Reconsider Mono.

I realise this posting is going to attract a lot of flames, so many apologies in advance for the controversial approach I am taking here.

However, I would like to put forth the notion that upgrading to Mono is not the correct approach, and instead, I would like to see more work done on improving what we have.

My reasoning is thus: SecondLife is a unique environment with very unique requirements. Trying to shoe-horn technology which will never be focused on a Second Life environment is a strategical error.

I also wonder, a bit, why Linden Lab (note the word *lab*) isn't moving forward in this particular area on its own, writing up a slew of patents which they richly deserve for leading the way in such an innovative manner.

In fact, the one benefit of Mono, allowing for any language, I am not sure is such a good idea, because again, SL has unique requirements.

In order to properly handle thousands of mobile micro-threads written by different and competing sources in one simulator space, it seems to me that you're going to want to have a narrow language that allows you to be comfortably assured of the specific behaviour of the scripted object.

I am also concerned that effort into improving what we have is not taking place because there is too much focus on reaching out to open source communities, which while admirable, probably has more theoretical than practical advantages.

Some examples of what could improve LSL significantly:

- Fix the memory leaks

I have posted about this before. There are memory leaks in LSL currently which *must* be addressed. You could successfully retrofit in Rational Rose + Visual Studio Team Edition and you'll still be missing the point if you can't fix the memory leaks. This should be the #1 quality issue. Quality can not occur while memory leaks are present.


- add pass by reference to LSL.

Right now, having to copy whole data structures onto the heap is severely limiting our usage of an already very constrained space. Huge amounts of needless memcopying is happening all over the grid, and pointless cycles are being wasted that are never being used. Fix this one thing, and you basically increase the memory available to our scripts by almost up to 100%


- Improve list handling routines in terms of performance and memory utilization.

Right now, we're all (well, most of us) have created our own string databases because the list routines that come with LSL are just no good. This takes up a lot of extra space and time could all be done via opcodes.

- JIT compilation for LSL opcodes. Yes, I know you want to use outside technology, but this problem has been tackled many times and has been written about extensively. It seems to me that it can't be that hard to write custom JIT for LSL. The other advantage, will be that the custom JIT will be well suited to the SL environment.

I know you might not want to waste all the work you have already done, however, it is not wasted time. I suspect you have learned huge amounts by investigating mono and how it all works.

Regards,

Iron.

Bob

I clicked on the link "Voodoo physics" on that silver bullet website and it seems the author of that website is a complete crackpot. He "proves" that Albert Einstein, Richard Feynman and other physicists are crackpots by saying the velocity of time equals dt/dt = 1. Doh, this guy doesn't have the slightest clue about what he's talking about.

Dave

Hi Jim hows things? Still in the US or are you back now?

I've got to agree with Bob. I'm not crazy about that silver bullet article. The thing that really told me he didnt understand what he's talking about is when he descibed software as bad and hardware as good. Whats he trying to say you dont make bugs in hardware?
I think that software is just an extension of the hardware.
Does he even know how hardware is created? Its created, or at least specified using software. I've used signal based design tools and yes it is possible still to create bugs.

He's incredibly arrogant and I fail to see where any of the evidence to back his ideas are

Oh and @Iron
How do you know that those things would improve LSL? How do you know memory is leaking? Doesn't Mono have JIT? Do you even know what JIT is?

Blind Wanderer

@Iron
LSL's memory issues stem from fragmentation. LSL does not defragment it's memory when it deallocates memory. For example... 'string a="test";a=a+a;' when executing the second statement 'a' is not deallocated until after 'a+a' is calculated and the result of 'a+a' is not moved down into the memory space; meaning that the space used by 'a' originally is lost. To reduce the leak the space leaked in the above exmple there is a solution: 'string a="test";a=(a="")+a+a;'. In some scripts this is actualy what I do to help free up memory.

LSL needs better memory management, it would be a great benifit if there were a defragmentation function or the memory was dynamicly allocated (which is what Mono does). Adding memory defragmentation to LSL currently would be difficult. One requires the VM to track the types of data allocated. The other menthod requires the compile to build an input for the function at compile time and limit the function so it is not called in functions (only events). Neither are nice solutions.

Adding pass-by-refrence is technicaly complicated and would require an entirely new class of operators; not to mention retrofitting existing operators.

The reason lists are slow, is because pass by value is used; lists have to be entirely duplicated when passed to a function. As to the overhead caused by using a list, it is reasonable.

JIT would be interesting for LSL. It would have to be done by the sim (or some other machine) and not the client for security reasons (currently LSL is compiled to LSL bytecode by the client).

ironperth

Yes, I suspect it's a fragmentation problem as well, hard to tell since I don't have the code in front of me, but the result is always going to be the same.

Pass by reference solves a lot of these time & space problems of course. And yeah, a new op and functions would be required, but those will not break old scripts.

As for the JIT, yes, it would have to run on the SIM, but then it would have to run on the sim for Mono as well.

Interestingly, a better JIT solution might be to do compilation while the SIM is being underused (ie: no avs present). I wonder if scheduling JIT compilaton will be that easy with mono.

ironperth

Great tip, btw:

'string a="test";a=(a="")+a+a;'

Blind Wanderer

Actually the actual compiling could be done by the client for Mono; because Mono can enforce memory protection & restrict dependencies.

----

I have a few issues with TSB ("The Silver Bullet"), it claims that hardware is reliable but doesn't take into account history, only his own experiences. In the mid 90's Intel released the Pentium, which the first version had defective floating point math capabilities, it was a PR disaster for Intel (Pentium FDIV bug). It is not uncommon for memory to fail, which can go unnoticed, for those doing serious work it can become apparent (like video encoding).

TSB argues that the brain is reliable, this is really splitting hairs; yes errors in logic do not lead to system failure, but they don't lead to the correct answer either. It is a popular opinion that large errors of judgment should result in death; hence capital punishment. It is a reasonable assumption that those who partake in this opinion would be all for large errors of judgment resulting in automatic termination. On the flip side, mankind has spent enormous amounts of time devising ways to eliminate these automatic terminations (allergies, cancer, old age to name a few).

TSB's handling of dependencies is flawed. It can produce code that loops infinitely without any particular malice from the programmer. Something like this would do it... 'event b(a 0){a = -a;}' event 'b' would trigger event 'c' which would intern trigger event 'b'. What is important here is that both events would be automatically registered when the modules were initiated; they don't even have to be in the same module. If they were in different modules, both modules separately could be 100% bug free, only together would there be a problem.

There are instances where something that looks like an event infinite loop is really just a form of recursion; it would be desirable. Then there is the issue where something uses a variable, but doesn't depend on it. Such as a block of code that writes to a log file with a time-stamp; it doesn't need to be executed for every change of the system clock. So in reality we are dealing with 3 types of dependencies: recursive, non-recursive and ignorable. The type of dependency would have to be tracked by the programmer. Which is the crux of the problem. TSB's main argument is that it simplifies dependencies, which it does not; the programmer is still required to know how dependencies should be connected.

What TSB should be advocating are better tools and languages for mapping dependencies. The amount of time wasted doing context switching seems to me to be the death knell for this approach.

----

Having spent the time now to read the article, and do some research into multitheading I have come to the belief that LSL's design is flawed because it encourages the existence of a large number of scripts. This is bad for a number of reasons: the limits of threads and the issues with implementing micro-threading (limited number of threads & switching between micro-threads), wasted blocks of memory (16k for a notecard script), event storms leading to lag (complex scripts sets need to communicate), wasted CPU time on pointless operations (code required to decode and encode data to send it between scripts).

If I were designing a scripting language for SL today, It would have:
1) looser memory constraints
2) scripts effect the properties of other prims (llSetLinkPrimitiveParams)
3) scripts to have public types, variables, functions, classes & function pointers.
4) not have function delays longer then event delays
5) binary communications between scripts.

Most if not all of these could be done with Mono without too much difficulty.

Blind Wanderer

sorry part of my even example got eaten during editing, supposed to be:
'event a(a 0){a = -a;}'

Blind Wanderer

*waves fist at the comment engine for eating his example*
event a(a gt 0){a = -a;}event b(a ls 0){a = -a;}

ironperth@gmail.com

It's the constraints that set us free.

ironperth@gmail.com

Also, are you referring to the JIT or the AOT done on the client?

Jim Purbrick

OK, The Silver Bullet article was just something found on the web and found thought provoking, not necessarily right or backed up with evidence. It's not worth reading too much in to its tealeaves as regards the work on Mono scripting. (I will put a disclaimer like this at the top of similar posts in future!)

The work on microthreading Mono is necessary as the VM needs to support the many scripts that have been already written in LSL, but Mono will also allow looser memory contraints. There will still need to be a mechanism for rationing script memory in a region, but no requirement for a script to be broken up in to multiple scripts due to an arbitrary 16K limit on script size.

ironperth@gmail.com

Well, hopefully you don't increase the overhead per script in order to make this happen.

I'd hate to lose the capability to create many small scripts.

Blind Wanderer

I normaly wouldn't have put so much into a comment on a source. I agree with you on the corrolations between LSL's current layout and that of TSB, which was why the lengthy comment. Some of the logic i hoped would have direct applications with LSL.

ironperth@gmail.com

Does anyone know who implemented the current virtual machine we're using?

Blind Wanderer

One of the Four. Not Andrew; I just don't remember. Been way to long. The answer got wiped with the great scripting forum accident of '04.

desdemona

At the risk of compounding irrelevancies, I will respond to Bob (of June 12).

No, the voodoo article does not seem know what it is talking about. The time variable is not 'on a par with the three spatial coordinates'. Nor is the t variable to be regarded as co-extensive with time in the conventional sense. Nor does one take derivatives of vectors with respect to components of vectors. Rather, the invariant proper time, which is a derived parameter that corresponds to experiential time, is used for vector differentiation. Nevertheless, critiques of the time travel ideas (crackpot is a bit overstated) have substance. Time travel and its companion concept, warp drive, all require theoretical conditions which turn out to be non-realizable in a physical world. Perhaps they are possible in SecondLife, smiles.

pregnancy

http://www.pregnancy.net.

in Pregnancy, Pregnancy Symptoms,detailed list of pregnancy Test is... biz. yahoo.comStages
Of symptomsPregnancy Calendar, Follow your pregnancy weekSig Of Pregnancy,early pregnancy
symptoms and signs Calculator,You can use this calculatorPregnancy Test,Result Pregnancy
Pregnancy Stages and SIGNSEctopic Pregnancy.

hertte

I agree with you on the corrolations between LSL's current layout and that of TSB, which was why the lengthy comment. Some of the logic i hoped would have direct applications with LSL.

Visit

let go to blogging :) Don't work too hard!

Home

Oh yeah.

Visit

Call me!

Go

All the best.

Site

Beautiful as usual.....hope you enjoy a lot !

Site

I have no idea about this.

The comments to this entry are closed.