User:Babbage Linden/Office Hours/2009 03 25

From Second Life Wiki
< User:Babbage Linden/Office Hours
Revision as of 04:25, 25 March 2009 by Nock Forager (talk | contribs) (New page: Transcript of Babbage Linden's office hours: '''Topics''' * Most of MONO script uses around 11KB. So it's not true Mono scripts "cost" 64KB and LSO script...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Transcript of Babbage Linden's office hours: 

 Topics
 * Most of MONO script uses around 11KB. 
   So it's not true Mono scripts "cost" 64KB and LSO scripts 16KB.
   There is no incentive to use LSO scripts LINK
 * We could add a function to return the usage of Mono scripts easily,
   but that's harder with LSO scripts LINK
[3:19] Morgaine Dinova: Babbage!

[3:19] Babbage Linden: hi everyone

[3:20] Qie Niangao: hello, Babbage!

[3:20] Nock Forager: Hi Babbage

[3:20] Opensource Obscure: phew!!

[3:20] Opensource Obscure: :D

[3:20] Simon Kline: hahah ello Babbage :D

[3:20] Morgaine Dinova: Hiya Babbage!

[3:20] Babbage Linden: sorry i'm a bit late, daylight saving has squashed the office hour in to our morning huddle until next week

[3:20] Opensource Obscure: we were crying about CG stopping doing Office Hours ... are you going to stop your meetings too?

[3:20] WolfPup Lowenhar: i went to CG's meeting to hear what was going on witht thw SL assets so i would know what to expect for dealing with the sim i co-manage

[3:20] WolfPup Lowenhar: morning babbage

[3:20] Babbage Linden: no, normal service will be resumed next week

[3:21] Morgaine Dinova: Hehe, any amount of time is better than none, late is fine :-))))

[3:21] Babbage Linden: when the office hours are 11AM my time

[3:21] Babbage Linden: and so don't collide with our 10AM huddle

[3:21] Opensource Obscure: cool! great : ) ... this is a good news.

[3:21] Morgaine Dinova: Excellent

[3:21] Babbage Linden: so, i've got lots of feedback about the script limits plans this week, which is great

[3:22] Babbage Linden: i wanted to reassure you all that we'll take all the feedback on board

[3:22] Morgaine Dinova: One line summary of expected limits?

[3:22] Qie Niangao: about those plans: is there (or is there to be) a kind of design-doc-in-process for those, perhaps on the wiki?

[3:22] Babbage Linden: and will be consulting with the community throughout the process

[3:22] Babbage Linden: we're not ready to talk about numbers yet

[3:22] Morgaine Dinova: kk

[3:22] Babbage Linden: but i can tell you how we're going to come up with them

[3:23] WolfPup Lowenhar: i know of a developer that is worrking about the limits now that he know about them

[3:23] WolfPup Lowenhar: worrying*

[3:23] Babbage Linden: we added logging to the simulator in 1.25 to find out the memory used by mono and lsl scripts across the grid

[3:23] Babbage Linden: by parcel

[3:23] Babbage Linden: xan linden is currently analysing the results

[3:24] Babbage Linden: and we're going to look at the allocations we need to support different percentages of current usage

[3:24] Babbage Linden: if we can we'd love to set the numbers so that we can support 100% of all current script usage

[3:24] Babbage Linden: so we turn it on and nothing changes, no one is using too much

[3:24] Babbage Linden: but, more likely there will be some outliers that use extreme amounts of memory

[3:25] Babbage Linden: that may have to rearrange their parcels

[3:25] Babbage Linden: but we'll keep those cases to a minimum

[3:25] WolfPup Lowenhar: like the people that have a few hundred scripts on a 512

[3:25] Babbage Linden: yes

[3:25] Babbage Linden: jack is also working on use cases for estate ownders

[3:26] Babbage Linden: who might want to rent out land with different multipliers

[3:26] Morgaine Dinova: It sounds very reasonable. Unbounded resource usage isn't sustainable.

[3:26] Babbage Linden: to create different skus of land for example

[3:26] Babbage Linden: or want to run administrative scripts on land they rent out

[3:26] Babbage Linden: we're hoping we can use an identical model to prims

[3:26] Babbage Linden: to keep it understandable

[3:27] Babbage Linden: it will be much easier to say script memory works like prims

[3:27] Qie Niangao: oh, hmm... I thought they were to be modeled after the llRequestURL() limits

[3:27] Babbage Linden: yes, qie, they will

[3:27] Morgaine Dinova: Eeek. Don't use the same model as for prims, as that's not sustainable either! Decouple from land acreage, or you have a severe problem ahead.

[3:27] Qie Niangao: cool, I like that, I think.

[3:27] Babbage Linden: which follows prims for land

[3:27] Babbage Linden: but also has pools per avatar

[3:27] Morgaine Dinova: No no no!!!

[3:27] Babbage Linden: if you can think of cases where that model isn't going to work, please let meknow

[3:27] Qie Niangao: right, the per-avatar limits *should* make vehicles less dangerous

[3:28] Babbage Linden: with a notecard if needs be

[3:28] Babbage Linden: that is clearly about script limits

[3:28] WolfPup Lowenhar: qie vheicles are not worn they are sat upon

[3:28] Babbage Linden: the other thing we're doing is looking at the memory we allocate to each simulator process

[3:29] Babbage Linden: to work out the maximum amount of memory we can reserve for scripts

[3:29] Babbage Linden: and how much needs to be used for physics, interest management and updates etc

[3:29] Qie Niangao: Wolf, it shouldn't matter: the URL limit works for sat-upon objects, too

[3:30] Qie Niangao: (I think)

[3:30] Babbage Linden: vehicles are a strange case

[3:30] Babbage Linden: they start off looking like seats

[3:30] Babbage Linden: but then change parcels

[3:31] Simon Kline: i do scripting classes where up to 25 people might be starting scripts at once, is that likely to be an issue with this?

[3:31] WolfPup Lowenhar: qie you have ot res a vhicle then 'sit on it to be able to do anything

[3:31] Babbage Linden: i can't remember how we handle the details of vehicle pool usage, i'd need to look it up

[3:31] Qie Niangao: in the forums, a huge part of the worry about this is that it will be problematic for vehicles... right now, the parcel prim limits are a killer for vehicles in sim-crossing conditions.

[3:31] WolfPup Lowenhar: that would be interesting to know

[3:32] Morgaine Dinova: Babbage: the acreage-tied model will land LL in extreme business trouble after interop. The problem is that inactive land acreage just costs disk space, unlike prims etc that represent CPU and bandwidth resources. Disk space is virtually free, and therefore third parties will be offering unbounded land acreage for next to nothing --- say 1 million m^2 estates for $1, because disk space costs nothing. You are in deep trouble if you cannot decouple your model from acreage to compete.

[3:32] Babbage Linden: simon, if all of your scripting pupils are cooperative, it shouldn't be a problem

[3:32] Babbage Linden: someone might accidentally use up too much memory, but you should be able to work out where things have gone wrong

[3:32] Simon Kline: cool ty :D

[3:33] Babbage Linden: morgaine, i don't think that's a problem

[3:33] Babbage Linden: at the moment pools will be tied to land

[3:33] Babbage Linden: as that's the model we have

[3:33] Morgaine Dinova: SL being non-competitive is not a problem?

[3:33] Babbage Linden: and people are familier with that model for prims

[3:33] Morgaine Dinova: Correct, it's the model you have now. You can't keep that model after interop.

[3:33] Babbage Linden: there would be nothing to stop us adding extra products that decouple pools from land

[3:34] Morgaine Dinova: Well you can keep it --- but you'd go out of business.

[3:34] Babbage Linden: but that would be a big decision to be taken by the product group

[3:34] Morgaine Dinova: Well bear it in mind. :-)

[3:34] Babbage Linden: the goal here is to avoid the tragedy in commons

[3:34] Babbage Linden: where everyone uses lots of script resources and eveyone suffers

[3:35] Morgaine Dinova: Yep. But in this case, the Commons has unlimited acreage.

[3:35] Babbage Linden: even worse: one region uses lots of resources and the other (unrelated) regions running on that host suffer as the machine swaps

[3:35] Babbage Linden: as the set of regions running on a host changes that can be difficult to diagnose

[3:35] Qie Niangao: a piece of confusion that may be easy to tie down: do Mono scripts necessarily use 64KB each now, compared to LSL2's 16KB? Or is that 64 dynamically allocated? And does this change after the limits?

[3:35] Babbage Linden: you can't even go to your neighbour and ask them to turn their usage down

[3:36] Morgaine Dinova: Well that's your statically tiled resource architecture to blame. I can't help you there, haha.

[3:36] Babbage Linden: as your neighbour may not be the problem

[3:36] Babbage Linden: qie, that is a really good question

[3:37] Babbage Linden: xan has already done some analysis and found that although we allow mono scripts 64KB

[3:37] Babbage Linden: most of them use around 11KB

[3:37] Babbage Linden: which is less than the 16KB we have to allocate for every LSO script

[3:37] Babbage Linden: so, if we were to introduce script limits

[3:37] WolfPup Lowenhar < knows of one set that is jus5t under the 64k mark

[3:38] Babbage Linden: and have Mono scripts "cost" 64KB and LSO scripts 16KB

[3:38] Babbage Linden: that is giving people an incentive to use LSO scripts

[3:38] Qie Niangao: (right, exactly my worry)

[3:38] Babbage Linden: which we don't want to do as they are actually less CPU and memory intensive than the equivalent LSO script

[3:38] Babbage Linden: so, we're thinking about that at the moment

[3:39] Morgaine Dinova: Very interesting

[3:39] Babbage Linden: and I'd love to hear your ideas on how we can properly align our costs with this system

[3:39] Babbage Linden: so, as you can see, there are lots of things to still work out

[3:39] Babbage Linden: and this is not going to happen any time soon

[3:39] Simon Kline: so you can't base it on over all memory size?

[3:40] Simon Kline: being used

[3:40] Qie Niangao: well, you could always make Premium memberships exempt from per-avatar script limits. :p

[3:40] Babbage Linden: one option would be to introduce memory request apis like the url apis

[3:40] Babbage Linden: that way Mono scripts that use less than 16KB could request 8KB or whatever

[3:41] Babbage Linden: and then their "cost" under this system would more closely match their actual cost

[3:41] Morgaine Dinova: I'm mostly looking at scripting from an interop angle, and this is all input that's bound to relevant to MMOX. Very interesting issue, how scripts can be made interoperable across systems.

[3:41] Babbage Linden: and they would become cheaper than LSO scripts, which would always cost 16KB

[3:41] WolfPup Lowenhar: one sugestion would be to look at the true average of scripts /parcel grid wide and then use that to figure the memory useage per sim according to there level open/homestead/full(4 or 5)

[3:41] Qie Niangao hears echoes of "malloc failed" "fork failed" etc.

[3:42] Babbage Linden: so, if you were scripting an object that just had a simple door opening script, you could make it Mono

[3:42] Babbage Linden: make it request 8KB and have it be cheaper than an LSO script

[3:42] Morgaine Dinova: Hehe, a "MALLOC_YouMustBeJoking" error :-)

[3:43] Babbage Linden: it would probably have to be along the lines of integer llSetMemoryUse(integer)

[3:43] Babbage Linden: which returned the amount of memory you actually got

[3:43] Babbage Linden: LSO scripts would always return 16K, regardless of what was requested

[3:43] Babbage Linden: as we can't change their size

[3:43] WolfPup Lowenhar: < wishes was able to find out the amount of memory his builds use

[3:44] Babbage Linden: that is another big issue wolfpup

[3:44] Qie Niangao: I think just the existence of limits will tidy-up a lot of messiness... how many running llSetTextureAnim() scripts must be on the grid now? ... but that raises the possibility of some lsl language extensions that could make scripts more memory efficient, or fewer.

[3:44] Babbage Linden: the current memory usage apis are poor

[3:44] Babbage Linden: we could add a function to return the usage of Mono scripts easily

[3:45] Babbage Linden: but that's harder with LSO scripts

[3:45] Babbage Linden: hence the current "high watermark" behaviour

[3:45] Babbage Linden wouldn't like to add a function that worked on Mono, but not on LSO

[3:45] Babbage Linden: but in this case, where you actually care about the differences between the different engines

[3:45] Babbage Linden: it may be acceptable

[3:45] Morgaine Dinova: Is the long-term plan to phase out LSO altogether?

[3:46] Babbage Linden: it would certainly make development easier

[3:46] Babbage Linden: and it would ensure that all new scripts use the more efficient engine

[3:46] Babbage Linden: so it makes sense

[3:46] Morgaine Dinova nods

[3:46] Babbage Linden: but, we'd need to make sure there were no mono specific bugs first

[3:46] Qie Niangao: i think adding features to Mono only would be fine, myself.

[3:47] Babbage Linden: we're nearly there, but i'd like to have a good few months of all clear before we started thinking about only allowing new scripts to use Mono

[3:47] WolfPup Lowenhar: there are lost of items out there still being sold that the orginal creators are not around any more so there is no way to redo the scripts because there no mod

[3:47] Babbage Linden: right, we would have to support old scripts on LSO

[3:48] Babbage Linden: but having all new scripts use Mono would mean we wouldn't have to worry about supporting new features on 2 platforms

[3:48] Babbage Linden: at the moment it means that often the implementations are sub optimal

[3:48] Babbage Linden: as we end up implementing features in unmanaged code

[3:48] Babbage Linden: so both LSO and Mono can call the same code path

[3:48] WolfPup Lowenhar: unless some linden want to go around to all the items on the grid and recomplie them to mono

[3:49] Babbage Linden: which means we need to make managed->unmanaged transitions for all features

[3:49] Babbage Linden: if new features only had to be supported, we could implement them in managed code where it made sense

[3:49] Babbage Linden: which would be more efficient

[3:49] Qie Niangao: /scripters, too, now will want to optimize for memory-limited Mono, not for LSO

[3:50] Babbage Linden: one of the things we've found making the scheduler changes which are now on aditi is that copying lists to the LSO representation

[3:50] Babbage Linden: so unmanaged API calls can work on them is very expensive

[3:50] Morgaine Dinova: In due course (but it could be many years), the burden of maintaining LSO will probably outweigh the perceived problem of losing old scripts.

[3:50] Babbage Linden: yes

[3:50] Babbage Linden: but we're along way off

[3:51] Morgaine Dinova: Aye

[3:51] Babbage Linden: some interesting numbers from xan's analysis

[3:51] Babbage Linden: Mono now makes up 10M of the 68M scripts running on the grid

[3:51] Morgaine Dinova: Wow!

[3:51] WolfPup Lowenhar: and there are morethan likely some LSO diehards out there still working in Lso

[3:51] Babbage Linden: and it's percentage of scripts is growing at about 2% per month

[3:51] Morgaine Dinova: I'm amazed --- excellent, so the population is moving over! Very cool

[3:52] Babbage Linden: so, we're a way off

[3:52] Babbage Linden: but things are moving in the right direction

[3:52] Babbage Linden: thanks everyone :-D

[3:52] WolfPup Lowenhar: all scripting i do is in mono

[3:53] Babbage Linden: it would be nice to know what %age of new scripts are Mono

[3:53] Babbage Linden: but that would require looking at asset creation dates as well as simulator data

[3:53] Babbage Linden: which is a lot more complicated

[3:53] WolfPup Lowenhar: but there in no whay to set that when your working on on just in your inventory and not in a object in world

[3:54] Morgaine Dinova: Hehe. You should have some developer charged with nothing but instrumenting everything in sight :P

[3:54] Babbage Linden: although i suppose we could instrument the compilation service....

[3:54] Babbage Linden: we are doing lots more analysis than we used to

[3:54] Babbage Linden: which is great

[3:54] Babbage Linden: and xan is excellent

[3:55] Morgaine Dinova: Indeed. What you don't measure, you don't really know, even when you think you do.

[3:55] Babbage Linden: agreed

[3:55] Babbage Linden: replacing fud with science is always a worthwhile upgrade

[3:55] Morgaine Dinova: Haha, Yep :-)))

[3:55] Babbage Linden: so, anyway, we're nearly out of time for this week

[3:55] Babbage Linden: any last thoughts or questions?

[3:56] Morgaine Dinova: Can I quote you, Babbage? That last line is a keeper :-)

[3:56] Simon Kline: this has been a cool and insightful office hour! :D

[3:56] Simon Kline: thanks :D

[3:56] Qie Niangao: I'd just encourage, when the time is right, to get a draft of design docs for this up on the wiki or somewhere the public can see and understand and maybe comment.

[3:56] Babbage Linden: sure, this is all covered by the wiki license

[3:56] Babbage Linden: once it makes it on to the wiki

[3:57] Babbage Linden: qie, yes, we will

[3:57] Babbage Linden: there will be lots of communication

[3:57] Qie Niangao: thanks. :)

[3:57] Morgaine Dinova: Excellent OH, many thanks Babbage :-)

[3:57] Babbage Linden: ok, i'm going to head off

[3:57] Babbage Linden: thanks again for coming

[3:57] Babbage Linden: and i hope to see some of you next week

[3:57] Qie Niangao: thanks for you time, Babbage--much appreciated.

[3:57] Nock Forager: Thanks, see you in next week.

[3:57] Opensource Obscure: ciao babbage - thanks!

[3:58] WolfPup Lowenhar: Thank Youuuuuu!! for the tip for having this meeting

[3:58] Babbage Linden: bye!#
Retrieved from "https://wiki.secondlife.com/w/index.php?title=User:Babbage_Linden/Office_Hours/2009_03_25&oldid=292982"