Can you write code directly in CIL ???

[Peter Olcott]

{snip}

Oh, Peter....

Since you didn't say "our" project I assume you spent 2000 8 hour
man-days (5.4794520547945205479452054794521 years) without taking a
day off on your project.

Would you mind telling us how many lines of code are in your 16,000
hour project? I'm sure one, such as yourself, who pays great
attention to detail will know the exact count.

I'd like to calculate how long it took you to write that 100 line
function.

I think you're full of BS, troll...

Time will tell.

 

[Peter Olcott]

{snip}

Oh, Peter....

Since you didn't say "our" project I assume you spent 2000 8 hour
man-days (5.4794520547945205479452054794521 years) without taking a
day off on your project.

Would you mind telling us how many lines of code are in your 16,000
hour project? I'm sure one, such as yourself, who pays great
attention to detail will know the exact count.

I'd like to calculate how long it took you to write that 100 line
function.

I think you're full of BS, troll...

Credibility like belief and disbelief are fallacious conceptions, they each
cause conclusions to be drawn based on necessarily insufficient information.

 

[Peter Olcott]

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.

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.

| 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.

Of course I would do it this way, yet I would not even proceed along the
learning curve path of .NET / C# if I did not at least have this last resort as
an option. There is great disagreement here whether or not this is an option.
What it seems to be is an option that few here are aware of.

