The future of MP support in VB

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Does anybody know if there are plans to add improved support for multi-core
processors in VB? It is easy to launch a process on a new thread in VB, but
in a real world application it can take a considerable effort to manage the
threads. For example, if you are looping through a 1000x1000 array, then it
would be nice to run each row on its own thread. But, you don't want to
create 1000 threads because doing so will dramatically reduce performance.
So, in order to be optimized, you would need to add a considerable amount of
code so that only one thread per CPU executes at a time. It seems to me that
something like OpenMP would be an ideal solution. VB is all about making
things easy and OpenMP is all about making multithreading easy (or at least
easier). Sounds like a good match to me.

Thanks for any feedback.
Lance
 
Lance,

Being busy with multiprocessing very long, I have recognised that
multiprocessing is often a wish that not is to realize on computers with
direct user communication (Multiprocessing/programming is great to do in
batch processes or in multitier operations). You see not much links anymore
about optimistic multiprocessing and things like that.

Multiprocessing from one task, is only possible if the processes are not
depending from each other (parallel processing). On very expensive
processors is already a long time ago started tests with optimistic
processing. (Killing the process as it becomes depended from another). AFAIK
are those tests still not ended.

A way to do multiprocessing is using pipes or multithreading.

From the start of NT4 it divides processes over the different physical
processors, this is everytime optimized by Microsoft in every new version of
NT.

However the process should be in no way dependable from each other,
otherwise your processors are probably only calculating if the dependency is
not happened.

I hope this gives some idea's,

Cor
 
Lance,
Why limit OpenMP features to VB?

I would expect the Framework itself to benefit from OpenMP, allowing C#,
managed C++ and even Fortran.NET to benefit from the features.

Although I have not used OpenMP, I do agree simplifying multi-threading is
always a benefit.


Having said that, have you looked at System.Threading.ThreadPool?

..NET 2.0 add SetMaxThreads to ThreadPool to allow you to limit the maximum
number of threads.

http://msdn2.microsoft.com/en-us/library/system.threading.threadpool.setmaxthreads.aspx

Granted ThreadPool is shared within your application & you need to be aware
of changing its parameters.


..NET 2.0 also introduces a BackgroundWorker object that simplifies creating
a background thread, primarily for Windows applications.

http://msdn2.microsoft.com/en-us/library/8xs8549b.aspx

http://msdn2.microsoft.com/en-us/library/4852et58(en-US,VS.80).aspx


I've used the BackgroundWorker in a VSTO sample for Outlook:

http://www.tsbradley.net/Samples/VSTO/Xml.Export.Sample.aspx
 
Hi Jay,

Thanks a lot for the ideas. I have looked into BackgroundWorker but it is
hardly useful. For complex multithreading situations I need more flexibility
and control than what BackgroundWorker provides. On the other hand,
BackgroundWorker would be prohibitively time consuming to implement in the
hundreds of simple loops within my app where multithreading would provide a
performance boost on multicore systems.

