0

I have question about difference of following code: I will show the code first used with normal for loop.

Guesser class contructor starts mixing the character array and startBruteForce calls the function which permutates it in the key with the appropriate length that is matched to the private password. To every new key, I setted Console.Write (key); And results was different in each loop.

DateTime timeStarted = DateTime.Now;
Console.WriteLine("Start BruteForce - {0}", timeStarted.ToString());
                for (int i = 0; i < Environment.ProcessorCount; i++)
                {
                    Guesser guesser = new Guesser();        
                    Thread thread = new Thread(guesser.startBruteForce);
                    thread.Start();
                }
                while (!Guesser.isMatched) ;
Console.WriteLine("Time passed: {0}s", DateTime.Now.Subtract(timeStarted).TotalSeconds);

and Parallel.For 

DateTime timeStarted = DateTime.Now;
Console.WriteLine("Start BruteForce - {0}", timeStarted.ToString());
                      Parallel.For(0, Environment.ProcessorCount , (i) =>
                              {
                                  Guesser guesser = new Guesser();
                                  guesser.startBruteForce();
                             });
                        while (!Guesser.isMatched) ;        
    Console.WriteLine("Time passed: {0}s", DateTime.Now.Subtract(timeStarted).TotalSeconds);

In ParallelFor it was something like: a,b,c,d,e,f...ab,ac,ad... While in normal foor loop it was much more permutated for ex: b,r,1,a,k,b,ed It look like ParrarelFor created only one thread.

Normal for loop performs the brute-force algorithm faster than Parallel.For loop.

My question is why this is happening.

  1. Another thing that interests me is why if I will narrow the number of iterations to Environment.ProcessorCount/2both algorithms execution time are faster than just iterted with unchangedEnvironment.ProcessorCount.
Alberto Solano
  • 7,972
  • 3
  • 38
  • 61
Kulkejszyn
  • 65
  • 1
  • 7
  • 6
    You're only running a loop with `Environment.ProcessorCount` elements. This is a fairly small value, so naturally `Parallel.For` will decide it's probably more efficient to use one thread for that. Turns out, that's not the case, but it can't open up your method to see what's inside. Your `Guesser` is suspect -- it takes no arguments at all, so it probably inappropriately relies on global state (if it's not just demonstration code). `Parallel.For` (and `Parallel.ForEach`) are designed to easily parallelize over large data sets, not to spawn a fixed, small set of workers. – Jeroen Mostert Jun 06 '19 at 13:30
  • 1
    What the heck is that `while` doing there. Also it is not easy to answer without knowing what `Guesser` does – CSharpie Jun 07 '19 at 07:33
  • 1
    We need to see the `Guesser`. I am guessing there is thread-unsafe code in there, or thread contention caused by inefficient locking. – Theodor Zoulias Jun 07 '19 at 07:46
  • Well the guesser contructor contains only shuffle method. Or do you want to see the whole class? – Kulkejszyn Jun 07 '19 at 10:34
  • Τhe whole class! – Theodor Zoulias Jun 07 '19 at 14:07
  • Do you have HyperThreading turn on (default usually) in the BIOS. With HT if you have 4 cores, the OS thinks you have 8 cores and it will spawn 8 threads, which are all competing for 4 cores. Turn HT off and test again, and you will see the performance scale with the # of theads up to the # of cores you have. – John Alexiou Jun 07 '19 at 15:24
  • PS. You get better time resolution by using the `Stopwatch` class, rather than `DateTime`. – John Alexiou Jun 07 '19 at 15:28
  • Related post: https://stackoverflow.com/q/8258406/380384 – John Alexiou Jun 07 '19 at 19:56
  • As far as serial code for permutations see [this post](https://stackoverflow.com/a/16988082/380384) also. it is VB/NET but can be directly converted to C# and it works. – John Alexiou Jun 07 '19 at 21:06

0 Answers0