Comparing performance between thread, task, parallel

Question

I wrote some function to compare the duration taken for 1000 loops. Just wondering if the comparison is right? For the thread, I want to set to maximum 3 thread. Thread is core, right? Task took the longest time which seems not correct.

using System;
using System.Diagnostics;
using System.Linq;
using System.Threading;
using System.Threading.Tasks;

namespace Multithreading_Loop
{
class Program
{
    static void Main(string[] args)
    {
        //PrintLoopWithoutThread();
        //PrintLoopWithThread();
        //PrintLoopWithTaskWaitAll();
        //PrintLoopWithParallelFor();
        PrintLoopWithParallelForEach();
    }

    /// <summary>
    /// Elapsed time: 4.13 seconds
    /// </summary>
    private static void PrintLoopWithoutThread()
    {
        Stopwatch sw = new Stopwatch();
        sw.Start();

        for (var x = 1; x <= 1000; x++)
        {
            Console.WriteLine($"Worker Id: {Thread.CurrentThread.ManagedThreadId}");
            Console.WriteLine(x);
        }

        sw.Stop();
        Console.WriteLine(sw.Elapsed.TotalSeconds);
    }

    /// <summary>
    /// Elapsed time: 11.4 seconds
    /// </summary>
    private static void PrintLoopWithThread()
    {
        Stopwatch sw = new Stopwatch();
        sw.Start();

        Thread t1 = new Thread(PrintLoopWithoutThread);
        t1.Start();
        Thread t2 = new Thread(PrintLoopWithoutThread);
        t2.Start();
        Thread t3 = new Thread(PrintLoopWithoutThread);
        t3.Start();
        t1.Join();
        t2.Join();
        t3.Join();

        sw.Stop();
        Console.WriteLine(sw.Elapsed.TotalSeconds);
    }


    /// <summary>
    /// Elapsed time: 15.5 seconds
    /// </summary>
    private static void PrintLoopWithTaskWaitAll()
    {
        Task task1 = Task.Factory.StartNew(() => PrintLoopWithoutThread());
        Task task2 = Task.Factory.StartNew(() => PrintLoopWithoutThread());
        Task task3 = Task.Factory.StartNew(() => PrintLoopWithoutThread());

        Task.WaitAll(task1, task2, task3);

    }

    /// <summary>
    /// Elapsed time: 2.2 seconds
    /// </summary>
    private static void PrintLoopWithParallelFor()
    {
        Stopwatch sw = new Stopwatch();
        sw.Start();

        Parallel.For(0, 999, x =>
        {
            Console.WriteLine($"WorkerId: {Task.CurrentId}. Number: " + x);
        });

        sw.Stop();
        Console.WriteLine(sw.Elapsed.TotalSeconds);
    }

    /// <summary>
    /// Elapsed time: 2.0 seconds
    /// </summary>
    private static void PrintLoopWithParallelForEach()
    {
        Stopwatch sw = new Stopwatch();
        sw.Start();

        var data = Enumerable.Range(0, 999);

        // If computer has 4 cores and you want to use the maximum 4, 
        // then put MaxDegreeOfParallelism = 4
        Parallel.ForEach(data, new ParallelOptions { MaxDegreeOfParallelism = 4 }, i =>
        {
            Console.WriteLine($"WorkerId: {Task.CurrentId}. Number: " + i);
        });

        sw.Stop();
        Console.WriteLine(sw.Elapsed.TotalSeconds);
    }

}
}

Answer 1

You definitely should remove all Console.WriteLine operations that are executed during the measuring. You want to measure pure excecution time.

Also thread creation/management costs time i.e. overhead. When using Thread (executing PrintLoopWithThread) you started the Stopwatch BEFORE you created the threads, which is correct, because you want to include the overhead of each parallelization method. But when creating Task instances (when executing PrintLoopWithTaskWaitAll), you started the Stopwatch AFTER their creation, which leads to ignore instantiation costs i.e. overhead. The results are therefore not comparable at all.

Furthermore keep in mind that Parallel.For performs bad for small workloads:

If the body of the loop performs only a small amount of work, you may find that you achieve better performance by partitioning the iterations into larger units of work. The reason for this is that there are two types of overhead that are introduced when processing a loop: the cost of managing worker threads and the cost of invoking a delegate method. In most situations, these costs are negligible, but with very small loop bodies they can be significant.

Threading can slow down operations/applications significantly. For efficient multithreading it's not enough to use a fixed number of threads. You usually use smart partitioning/ workload balancing algorithms, thread pooling and metrics to find the pivot when multithreading becomes too expensive i.e. wrong choice. It's not simple to implement efficient multithreading or test efficiency.

Most of the time tests are only relevant for a special scenario - the tested scenario. So, it'S best to test at least both expected ends: a worst-case sccenarion and a best-case scenario. You maybe will come to the conclusion to use dynamic workload based multithreading (like PLINQ does) and only use threads under certain conditions.
The best is to test with the real code you are trying to parallelize. 999 iterations is way too few to have significant impact - at least when running no-ops. You want CPU bound heavy loads, but 999 "empty" iterations is just a blink in terms of CPU workload.

Answer 2

The Console uses synchronization:

I/O operations that use these streams are synchronized, which means that multiple threads can read from, or write to, the streams.

This synchronization ensures that all sentences are printed and nothing gets lost due to a data race.

However, synchronization kills multithreading, because the threads will stop at the synchronization object. Don't use Console.WriteLine() for performance comparisons.

Another thing to consider: at the moment you have 3 tasks, each printing 1000 lines. That way, scheduling cannot be done in small pieces. What you typically want is 3000 tasks, each printing 1 line. (read "printing" == "doing work").