NET framework and hyperthreading/MMX/SSE/....

[Olaf Baeyens]

Will future .NET frameworks JIT use the hyperthreading, dual core and
MMX/SSE/SSE2/SSE3 instructions of the processor if I double click on a .NET
program?

I know that the new C++ of Visual Studio 2005 have these hyperthreading
compiler optimizing options that splits a loop in multiple hyper threads
while the programmer does not need to know hyperthreading
..

 

[Daniel O'Connell [C# MVP]]

Will future .NET frameworks JIT use the hyperthreading, dual core and
MMX/SSE/SSE2/SSE3 instructions of the processor if I double click on a
.NET
program?

I know that the new C++ of Visual Studio 2005 have these hyperthreading
compiler optimizing options that splits a loop in multiple hyper threads
while the programmer does not need to know hyperthreading
.

It is possible, but I know of no current plans to provide any sort of
parallel looping(I don't know that the JIT itself would know enough to do so
either). But then they don't really tell us anything anyway, .

For what its worth, dual core and hyperthreaded processors are supported by
the OS, so you just have to do the threading yourself. I assume waht you
want is compiler support for parralellizing loops? Something like OpenMP?

 

[Olaf Baeyens]

For what its worth, dual core and hyperthreaded processors are supported
by

the OS, so you just have to do the threading yourself. I assume waht you
want is compiler support for parralellizing loops? Something like OpenMP?

This is true, but it would be nice if older none-multi theaded programs
would also speeded up using these hyperthreading features. If OpenMP is
implemented in the .NET CLR 2.x.

 

[Daniel O'Connell [C# MVP]]

This is true, but it would be nice if older none-multi theaded programs
would also speeded up using these hyperthreading features. If OpenMP
is
implemented in the .NET CLR 2.x.

Ya it would be nice, wouldn't it, . I'm just not sure that the JIT has
enough contextual information to determine what can safely be calculated in
parallel. OpenMP uses a number of pragmas to determine what the compiler
does, forcing the developer to explicitly define much(all?) of it. Could the
JIT safely do that work without that developer provided information?

Coincidentally, I was looking at parallelization as a possible extension to
C# a few weeks ago, using OpenMP as a bit of a model. I was playing with
syntax similar to:

parallel for (private int i = 0; i < 1000; i++)
{
list = GetFactorsOf(i);
}

parallel is actually a block and could be written parallel { for ...}.
Private within the parallell block would define that variable as private to
the individual thread and so on.

It is just a work in progress amongst my piles of C# ideas, but I figured
the coincidence reason enough to mention it. Thoughts?

 

[Olaf Baeyens]

Ya it would be nice, wouldn't it, . I'm just not sure that the JIT has

enough contextual information to determine what can safely be calculated in
parallel. OpenMP uses a number of pragmas to determine what the compiler
does, forcing the developer to explicitly define much(all?) of it. Could the
JIT safely do that work without that developer provided information?

Couldn't the JIT somehow inplement some statistics about the program running
like what methods are used more often?
And then either dynamically recompile that part and optimize to speed up
even more, or store the data so that next time your program gets run and
compiled then it uses that statistics to get a better optimization? So the
more you use the program the faster it gets fine-tuned on your behaviour?
Just an idea. ;-)

I really do believe that .NET programs one day could outperform conventional
none-.NET programs because of the JIT compiler be able to optimize depending
on the real user in the field opposed to the optimizing of the programmer
that thinks that the user would use it this way.

Coincidentally, I was looking at parallelization as a possible extension to
C# a few weeks ago, using OpenMP as a bit of a model. I was playing with
syntax similar to:

parallel for (private int i = 0; i < 1000; i++)
{
list = GetFactorsOf(i);
}

parallel is actually a block and could be written parallel { for ...}.
Private within the parallell block would define that variable as private to
the individual thread and so on.

It is just a work in progress amongst my piles of C# ideas, but I figured
the coincidence reason enough to mention it. Thoughts?

You mean "paralel" is a keyword indicating that it is safe to run in
paralel?
It sounds good but it might give problems when you have methods inside that
is not safe for paralel executing.
I don't think it can be implemented that easily.

 

[Daniel O'Connell [C# MVP]]

Couldn't the JIT somehow inplement some statistics about the program
running
like what methods are used more often?
And then either dynamically recompile that part and optimize to speed up
even more, or store the data so that next time your program gets run and
compiled then it uses that statistics to get a better optimization? So the
more you use the program the faster it gets fine-tuned on your behaviour?
Just an idea. ;-)

I might be able to, I don't think I know enough about JIT's to really say,
.

I really do believe that .NET programs one day could outperform
conventional
none-.NET programs because of the JIT compiler be able to optimize
depending
on the real user in the field opposed to the optimizing of the programmer
that thinks that the user would use it this way.

I think they will as well, as far as net performance goes. On a given
architecture, I suspect static compilers will always win or tie, but for the
varying systems that are available today, the across the board performance
should be significantly increased.

You mean "paralel" is a keyword indicating that it is safe to run in
paralel?
It sounds good but it might give problems when you have methods inside
that
is not safe for paralel executing.
I don't think it can be implemented that easily.

Yes there are certainly things to be considered. On one hand you could say
that it is the developers responsibility to deal with threading within
parallel blocks just as they would if they had written the threads
themselves, on the otehr some sort of compiler guarentee woudl be nice.
I don't know what I like, don't know that I'll ever even finish this idea,
but it is one that is on my active consideration pile.

 

[Sean Hederman]

message [Snip]

I might be able to, I don't think I know enough about JIT's to really say,
.

Anders implied that this is one of the things they are looking at in one of
the Channel 9's. Definately not for 2.0 though.

 

[Daniel O'Connell [C# MVP]]

Anders implied that this is one of the things they are looking at in one
of the Channel 9's. Definately not for 2.0 though.

That'd be nice to see.

 

[Olaf Baeyens]

You mean "paralel" is a keyword indicating that it is safe to run in

Yes there are certainly things to be considered. On one hand you could say
that it is the developers responsibility to deal with threading within
parallel blocks just as they would if they had written the threads
themselves, on the otehr some sort of compiler guarentee woudl be nice.
I don't know what I like, don't know that I'll ever even finish this idea,
but it is one that is on my active consideration pile.

My experience is that a lot of developers gets scared of the unknow and
oddly enough the reasoning they give are emotional based instead of logic
based. Instead of actual testing if it is that bad, they will use any
emotional technique in order not to touch the thing.

So I guess that if you make loops default to execute in paralel, then they
will get scared because they have no control.
So I guess if you implement a feature like that, then you must at least
provide a way to disable it too. A keyword like noparalel, or a compiler
option. Just an idea.

My guess is that programmers coming from VB, probably would love the fact
that it gets treaded, and programmers from VC++ probably would love not to
have it hyperthreaded because they are mostly scared of things they do not
have control over.

One thing I do miss is the ability to include ILAsm in the code. And I don't
know if ILAsm contains MMX and the SSEx-like instructions? But then again,
this could give additional problems with security things.

 

[Daniel O'Connell [C# MVP]]

One thing I do miss is the ability to include ILAsm in the code. And I
don't
know if ILAsm contains MMX and the SSEx-like instructions? But then again,
this could give additional problems with security things.

You would potentially lose verfiablity(one would likely want to require
unsafe code for IL directly in code), but it doesn't provide anything that I
know of that works like MMX. I assume something like that is under
consideration, but I know nothing about it.

 

[Daniel O'Connell [C# MVP]]

Oops, that reply was very badly worded and incomplete, let me try again.

My experience is that a lot of developers gets scared of the unknow and
oddly enough the reasoning they give are emotional based instead of logic
based. Instead of actual testing if it is that bad, they will use any
emotional technique in order not to touch the thing.

Since any work I would do would be nothing but experimentation quality, I
don't think I'd need to worry much about individuals going emotional on it.
Anyone who would touch taht particular compiler would likely do so strictly
to play with the parallelziation.

So I guess that if you make loops default to execute in paralel, then they
will get scared because they have no control.
So I guess if you implement a feature like that, then you must at least
provide a way to disable it too. A keyword like noparalel, or a compiler
option. Just an idea.

Parallel would be like the checked{} block, forcing parallelization within
that block. Not sure if turning it off makes any sense or not, that's
something to think about.

My guess is that programmers coming from VB, probably would love the fact
that it gets treaded, and programmers from VC++ probably would love not to
have it hyperthreaded because they are mostly scared of things they do not
have control over.

If the design was similar to OpenMP in capability, I imagine advanced VC++
coders would like it as it should offer a much finer grained control than I
have illustrated here.

But the VB\Java\Delphi crowd would be the core target, as this would be C#,
so I wouldn't personally go as far as OpenMP does.

One thing I do miss is the ability to include ILAsm in the code. And I
don't
know if ILAsm contains MMX and the SSEx-like instructions? But then again,
this could give additional problems with security things.

Directly embeddable IL would be a bit tricky(I'm not sure how it would deal
with variables), but it would probably require a loss of verifiability, thus
unsafe code.

Now, IL doesn't have any form of MMX\SSE style instructions that I can think
of. So that capability is somethign the CLR developers would have to add. I
hope they are thinking about it and chose to, being able to hint to the JIT
to use instructions of that nature might produce faster\better code in
future runtime generations.

 

[Olaf Baeyens]

One thing I do miss is the ability to include ILAsm in the code. And I

You would potentially lose verfiablity(one would likely want to require
unsafe code for IL directly in code), but it doesn't provide anything that I
know of that works like MMX. I assume something like that is under
consideration, but I know nothing about it.

Yes this would be a problem, but then again, sometimes people come up with
very elegant solutions to problems.
I just put it on a wish list, you never know that some clever design can
make it possible.

I did not check the IL assembler yet, so I have no clue if it provides ways
that would look like MMX instruction sets.

In my company we do a lot of image processing, so it would be nice to have
somehow control at the lower levels too to speed up our processing. This is
why some control of IL assembler would be nice. Then again we could do parts
in C++ too, if we need this as we do now.

 

[Olaf Baeyens]

So I guess that if you make loops default to execute in paralel, then
they

Parallel would be like the checked{} block, forcing parallelization within
that block. Not sure if turning it off makes any sense or not, that's
something to think about.

I do not recall checked {} but I think it is analogiosly to the unsafe {}
way?
I mean something like this:

parallel {
for (int iX=0; iX<iCount; iX++) {
DoMyThing....
}
}

compared to
unsafe {
for (int iX=0; iX<iCount; iX++) {
DoMyThing....
}
}

That would be a good idea.
Existing programs would have the default single threaded and would work the
same as before, but new code that has this functionality would have the
mutli-threaded approach because the developer chooses to be hyper threaded
(when it is possible).

Now, IL doesn't have any form of MMX\SSE style instructions that I can think
of. So that capability is somethign the CLR developers would have to add. I
hope they are thinking about it and chose to, being able to hint to the JIT
to use instructions of that nature might produce faster\better code in
future runtime generations.

I disassembled the resulting code of C# programs and C++ programs and I can
conclude that the JIT people does a very fine job.
The code comes very near the C++ code looking from x86 point of view.
Who said that C# was much slower?