Memory Optimization Tips

Not sure how knowing this helps. Like what we know about in the wiki, strings are the way to go instead of lists.




I think we can all do alg anlaysis. But, again, interesting, but doesn't help. I rarely run into computational constrained situations, just time delays that Lindens put in. We have access to massive amounts of CPU but little to no memory. This will even get more magnified when MONO comes on the scene.

Except that the only way to communicate between scripts even in the same prim is link messages (AFAIK), which are pretty clunky if this was the expected scripting model. I do break up stuff into separate scripts if the stuff is independent. And I'm pretty new here so I haven't tried any complex communicating objects, though I expect to get there some day. But if parallelism is the preferred model, it would seem to me that some kind of shared memory between scripts, ideally with locking capabilities, would be a big help here. I don't think 1.7 is bringing anything like that. Will Mono have something along those lines?

I'd also like an answer to one of my questions, if anyone knows it - does making a library function call add the function's bytecode to the script's bytecode usage, or is that handled differently and not linked directly like user defined functions?

Doubtfu anything gets linked in, but for an authoritative answer you'd have to ask a linden.

Thanks.

Personally, I want our memory upped to 64k. That's what the Commodore had, and that's how big some of the early versions of Turbo Pascal were.

And then, with MONO, I just want them to give us a C and a C++ compiler. Then we can use languages that are industry standard.

Message-passing architectures, particulary asynchronous ones, take a bit of getting used to. The modeling tools help quite a bit, as does having a library of reusable components.



IIRC there was discussion that 1.7 was introducing some form of global memory. Have not overly paid attention, but you can probably find something with a forum search.



Having gotten home to confirm: LSL library functions are provided via external functions. You can test this fairly easily by defining a function of your own with identical parameters and return, and watching the free memory as you change from it to the LSL function. Additionally, the LSL functions are probably provided via special opcodes: the posted LSL grammar recognizes the LSL functions as keywords, and my test showed the bytecode size decreased when I switched to the LSL function.

(Forget C and C++, I want my Ada compiler...)

True. I'm not used to coding in an environment where messages are the only available form of IPC. I'm used to designing so common data stays in one place, everyone accesses it in a controlled fashion, and messages are used to signal events/changes, not pass the actual data around. I can't really visualize how one would ensure data consistency and avoid duplication/memory usage in a message-only environment like we have here. It seems to me that shared + lockable memory would be useful, but like you said, that's also what I'm used to working with, so maybe I'm just not thinking outside my box



Thanks.

Just woke up.



No, they are not linked in.

LL functions are called with one code, User functions with another.


here is the section taken from my LSL bytecode notes on functions

