Re: help with huge memory consumption??
- From: phil-news-nospam@xxxxxxxx
- Date: 11 Mar 2007 02:30:58 GMT
On 10 Mar 2007 17:19:56 -0800 David Schwartz <davids@xxxxxxxxxxxxx> wrote:
| On Mar 9, 3:57 pm, Chris Friesen <cbf...@xxxxxxxxxxxxx> wrote:
|
|> Sure there is. Given a parallel task that can be done with threads,
|> there is almost always an equivalent way to do that task using
|> separate
|> processes with shared memory, unix sockets, etc.
|
| The design issues between the two approached would be so different
| that it would no longer make sense to compare the creation time of a
| thread to the creation time of a process.
Just because design issues are different (they are for lots of choices
we make) in threads vs. processes does not mean these are not comparable.
| For example, suppose the threads could be reused but the processes
| couldn't. Then you would be creating far fewer threads than processes.
| Suppose the processes could easily be reused but not the threads,
| again the number would be different.
You'll going to have to give a clear, precise, and unambiguous definition
of what you mean by re-use here. As far as I know, both processes and
threads are re-usable in the sense that when a thread or process gets
done doing one thing, it can pick up something else to do and work on
that next.
| You cannot take two completely different programs and compare them by
| looking at the cost of one operation that one does against some other
| one operation the other does. That's just nonsensical.
But you can when making design decisions. Just because other design
decisions are different depending on this choice does not matter. The
costs of the other design decision work would be part of that comparison.
|> While POSIX has defined threads and processes in a particular way,
|> from
|> an implementation level in linux they are fundamentally a schedulable
|> entity that shares various amounts of data with other schedulable
|> entities. Threads share almost everything, processes share almost
|> nothing. You can create wierd hybrids that are partway in between.
|
| And if you did so, the costs of creating those weird hybrids would be
| incomparable to the costs of creating either threads or processes.
| It's like comparing the cost to overnight a pound of bananas against
| the cost to send by boat a ton of eggs. There is almost no conceivable
| case where you would want to do one or the other the same number of
| times.
Your analogy is like trying to compare the value of threads for application
A against the value of processes for application B. Of course that is no
benefit to compare. But your analogy doesn't work for this. Comparing
threads and processes is more like comparing shipping the _same_ product
by overnight vs. by boat. There are fundamental differences. Some things
should not be shipped by some means. The eggs might break in airplanes.
Fresh fish might spoil shipped by truck. Certain hazardous material just
cannot be shipped by mail or courier. But that doesn't mean you can't
compare airplanes vs. boats vs. trucks vs. railroads vs. donkey backs.
By doing the comparisons you find out what may be impractical for some
things. You may find out which programs are impractical to do in threads
or in processes. But that's a result of comparison, not an excuse to
deny that comparison can even be done.
|> Suppose you want to simultaneously issue statfs() calls for each
|> filesystem on the machine. One method would be to set up a shared
|> memory mapping for the results and fork() one process for each
|> filesystem. Alternately, you could pthread_create() one thread for
|> each
|> filesystem. The two are equivalent. There is slightly more overhead
|> involved in the fork() version, but the result is the same.
|
| Let's assume they are equivalent. That means, in both cases we keep
| the threads/processes around if we're going to reuse them (or we don't
| in either case). That means the total creation cost in both cases is
| negligible. If we aren't reusing them, then if the cost is high, it's
| because of our bad design choices, not because of the cost of creating
| threads or processes.
You don't dismiss design issues in comparison. If processes mean more
design work to figure out how to get large bulks of data between them,
then that is part of the cost figure that says "use threads". For many,
it can be so obvious that one or the other method is better that we don't
even bother doing the cost figured in detail. Better programmers would
only need to figure this out where the benefits of the choice is very
close for a given project.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-03-10-2017@xxxxxxxx |
|------------------------------------/-------------------------------------|
.
- Follow-Ups:
- Re: help with huge memory consumption??
- From: David Schwartz
- Re: help with huge memory consumption??
- References:
- help with huge memory consumption??
- From: Dan Miller
- Re: help with huge memory consumption??
- From: David Schwartz
- Re: help with huge memory consumption??
- From: phil-news-nospam
- Re: help with huge memory consumption??
- From: David Schwartz
- Re: help with huge memory consumption??
- From: Rainer Weikusat
- Re: help with huge memory consumption??
- From: David Schwartz
- Re: help with huge memory consumption??
- From: Rainer Weikusat
- Re: help with huge memory consumption??
- From: David Schwartz
- Re: help with huge memory consumption??
- From: Chris Friesen
- Re: help with huge memory consumption??
- From: David Schwartz
- help with huge memory consumption??
- Prev by Date: Re: help with huge memory consumption??
- Next by Date: test
- Previous by thread: Re: help with huge memory consumption??
- Next by thread: Re: help with huge memory consumption??
- Index(es):
Relevant Pages
|
