As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I read this question Asynchronous vs Multithreading- is there a difference and search in Google about differences.
What is the benefit to use Asynchronous instead of Multithreading?
and when use Asynchronous instead of Multithreading?
If your task can be done using asynchronous programming, the it is better to do it that way instead of going for multi-threaded programming. for 3 reasons:-
1: Perfomance
In multi-threading, the CPU or w/e has to keep switching between threads. So, even if your thread is doing nothing and just sitting there (or more likely, doing a comparison to see if a condition is true so it can get one with doing with w/e it was created to do), the CPU still switches threads and the process takes some time. I don't think that would be very bad, but your performance surely takes a hit.
2: Simplicity & Brevity
Also, maybe it's just me, but asynchronous programming just seems more natural to me. And before you ask, no, I'm not a fan of JS but still. Not only that, but you run into problems with shared variables and thread-safeness and others — all of which can be side-stepped by using asynchronous programming and callbacks.
3: Annoying implementations of threads
In Python there's this really horrible thing called a GIL (Global Interpreter Lock). Basically, Python doesn't let you actually run concurrent threads. Also, if you're thinking about running a threaded program on a multi-core CPU, forget it.
There might be caveats in C# too, I don't know. These are just my 2 cents...
All that said, asynchronous and multi-threading are really not that comparable. While multi-threading may be used (inefficiently) to implement asynchronousity, it is a way to get concurrency and acynhrounousity is a programming style, like OOP (Object Oriented Programming).
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Donald Knuth said that "premature optimization is the root of all evil", and I gradully believe the saying.
So can I put it that when writing an application, we should concentrate on completing the functions, without concerning performance issue, until we cannot bear the low performance?
I'm afraid that if I use a wrong pattern many times which slows down the application, as a result fix the issue may consume a considerable amount of time. Should I test the performance of the pattern before widely using it?
The pattern I mentioned may refer to use Linq or for-loop, use Delegate.BeginInvoke, Parallel.For, or Task<T>, dispose IDisposable or just ignore it, etc.
Any refernece materials are all welcomed.
I agree with the spirit of Knuth's quote about premature optimization, as it can cause code to become overly complex and unwieldy too early in development, impacting both the quality of the code and the time needed to complete a project.
Two concerns I have about your post:
You should have a sense about whether or not your function/algorithms can theoretically scale/perform or not to meet your requirement (e.g. the O complexity of your solution -> http://en.wikipedia.org/wiki/Analysis_of_algorithms )
The patterns you mention are actually concrete implementation items, only some of which are related to performance, e.g.
Parallel.For/Task - these are useful for gaining performance on multi-core systems
IDisposable - this is for resource management related, and not something to be avoided
Linq vs. for-loop - this can be a point-optimization, but you'll need to benchmark/assess your use case to determine which is best for you (e.g. Linq can be moved to PLinq in some cases for parallelism)
Delegate.BeginInvoke - a non-optional component of thread synchronization
Never code without concern for performance.
Code for performance up until the code would get more complex (e.g. parallel).
But with C# 5.0 even parallel is not complex.
If you have some calls you think might need to optimize then design for that.
Design the code so optimization does not change the interface to the method.
There is speed, memory, concurrency (if a server app), reliability, security, and support.
Clean code is often the best code.
Don't get crazy until you know you have a performance problem but don't get sloppy.
In answering another question on SO I told the person they did not need a DataTable and DataReader would be faster with less memory. Their response was it still runs in 1/2 a second I don't care. To me that is sloppy code.
#JonhSanders I disagree that "Code for performance up until the code would get more complex" will cause either bugs or incomplete. For me coding for performance is not the same as optimize. First pass on anything but throw away code I code for performance - nothing exotic just best practices. Where I see potential hot spots that I might need to come back and optimize I write with optimization in mind. P.S. I agree on closing the question.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
We are about to implement a small automated securities trader. The trader will be build on top of the excellent quickfix FIX engine.
After due though, we narrowed our options down to implementing it in C# or in Python. Please specify the pros and cons of each language for this task, in term of:
Performance (The fact that Python uses a GIL troubles me in terms of thread concurrency)
Productivity
Scalability (We may need to scale this trader to a fully-sized platform)
EDIT
I've rephrased the question to make it less "C# vs. Python" (which I find irrelevant - both languages have their merits), but I'm simply trying to draw a comparison table before I make the decision.
I like both languages and a think both would be a good choice. The GIL might really be the most important difference. But I'm not sure if it's a problem in your case. The GIL only affects code running in pure Python. I assume that your tool depends more on I/O than on raw number crunching. If your I/O libraries handle the GIL correctly, they can execute concurrent code without problems. And even for number crunching you still have numpy.
My choice would depend on your existing knowledge. If you have experienced C# developers at hand I would go for C#. If you start absolutly from scratch and it's really 50:50, then I would go for Python. It's easier to learn, free and in many cases more productive.
And just to mention it: You might also have a look at IronPython. ;-)
For points "Performance" and "Scalability" I would suggest C# (although a large part of performance depends on your algorithms). Productivity is much of a subjective thing, but now C# has all cool features like lambda, anonymous method, classes etc which makes it much more productive.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I want to get a good grasp of multi-threading in C#. I've read some articles like Joseph Albahari's tutorials that explain the concepts, but as you know, no matter how much you read, most of it becomes rubbish if you don't practice. I need something that has instructive and pragmatic code examples related to real life practices, not some examples that print some lines. Do you have any suggestions?
guys guys I think I found a good site: planet-source-code.com. Searching in .Net codes with "thread" keyword seems to return some good examples, like
multi threaded folder synchronization
multi threaded TCP server
background file downloader
async. socket
P2P file sharing
simple POP3 console mail checker and lots of others!
yay!
Some kind of random number-crunching is a good test for this. I taught myself threading by writing a prime number finder, then breaking my "search" numbers into blocks and using a thread to work through each one.
This let me set some variables on block size, number of threads to use, wait time between firing threads etc. to test how each of these affects performance.
If you're doing any winforms or wpf development, you'll quickly run across issues when you try to do "stuff" in the UI thread.
Let's say that you need to read and parse the contents of a large (2GB) XML file. If the work were performed in the UI thread, the interface would hang until the work had been completed. Conversely, if you were to do the work correctly in a worker thread, then you could keep the UI responsive via messaging and let the user know what you're currently doing (status bar (ugh,) or display in text what you're doing "Reading XML.", etc.)
A good simple example would be to make a sample application and have it fire off a BackgroundWorker to handle some arbitrary work in the background (it could even be Thread.Sleep(10000), or something trivial like that.)
I'd say this is one of the many good starting points out there on the subject.
http://msdn.microsoft.com/en-us/library/cc221403%28VS.95%29.aspx
This site has a few sample applications that I think would be decent practice applications to implement. However, it seems like the links to the source code are broken. Nonetheless, I believe the applications presented represent very practical examples. A few include:
Desktop Search
Download Manager
FTP Client
File Compression
Multiple RSS Feeds
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What would you suggest as a road map for becoming very proficient in writing multithreaded applications - beyond "tinkering"?
I am a C# developer - would branching off into some other languages help this endeavor?
Does the parallel addition to .NET 4.0 hide things that you should know in order to make it easier?
Read Joe Duffy's "Concurrent Programming on Windows". Joe is an amazing expert.
Investigate different approaches to concurrency on different platforms; look at Erlang, Scala etc
Likewise read Java concurrency books, which will have some subtly different details, but often tackle the same core issues and have some useful patterns. "Java Concurrency in Practice" is often recommended.
Look at the various options on .NET, including the Coordination and Concurrency Runtime and F# asynchronous computations
Definitely learn Parallel Extensions - it'll help a lot, and from what I've seen, a lot of very careful design work has gone into it. (It's changing somewhat for 4.0b2 though, so you may want to defer this for now.)
Theres a really good PDF about threading in .NET here the MSDN documentation for the Thread class as well as the threading primitives (Mutex, WaitHandle, ReaderWriterLockSlim et al) is also good reading.
The key things to understand are:
When to use a thread
When not to use threads
How to manage sharing state between threads.
I could go on to explain these here, but I feel the threading PDF linked to above does a far better job than I could in that respect, the key point is that threads are a powerful tool and understanding when and how to use them will make you more proficient in their use than simply reading MSDN, although strategies for using threads effectively are covered there also.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm doing a little research in developing a simple socket server that will run as a windows service. I'm going to write this in C#, but I've been made aware that .Net sockets are slllooooowwwww. For the initial roll out using the .Net Networking classes will be fine, but I'm wondering if anyone has experience with a high performance (and hopefully free) socket library. I'm thinking probably something written in c++ that I can use as a com object in .net.
I've used indy sockets before, but it doesn't look like there is any active development going on with the project anymore. I've done some googling and I've found a few libraries, but I was hoping to get feedback from someone who has actually used a socket library with good success.
Any help appreciated. Thanks.
I would revisit your initial assumption - I don't believe it's accurate.
In my experience, the overhead of using .NET's framework socket libraries is not high - they perform quite well. The main cause of very slow socket code, that I've seen, is when people try to port non-C# code into C# directly, in particular, trying to port synchronous C++ socket code. The sockets in .NET's BCL are all designed to be used asynchronously. If you try to force them into a synchronous model, you'll end up adding quite a bit of blocking, which definitely causes very slow code.
Try using the socket classes the way they were designed - I think you'll be very happy with the performance, as well as the usability.
Sounds like you are optimizing before you need to. I would go ahead and build it with .NET and see if you have a performance problem before you try to do something that would potentially be slower. COM has a lot of overhead.