locked
Are you using Parallel Extensions? We'd love to hear about it. RRS feed

  • General discussion

  • Are you using Parallel LINQ (PLINQ), the Task Parallel Library (TPL), or any of the new coordination and synchronization primitives in .NET 4 (or in the Parallel Extensions June 2008 CTP or with the recent Reactive Extensions release)?  Are you planning to use or are you already using this support in a production application or library? We'd love to hear about it, and if you have time, what your experiences have been (good or bad).  Please email me at stoub at microsoft dot com... we're looking forward to hearing from you.  Thanks!
    Wednesday, December 16, 2009 9:39 PM
    Moderator

All replies

  • To the Microsoft team Brilliant job, I am a VB.NET Developer, have been for past few years, until parallel development came along, long standing optimization Ideas were in stall mode, until I started getting curious as to the buzz words of Tasks, Plinq e.t.c, Stephen Toub, legend, helped understand in simple ways how you should go about things in Parallel, including all the other memebers of your team and developers.

    My core :-) usage so far is with XNA / 3D Games design, I had a game engine I had been writing, and ran into some major optimization problems, !!! once I statred playing around with the PARALLEL LIBS, which I would strongley Urge all vb.net developers to get on with, I started to hit Frame rates in 100FPS, with

    realtime texture / Bitmap Processing effects

     Object collision Detection

    Object Picking

    Cull Cliping 

     Sorting

    Paricle Systems

    Audio Processing

    It has just been so much fun and so darn easy to do :-), if any one in the VB.net community want the code for the Engine is called Levler 3D at the moment, let me know and I can upload the code, so all users of VB.NET and XNA can have a look and use as you like (Always belived freedom of code usage is a good thing!!!)

    Please keep up the good work, and pay attention to US VB.NET users....

    Cheers and a ll the best guys ...  Stephen legend!!

    Tridex@yahoo.com ....

     

    Friday, July 2, 2010 12:34 PM
  • Hi Tridex-

    That's terrific to hear.  Thanks for sharing your experiences!

    Wednesday, July 7, 2010 4:49 PM
    Moderator
  • I've ported the 99 line ray tracer smallpt, found here , to VB.NET using the TPL. The goal of the port was to keep the VB code as close to the original in form and brevity. I'll post a link to the port as soon as I can. The original C++ achieved parallel processing through a one line OpenMP pragma. Thanks to the TPL I was able to add parallel processing using a similar one line Tasks.Parallel.For(). Thanks for the good work!
    Tuesday, August 10, 2010 9:49 PM
  • Hi Eric-

    Very cool; I'm glad it's worked well for you.  Please do share a link to your port when you have it available.

    Wednesday, August 11, 2010 4:41 PM
    Moderator
  • I have been using the Parallel class and the task class a lot recently. I am honestly floored at how easy it is to impliment parallel processing. I rewrote some of our batch processes... we have cut the run time down by HOURS literally by changing a foreach loop to a Parallel.ForEach(). Great stuff. I can't want to explore it more.
    Thursday, August 12, 2010 7:38 PM
  • Great to hear, Ryan; thanks for letting us know.
    Sunday, August 15, 2010 10:48 PM
    Moderator
  • I've been using the TPL heavily recently to parallelize some network device monitoring chores recently.  I have about 8000 devices.  When things work, I've been able to reduce the scan time from multiple hours to just under an hour.  Making some additional architectural changes looks like, if I can keep things working, I'll hit about 20 minutes which is my unofficial goal.  The ".WithTimeout(TimeSpan)" extension is really cool! ... and a life saver.

    I have noticed that I must be running up against some limitation in the environment.  I'm running on a W2K8 machine with 12 Gig of RAM.  I've noticed that when the memory usage grows to perhaps 2.5 Gig, however, the environment breaks down.  I also notice that apparently there are synchronizing events occurring as I notice that the performance monitor will never have more than one core running, when the environment breaks down.

    Obviously, better debug tools would be a great addition to the environment.

    All in all though, I think this a significant addition for you!

     

    Tuesday, August 24, 2010 5:01 PM
  • Hi Rusty-

    Thanks for sharing your feedback and experiences! It's great to hear about your successes and the things you'd like to see improved.

    Wednesday, September 15, 2010 5:51 PM
    Moderator
  • Dear Stephen,

    I tried to use the TPL inside my managed C++ (using /CLR compile option) without any success (after one full day spending on it)!!!
    I could not get my parallel::for or parallel::invoke methods to work.

    The problem I have is that all the help files in the MSDN and local help gives examples either for the concurrency native C++ or the TPL with C#.
    Also the intellisense on C++ express does not work, so that does not help either.

    Could you please send some sample projects with C++ managed code and the TPL???


    Thanks for your help!
    Michel
    Thursday, October 21, 2010 2:43 PM
  • I'm using Parallel.ForEach in an IronRuby 1.1.1 project.  The project is an attempt to speed up long-running queries which run against a massive data warehouse.  So far it looks promising, however I've found that debugging can be challenging due to the parallel nature.  Though I already knew it would be, before chosing this route.

    One thing I'm wondering though, what is the best practice for providing progress information on long-running tasks?  For example, is there an established pattern for providing progess, and how to expose or consume that data for updating something on a UI thread?

    Sunday, October 24, 2010 1:36 AM
  • ejstembler-

    Thanks for taking the time to respond!  Regarding your question on providing progress, typically you'd do one of two things: have a per-thread/task counter that is updated by the task each time it makes progress, and every N iterations based on that counter posts back to the UI thread to update progress, or have a shared counter across all threads, and again every N iterations based on that counter posts back to the UI thread.  The goal here is to provide enough progress information to keep the user satisfied but not impact performance significantly with a lot of synchronization overhead.

    Friday, November 19, 2010 3:46 PM
    Moderator