{"Function Syntax"
format:<return>0x63 0x5b <paramaters> 0x66 <offset> 0x5c <move>0x7011 0x08 <funciton call><func>
	<move> = sizeof(<paramater>) + <offset>, this is how far to move the stack
	{<return> = (variable types)
		<return> == 0x63 (integer, float, string, key, list)
		<return> == 0x64 (vector)
		<return> == 0x65 (rotation)
		<return> == () (void)
	}
	{<funciton call> = Call User Function 0x94
		<offset> = memory requirements of the functions.
		format: 0x94<func>
		<func> = 1 dword (4 bytes)
		{<mem req of <paramater>s + <offset>>(i can`t imagine how adding the <offset> could be valid but it is)
			rotation	0x10 bytes
			vector		0x0C bytes
			list			0x04 bytes
			key			0x04 bytes
			string		0x04 bytes
			float		0x04 bytes
			integer	0x04 bytes
		}
	}
	{<funciton call> = Call LL Function 0xD1
		<offset> = 0x00000000
		format: 0xD1<func>
		<func> = 1 word (2 bytes)
		{
			<return>	<function>
			0x63	llSin
			0x63	llCos
			0x63	llTan
			0x63	llAtan2
			0x63	llSqrt
			0x63	llPow
			0x63 	llAbs
			0x63 	llFabs
			0x63	llFrand
			0x63	llFloor
			0x63	llCeil
			0x63	llRound
			0x63 	llVecMag
			0x64	llVecNorm
			0x63	llVecDist
			0x65	llRot2Euler
			0x65	llEuler2Rot
			0x65	llAxes2Rot
			0x64	llRot2Fwd
			0x64	llRot2Left
			0x64	llRot2Up
			0x65 	llRotBetween
				llWhisper
				llSay
				llShout
			0x63	llListen
				llListenControl
				llListenRemove
				llSensor
				llSensorRepeat
				llSensorRemove
			0x63	llDetectedName
			0x63	llDetectedKey
			0x64	llDetectedOwner
			0x63	llDetectedType
			0x63	llDetectedPos
			0x64	llDetectedVel
			0x63	llDetectedGrab
			0x65	llDetectedRot
			0x63	llDetectedGroup
			0x63	llDetectedLinkNumber
				llDie
			0x63	llGround
			0x63	llCloud
			0x64	llWind
				llSetStatus
			0x63	llGetStatus
				llSetScale
			0x64	llGetScale
				llSetColor
			0x63	llGetAlpha
				llSetAlpha
			0x63	llGetColor
				llSetTexture
				llScaleTexture
				llOffsetTexture
				llRotateTexture
			0x63	llGetTexture
				llSetPos
			0x64	llGetPos
			0x64	llGetLocalPos
				llSetRot
			0x65	llGetRot
			0x65	llGetLocalRot
				llSetForce
			0x64	llGetForce
			0x63	llTarget
				llTargetRemove
			0x63	llRotTarget
				llRotTargetRemove
				llMoveToTarget
				llStopMoveToTarget
				llApplyImpulse
				llApplyRotationalImpulse
			0x64	llSetTorque
			0x64	llGetTorque
				llSetForceAndTorque
			0x65	llGetVel
			0x64	llGetAccel
			0x64	llGetOmega
			0x63	llGetTimeOfDay
			0x63	llGetWallclock
			0x63	llGetTime
				llResetTime
			0x63	llGetAndResetTime
				llSound
				llPlaySound
				llLoopSound
				llLoopSoundMaster
				llLoopSoundSlave
				llPlaySoundSlave
				llTriggerSound
				llStopSound
				llPreloadSound
			0x63	llGetSubString
			0x63	llDeleteSubString
			0x63	llInsertString
			0x63	llToUpper
			0x63	llToLower
			0x63	llGiveMoney <--doesn`t acutaly use the return
				llMakeExplosion
				llMakeFountain
				llMakeSmoke
				llMakeFire
				llRezObject
				llLookAt
				llStopLookAt
				llSetTimerEvent
				llSleep
			0x63	llGetMass
				llCollisionFilter
				llTakeControls
				llReleaseControls
				llAttachToAvatar
				llDetachFromAvatar
				llTakeCamera
				llReleaseCamera
			0x63	llGetOwner
				llInstantMessage
				llEmail
				llGetNextEmail
			0x63	llGetKey
				llSetBuoyancy
				llSetHoverHeight
			0x63	llStopHover
				llMinEventDelay
				llSoundPreload
				llRotLookAt
				llStringLength
				llStartAnimation
				llStopAnimation
				llPointAt
				llStopPointAt
				llTargetOmega
			0x63	llGetStartParameter
				llGodLikeRezObject <- stipulated, never proven
				llRequestPermissions
			0x63	llGetPermissionsKey
			0x63	llGetPermissions
			0x63	llGetLinkNumber
				llSetLinkColor
				llCreateLink
				llBreakLink
				llBreakAllLinks
			0x63	llGetLinkKey
			0x63	llGetLinkName
			0x63	llGetInventoryNumber
			0x63	llGetInventoryName
				llSetScriptState
			0x63	llGetEnergy
				llGiveInventory
				llRemoveInventory
				llSetText
			0x63	llWater
				llPassTouches
			0x63	llRequestAgentData
			0x63	llRequestInventoryData
				llSetDamage
				llTeleportAgentHome
				llModifyLand
				llCollisionSound
				llCollisionSprite
			0x63	llGetAnimation
				llResetScript
				llMessageLinked
				llPushObject
				llPassCollisions
			0x63	llGetScriptName
			0x63	llGetNumberOfSides
			0x65	llAxisAngle2Rot
			0x65	llRot2Axis
			0x63	llRot2Angle
			0x63	llAcos
			0x63	llAsin
			0x63	llAngleBetween
			0x63	llGetInventoryKey
				llAllowInventoryDrop
			0x64	llGetSunDirection
			0x64	llGetTextureOffset
			0x64	llGetTextureScale
			0x65	llGetTextureRot
			0x63	llSubStringIndex
			0x63	llGetOwnerKey
			0x64	llGetCenterOfMass
			0x63	llListSort
			0x63	llGetListLength
			0x63	llList2Integer
			0x63	llList2Float
			0x63	llList2String
			0x63	llList2Key
			0x64	llList2Vector
			0x65	llList2Rot
			0x63	llList2List
			0x63	llDeleteSubList
			0x63	llGetListEntryType
			0x63	llList2CSV
			0x63	llCSV2List
			0x63	llListRandomize
			0x63	llList2ListStrided
			0x64	llGetRegionCorner
			0x63	llListInsertList
			0x63	llListFindList
			0x63	llGetObjectName
			0x63	llSetObjectName
			0x63	llGetDate
			0x63	llEdgeOfWorld
			0x63	llGetAgentInfo
				llAdjustSoundVolume
				llSetSoundQueueing
				llSetSoundRadius
			0x63	llKey2Name
				llSetTextureAnim
				llTriggerSoundLimited
				llEjectFromLand
			0x63	llParseString2List
			0x63	llOverMyLand
			0x63	llGetLandOwnerAt
			0x63	llGetNotecardLine
			0x64	llGetAgentSize
			0x63	llSameGroup
				llUnSit
			0x64	llGroundSlope
			0x64	llGroundNormal
			0x64	llGroundContour
			0x63	llGetAttached
			0x63	llGetFreeMemory
			0x63	llGetRegionName
			0x63	llGetRegionTimeDilation
			0x63	llGetRegionFPS
				llParticleSystem
				llGroundRepel
				llGiveInventoryList
				llSetVehicleType
				llSetVehicleFloatParam
				llSetVehicleVectorParam
				llSetVehicleRotationParam
				llSetVehicleFlags
				llRemoveVehicleFlags
				llSitTarget
			0x63	llAvatarOnSitTarget
				llAddToLandPassList
				llSetTouchText
				llSetSitText
				llSetCameraEyeOffset
				llSetCameraAtOffset
			0x63	llDumpList2String
			0x63	llScriptDanger
				llDialog
				llVolumeDetect
				llResetOtherScript
			0x63	llGetScriptState
				llRemoteLoadScript
				llSetRemoteScriptAccessPin
				llRemoteLoadScriptPin
				llOpenRemoteDataChannel
				llSendRemoteData
				llRemoteDataReply
				llCloseRemoteDataChannel
			0x63	llMD5String
			0x63	llSetPrimitiveParams
			0x63	llStringToBase64
			0x63	llBase64ToString
			0x63	llXorBase64Strings
				llRemoteDataSetRegion
			0x63	llLog10
			0x63	llLog
			0x63	llGetAnimationList
			0x63	llSetParcelMusicURL
			0x64	llGetRootPosition
			0x65	llGetRootRotation
			0x63	llGetObjectDesc	
				llSetObjectDesc
			0x63	llGetCreator
			0x63	llGetTimestamp
			0x63	llSetLinkAlpha
			0x63	llGetNumberOfPrims
			0x63	llGetNumberOfNotecardLines
			0x63	llGetBoundingBox
			0x64	llGetGeometricCenter
			0x63	llGetPrimitiveParams
			0x63	llIntegerToBase64
			0x63	llBase64ToInteger
			0x63	llGetGMTclock
			0x63	llGetSimulatorHostname
				llSetLocalRot
			0x63	llParseStringKeepNulls
				llRezAtRoot
				llGetObjectPermMask
			0x63	llSetObjectPermMask
				llGetInventoryPermMask
			0x63	llSetInventoryPermMask
			0x63	llGetInventoryCreator
				llOwnerSay
			0x63	llRequestSimulatorData
				llForceMouselook
			0x63	llGetObjectMass
			0x63	llListReplaceList
				llLoadURL
				llParcelMediaCommandList
			0x63	llParcelMediaQuery
		}
	}
}

Some bytecodes to help explain the function call setup above

	0x08 		= 	pop dword and set that as the stack memory offset
	0x5B		=	push (stack address as?) a dword into the stack
	0x5C		=	push stack address as a dword into the stack
	0x63		=	declare 1 dword in memory, push pointer into stack
	0x64		=	declare 3 dwords in memory, push pointer into stack
	0x65		=	declare 4 dwords in memory, push pointer into stack
	0x66<dword>	= <dword> = <offset> = number of dwords in stack
	0x71<byte>	= '-'  	pop 2 variables push result [b, a] (with 'a' taken out last), a - b{<byte> = <Type = a><Type = b>
			{<byte>
				valid values: 0x11, 0x12, 0x21, 0x22, 0x33, 0x55, 0x66
			}
			{<Type>
				{void	0x0}
				{integer	0x1}
				{float	0x2}
				{string	0x3}
				{key	0x4}
				{vector	0x5}
				{rotation	0x6}
				{list	0x7}
			}
		}
	0x94<dword>	=	call user function number <dword>
	0xD1<word>	=	call LL function number <word> see "Function Syntax"

HMMMM.

Does the bytecode hit the client side?


I mean.. where did you get that / decompile that / etc from?

The client does the compiling.

All i can comment on (without digging a grave) is that the client compiles the script and uploads the script text and bytecode at the same time (you can see this if you examine the client logs). It has been reported on the forums that bytecode and script text can be seperated (via database problems).

There is a bigger issue here that would be exposed if i went into great detail.

I don't know assembly.

Good lord.

Now that's insecure!

Well.. I guess it is easily fixed.

But really .. now you have to do security checks on the scripts everytime they run in order to make sure it's safe code, rather then just once when you compile it.

I mean.. how often do people compile scripts? Not that often. Not like it's going to take down a sim or something.

Hmmm.. ok, maybe it could slow down a sim. Interesting trade offs.

I've drempt up some really perverse stuff to do in the bytecode, like use link messages and rewrite the bytecode while the script runs. Pointing multiple events to the same blocks of code. All sorts of fun evil stuff. Not really sure if you would leak stack memory if you didn't do proper cleanup before returning.

(After i completed my bytecode mapping project, I took up a new umbrella project that could have encompassed my bytecode project. This second project after talking with LL for an extended period, I came to the conclusion it was unsafe to talk about. So my answers will only cover information that is either publicly available or is unique to my bytecode mapping.)

Unsafe in that your physical safety will be endangered?

Unsafe in that you have a way to hack SL?

Unsafe in that you're worried LL is going to steal your ideas?

Unsafe in that there are plenty of race conditions?

How unsafe are we talking?

My only concern with this is pointers and memory allocation routines. Would you really want to unleash this? Considering that there is a lot of people scripting that don't really have even a basic udnerstanding of how LSL works? Provided there is some way to restrict the memory allocations to the script's memory, like what is already being done internall with LSL, I would love to be able to use pointers and variants. Especially arrays of pointers but I can also see the potential problems, and outright maliciousness, this might cause if it was released to the general public. I mean.. professional people in real jobs, in the real world still forget to release the memory they are using. I know there's already a way to cause a buffer overrun in the curent system but it's not in plain sight like the inclusion of pointers and other memory allocation routines are.

Nawww.... really?

That is an interesting question though. Since a script never really exits, you can't do garbage collection in the task exit block like you could with a normal OS. And embedded OS's often leave that out too. The only analogous concept I can think of is state changes, but if malloc'd memory is freed on every state change, that wouldn't be very useful, so that's not an answer.

And this may sound like heresy, but I actually like some of the things that LSL does differently from C Like having strings be built in data types, allowing concatenations and comparisons to look simpler in the source code. I'm asuming that the built-in handlers for these operations are as optimized as anything I could write. So I wouldn't really mind if we never got all the way to full-blown C. Add in arrays and user-defined types (and probably some other things I'm missing right now), and that'll be enough to make me happy, I think. Though malloc is still an interesting problem. They could put in something like C++'s reference, so you could get call-by-reference without having to give scripters access to pointers, the compiler would handle the internals. Though that might open it up to exploits, I don't know.

OO would be nice too, but I wonder how that would work with 16K. I don't have much experience with embedded C++ compilers, but the general sentiment among the engineers I work with seems to be that they're not as tight as C compilers. Not sure of the same thing applies to a VM environment like this one or not. IMO OO starts to become more and more attractive as the size and complexity of the design grows, but large and complex C++ code would be precisely where one would probably run into the 16K limit.

One of the design objects of CIL ("Common Intermediate Language", the .Net bytecode) is that it be fairly easy to check its validity and safety. If you want to punch up some of the discussions on "Managed Code", they usually assume C# but are relevent no matter what is being compiled to CIL. Basically: set the security policy appropriately, slap in memory and processor limits, and the extra power does not provide any new ways to screw up a sim.

Having seen bits of the LSL bytecode, someone should have started from Java bytecode rather than reinventing the wheel. I am definitely not optimizing to it, and I pity the poor schmuck who got stuck with that job. (Good grief LL, you might not want to implement the Self optimizations, but there are lines between that and making x86 look pretty)



Most embedded systems do not have hundreds a parallel threads running: sharing an incremental garbage collector between scripts reduces the effective overhead significantly. LSL itself is designed to not require a garbage collector (everything is either stack allocated or reference counted), so they can put of worrying about that for a while.

Compiling and optimizing OO for small footprint systems is a fairly well studied problem. C++ is really ugly to optimize, and most compilers do a disgustingly poor job of handling the more complex features (if you disable exceptions and RTTI, and avoid vtables, it is not all that bad). Look up Ada (I believe the 95 standard) for something that provides decent real-time and embedded OO.

Interesting. I'm not familiar with Ada, but I've heard that sentiment expressed before. Maybe they could implement some kind of simple OO. I don't consider exception handling or RTTI to be essential features of C++. Whatever litle embedded C++ I've dealt with tends to avoid the complex features anyway, just because the implementations are often so platform dependent.

Anyway... I'll stop derailing this thread now. Thanks everyone for answering my questions, it's been really educational.

lambda functions sure would be nice. I could save a tonne of bytecode memory with those.

Screw garbage collecting, let me manage my own memory

Of course we would keep LSL. It's simple, but it's good for newbies.

So, Strife, I'm just wondering how you got that bytecode. Did you redirect the SSL socket through a private server that made its OWN connection to the file server? Have I said to much?

We need assembly. That would be infinitely cool.

O_O that sounds like alot of work.

LL has an IP treasure chest, the contents of that chest is only valuable if A) whats inside is cept secret B) people think there is treasure inside. While the programers may innovate new things for the treasure chest, ultimately they don't control the chest. Piss off the gaurdians of the treasure chest and they will sick thier wolves on you.

