What this does is allow for certain operations to automatically be run in parallel. If you wanted to add 1 to every element in an array, you could do that with with Linq:
IEnumerable<int> numbers = new List<int>() { 1, 2, 3, 4, 5 };
var newList = from num in numbers.AsParallel()
select (x => x+1);
but by adding ".asParallel()" to the chain: var newList = from num in numbers.AsParallel()
select (x => x+1);
your code is automatically run on each element in a parallel fashion and the runtime handles marshalling it all into a queue for processing... or however it does it's magic.The MSDN document on the way it does it is quite clear: http://msdn.microsoft.com/en-us/library/dd997399(v=vs.110).a... - describing many linq operations as 'delightfully parallel'.
I personally love Linq. To me it feels like using a Functional Relational Mapping system when combined with Linq-To-SQL, and the same semantics can be used to create a reactive programming model similar to what is intended with kefir.js and Akka ( http://msdn.microsoft.com/en-us/data/gg577609.aspx )
The idea itself isn't new, Perl 6 has something like this planned for trivial cases like for (1..10) { $_ = $_ +1; }
----
I don't know the full story, but for me the significance of open sourcing this code is that it will potentially encourage forks and extensions that allow running stuff upon GPGPUs or other massively parallel architectures while still using Linq style syntax.
TL;DR: With Linq, Anything that implements iEnumerable (lists, arrays, streams, etc) can be made to automatically support all sorts of nifty transforms. The Parallel bits let many of them run in parallel quite trivially
Your code should have read:
var numbers = new List<int>() { 1, 2, 3, 4, 5 };
var newList = numbers.AsParallel().Select(p => p + 1);And using IEnumerable was probably making the point that it didn't have to be a list, it could be anything implementing that interface.
Downvoters be damned, they know not what they talk about. ultimape is clearly not a C# developer.
There is a lot of discussion about the usage of var, and ultimape's non-usage of it in his example is a personal preference, as well as making sense in an educational post.
And lastly, I think you'll find many developers, young and old alike, use x, y and z as their lambda parameters. I do too. It comes from the mathematical function origin of the syntax. In most early examples when it was introduced, and loads of educational materials now, lambda syntax is still presented akin to a mathematical formula:
x => x+1
In that context, using x makes a lot more sense than p, and has stuck around as a habit. It's a style thing, and everybody has their own style. You don't get to claim superior experience or skill based on a 2 line snippet that doesn't match your style.
And as an aside: you're not being downvoted by "the ignorant masses". You're being downvoted for being confrontational and not contributing to a conversation about the topic, which is Parallel LINQ and not coding style.
For longer queries, that little DSL syntax it's a bless. It's way more pleasant to read, write or think about it than the alternative.
Ah, and since you care so much about it, I've been developing in C# for freaking years that I don't bother to sum it up anymore.
There is nothing wrong with the DSL syntax at all.
The authors of the plinq library are clearly not C# developers then. https://github.com/dotnet/corefx/search?p=1&q=select&utf8=%E...
While using i,j,k as loop variables have a long tradition behind them (from FORTRAN77, IIRC), no reason to limit myself when using Linq.
Then don't :). What you've presented is very much like saying "I don't encounter many people with your style of programming and thus, no one uses that style and you're not an actual programmer in this language".
Don't forget that there are varying styles of doing things. You use 'p'? great! Others will use foo, i, j, lalal, etc. No need to get worked up over such a minor issue and detract from the actual conversation at hand.
Of course we do. I wrote this just the other day:
var salesAndReturns = from sale in sales
join return in returns on new { StockId = sale.StockId, ClientStockId = sale.ClientStockId, SellPointId = sale.SellPointId }
equals new { StockId = return.StockId, ClientStockId = return.ClientStockId, SellPointId = return.SellPointId } into gpu
from subreturn in gpu.DefaultIfEmpty()
select new
{
sale.ClientStockId,
sale.StockId,
Quantity = -sale.Quantity + (subreturn ?? new SellPointStock()).Quantity
};
The are no rules restricting us from how we should use LINQ.Parallel LINQ is an extension to LINQ (Language Integrated Querying). The "parallel" hints that it is a way to process results in parallel - using multiple threads, possibly on multiple CPUs/cores.
It allows you to express patterns like fork/join in a very elegant, fluent way.
If I have a set of Orders each with a collection of OrderItems, and each OrderItem* has a Consolidate method (I know, contrived, but bear with me).
Orders.SelectMany(o => o.OrderItems).AsParallel().ForAll(Consolidate);
will "consolidate" all of the order items in parallel (or with the optimal degree of parallelism given CPUs/cores).I'm willing to bet the submitter went through a series of links beginning with some sort of announcement that something changed to get to the link they submitted. Why do folks think that we would not also benefit from that information or that it would not help to foster more interesting discussion?
Parallel = executes tasks on multiple cores simultaneously if possible