CLR Binary

[lost_jedi]

Hey there,

I'd just like to commend you on your fantastic work and community!
I was just wondering if there were any versions of Newton 2.0 compiled with the CLR knocking about? I had a search around but could only find a thread that said you made one a while ago but never heard back from the guy.

All the best,

John

[martinsm]

Newton must do nothing additional to be used in CLR binary.
If you are talking about C++/CLR, then you can simply link to static Newton library like in regular C++. If you mean other .NET languages. You can use P/Invoke to call Newton into DLL. It works fine.

[lost_jedi]

Newton must do nothing additional to be used in CLR binary.
If you are talking about C++/CLR, then you can simply link to static Newton library like in regular C++. If you mean other .NET languages. You can use P/Invoke to call Newton into DLL. It works fine.

I'm using C# and have been using a Newton P/Invoke wrapper in my project for about a year now; I am just hoping that there is a CLR binary out there which could replace the indirection of my wrapper. Further, a CLR binary would, for instance, be deployable on the XBox360*.

*In theory!

[martinsm]

Afaik Newton is written in C++. So to port it to CLR would involve much effort. I don't see huge advantage of this. - it's unlikely that Julio would throw away his previous work on Newton, and move to completely new platform.

[lost_jedi]

That's a bit drastic mate! It is usually just a case of adding the /clr compiler flag. I'm fairly sure I read that Julio compiled a clr binary of it once, which lead me to believe he might be willing to do it again - assuming, like you say, it doesn't involve any throwing away of work.

[kallaspriit]

I think it's written in plain C, C++ is used for JointLibrary. Might be wrong

[Stucuk]

The interface is C style so that any language can interface with it(DLL anyway). But everything Julio has done is C++.

[Julio Jerez]

Further, a CLR binary would, for instance, be deployable on the XBox360*.

?
how can you tell me more?
I do not see how that could be possible since the CPU on the xbox and the PC are very different,
does CLR generate machine independ code, that gets conveter to binary at load time?
Please tell me more.
Yes I once added the CLR flag but I thionk is was pre xBox public SDK, 2.00 had never being buidl with that option, no one has asked for.


Newton is full blrown C++,
The element in the container libray are the same buidling block I use for Netwon, the only defference is that I prepend the with the prefix dg and in the SDK they uses prefix d
This is to avoid conflicts with C Linkage and someone replacing and libray and generate side effects.

[lost_jedi]

AFIK there are two main ways .NET supports C++ code.

(1) The old one, also known as 'managed extensions for C++' was how it was done in Visual C++ 2002/2003, although you can still use it with the /clr:oldSyntax flag. The code it generates is a mixture of native and MSIL code and would not work on the XBox for the reasons you mention.

(2) The new one, which is called C++/CLI, is supposed to be a much cleaner implementation. Of C++/CLI there are different modes of code generation.
(2.1) /clr -- An improved version of (1).
(2.2) /clr:pure -- Uses only the managed structures and stuff. Looks like C# with /unsafe.
(2.3) /clr:strict -- Generates type-safe, verifiable MSIL-only assembly, exactly like C# compiler without /unsafe.

Given I've seen code examples for the XNA which run with /unsafe, I'd be willing to wager that (2.2) and (2.3), being virtual machine instructions, the MISL will run on your XBox.

I found this on xboxreporter

The cpu for the Xbox 2 is rumoured to be designed to be a processor that can decode and execute instructions in Microsoft Intermediate Language (msil) while at the same time being able to run x86 code, to remain compatible with Xbox 1.

That said, I don't have an XBox so I can't try it for you to find out!

[lost_jedi]

Or perhaps not looks like its disabled on the 360 for security reasons: http://forums.xna.com/forums/p/13306/72181.aspx

[martinsm]

That's a bit drastic mate! It is usually just a case of adding the /clr compiler flag.

This wont help anything - at least for running on Xbox360.

Only /clr:pure generated code will run on xbox. But /clr:pure code requires that code is able to be compiled to 100% MSIL instructions. And that usually doesn't happen on C++ projects. Lot of C++ code will use natively generated code (x86/x86_64) when compiled as /clr.

[lost_jedi]

Just to be clear; I'm not interested in running on the 360. I'm just after trying out a native CLR binary on an x86/x86_64 machine so that I don't have the extra overhead of my P/Invoke wrapper. (assuming the C++/CLI is able to optimise as well as the native builds that is)

[Julio Jerez]

That's possible, I did before I can do it again.

what are the benifit of CLR? I do not undertant

[martinsm]

I'm just after trying out a native CLR binary on an x86/x86_64 machine so that I don't have the extra overhead of my P/Invoke wrapper. (assuming the C++/CLI is able to optimise as well as the native builds that is)

That is not the case with Newton. As far as I know Newton uses lot of optimizations inside - SSE, Multithreading, etc... All these require native code. Function that will use SSE will be generated in native code, not MSIL. Also any WinAPI function will be automagically PInvoke'd. So P/Invoke still will be invoked a lot of times. So better is just to P/Invoke just once per Newton function than inside Newton function many times.
Of course, Julio could exclude SSE code in CLR builds, but I think this will hurt performance a lot. CLR generated SSE code is not able to compete with hand written SSE code.

Julio: lost_jedi is talking about managed->unmanaged call overhead. If all the code would be compiled to CLR, then there would be no unmanaged (native) code - everything would be in .NET bytecode which is optimized by .NET VM at runtime to native code for executing it. But as I explained above that would happen if code would compile to 100% CLR code. If not, then it will still have managed to unmanaged code translations inside it.

[Julio Jerez]

does that includes intrisic SEE, becsue I remove all instace of asm in the code when I added 64 bit build, in 64 bit asm is not allowed only intrisics.


Oh I remember now, long time ago when I made a build with CLR for the people using true vision 3d the performance lost was really bad, they figured out a different way of using it.
no matter waht Micrisof say the CLR code is significanlly slower than plain c/c++