On Thu, Mar 29, 2007 at 07:29:35AM -0700, Ken Taylor wrote: > This seems like a very good optimization, given how string-heavy the system > is. Could string tables also be used to compress COD files more? How about > network optimization by having two sites "share" a string table (or have a > static standard string table of commonly used strings in the "core" > protocol?). Also ... are properties stored as strings at the moment or as > native bytes (I actually don't know this)? If they're stored as strings, > compressing them to native data structures would probably be a big win too > (same thing goes for properties with storing them in COD and sending them > over the network).
Presently there is support for having COD files gzipped by default, which helps a bit. The COD file format will need to be reworked to take advantage of s5 features anyhow. Properties are presently stored as strings, but in s5 will be stored in the native binary encoding. This is a major change since it requires that we define the set of primitive types that VOS will support. Indeed, this ties in directly with a general overhaul of the type system that I'm going to propose when I write about scripting. > [I also had another idea related to network optimization -- which is > unrelated to memory footprint. The idea is particularly for large worlds > with lots of objects to listen to: instead of listening update messages > sending the whole message string and object identification, etc, have an > "optimized listen" protocol, where a chosen-at-runtime "tag" is used to > identify a certain kind of update message coming from a specific object, and > that's all you need to have in the network traffic (other than the actual > updated values, of course). This could even be done transparently at the > network interface level] I think what you're describing is essentially packet compression by creating a dictionary during the session mapping short identifiers to common packet headers. A separate problem with updates at the moment comes from the fact that the client presently has to subscribe to each vobject individually, which is one source of memory overhead since this is often redundant. I've been mulling over ways of subscribing to changes in a subtree of vobjects without having to communicate with each one separately. > Could this also be extended to support persistant transparent caching of > remote sites that have been visited? Perhaps paired with a new method to > query certain information about vobjects, such as is-cacheable and > last-updated/version? Yes! I'm glad you mentioned caching, because that is another thing that is sorely lacking in s4 and needs to be designed for in s5. > Sounds reasonable... What reasons (other than asthetics/symmetry) are there > for properties to be first-class? Will a property object ever have children? > Will one ever be at site root with no other parent? Will one ever be a > meta-object other than "property"? I guess you could have two parents > sharing the same property if it's a big one ... Well, so you can share properties, and originally (in s3/s4) so we could have special properties like the file property (its value was bound to the contents of a particular file on disk) and extrapolated property (the property included velocity/acceleration, used for client-side movement prediction). It is a like like the notion of "boxed objects" in some object oriented languages like Java, C# and Ruby, where a primitive value like an integer is treated like a first class object which allows you to assign it to System.Object type references. > > Other strategies to make memory management easier will include a greater > > emphasis on copying semantics when the amount of memory involved is > > small. This avoids having to maintain reference counts, and we can keep > > simple data structures on the stack (and in L1 cache?) to avoid > > potentially expensive calls to the heap allocator. > > I don't think I understand this one.... Memory management is exceedingly difficult in C and C++, since if a data structure has multiple pointers going to it can be difficult to determine when it is appropriate to free() it. Concurrency makes this even worse, since you could have a thread still accessing that structure while it is being free()ed. Smart pointers and reference counts can help a lot, but they can be incredibly difficult to debug. For s5 I want minimize the amount of shared state (which I'll talk about in the next email about concurrency) and one way to do that is when copying data to someone else, to pass a copy rather than a reference. Another related technique will be the use of opaque identifiers rather than pointers where possible, so that if a vobject is freed in the background (or alternately, the object is swapped out) we don't dereference an invalid pointer. > Scalability is going to be hugely important if vos is ever going to support > a world-wide metaverse with large, interactive worlds. I'm glad you guys are > going to be focusing on the issue from the ground up. My goal for s5 is to be able to support one million vobjects on a single site, on reasonable hardware. We'll be doing benchmarks. -- [ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
signature.asc
Description: Digital signature
_______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
