ParallelFX CTP available
-
ParallelFX CTP available[^] Download here[^]. This is a library that runs on .NET 3.5 designed to make concurrency easier for .NET apps. The jist of it is to let you change this:
var allElementsWithFoo = from element in tables
where element.Foo == bar && otherCrazyCriteriaHere...
select element;To this:
var allElementsWithFoo = from element in tables.AsParallel()
where element.Foo == bar && otherCrazyCriteriaHere...
select element...and let the AsParallel part takes care of scheduling across multiple threads (created based on the number of available cores), balance the load, steal work from busy threads, etc. It introduces no overhead if the current machine doesn't have multiple cores. The library also contains APIs designed to make concurrency easier: scheduling, waiting, cancelling, task managers. Additionally, there are APIs for parallelizing common tasks, such as finding something inside an array. Microsoft has also launched a new MSDN developer center dedicated to concurrent programming: http://msdn2.microsoft.com/concurrency/[^] (being pushed out as we speak, link might not work for everyone just yet). *edit* Daniel Moth from Microsoft UK points me to the ParallelFX videos he's made[^] on Channel9.
Tech, life, family, faith: Give me a visit. I'm currently blogging about:
This looks promising. I imagine it may not be as robust or mature as OpenMP at this early stage but, it is the only release from MS since 2005 that has me remotely interested.
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
-
ParallelFX CTP available[^] Download here[^]. This is a library that runs on .NET 3.5 designed to make concurrency easier for .NET apps. The jist of it is to let you change this:
var allElementsWithFoo = from element in tables
where element.Foo == bar && otherCrazyCriteriaHere...
select element;To this:
var allElementsWithFoo = from element in tables.AsParallel()
where element.Foo == bar && otherCrazyCriteriaHere...
select element...and let the AsParallel part takes care of scheduling across multiple threads (created based on the number of available cores), balance the load, steal work from busy threads, etc. It introduces no overhead if the current machine doesn't have multiple cores. The library also contains APIs designed to make concurrency easier: scheduling, waiting, cancelling, task managers. Additionally, there are APIs for parallelizing common tasks, such as finding something inside an array. Microsoft has also launched a new MSDN developer center dedicated to concurrent programming: http://msdn2.microsoft.com/concurrency/[^] (being pushed out as we speak, link might not work for everyone just yet). *edit* Daniel Moth from Microsoft UK points me to the ParallelFX videos he's made[^] on Channel9.
Tech, life, family, faith: Give me a visit. I'm currently blogging about:
-
ParallelFX CTP available[^] Download here[^]. This is a library that runs on .NET 3.5 designed to make concurrency easier for .NET apps. The jist of it is to let you change this:
var allElementsWithFoo = from element in tables
where element.Foo == bar && otherCrazyCriteriaHere...
select element;To this:
var allElementsWithFoo = from element in tables.AsParallel()
where element.Foo == bar && otherCrazyCriteriaHere...
select element...and let the AsParallel part takes care of scheduling across multiple threads (created based on the number of available cores), balance the load, steal work from busy threads, etc. It introduces no overhead if the current machine doesn't have multiple cores. The library also contains APIs designed to make concurrency easier: scheduling, waiting, cancelling, task managers. Additionally, there are APIs for parallelizing common tasks, such as finding something inside an array. Microsoft has also launched a new MSDN developer center dedicated to concurrent programming: http://msdn2.microsoft.com/concurrency/[^] (being pushed out as we speak, link might not work for everyone just yet). *edit* Daniel Moth from Microsoft UK points me to the ParallelFX videos he's made[^] on Channel9.
Tech, life, family, faith: Give me a visit. I'm currently blogging about:
-
ParallelFX CTP available[^] Download here[^]. This is a library that runs on .NET 3.5 designed to make concurrency easier for .NET apps. The jist of it is to let you change this:
var allElementsWithFoo = from element in tables
where element.Foo == bar && otherCrazyCriteriaHere...
select element;To this:
var allElementsWithFoo = from element in tables.AsParallel()
where element.Foo == bar && otherCrazyCriteriaHere...
select element...and let the AsParallel part takes care of scheduling across multiple threads (created based on the number of available cores), balance the load, steal work from busy threads, etc. It introduces no overhead if the current machine doesn't have multiple cores. The library also contains APIs designed to make concurrency easier: scheduling, waiting, cancelling, task managers. Additionally, there are APIs for parallelizing common tasks, such as finding something inside an array. Microsoft has also launched a new MSDN developer center dedicated to concurrent programming: http://msdn2.microsoft.com/concurrency/[^] (being pushed out as we speak, link might not work for everyone just yet). *edit* Daniel Moth from Microsoft UK points me to the ParallelFX videos he's made[^] on Channel9.
Tech, life, family, faith: Give me a visit. I'm currently blogging about:
Avtually, the AsParallel is best placed onto the source (i.e. tables in your example). Check out my screencasts for how to get started: http://channel9.msdn.com/Showforum.aspx?forumid=38&tagid=269[^] Cheers Daniel
-
ParallelFX CTP available[^] Download here[^]. This is a library that runs on .NET 3.5 designed to make concurrency easier for .NET apps. The jist of it is to let you change this:
var allElementsWithFoo = from element in tables
where element.Foo == bar && otherCrazyCriteriaHere...
select element;To this:
var allElementsWithFoo = from element in tables.AsParallel()
where element.Foo == bar && otherCrazyCriteriaHere...
select element...and let the AsParallel part takes care of scheduling across multiple threads (created based on the number of available cores), balance the load, steal work from busy threads, etc. It introduces no overhead if the current machine doesn't have multiple cores. The library also contains APIs designed to make concurrency easier: scheduling, waiting, cancelling, task managers. Additionally, there are APIs for parallelizing common tasks, such as finding something inside an array. Microsoft has also launched a new MSDN developer center dedicated to concurrent programming: http://msdn2.microsoft.com/concurrency/[^] (being pushed out as we speak, link might not work for everyone just yet). *edit* Daniel Moth from Microsoft UK points me to the ParallelFX videos he's made[^] on Channel9.
Tech, life, family, faith: Give me a visit. I'm currently blogging about:
Hi... I didn't read anything about this and I don't know much about it either so excuse me if I'm about to ask is just isn't possible. Question: Shouldn't the OS or even on a lower lever the CPU itself to manage this? Lets say that we have a Quad Code CPU... How good is it for us if the OS or the CPU needs special care on the app side for the app itself take advantage of the 3 extra cores? Sure this is a way for us to explicit the way we want it to run. It's useful and it's still a good tool, but will this represent a significant boost over a multi-threading aware application? Cheers, Alex
-
Hi... I didn't read anything about this and I don't know much about it either so excuse me if I'm about to ask is just isn't possible. Question: Shouldn't the OS or even on a lower lever the CPU itself to manage this? Lets say that we have a Quad Code CPU... How good is it for us if the OS or the CPU needs special care on the app side for the app itself take advantage of the 3 extra cores? Sure this is a way for us to explicit the way we want it to run. It's useful and it's still a good tool, but will this represent a significant boost over a multi-threading aware application? Cheers, Alex
AlexCode wrote:
Shouldn't the OS or even on a lower lever the CPU itself to manage this?
No. When you write an application, it runs under a single thread. Thus, it cannot take advantage of multiple CPU's or cores. You may be able to take advantage of multiple cores with separate threads, the management of these threads may not be optimum for your needs. New threads may or may not run on a different core, it's up to the OS. A parallel computing system takes great care to ensure that all cores are fully utilized to achieve the best possible performance. This is at odds with the OS who's job is to manage the CPUs efficiently, not ensure any given application is performing at it's highest possible speed.
-- Where are we going? And why am I in this handbasket?
-
AlexCode wrote:
Shouldn't the OS or even on a lower lever the CPU itself to manage this?
No. When you write an application, it runs under a single thread. Thus, it cannot take advantage of multiple CPU's or cores. You may be able to take advantage of multiple cores with separate threads, the management of these threads may not be optimum for your needs. New threads may or may not run on a different core, it's up to the OS. A parallel computing system takes great care to ensure that all cores are fully utilized to achieve the best possible performance. This is at odds with the OS who's job is to manage the CPUs efficiently, not ensure any given application is performing at it's highest possible speed.
-- Where are we going? And why am I in this handbasket?
Agreed. I'm still concerned, though, with the fact that you never know which core and how much of it is already being used by the OS for other programs/tasks/threads, so in the end you never really know if you are indeed squeezing the most out of your multi-core architecture. Any thoughts on that?
-
Agreed. I'm still concerned, though, with the fact that you never know which core and how much of it is already being used by the OS for other programs/tasks/threads, so in the end you never really know if you are indeed squeezing the most out of your multi-core architecture. Any thoughts on that?
Well, it's not an easy problem to solve. I was merely pointing out that the OS scheduler and a Parallel Processing scheduler are optimized in different ways. I don't know how ParallelFX works, so I can't really comment on that. Ultimately, however, the problem boils down to the fact that the computer runs at the behest of the user, and it's not very easy for the OS or a program to predict what the user will want in the future.
-- Where are we going? And why am I in this handbasket?
-
Hi... I didn't read anything about this and I don't know much about it either so excuse me if I'm about to ask is just isn't possible. Question: Shouldn't the OS or even on a lower lever the CPU itself to manage this? Lets say that we have a Quad Code CPU... How good is it for us if the OS or the CPU needs special care on the app side for the app itself take advantage of the 3 extra cores? Sure this is a way for us to explicit the way we want it to run. It's useful and it's still a good tool, but will this represent a significant boost over a multi-threading aware application? Cheers, Alex
Shouldn't the OS or even on a lower lever the CPU itself to manage this? Interesting idea. Similar to the way instruction scheduling in single cores is handled by the CPU. As the number of cores begin to increase to the 100's and eventually 1000's, there probably will be a hardware implemented core manager. Until that day, compilers will take a lot of the multi core management away from programmers (hence new things like .AsParrallel), but not all of it.
Introduced to programming by VB, grew up on C++, tangoed with a slew of other languages, and now mainly partying with C#.
-
Agreed. I'm still concerned, though, with the fact that you never know which core and how much of it is already being used by the OS for other programs/tasks/threads, so in the end you never really know if you are indeed squeezing the most out of your multi-core architecture. Any thoughts on that?
Andre Luiz V Sanches wrote:
in the end you never really know if you are indeed squeezing the most out of your multi-core architecture.
Technically speaking, and from my understanding of it, the OS manages the hardware, the cores, this case. ParallelFX is designed to balance load across threads that run on those cores. While the OS decides which core to run on, this library implements task scheduling and work stealing; so if you've got a task you'd like to run, the library may create 8 threads for your 8 core processor to do the job. It will split up your job among the threads, and if one thread finishes before another, that thread will steal work from the busy threads in order to finish the job faster. Make sense?
Tech, life, family, faith: Give me a visit. I'm currently blogging about: The Story of the Spoiled Child The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
Avtually, the AsParallel is best placed onto the source (i.e. tables in your example). Check out my screencasts for how to get started: http://channel9.msdn.com/Showforum.aspx?forumid=38&tagid=269[^] Cheers Daniel
Thanks, Daniel. I've modified the post. Watching your videos now, good stuff.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: The Story of the Spoiled Child The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
ParallelFX CTP available[^] Download here[^]. This is a library that runs on .NET 3.5 designed to make concurrency easier for .NET apps. The jist of it is to let you change this:
var allElementsWithFoo = from element in tables
where element.Foo == bar && otherCrazyCriteriaHere...
select element;To this:
var allElementsWithFoo = from element in tables.AsParallel()
where element.Foo == bar && otherCrazyCriteriaHere...
select element...and let the AsParallel part takes care of scheduling across multiple threads (created based on the number of available cores), balance the load, steal work from busy threads, etc. It introduces no overhead if the current machine doesn't have multiple cores. The library also contains APIs designed to make concurrency easier: scheduling, waiting, cancelling, task managers. Additionally, there are APIs for parallelizing common tasks, such as finding something inside an array. Microsoft has also launched a new MSDN developer center dedicated to concurrent programming: http://msdn2.microsoft.com/concurrency/[^] (being pushed out as we speak, link might not work for everyone just yet). *edit* Daniel Moth from Microsoft UK points me to the ParallelFX videos he's made[^] on Channel9.
Tech, life, family, faith: Give me a visit. I'm currently blogging about:
I'm sorry, but unless, the ".AsParallel()" method is generically available as an option somewhere else besides a LINQ SQL query, then I find it's usefulness negligible. In a LINQ select query, it would usually exectuate against a backend end which is I/O-bound anyway, not CPU bound. Adding a touch of parallelism here is trying to do the job of what a good Database engine would do for you, and has nothing to do with the performance of the client CPUs. At most, this method could provide a hint to the backend engine to try to optimize the query, but seems to me has little to do with maximizing core usage. (Albeit, a LINQ query may not necessarily always be going to a DB backend, but could be performing the query in memory, in which case the parallel feature could be useful.) Likewise, applying parallel programming may be useful in some cases for speed up, but would find it's best application by a CLR engine and compiler set which self-optimizes the code for maximum parallel effects. I'm not against a new programming paradigm (if you can call concurent programming new), but the application by average programmers is dubious at best. If someone wants to demonstrate superior parallel techniques, then the the language constructs of C# (3.0?) and VB.Net will need to be enhanced to make these features truly native. And, if speed is really the issue, then why would we still be using a CLR-based language, and not a native C++ or other native language to maximize multiple CPU cores? If this is what Microsoft is putting out as an example of good parallel techniques, heaven help us. --ronald
-
AlexCode wrote:
Shouldn't the OS or even on a lower lever the CPU itself to manage this?
No. When you write an application, it runs under a single thread. Thus, it cannot take advantage of multiple CPU's or cores. You may be able to take advantage of multiple cores with separate threads, the management of these threads may not be optimum for your needs. New threads may or may not run on a different core, it's up to the OS. A parallel computing system takes great care to ensure that all cores are fully utilized to achieve the best possible performance. This is at odds with the OS who's job is to manage the CPUs efficiently, not ensure any given application is performing at it's highest possible speed.
-- Where are we going? And why am I in this handbasket?
Ok, I know that 1 thread = 1 Core. Multi-threading with a one core CPU is a myth discussed over and over.
Erik Funkenbusch wrote:
New threads may or may not run on a different core, it's up to the OS.
Right... this is my point... it already manages it! Based on what? My guess is that it have a "cute" algorithm that calcs the optimum way to get a job done...
Erik Funkenbusch wrote:
This is at odds with the OS who's job is to manage the CPUs efficiently
Isn't CPU maximum efficiency directly related with a certain application efficiency? As I see it efficiency have to be measured on a global scale, not at an application scope. For that we already have thread priorities... ;P
Erik Funkenbusch wrote:
ensure any given application is performing at it's highest possible speed
This will make the other apps run on a lower priority... If we take a look at the Task Manager Performance tab on a multi-core computer (CPU) we can see that both cores are working in parallel already... My point is: * why bother? * What kind of applications will actually take advantage of this? * What kind of maintainability problems will this bring? * Won't this actually increase the load on the CPU process? (kind of the same discussion I had over and over again about multi-threading on a single-core CPU). Cheers, Alex
-
I'm sorry, but unless, the ".AsParallel()" method is generically available as an option somewhere else besides a LINQ SQL query, then I find it's usefulness negligible. In a LINQ select query, it would usually exectuate against a backend end which is I/O-bound anyway, not CPU bound. Adding a touch of parallelism here is trying to do the job of what a good Database engine would do for you, and has nothing to do with the performance of the client CPUs. At most, this method could provide a hint to the backend engine to try to optimize the query, but seems to me has little to do with maximizing core usage. (Albeit, a LINQ query may not necessarily always be going to a DB backend, but could be performing the query in memory, in which case the parallel feature could be useful.) Likewise, applying parallel programming may be useful in some cases for speed up, but would find it's best application by a CLR engine and compiler set which self-optimizes the code for maximum parallel effects. I'm not against a new programming paradigm (if you can call concurent programming new), but the application by average programmers is dubious at best. If someone wants to demonstrate superior parallel techniques, then the the language constructs of C# (3.0?) and VB.Net will need to be enhanced to make these features truly native. And, if speed is really the issue, then why would we still be using a CLR-based language, and not a native C++ or other native language to maximize multiple CPU cores? If this is what Microsoft is putting out as an example of good parallel techniques, heaven help us. --ronald
azusastreet wrote:
I'm sorry, but unless, the ".AsParallel()" method is generically available as an option somewhere else besides a LINQ SQL query, then I find it's usefulness negligible.
Cool, because it's an extension method that works on any IEnumerable<T>. (e.g. your custom collections, arrays, lists, etc.). Enjoy! Give it a try and then comment. :)
Tech, life, family, faith: Give me a visit. I'm currently blogging about: The Story of the Spoiled Child The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
Ok, I know that 1 thread = 1 Core. Multi-threading with a one core CPU is a myth discussed over and over.
Erik Funkenbusch wrote:
New threads may or may not run on a different core, it's up to the OS.
Right... this is my point... it already manages it! Based on what? My guess is that it have a "cute" algorithm that calcs the optimum way to get a job done...
Erik Funkenbusch wrote:
This is at odds with the OS who's job is to manage the CPUs efficiently
Isn't CPU maximum efficiency directly related with a certain application efficiency? As I see it efficiency have to be measured on a global scale, not at an application scope. For that we already have thread priorities... ;P
Erik Funkenbusch wrote:
ensure any given application is performing at it's highest possible speed
This will make the other apps run on a lower priority... If we take a look at the Task Manager Performance tab on a multi-core computer (CPU) we can see that both cores are working in parallel already... My point is: * why bother? * What kind of applications will actually take advantage of this? * What kind of maintainability problems will this bring? * Won't this actually increase the load on the CPU process? (kind of the same discussion I had over and over again about multi-threading on a single-core CPU). Cheers, Alex
AlexCode wrote:
Isn't CPU maximum efficiency directly related with a certain application efficiency?
AlexCode wrote:
Multi-threading with a one core CPU is a myth discussed over and over.
I'm not sure what you mean by a "myth". Multi-threading, even on a single core has advantages.
AlexCode wrote:
Right... this is my point... it already manages it!
Yes, but it doesn't, necessarily, manage it the way you want it managed. For example, the thread scheduler will prefer that threads run on the same CPU as they previously ran on, in order to improve cache hits. However, that may not be what you want in all cases.
AlexCode wrote:
Isn't CPU maximum efficiency directly related with a certain application efficiency?
To some degree, sure. Windows uses SMP, or symetric multiprocessing. This is different from Parallel processing. There are similarities, but there are also major differences. To put it another way, the OS doesn't care about your one application. It cares about balancing all the processes on the computer. Parallel processing doesn't care about anything but itself.
-- Where are we going? And why am I in this handbasket?
-
Shouldn't the OS or even on a lower lever the CPU itself to manage this? Interesting idea. Similar to the way instruction scheduling in single cores is handled by the CPU. As the number of cores begin to increase to the 100's and eventually 1000's, there probably will be a hardware implemented core manager. Until that day, compilers will take a lot of the multi core management away from programmers (hence new things like .AsParrallel), but not all of it.
Introduced to programming by VB, grew up on C++, tangoed with a slew of other languages, and now mainly partying with C#.
-
AlexCode wrote:
Isn't CPU maximum efficiency directly related with a certain application efficiency?
AlexCode wrote:
Multi-threading with a one core CPU is a myth discussed over and over.
I'm not sure what you mean by a "myth". Multi-threading, even on a single core has advantages.
AlexCode wrote:
Right... this is my point... it already manages it!
Yes, but it doesn't, necessarily, manage it the way you want it managed. For example, the thread scheduler will prefer that threads run on the same CPU as they previously ran on, in order to improve cache hits. However, that may not be what you want in all cases.
AlexCode wrote:
Isn't CPU maximum efficiency directly related with a certain application efficiency?
To some degree, sure. Windows uses SMP, or symetric multiprocessing. This is different from Parallel processing. There are similarities, but there are also major differences. To put it another way, the OS doesn't care about your one application. It cares about balancing all the processes on the computer. Parallel processing doesn't care about anything but itself.
-- Where are we going? And why am I in this handbasket?
Erik Funkenbusch wrote:
I'm not sure what you mean by a "myth". Multi-threading, even on a single core has advantages.
Sure it has its advantages, the "myth" is on the overall performance increase. Here we go again... :) Sure it's good, but it also increases the overhead on the CPU, making the total process time slower that executing each one at a time. I'm not saying it's wrong the way it's now, as executing one task at a time will keep the computer frozen for a lot of time, but most people think that adding threads on their applications will increase the application speed and this is wrong if we're on a single-core CPU as we were 'till the multi-core cpu's arrival.
Erik Funkenbusch wrote:
To put it another way, the OS doesn't care about your one application. It cares about balancing all the processes on the computer. Parallel processing doesn't care about anything but itself.
I'm just wondering, won't this raise some conflicts? Not errors, but conflicts on the CPU about what goes to where? I think I'll only believe it when one entity (the CPU) manages it all...
-
Erik Funkenbusch wrote:
I'm not sure what you mean by a "myth". Multi-threading, even on a single core has advantages.
Sure it has its advantages, the "myth" is on the overall performance increase. Here we go again... :) Sure it's good, but it also increases the overhead on the CPU, making the total process time slower that executing each one at a time. I'm not saying it's wrong the way it's now, as executing one task at a time will keep the computer frozen for a lot of time, but most people think that adding threads on their applications will increase the application speed and this is wrong if we're on a single-core CPU as we were 'till the multi-core cpu's arrival.
Erik Funkenbusch wrote:
To put it another way, the OS doesn't care about your one application. It cares about balancing all the processes on the computer. Parallel processing doesn't care about anything but itself.
I'm just wondering, won't this raise some conflicts? Not errors, but conflicts on the CPU about what goes to where? I think I'll only believe it when one entity (the CPU) manages it all...
AlexCode wrote:
I'm just wondering, won't this raise some conflicts?
AlexCode wrote:
Sure it has its advantages, the "myth" is on the overall performance increase.
Multithreading can increase performance, just not automatically. For example, instead of doing a lot of processing by waiting for messages to be pumped, you can spin off another thread and it will often do the work faster (because it doesn't have to compete with the message queue). Another way multithreading can increase performance, even on a single core is when a task is disk-bound, this allows other threads to continue working even while the disk-bound thread is chugging away. But no, multiple threads do not just automatically achieve more performance, only under certain conditions.
AlexCode wrote:
I'm just wondering, won't this raise some conflicts?
I guess that depends entirely on what you're doing. Regular multithreading can cause conflicts too.
-- Where are we going? And why am I in this handbasket?