Re: concurrency, threads and objects

Tom Forsmo <spam@xxxxxxxxxx> wrote:
That only applies if you don't have experience in thinking about
avoiding code bloat and its problems. I have numerous times created
applications that require a fraction of memory or cpu power compared to
a someone's idea that you should not worry about it. In some cases I
have also created working and stable solutions when others have not
managed to get one off the ground, because of code bloat.

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.

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. Half my point is
that you are overestimating the performance impact of creating
objects... but the other half is that you are underestimating the
performance impact of creating threads. If you need that kind of
performance, you should be doing thread pooling and asynchronous I/O in
concert with state machines to reduce the number of threads to less than
about twice the number of CPUs.

Its funny how many people hide behind that statement, it clearly shows
they really do not know what they are talking about in that respect.

"That" statement? You mean the one that says that threads are likely
killing your performance, so stop worrying about 1K of memory
allocations? 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.

Yes, I realize you'd like to come away from this conversation feeling
superior because you can avoid "code bloat" while all us lowly Java
programmers can't. Feel free to do so, of that's what your ego needs.
Otherwise, you might want to fix your thread problem.

--
Chris Smith
.

Relevant Pages

  • Re: 2nd CPU on a Sun Blade 2000 problem
    ... memory) and left the original in the '0' slot? ... will only find in a Sun Fire 280R (uses the same CPUs and system board, ... but is a rack mount server, and the RSC card allows "LOM" (Lights Out ... framebuffer slot -- and there is no way to use a UPA framebuffer in the ...
    (comp.sys.sun.hardware)
  • Re: Lies, Damn Lies and Statistics...
    ... I've never looked at the source code of either IDS or DB2. ... binds sessons to engines hence if the engine is busy ... dynamically add shared memory segments on Linux. ... CPUs, as it sees fit. ...
    (comp.databases.informix)
  • Re: Best FPGA for floating point performance
    ... > the problem with highly threaded cpus is that they are not very good ... SW performance today as well as the cpus memory systems that don't like ... also FPGA P/R have no locality at all. ... Sparc in its Niagara form will serve their needs better than any x86, ...
    (comp.arch.fpga)
  • Re: Intel details future Larrabee graphics chip
    ... for dinky little SMP systems of 4-8 cores. ... Why multi-thread *anything* when hundreds or thousands of CPUs are ... video CPUs using fancy memory and generics doing the grunt work. ... Duo, and never get trojans, memory leaks, any of that. ...
    (sci.electronics.design)
  • Re: what is the meaning of registers,internal memory?
    ... Unlike RAM, these little scratch pads as I mentioned are tucked away ... RAM = Random Access Memory, ... number of CPUs on a memory bus, and eliminates the bottlenecks with many ... NUMA systems are not clusters however, ...
    (comp.lang.asm.x86)