|
-
Jul 4th, 2006, 12:57 PM
#1
Thread Starter
PowerPoster
VB dot net multithreading
I was interested in hearing VB dot net programmers ideas on this. which of the 2 multhithreading methods would be better/faster/safer? This is for a long calculation loop ... entire loop is repeated multiple times (in separate threads).
1) do all the multithreading in VC++ dll
2) just do the loop in the VC++ dll and use VB dot net to start the loops in threads.
I hope this thread doesnt turn into one of those long heated discussions about what multi threading really is ... :-)
Any thoughts greatly appreciated.
-
Jul 4th, 2006, 03:45 PM
#2
Re: VB dot net multithreading
Is the calculation routine already written in VC++?
I don't see a need to have any of the code written in VC++ but if the component is already in VC++ then I probably #2 but I don't think it will really matter much.
-
Jul 4th, 2006, 04:41 PM
#3
Re: VB dot net multithreading
You've brought VC++ into the conversation without any indication of why. You can do everything in VB.NET, so what has C++ got to do with it? Have you already written some code in C++? Do you want to use C++ because you need the increased performance that it offers? Is/will the C++ be managed or unmanaged? If you want to use pointers to speed up your calculations you could also use C# for either the whole thing or for the performance-critical sections. I wouldn't like to say either way until I know where the C++ bit comes into the equation.
-
Jul 4th, 2006, 09:27 PM
#4
Thread Starter
PowerPoster
Re: VB dot net multithreading
My line of thinking is that VC++ will be finish the lengthy calculation loop faster than dot net. this loop can run for hours ... even a day or more ...
Will managed vs unmanaged VC++ slow me down?
Here is something to give you an idea of what i want to accomplish (this isnt the actual code, of course):
for i = 1 to 100
do until Finished = True
'much nastiness here ... can take an hour before Finished = True
Loop
next i
So I am looking for the fastest execution time by:
1) Letting a VB dot net program send a VC++ dll containing the do loop into multiple threads
2) Let a VB dot net simply call a VC++ dll that takes care of everything internally in multiple threads.
exection speed are the biggest concerns (of course it has to be stable)
thanks for any addtional ideas or comments.
-
Jul 4th, 2006, 09:37 PM
#5
Re: VB dot net multithreading
If you're using C++ to increase execution speed then just use it for the blocks of code for which it will produce such an effect. Multi-threading in .NET is relatively easy so take advantage of that.
-
Jul 5th, 2006, 12:29 AM
#6
Re: VB dot net multithreading
Calling DLL functions has an overhead that offsets performance gains for small blocks of code. If you have the loop in a function in the C++ DLL and call it from a new thread .NET it should be executed in the context of that thread thus not locking up the rest of your application.
However! Whether you gain anything from using C++ depends on what you are doing. Basic arithmetic is not any slower in .NET than any other language. The main slowdowns come from marshalling and garbage collection. Both associated with complex types. If you could elaborate on the "calculations" then we could assess whether or not it wouldn't just be easier and more efficient to do the whole thing in 'Net.
-
Jul 5th, 2006, 09:48 AM
#7
Thread Starter
PowerPoster
Re: VB dot net multithreading
inside the loop are many math calculations ... you could say that it is simple math calcs used to implement complex numerical approximations. Also remember that this isnt a small block of code ... its not uncommon for a Pentium 4 3+ GHz or a Pentium M to spend an hour inside just one execution of the loop. The values operated on all reside in class properties. Is that enough info to give you an idea of a preferred approach? Any ideas on how I can make this really lean and fast?
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|