Visual C++ 2005 supports OpenMP as described in the October 2005 issue of
MSDN Magazine. I found this article very frustrating because I was asking
myself questions very similar to those that you raised. Why limit OpenMP to
C++ at a time when multithreading is quickly becoming a necessity? Is VB
better off without a feature that would dramatically simplify one of the most
complex and error prone tasks in programming? I thought that VB was all
about making things as easy and programmer friendly as possible. I guess the
VB team decided that MY was more important than MP :(

Lance


Jay B. Harlow said:
Lance,
Why limit OpenMP features to VB?

I would expect the Framework itself to benefit from OpenMP, allowing C#,
managed C++ and even Fortran.NET to benefit from the features.

Although I have not used OpenMP, I do agree simplifying multi-threading is
always a benefit.


Having said that, have you looked at System.Threading.ThreadPool?

..NET 2.0 add SetMaxThreads to ThreadPool to allow you to limit the maximum
number of threads.

http://msdn2.microsoft.com/en-us/library/system.threading.threadpool.setmaxthreads.aspx

Granted ThreadPool is shared within your application & you need to be aware
of changing its parameters.


..NET 2.0 also introduces a BackgroundWorker object that simplifies creating
a background thread, primarily for Windows applications.

http://msdn2.microsoft.com/en-us/library/8xs8549b.aspx

http://msdn2.microsoft.com/en-us/library/4852et58(en-US,VS.80).aspx


I've used the BackgroundWorker in a VSTO sample for Outlook:

http://www.tsbradley.net/Samples/VSTO/Xml.Export.Sample.aspx

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


ljlevend2 said:
Does anybody know if there are plans to add improved support for
multi-core
processors in VB? It is easy to launch a process on a new thread in VB,
but
in a real world application it can take a considerable effort to manage
the
threads. For example, if you are looping through a 1000x1000 array, then
it
would be nice to run each row on its own thread. But, you don't want to
create 1000 threads because doing so will dramatically reduce performance.
So, in order to be optimized, you would need to add a considerable amount
of
code so that only one thread per CPU executes at a time. It seems to me
that
something like OpenMP would be an ideal solution. VB is all about making
things easy and OpenMP is all about making multithreading easy (or at
least
easier). Sounds like a good match to me.

Thanks for any feedback.
Lance
Click to expand...
Click to expand...
 
Hi

From VS.NET 2005, I think VB.NET is not just an alternative to C#. It
mainly focus on Rapid Application Development, it can be considered as a
more high level programming language, that is why it introduce My which is
not available in C#. And MP is most related with performance, and C++ is a
language in VS.NET 2005 that focus on performance and more low level
control. So we commonly talking about MP over C++.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Lance
| Why limit OpenMP to
| C++ at a time when multithreading is quickly becoming a necessity?
Because its already a C++ standard, to allow any .NET language to use it,
it would need to be ported to a .NET class library. Seeing as OpenMP is an
open standard, you really need to ask them (the Open MP committee) why they
choose to support C++ over .NET.

| I guess the
| VB team decided that MY was more important than MP :(
For the VB team, yes MY is more important than MP! (Primarily for, but not
limited to, the reasons that Peter stated)

IMHO OpenMP really belongs to the CLR/BCL teams!

For the CLR/BCL team, IMHO it may be important. However! should it have been
more important then generics? Or any of the .new CLR/BCL features that were
added?

I believe they are still accepting bug/feature requests at:

http://lab.msdn.microsoft.com/ProductFeedback/

It would/should be added to the list for future versions of the framework.


Of course you could port the OpenMP spec to .NET if you like. ;-) If you
have C++ source for the OpenMP library itself, it should be easy enough to
create Managed C++ wrappers for it... Actually C++ wrappers wouldn't be that
hard with just the library.

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


| Hi Jay,
|
| Thanks a lot for the ideas. I have looked into BackgroundWorker but it is
| hardly useful. For complex multithreading situations I need more
flexibility
| and control than what BackgroundWorker provides. On the other hand,
| BackgroundWorker would be prohibitively time consuming to implement in the
| hundreds of simple loops within my app where multithreading would provide
a
| performance boost on multicore systems.
|
| Visual C++ 2005 supports OpenMP as described in the October 2005 issue of
| MSDN Magazine. I found this article very frustrating because I was asking
| myself questions very similar to those that you raised. Why limit OpenMP
to
| C++ at a time when multithreading is quickly becoming a necessity? Is VB
| better off without a feature that would dramatically simplify one of the
most
| complex and error prone tasks in programming? I thought that VB was all
| about making things as easy and programmer friendly as possible. I guess
the
| VB team decided that MY was more important than MP :(
|
| Lance
|
|
<<snip>>
 
Hi Peter,

Thanks for your feedback. I think a key point that you are excluding is
that multithreading has or will very soon become a necessity rather than
luxury. This point has been emphasized in several articles in MSDN Magazine
as well as many other sources. With this being the case then doesn't it make
sense to include tools that dramatically simplify multithreading in a RAD
language such as VB.NET? Furthermore, many multithreading articles use
database access as their example which is a common task for VB programmers.

Best regards,
Lance
 
Hi Jay,

Thank you very much for your reply. I found it to be quite informative.

You wrote, "Of course you could port the OpenMP spec to .NET if you like.
;-) If you
have C++ source for the OpenMP library itself, it should be easy enough to
create Managed C++ wrappers for it... Actually C++ wrappers wouldn't be that
hard with just the library."

Are you suggesting that this is something that I could do? If so, I
certainly would be interested to learn how.

Thanks again,
Lance
 
Lance,
| Are you suggesting that this is something that I could do? If so, I
| certainly would be interested to learn how.
Do you know C++? Then Yes I think you can.

Here is an example of wrapping a C++ DLL with Managed Extensions:
http://msdn.microsoft.com/library/d...nstrateswrappingcdllwithmanagedextensions.asp

This article may be helpful also:
http://msdn.microsoft.com/msdnmag/issues/02/02/ManagedC/default.aspx

This section of MSDN might be useful:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmex/html/vcconMCOverview.asp


I seem to remember an MSDN article (not the above MSDN magazine article)
that walked you through what to do, however I don't see it right now.

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


| Hi Jay,
|
| Thank you very much for your reply. I found it to be quite informative.
|
| You wrote, "Of course you could port the OpenMP spec to .NET if you like.
| ;-) If you
| have C++ source for the OpenMP library itself, it should be easy enough to
| create Managed C++ wrappers for it... Actually C++ wrappers wouldn't be
that
| hard with just the library."
|
| Are you suggesting that this is something that I could do? If so, I
| certainly would be interested to learn how.
|
| Thanks again,
| Lance
|
 
Hi Lance,

I think MP is more related with how to execute threads on multiple CPUs. As
Jay said, it is implement in the underlying CLR, VB.NET as a high level
language, when it did multithread, the CLR took care the MP issue.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Peter,

As I already wrote, with using pipes instead of multithreading than the
automatic mechanism from NT makes this very simple. If it is multitier
processing over a LAN than remoting is the feature, is it over Internet than
it is WebService.

However don't overestimate the use of this in a normal screen operation.
Although the new Background worker is a nice thing for a slightly better
program behaviour if there is a large processing time. The multithreading
approach without that forces you to remove a big part of the logic of a
program (and with that stability).

If it is for multitier operations than multiprocessing/programming comes
direct in effect.

AFAIK is there almost not any extra effort needed if the architecture is as
this on a NT type server. (On Server 2003 Enterprise are a maximum of 8
processors supported). As I wrote with the first NT4 it was already 2.

Just my thought,

Cor
 
Back
Top