[Opensim-dev] Upcoming work on alternative client stack

Mon Aug 18 02:30:05 UTC 2008

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] On Behalf Of Dzonatas
Sent: Sunday, 17 August 2008 7:36 PM
To: 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

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