Software is sucks? Probably it really is!

3 בדצמבר 2007

14 תגובות

[This blog was migrated. You will not be able to comment here.
The new URL of this post is http://khason.net/blog/software-is-sucks-probably-it-really-is/]


Remember new features, that make your code unreadable? A couple of days ago, CLR team released first preview of Parallel Computing for .NET. Isn't it really cool, that now you can use full power of your computer? I decided to test the extension and wrote simple routine, that throttles your CPU.

static int i=0;
static void MessMe()
        {
            for (;;)
            {
                i ++;
                if (Console.KeyAvailable)
                {
                    Console.ReadKey(true);
                    break;
                }
            }
        }

Cool, now let's run it (with measurement) on my Dual Core 2 processor.

MessMe();

image

Nice, 54K simple math operations per second with half of each of my cores

image

It's already works (maybe because of my super OS?), but I still did not used it. Let's try to use the Parallel Computing extension.

Parallel.Do(MessMe);

image

What's going on with CPU?

image

Looks the same? Probably. Now the question is why the application performance degraded? Maybe it should know how much cycles I need?

image

And now with the Extension

image

Well, not really works. Let's try another method

Parallel.For(1, int.MaxValue, delegate(int k)
            {
                i = k;
                if (Console.KeyAvailable)
                {
                    Console.ReadKey(true);
                }
            });

 image

Hmmm, it looks much better now, but still I do not understand that's going on here.

Yes, I know, this is stupid way to test framework and it's very early stage to judge, however, please someone can explain me what exactly wrong I'm doing?

Download Parallel Computing December CTP

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

14 תגובות

  1. Eran Kampf3 בדצמבר 2007 ב 20:13

    According to the docs I read on MSDN:
    The Parallel.Do method is a static method that takes two or more delegates as arguments and potentially executes them in parallel.

    So running Parallel.Do(MessMe); should be pretty much like running MessMe();

    Parallel.For() actually runs the interations in multiple threads so it works faster but requires you to make sure the iterations are independent of each other.

    הגב
  2. Tamir Khason3 בדצמבר 2007 ב 20:15

    Eran, try to run MessMe twice – you'll get the same result 🙂

    הגב
  3. עומר ון קלוטן3 בדצמבר 2007 ב 20:54

    When you ran Do, you told the framework to run your code as is, as an atomic unit. Running it twice just tells the framework that it can run the atomic units of code on two processors (or threads) at the same time, but it will still not have the freedom to divide the work itself.

    When you ran For, you told the framework to do the work division for you, which means that you gave it more freedom to parallelize your code.

    More here: http://msdn.microsoft.com/msdnmag/issues/07/10/Futures/default.aspx

    הגב
  4. ekampf3 בדצמבר 2007 ב 21:15

    Hey, my machine has .NET 3.5 beta2 and highly unstable O14 bits that I just got working…

    I'm not risking any other CTP\WIP bits installations now 🙂

    Anyway, there's a difference between running parallization on MessMe which contains a for loop inside than running Parallel.For whith a delegate that represent one loop iteration.

    I don't think Parallel.Do(MessMe); can go inside MessMe() and parallelize the fir loop inside it (it can't know or assume that the iterations are not dependent and MessMe should be an atomic operation for it)

    הגב
  5. ekampf3 בדצמבר 2007 ב 21:16

    What's that spanish site that keeps syndicating you?

    הגב
  6. Tamir Khason3 בדצמבר 2007 ב 21:53

    Eran, just another spammer
    Eran, Omer – the question is not how to use it, but in current 3.5 RTM a lot of this concept already implemented

    הגב
  7. עומר ון קלוטן3 בדצמבר 2007 ב 22:23

    I thought the question was:

    "please someone can explain me what exactly wrong I'm doing?"

    Which to me read:

    "how should I use this?"

    But maybe I'm off here. What is the question being posed by this post? 🙂

    הגב
  8. Tamir Khason3 בדצמבר 2007 ב 22:30

    It was rather statement, then question 🙂 Something like: "I know for sure, that i'm doing wrong, but why should you (as CLR team) make me able to do things wrong.
    Back to connection of context.

    Assembler – if you're doing something wrong, you're get very bad results
    C++ – if you're doing something wrong, you're get blue screen or nothing works
    C# 1.1-2.0 – you, probably, can do things wrong, but you're going pay for it
    C# 3.0-3.5+ – you, probably, do something wrong, 'cos we have too much things to do wrong
    C# 4.0 and up – I do not want to be developer, due to fact, that if I'll do something ok, I'll get very bad results

    That's my point:)

    הגב
  9. Bill4 בדצמבר 2007 ב 0:24

    Parallel.Do is not intended to run a single function/delegate over multiple processers, it will simply run as many functions as it can from its param list at the same time.

    Parallel.For will run the parallel delegate as many times as it can at the same time with the different inputs.

    Your test is probably not very good in that you are writing to a static object. There could be locking issues there.

    הגב
  10. Sasha Goldshtein4 בדצמבר 2007 ב 0:49

    You didn't post the entire test harness, and I found it quite difficult to follow exactly what you were measuring. As other commenters noted, Parallel.Do(MessMe) and a direct call to MessMe() are essentially the same, sans little initial overhead from using the parallel version, which should be amortized with time.

    However, what you should bear in mind that your code spends most of its time in kernel mode, executing Console.KeyAvailable (which boils down to kernel32!PeekConsoleInput). So this is really a bad example of parallelizing anything, since the majority of work here is polling the console input handle.

    The following is a slightly better scenario which shows the added value of parallel extensions, because the work is CPU-bound:

    static int primeSum;
    static void Compute(int i)
    {
    for (int j = 1; j <= Math.Sqrt(i); ++j) { if (i % j == 0) primeSum += j; } } Take this method and call it 500,000 times and here's what you get on my PC (a modest Core 2 Duo 1.86 GHz)... Using a simple loop (from 0 to 500,000) it performs 40,900 operations per second with 50% CPU utilization. Using Parallel.For (from 0 to 500,000) it performs 77,000 operations per second (which is really good, considering that the first few thousand invocations of Compute are really really cheap and therefore the overhead of the delegate call dominates), with 100% CPU utilization. Using Parallel.Do it performs 40,400 operations per second (which is the amortized cost of the initial Parallel.Do overhead), with 50% CPU utilization. All these results are perfectly on par with the way the parallel extensions are supposed to work. In fact, it's hardly magic - you could easily implement this kind of framework yourself. What I find valuable here is that Microsoft finally released a parallelization framework which might actually be accessible for those 80% of developers who do not read blogs, read books or attend conferences. And that's what makes me happy.

    הגב
  11. Mr.J4 בדצמבר 2007 ב 4:44

    Did I say I love you guys for having this little "chat" online. . . I think I have to second Sasha both with his analysis and his final statment.

    הגב
  12. עומר ון קלוטן4 בדצמבר 2007 ב 6:12

    As for your analysis of the advances in C#, I think my best advice for you would be that you wait until these language features grow on you, just like I'm letting WPF grow on me. Some day you'll not know how you could have done without them. 🙂

    הגב
  13. Tamir Khason4 בדצמבר 2007 ב 11:09

    Thank's Sasha
    I understand the point, really. My problem is with way of using it and not with the framework itself. I think, this should be an integrated part of .NET from 1.1, integrated into it and not additional install as tool.

    הגב
  14. Sasha Goldshtein4 בדצמבר 2007 ב 15:37

    Oh, I'm pretty sure it's going to be integrated into the framework. They just didn't make it to the .NET 3.5 deadline.

    As for previous versions, well, they are not the only platform development group that ignored concurrency issues for several years now… We are just starting to see the sprouts of concurrency and parallelization as first-class constructs or first-class libraries. I have almost no doubt that this will change.

    הגב