[Opensim-dev] Upcoming work on alternative client stack

Frisby, Adam adam at deepthink.com.au
Mon Aug 18 04:27:02 UTC 2008


I don’t know either are fully necessary actually.

Personally I suspect the performance problems here are likely to be something behaving badly rather than a limitation on the runtime itself.

Adam

From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Dzonatas
Sent: Sunday, 17 August 2008 9:30 PM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Upcoming work on alternative client stack

Then, may I guess, some available options are:
* "safe" platform-specific native libraries that provide handles (hHandle style) to a packet subsystem
or
* re-write the transport to a portable implementation that performs/scales under CIL

First option requires management of platform portability, which APR can help and probably reaches all platforms that CIL runs on. Exceptions are a pain, however.

Second option would be easy on the server side, but even if implemented in CIL the support of it would require implementation in the viewers to switch between either transport.

I'm sure I'm not the first to suggest these on this list.

Frisby, Adam wrote:
Using unsafe blocks though is generally considered a bad idea(tm), and has a good chance of breaking compatibility with things though.

Regards,

Adam

From: opensim-dev-bounces at lists.berlios.de<mailto:opensim-dev-bounces at lists.berlios.de> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Dzonatas
Sent: Sunday, 17 August 2008 7:36 PM
To: opensim-dev at lists.berlios.de<mailto:opensim-dev at lists.berlios.de>
Subject: Re: [Opensim-dev] Upcoming work on alternative client stack

If unsafe blocks are allowed, then shuffle optimizations could be used. It would only be advantageous if the data is streamed. The packets are probably accumulated in a way that would cause more overhead just to sort them and stream them. If there are ones that can be arranged, then it may be practical.


Melanie wrote:

Not really. Two memory accesses to retrieve 2 values packed into one

byte are 2 accesses. in C#, C++, unsafe blocks or even assembly.

They remain inefficient.



Melanie





Kyle Hamilton wrote:



Could the unpackers be implemented more efficiently if they could run

in unsafe blocks?



-Kyle H



On Sun, Aug 17, 2008 at 6:33 PM, Melanie <melanie at t-data.com><mailto:melanie at t-data.com> wrote:



Hi,



specific types, as we have now. What is it you don't like about what

we have now? With the framework we have to work with (C#) the

current implementation seems the best one we can get.

I have already shown in chat how unpackers lose efficiency with LL's

weird bitpacked data fields. This would show less performance, not

more. So I wonder what the point is?



Melanie





Mike Mazur wrote:



Hi,



On Mon, 18 Aug 2008 01:49:51 +0100

Melanie <melanie at t-data.com><mailto:melanie at t-data.com> wrote:





if the packets are structs/arrays, be careful of boxing issues. You

would have no advantage from that if you have to eat the boxing

overhead instead.



Hm, that's a good point. I guess since Packet is a descendant of

object, no performance hit occurs.



What would be a good way to get around this?



Mike

_______________________________________________

Opensim-dev mailing list

Opensim-dev at lists.berlios.de<mailto:Opensim-dev at lists.berlios.de>

https://lists.berlios.de/mailman/listinfo/opensim-dev







_______________________________________________

Opensim-dev mailing list

Opensim-dev at lists.berlios.de<mailto:Opensim-dev at lists.berlios.de>

https://lists.berlios.de/mailman/listinfo/opensim-dev





_______________________________________________

Opensim-dev mailing list

Opensim-dev at lists.berlios.de<mailto:Opensim-dev at lists.berlios.de>

https://lists.berlios.de/mailman/listinfo/opensim-dev







_______________________________________________

Opensim-dev mailing list

Opensim-dev at lists.berlios.de<mailto:Opensim-dev at lists.berlios.de>

https://lists.berlios.de/mailman/listinfo/opensim-dev













________________________________






_______________________________________________

Opensim-dev mailing list

Opensim-dev at lists.berlios.de<mailto:Opensim-dev at lists.berlios.de>

https://lists.berlios.de/mailman/listinfo/opensim-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080818/d3ad917a/attachment-0001.html>


More information about the Opensim-dev mailing list