Mono 1.2.6 and Ice

[michi]

Thanks for the tip. Someone on the Mono mailing list mentioned the bind() option to me too. I'll try this out. If it works, that'll get rid of the P/Invoke in this case.

We are using P/Invoke in a number of other places to work around limitations of .NET, and we also use P/Invoke for protocol compression. Getting rid of all of these might be difficult.

Cheers,

Michi.

[kwaclaw]

Originally Posted by michi

Thanks for the tip. Someone on the Mono mailing list mentioned the bind() option to me too. I'll try this out. If it works, that'll get rid of the P/Invoke in this case.

We are using P/Invoke in a number of other places to work around limitations of .NET, and we also use P/Invoke for protocol compression. Getting rid of all of these might be difficult.

Cheers,

Michi.

It probably requires some study as to which managed API is a good replacement for some of your interop calls. I just had a quick look, and maybe there are a few avenues worth looking at:

1) For SetConsoleCtrlHandler, the Console.CancelKeyPressEvent would be an alternative, as long as all you care about is capturing Ctrl+C and Ctrl+Break.

2) It looks as if Guid.NewGuid() does the same as UUIDCreate in rpcrt4.dll.

3) It seems there is also a managed alternative for libbz2.dll:
.NET Zip Library #ziplib (SharpZipLib)

Karl

[matthew]

How much of a performance cost are you willing to bear? Some of the marshaling code is also unsafe -- this could be replaced with safe code but its quite a bit slower.

What environments you are considering that require fully manged code?

[kwaclaw]

Originally Posted by matthew

How much of a performance cost are you willing to bear? Some of the marshaling code is also unsafe -- this could be replaced with safe code but its quite a bit slower.

What environments you are considering that require fully manged code?

We have an internal ASP.NET site that runs assemblies in semi-trusted mode. That excludes unsafe code and native interop. We are also considering running one of our apps from a web server (to simplify deployment). Though this app is currently not using ICE, I would not want to exclude ICE in the future simply because it can only run in a fully trusted context. I would also think that in Silverlight 2.0 (which apparently will have Socket support) using full IceCS instead of the HTTP bridge would be advantageous.

I have looked at your ByteBuffer class, the only place where I found unsafe code. I think the overall performance impact might not be as bad. It appears the unsafe code is mostly used for marshaling value types. For example, once could replace the unsafe getShort() and putShort() methods with this (untested!) code:

private const UInt16 ByteLoMask = 0x00FF;

public short getShort()
{
  unchecked {
    checkUnderflow(2);
    int ret;
    if(NO._o == _order)
    {
      ret = (_bytes[_position] << 8;
      ret |= _bytes[_position + 1];
    }
    else
    {
      ret = _bytes[_position + 1] << 8;
      ret |= _bytes[_position];
    }
    position += 2;
    return (short)ret;
  }
}

public ByteBuffer putShort(short val)
{
  unchecked {
    checkOverflow(2);
    if(NO._o == _order)
    {
      _bytes[_position] = (byte)(value >> 8);
      _bytes[_position + 1] = (byte)(value & ByteLoMask);
    }
    else
    {
      _bytes[_position + 1] = (byte)(value >> 8);
      _bytes[_position] = (byte)(value & ByteLoMask);
    }
    _position += 2;
  }	
  return this;
}

with no significant performance loss.

Karl

[michi]

I agree that getting rid of the P/Invoke calls and the unsafe code would be nice. I wasn't aware that there is a .NET compression library available now--it's worth a try.

It will still be difficult to get rid off all the P/Invoke code though. We are using it for monotonic time, and CancelKeyPressEvent doesn't deal with window closure, logoff, and shutdown events (which SetConsoleCtrlHandler does).

Cheers,

Michi.

[matthew]

Originally Posted by kwaclaw

...

with no significant performance loss.

Karl

Its also possible to use BitConverter. At any rate, for sure its slower depending on what your application is doing (for example, marshaling an array of shorts or similar). The question is whether this matters to you

[kwaclaw]

Originally Posted by matthew

Its also possible to use BitConverter. At any rate, for sure its slower depending on what your application is doing (for example, marshaling an array of shorts or similar). The question is whether this matters to you

From my experience, .NET optimizes quite well, and since there is also a little overhead pinning memory (as in the 'fixed' statement), I did some benchmarking myself, using your ByteBuffer, but adding safe variants of putInt(), getInt(), putIntSeq() and getIntSeq(). I thought a performance difference would show up more clearly for ints than for shorts. The safe variants are coded like what I outlined previously. I built the app under VS 2005 in release mode, as debug mode is actually slower for this kind of application.

In my measurements, the safe code was most of the time *faster* than the unsafe code (it varied from one test run to the other). I also uncovered one specific *huge* performance issue with your code: if it has to reverse the byte order, the unsafe code is more than 10 times as slow as the safe code. This is normally the case on little-endian CPUs, i.e. almost always. The reason I think is the use of all those Buffer.SetByte/GetByte calls that are obviously not inlined by the compiler.

My CPU is an Athlon x64 dual core 3600.
If you like, I can send you the VS 2005 project (just tell where to) so that you can check for yourself and try it on other CPUs.

Karl

[kwaclaw]

Originally Posted by michi

I agree that getting rid of the P/Invoke calls and the unsafe code would be nice. I wasn't aware that there is a .NET compression library available now--it's worth a try.

It will still be difficult to get rid off all the P/Invoke code though. We are using it for monotonic time, and CancelKeyPressEvent doesn't deal with window closure, logoff, and shutdown events (which SetConsoleCtrlHandler does).

Cheers,

Michi.

I could not find any P/Invoke calls that are time related. Where should I look?

Regarding SetConsoleCtrlHandler : It is only used in your helper class, so it is not an essential part of IceCS. Maybe one could spin off non-essential classes into a separate assembly?

Karl

[michi]

Originally Posted by kwaclaw

In my measurements, the safe code was most of the time *faster* than the unsafe code (it varied from one test run to the other).

I benchmarked this fairly extensively when I initially wrote the C# implementation. Back then, the unsafe version was faster than than the safe one. But that was several iterations of the compiler and run time ago, so this may have changed in the mean time.

I also uncovered one specific *huge* performance issue with your code: if it has to reverse the byte order, the unsafe code is more than 10 times as slow as the safe code. This is normally the case on little-endian CPUs, i.e. almost always. The reason I think is the use of all those Buffer.SetByte/GetByte calls that are obviously not inlined by the compiler.

I'll have a look at this too. It may well be that doing this differently will be faster now with the later version of the compiler and run time. Note that the byte order on the wire is little-endian--for little-endian CPUs, no byte swapping should take place.

If you like, I can send you the VS 2005 project (just tell where to) so that you can check for yourself and try it on other CPUs.

Yes, that would be useful. Can you just email me the code please?

Thanks,

Michi.

[kwaclaw]

Originally Posted by michi

Yes, that would be useful. Can you just email me the code please?

Thanks,

Michi.

I e-mailed the code to the e-mail address on your home page, hope that is the correct one.

Karl