Re: concurrency, threads and objects
- From: Tom Forsmo <spam@xxxxxxxxxx>
- Date: Thu, 16 Nov 2006 18:45:56 +0100
Chris Smith wrote:
Tom Forsmo <spam@xxxxxxxxxx> wrote:
I don't believe you. That is, I believe you've created better software than other people; I don't believe that an improvement of that scale came from decisions along the lines of trying to avoid creating one object per thread.
No, not at that small level, but applying the same principle to all code and especially to data structures that hold big amounts of data.
Sometimes creating 100 threads can make your development life easier by helping you separate various tasks in your application design; but if that cost is okay with you,Yes, for example in high performance server design, where the server should be able to handle between thousand and ten thousand transactions per second.
Are there anything close to 50 CPUs in the box? If not, then 100 threads is still very likely to be killing your performance to the point that it's way past time to worry about 100 objects.
Are you pulling my leg? What system are you running on?
The code I did which prompted me to ask the original question, ran a thousand server threads and five hundred client threads where the client issued ten thousand requests per thread. In total five million requests, which finished in around 45 minutes. This is on a Intel Core Duo processor running Linux with 1.5 GB of RAM:
Linux duplo 2.6.17.8tf2 #10 SMP PREEMPT Wed Aug 30 22:35:48 CEST 2006 i686 Genuine Intel(R) CPU T2300 @ 1.66GHz unknown GNU/Linux
Threads are very cheap in linux 2.6, when they changed the kernel thread model, they did a test where they created one hundred thousand threads. With the old model that took about 15 minutes with the new model it took 2 seconds ref: http://kerneltrap.org/node/422
As far as I understand it. On Windows processes are expensive while threads are cheap. On linux processes are cheap and threads are extremely cheap.
Back to the business at hand. The server and client is communicating with UDP (so that's a bit cheaper and its a simple request/reply operation, which talks to a DB (oracle cluster, so the DB does not cause any problems). In addition the code is completely self made, no app servers or anything like that, which of course would eat up a lot of the cpu power and memory.
"That" statement? You mean the one that says that threads are likely killing your performance, so stop worrying about 1K of memory allocations?
No, I mean the statement: "stop worrying about memory and processing power, we can just buy some more...".
Most people probably don't hear that a lot. If you're hearing that a lot from other developers, then perhaps it's time to think about whether threads are killing your performance.
Its almost exclusively coming from java developers, but also from developers of other languages, although not as much. I think its lazy programming. I don't mean to be rude and condescending towards java or java developers, I like java as well. I just think there are some ideas that the programming and java community should open their eyes to. I have been working in a C project the last couple of years and that's where I learned to appreciate that sentiment.
tom
.
- Follow-Ups:
- Re: concurrency, threads and objects
- From: Robert Klemme
- Re: concurrency, threads and objects
- From: Chris Smith
- Re: concurrency, threads and objects
- References:
- concurrency, threads and objects
- From: Tom Forsmo
- Re: concurrency, threads and objects
- From: Chris Uppal
- Re: concurrency, threads and objects
- From: Tom Forsmo
- Re: concurrency, threads and objects
- From: Chris Uppal
- Re: concurrency, threads and objects
- From: Tom Forsmo
- Re: concurrency, threads and objects
- From: Chris Smith
- Re: concurrency, threads and objects
- From: Tom Forsmo
- Re: concurrency, threads and objects
- From: Chris Smith
- concurrency, threads and objects
- Prev by Date: Re: NPE in PriorityQueue.poll()
- Next by Date: Re: NPE in PriorityQueue.poll()
- Previous by thread: Re: concurrency, threads and objects
- Next by thread: Re: concurrency, threads and objects
- Index(es):
Relevant Pages
|