CTP Quality

re: CTP Quality

Keith Patrick — Fri, 07 Dec 2007 23:53:02 GMT

toub: The slowdown was caused in the different method I used for joining the results of my parse, not in the PFX library itself; I was trying to restructure my outer code to work in a parallel manner without explicit locks.

I've been trying to wrap my head around the issue, and I think the solution lies within ParallelEnumerable.Concat, as it probably has a much more elegant means for preserving order and sharing the result buffer than my brute force methods. I'm still trying to get my head around the paradigm enough to rewrite my logic, but basically what I do is take in an object with a string value, split it via some delimiter, and end up with the same object, but instead of it containing a string value, it has a bunch of children of the same type as itself, but now *they* have the string values (or depending on how many levels the grammar def is, their children have the strings). Catch is each thread is expected to dump its results in a shared collection while preserving order, and that isn't the most thread-friendly thing to do (and also why I want to try using the PLINQ concatenator instead of my brute force attempts)

re: CTP Quality

Stephen Toub - MSFT — Fri, 07 Dec 2007 20:17:25 GMT

Thanks, Keith. Very interesting. If you wanted to put together a small repro code sample that highlights the kinds of bottlenecks you're running into, we'd be happy to look at it. I'm most curious, though, about your 100x slowdown reported with Parallel.For. Are you comparing that Parallel.For implementation to your original sequential implementation or to a sequential implementation that mimicks the same new approach you're taking?

re: CTP Quality

Keith Patrick — Fri, 07 Dec 2007 08:19:09 GMT

On the speed issue, just for kicks I wanted to try converted a generic grammar parser I wrote because a) it's highly recursive with some relatively tightly-written core algorithms, and b) I had already started refactoring it for a threading recompiler I abandoned recently.

The the plus side, it was super-easy to wrap the central code in a Parallel.For/Each. I tried both ForEach and later For, trying a couple of ways of getting the results into the result collection. I'm not really expecting a performance gain on my single-core setup with preview bits anyway, but it was interesting in terms of the different PFX methods for enumerating. My Parallel.ForEach version ran 10x slower than the original version using a synch-heavy collection scheme, but with the For, where I store my results for each iteration in an array element and then gather them at the end, it was 100x.

I'm interesting in comparing it with a PLINQ version of my loop, but that's where it gets a bit more complex in my head to integrate the parallel stuff (extension methods and the SQL-ness of it don't feel natural to me). I do expect performance to improve with later CTPs and upon final release, but comparing the different ways within PFX is interesting, as is trying to restructure my code to me more "pure" (in PFX doc parlance)

.Sitecore » Blog Archive » PLINQ to Sitecore

.Sitecore » Blog Archive » PLINQ to Sitecore — Sun, 02 Dec 2007 21:59:27 GMT

PingBack from http://sitecore.alexiasoft.nl/2007/12/02/plinq-to-sitecore/

re: CTP Quality

Martin — Sun, 02 Dec 2007 01:47:42 GMT

Yes thanks you're right. I noticed this myself after better testing.

Martin

KubuS — Sat, 01 Dec 2007 20:11:20 GMT

Matrix of rank 10 is too small. In this case parallel matrix multiplication will give you no gain, rather performance degradation, as you observed.

Instead of using Paraller.For inside the calculation algorithm, try moving it one scope higher, when you iterate 1000000 times. Or try testing it on a bigger matrix.

Remember that parralel coumputing/programming is not a cure for everything, you have to know when to use it, and when fallback to sequential algorithms.

re: CTP Quality

Martin — Sat, 01 Dec 2007 13:34:31 GMT

Is it normal, that using Parallel.For is SLOWER than the normal for?

I made a little test with MatrixMultiplication, and the parallelizized part was more than two times slower.

That's the code I used:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Threading;

namespace PLINQ_Test

{

class Program

{

static void Main(string[] args)

{

double[,] res = new double[10, 10];

Console.WriteLine("press a key");

Console.ReadKey();

Console.WriteLine(System.Environment.TickCount);

for (int i = 0; i < 1000000; i++)

{

MatrixMult(10, getRandMat(10), getRandMat(10), res);

}

Console.WriteLine(System.Environment.TickCount);

for (int i = 0; i < 1000000; i++)

{

ParMatrixMult(10, getRandMat(10), getRandMat(10), res);

}

Console.WriteLine(System.Environment.TickCount);

Console.WriteLine("press a key");

Console.ReadKey();

}

private static double[,] getRandMat(int p)

{

double[,] res = new double[p, p];

Random rand = new Random();

for (int i = 0; i < p; i++)

{

for (int j = 0; j < p; j++)

{

res[i, j] = (int)(rand.NextDouble() * 1000);

}

return res;

}

static void ParMatrixMult(int size, double[,] m1, double[,] m2, double[,] result)

{

Parallel.For(0, size, delegate(int i)

{

for (int j = 0; j < size; j++)

{

result[i, j] = 0;

for (int k = 0; k < size; k++)

{

result[i, j] += m1[i, k] * m2[k, j];

}

});

}

static void MatrixMult(int size, double[,] m1, double[,] m2, double[,] result)

{

for(int i=0;i<size;i++) //Parallel.For(0, size, delegate(int i)

{

for (int j = 0; j < size; j++)

{

result[i, j] = 0;

for (int k = 0; k < size; k++)

{

result[i, j] += m1[i, k] * m2[k, j];

}