--
Hope this helps
Jay [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


|
| | >
<<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.
|

 

[Peter Olcott]

I want to advise that you first study the framework details. You are wanting
to write the IL yourself which would be better than the C# compiler
generated output, and you dont yet know about verified code, details of GC,

http://vstte.inf.ethz.ch/pdfs/vstte-hoare-misra.pdf
This was written by microsoft research about verified code, apparently you must
be talking about something else. This will not be fully implemented for at least
twenty years.

 

[Peter Olcott]

I want to advise that you first study the framework details. You are wanting
to write the IL yourself which would be better than the C# compiler
generated output, and you dont yet know about verified code, details of GC,

Google and Google groups doesn't know about it either. I wonder what that means?

 

[Jay B. Harlow [MVP - Outlook]]

Peter,
| The project has already been determined to be feasible. This stage is
assessing
| whether or not converting it to C# .NET is feasible.
You misunderstand!

What I stated in the message, and you seem to have missed:

It would seem to me that if these 100 lines are the "critical" lines to your
process, then taking the time to convert them to C# would be paramount for
determining the feasibility of using C# for the project.

In other words I would build a C# prototype to determine if C# was going to
work or not! Likewise with managed C++ or IL.

| 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.

You can use my web site below to contact me if you would like to hire my
services on converting the 100 lines...

--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


|
message
| | > 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.
|
| The project has already been determined to be feasible. This stage is
assessing
| whether or not converting it to C# .NET is feasible.
|
| >
| > 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.
|
| 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.
|
| >
| > | 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
| >
| >
| > | > |
| > | | > | >
| > <<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.
| > |
| >
| >
|
|

 

[Peter Olcott]

Peter,
| The project has already been determined to be feasible. This stage is
assessing
| whether or not converting it to C# .NET is feasible.
You misunderstand!

What I stated in the message, and you seem to have missed:

It would seem to me that if these 100 lines are the "critical" lines to your
process, then taking the time to convert them to C# would be paramount for
determining the feasibility of using C# for the project.

It looks like C# will not be feasible, but Managed C++ might be feasible.
http://msdn.microsoft.com/msdnmag/issues/04/05/VisualC2005/
Microsoft has focused their attention on providing optimization to managed C++
because this was the quickest way to provide the best optimization.

Now that I have a copy of Visual Studio 2005, with its purported much better
optimizations, I could make this sort of test. My purpose here was to see which
learning curve path I would need to proceed with. .NET or COM. I can't afford
the time to proceed down both these paths. If I proceed down both these paths
and find that the current path is infeasible, I am out of time and can't
complete the project. For this reason I needed to know if it was feasible to
write code directly in CIL, as a backup plan just in case the compiler
optimizations are not good enough. If this is true, then I can take the time to
learn .NET so that I can convert this 100-line function to .NET, otherwise I
must find some other way to determine which of these two paths to take in
advance. I guess that another scenario could be a .NET component wrapper with
unmanaged code at its core. There would only need to be one transition to the
unmanaged code, and one transition back form the unmanaged code. Since .NET has
such a simpler component model than COM, this approach might also prove to work.
The latest version of Visual Studio has a managed version of the STL. This would
further reduce my learning curve.

In other words I would build a C# prototype to determine if C# was going to
work or not! Likewise with managed C++ or IL.

| 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.

You can use my web site below to contact me if you would like to hire my
services on converting the 100 lines...

--
Hope this helps
Jay [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


|
message
| | > 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.
|
| The project has already been determined to be feasible. This stage is
assessing
| whether or not converting it to C# .NET is feasible.
|
| >
| > 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.
|
| 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.
|
| >
| > | 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
| >
| >
| > | > |
| > | | > | >
| > <<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.
| > |
| >
| >
|
|

 

[Jay B. Harlow [MVP - Outlook]]

Peter,
| It looks like C# will not be feasible, but Managed C++ might be feasible.
| http://msdn.microsoft.com/msdnmag/issues/04/05/VisualC2005/
| Microsoft has focused their attention on providing optimization to managed
C++
| because this was the quickest way to provide the best optimization.
Just remember one of the strengths in .NET is that you can create solutions
(applications) that leverage multiple languages.

You could create the bulk of your application in C#. You could write the
time critical part in Managed C++, you could write the UI in VB.NET. They
all get compiled into .NET Assemblies (an EXE or DLL that contains IL code).
The JIT compiler doesn't really care what languages created the assemblies.


--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


|
message
| | > Peter,
| > | The project has already been determined to be feasible. This stage is
| > assessing
| > | whether or not converting it to C# .NET is feasible.
| > You misunderstand!
| >
| > What I stated in the message, and you seem to have missed:
| >
| > It would seem to me that if these 100 lines are the "critical" lines to
your
| > process, then taking the time to convert them to C# would be paramount
for
| > determining the feasibility of using C# for the project.
|
| It looks like C# will not be feasible, but Managed C++ might be feasible.
| http://msdn.microsoft.com/msdnmag/issues/04/05/VisualC2005/
| Microsoft has focused their attention on providing optimization to managed
C++
| because this was the quickest way to provide the best optimization.
|
| Now that I have a copy of Visual Studio 2005, with its purported much
better
| optimizations, I could make this sort of test. My purpose here was to see
which
| learning curve path I would need to proceed with. .NET or COM. I can't
afford
| the time to proceed down both these paths. If I proceed down both these
paths
| and find that the current path is infeasible, I am out of time and can't
| complete the project. For this reason I needed to know if it was feasible
to
| write code directly in CIL, as a backup plan just in case the compiler
| optimizations are not good enough. If this is true, then I can take the
time to
| learn .NET so that I can convert this 100-line function to .NET, otherwise
I
| must find some other way to determine which of these two paths to take in
| advance. I guess that another scenario could be a .NET component wrapper
with
| unmanaged code at its core. There would only need to be one transition to
the
| unmanaged code, and one transition back form the unmanaged code. Since
..NET has
| such a simpler component model than COM, this approach might also prove to
work.
| The latest version of Visual Studio has a managed version of the STL. This
would
| further reduce my learning curve.
|
| >
| > In other words I would build a C# prototype to determine if C# was going
to
| > work or not! Likewise with managed C++ or IL.
| >
| > | 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.
| >
| > You can use my web site below to contact me if you would like to hire my
| > services on converting the 100 lines...
| >
| > --
| > Hope this helps
| > Jay [MVP - Outlook]
| > .NET Application Architect, Enthusiast, & Evangelist
| > T.S. Bradley - http://www.tsbradley.net
| >
| >
<<snip>>

 

[Peter Olcott]

Peter,
| It looks like C# will not be feasible, but Managed C++ might be feasible.
| http://msdn.microsoft.com/msdnmag/issues/04/05/VisualC2005/
| Microsoft has focused their attention on providing optimization to managed
C++
| because this was the quickest way to provide the best optimization.
Just remember one of the strengths in .NET is that you can create solutions
(applications) that leverage multiple languages.

You could create the bulk of your application in C#. You could write the
time critical part in Managed C++, you could write the UI in VB.NET. They
all get compiled into .NET Assemblies (an EXE or DLL that contains IL code).
The JIT compiler doesn't really care what languages created the assemblies.

I just hope that the 2005 compiler fulfills its optimization claims.

--
Hope this helps
Jay [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


|
message
| | > Peter,
| > | The project has already been determined to be feasible. This stage is
| > assessing
| > | whether or not converting it to C# .NET is feasible.
| > You misunderstand!
| >
| > What I stated in the message, and you seem to have missed:
| >
| > It would seem to me that if these 100 lines are the "critical" lines to
your
| > process, then taking the time to convert them to C# would be paramount
for
| > determining the feasibility of using C# for the project.
|
| It looks like C# will not be feasible, but Managed C++ might be feasible.
| http://msdn.microsoft.com/msdnmag/issues/04/05/VisualC2005/
| Microsoft has focused their attention on providing optimization to managed
C++
| because this was the quickest way to provide the best optimization.
|
| Now that I have a copy of Visual Studio 2005, with its purported much
better
| optimizations, I could make this sort of test. My purpose here was to see
which
| learning curve path I would need to proceed with. .NET or COM. I can't
afford
| the time to proceed down both these paths. If I proceed down both these
paths
| and find that the current path is infeasible, I am out of time and can't
| complete the project. For this reason I needed to know if it was feasible
to
| write code directly in CIL, as a backup plan just in case the compiler
| optimizations are not good enough. If this is true, then I can take the
time to
| learn .NET so that I can convert this 100-line function to .NET, otherwise
I
| must find some other way to determine which of these two paths to take in
| advance. I guess that another scenario could be a .NET component wrapper
with
| unmanaged code at its core. There would only need to be one transition to
the
| unmanaged code, and one transition back form the unmanaged code. Since
.NET has
| such a simpler component model than COM, this approach might also prove to
work.
| The latest version of Visual Studio has a managed version of the STL. This
would
| further reduce my learning curve.
|
| >
| > In other words I would build a C# prototype to determine if C# was going
to
| > work or not! Likewise with managed C++ or IL.
| >
| > | 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.
| >
| > You can use my web site below to contact me if you would like to hire my
| > services on converting the 100 lines...
| >
| > --
| > Hope this helps
| > Jay [MVP - Outlook]
| > .NET Application Architect, Enthusiast, & Evangelist
| > T.S. Bradley - http://www.tsbradley.net
| >
| >
<<snip>>