Re: concurrency, threads and objects
Chris Smith wrote:
Tom Forsmo <spam@nospam.net> 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