I made comments like that in my first weeks. Since then I've come to realize that what we have is an OO platform like no other, it's just that our objects (or classes) are actual objects floating in virtual space. I've devised a pretty nice naming system that even let's me access properties (or functions) of my "class" objects a la objectname.propertyname (in linkmessages or chat channels depending on the architecture of the system). I know you're talking about OO integrated into the syntax of the scripting language itself, but I've been there and now I'm outside that box... look around in SL at all the objects. It's an object oriented environment.

As far as inheritence... say you have object X. You rez a copy of it, add some new linked prims or scripts or functionality or what have you. You now have object Y which has object X's properties plus some. Inheritence. You just didn't have to explicitly call it inheritence.

So if you start looking at it this way you can extend the analogies further and further and you'll start programming with methodologies that very closely resemble OO. The biggest difference really is the nature of the asynchronous messaging for inter-object comm. and some funky stuff inherent with a finite state machine. Our objects or classes are not chunks of code, they are floating thing-a-ma-bobs.

Hmm... very interesting. Thanks. I'll have to think about that. I've spent most of my career doing communications protocols on embedded targets, so I'm fairly confortable with FSMs and asynchronous communication/events/etc.



That's beautiful And you're right, I was talking about having the support built into the language. But that isn't essential, and one could still design/implement OO without it, like you have.

Once again, thanks for a thought-provoking post.

In that case, I'll take your advice and shut up.