Re: Can you write code directly in CIL ???
"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @tsbradley.net> wrote in message
news:%23w4YrBAD GHA.1312@TK2MSF TNGP09.phx.gbl. ..[color=blue]
> Peter,
> | That would take more time that I can afford to spend right now.
> PMFJI: I would think the amount of time you have spent battling your cause
> in *this* thread and the other thread, you could have translated the code
> itself to C# & timed it. I further suspect you could have come close to
> converting the code with ILDASM and hand tweaked the IL itself.
>
> | I already did
> | that with native code 6.0 and 7.0. Even this is too slow. Because
> benchmarks
> | indicate that C# can be 450% slower on nested loops (my code is mostly
> nested
> | loops), I wanted to look into solving this problem in advance.
> I would "solve" this problem by converting the code, do some profiling &
> timing on the converted code, and going from there! I would convert to C#
> first, if C# proved to be too slow, I would then consider a unsafe C#,
> followed by Managed C++ class library, as a last resort I would consider a
> hand tweaked IL class library. My concern with hand tweaked IL would be when
> the JIT was updated with better optimization algorithms which conflicted
> with my hand tweaking, the 32bit JIT behaved differently then the 64bit JIT,
> or the JIT behaved differently based on processor...
>
> Remember to time the C# code outside of the VS IDE and use a Release build.
> As the C# compiler doesn't optimize Debug builds & JIT compiler won't
> optimize any code run under the IDE.
>
> | This is just the
> | feasibility study stage.
> It would seem to me that if these 100 lines are the "critical" lines to your
> process, then taking the time to convert them would be paramount for
> determining the feasibility of the project.[/color]
The project has already been determined to be feasible. This stage is assessing
whether or not converting it to C# .NET is feasible.
[color=blue]
>
> IMHO I would not use some generic C# benchmark to decide if the project is a
> go or no go. I would prototype (translate) the critical code & time that.[/color]
There is a learning curve involved in this that might hurt my chances of
ultimate success. This is the point in time where I decide to proceed down the
C# .NET path or remain on the native code C++ path. I can't afford to spend the
time learning C# and .NET, and then converting even this part of the project to
later find out that C# and .NET were not the way to go. At this stage I am
determining which of these two paths to take.
[color=blue]
>
> | I might be forced to digress to unmanaged code.
> I would only digress to unmanaged code, once C#, unsafe C#, Managed C++ &
> hand tweaked IL all proved (*proved*) to have performance issues.
>
>
> --
> Hope this helps
> Jay [MVP - Outlook]
> .NET Application Architect, Enthusiast, & Evangelist
> T.S. Bradley - http://www.tsbradley.net
>
>
> "Peter Olcott" <olcott@att.net > wrote in message
> news:NSDsf.3809 2$QW2.25345@duk eread08...
> |
> | "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
> | news:%23mzM%23V $CGHA.2644@TK2M SFTNGP09.phx.gb l...
> | >
> <<snip>>
> | > Again this is all based on what you read on the internet (NG's etc) not
> on
> | > personal findings, while my findings are based on real test runs.
> | > Please do us and yourself a favor, translate your 100 line C++ (or
> whatever)
> | > code to C# and run it and compare the time it takes with a similar run
> of your
> | > C code.
> |
> | That would take more time that I can afford to spend right now. I already
> did
> | that with native code 6.0 and 7.0. Even this is too slow. Because
> benchmarks
> | indicate that C# can be 450% slower on nested loops (my code is mostly
> nested
> | loops), I wanted to look into solving this problem in advance. This is
> just the
> | feasibility study stage. I might be forced to digress to unmanaged code.
> |
>
>[/color]
"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @tsbradley.net> wrote in message
news:%23w4YrBAD GHA.1312@TK2MSF TNGP09.phx.gbl. ..[color=blue]
> Peter,
> | That would take more time that I can afford to spend right now.
> PMFJI: I would think the amount of time you have spent battling your cause
> in *this* thread and the other thread, you could have translated the code
> itself to C# & timed it. I further suspect you could have come close to
> converting the code with ILDASM and hand tweaked the IL itself.
>
> | I already did
> | that with native code 6.0 and 7.0. Even this is too slow. Because
> benchmarks
> | indicate that C# can be 450% slower on nested loops (my code is mostly
> nested
> | loops), I wanted to look into solving this problem in advance.
> I would "solve" this problem by converting the code, do some profiling &
> timing on the converted code, and going from there! I would convert to C#
> first, if C# proved to be too slow, I would then consider a unsafe C#,
> followed by Managed C++ class library, as a last resort I would consider a
> hand tweaked IL class library. My concern with hand tweaked IL would be when
> the JIT was updated with better optimization algorithms which conflicted
> with my hand tweaking, the 32bit JIT behaved differently then the 64bit JIT,
> or the JIT behaved differently based on processor...
>
> Remember to time the C# code outside of the VS IDE and use a Release build.
> As the C# compiler doesn't optimize Debug builds & JIT compiler won't
> optimize any code run under the IDE.
>
> | This is just the
> | feasibility study stage.
> It would seem to me that if these 100 lines are the "critical" lines to your
> process, then taking the time to convert them would be paramount for
> determining the feasibility of the project.[/color]
The project has already been determined to be feasible. This stage is assessing
whether or not converting it to C# .NET is feasible.
[color=blue]
>
> IMHO I would not use some generic C# benchmark to decide if the project is a
> go or no go. I would prototype (translate) the critical code & time that.[/color]
There is a learning curve involved in this that might hurt my chances of
ultimate success. This is the point in time where I decide to proceed down the
C# .NET path or remain on the native code C++ path. I can't afford to spend the
time learning C# and .NET, and then converting even this part of the project to
later find out that C# and .NET were not the way to go. At this stage I am
determining which of these two paths to take.
[color=blue]
>
> | I might be forced to digress to unmanaged code.
> I would only digress to unmanaged code, once C#, unsafe C#, Managed C++ &
> hand tweaked IL all proved (*proved*) to have performance issues.
>
>
> --
> Hope this helps
> Jay [MVP - Outlook]
> .NET Application Architect, Enthusiast, & Evangelist
> T.S. Bradley - http://www.tsbradley.net
>
>
> "Peter Olcott" <olcott@att.net > wrote in message
> news:NSDsf.3809 2$QW2.25345@duk eread08...
> |
> | "Willy Denoyette [MVP]" <willy.denoyett e@telenet.be> wrote in message
> | news:%23mzM%23V $CGHA.2644@TK2M SFTNGP09.phx.gb l...
> | >
> <<snip>>
> | > Again this is all based on what you read on the internet (NG's etc) not
> on
> | > personal findings, while my findings are based on real test runs.
> | > Please do us and yourself a favor, translate your 100 line C++ (or
> whatever)
> | > code to C# and run it and compare the time it takes with a similar run
> of your
> | > C code.
> |
> | That would take more time that I can afford to spend right now. I already
> did
> | that with native code 6.0 and 7.0. Even this is too slow. Because
> benchmarks
> | indicate that C# can be 450% slower on nested loops (my code is mostly
> nested
> | loops), I wanted to look into solving this problem in advance. This is
> just the
> | feasibility study stage. I might be forced to digress to unmanaged code.
> |
>
>[/color]
Comment