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

  • Thread starter Thread starter Olaf Baeyens
  • Start date Start date
O

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
..
 
Olaf Baeyens said:
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
.
Click to expand...

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?
 
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?
Click to expand...
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.
 
Olaf Baeyens said:
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.
Click to expand...

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?
 
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?
Click to expand...
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?
Click to expand...

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.
 
Olaf Baeyens said:
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. ;-)
Click to expand...

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.
Click to expand...

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.
Click to expand...

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.
 
message [Snip]
I might be able to, I don't think I know enough about JIT's to really say,
;).
Click to expand...

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.
 
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.
Click to expand...


That'd be nice to see.
 
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.
Click to expand...
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.
 
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.
Click to expand...

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.
 
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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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.
 
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.
Click to expand...
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.
 
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.
Click to expand...
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.
Click to expand...
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? :-)
 
Back
Top