| Christopher Browne 2004-11-15, 2:45 am |
| After a long battle with technology, mlw <mlw@nospam.no>, an earthling, wrote:
> Christopher Browne wrote:
>
>
> I've never hear of that acronym. FYI proper SMP implementation
> provides for simultaneous thread execution.
It's a new acronym that Sun and Intel are evidently using to describe
the usage of their multicore CPUs.
[vbcol=seagreen]
> Well, it is a bit more complex than it looks. Many simple algoritms
> are either incapable of being divided into threads or become an
> order of magnitude more difficult.
>
> Take the classic sort algorithm, conceptually very easy to divide
> across many threads, implementation, however is very difficult to do
> in a generic way. Executing processes across multiple CPUs works
> really well. Using threads to service connections in a server
> application works.
Well, that means that you're not going to get much value out of trying
to multithread (or multitask) a sort.
I sure wouldn't have expected sorting to be an example of an
application that would improve performance by spawning helper
processes.
> Taking a single logical progression of instructions which will
> branch based on various conditions and turing it into a multiple
> thread execution is very difficult (I dare not say impossible) to
> do. There are threaded applications which are designed to take
> advantage of SMP. The whole pthread API is designed to facilitate
> this. The difference is that tasks are broken up into multiple
> logical progressions were possible.
That's not what I'm thinking of.
What I was thinking of was more along the lines that complex apps like
Mozilla and OpenOffice.org lend themselves to having plenty of
components that it would make sense to spawn as separate processes
that could invisibly take advantage of SMP.
For instance, Mozilla has to split off threads to do such things as:
- managing concurrently loading data from many data sources
- sometimes data sources use SSL; sometimes they don't...
- caching recently-read data
In all of these cases, it would make a fair bit of sense to split
this off to one or more separate processes in much the way people
use Squid as a web proxy. At one point, someone tried adding SSL
support to Lynx via redirecting https requests to a separate SSL
proxy process so that Lynx wouldn't have to know about data
encryption at all.
- data storage (e.g. - configuration properties, XUL files, chrome,
and such)
Perhaps storage could be managed by a separate "database" process?
- displaying and managing bookmarks
perhaps simplified if there was a "database" process?
- rendering web pages
The obvious part...
- resolving addresses
Which has historically been done in a separate process...
I'm not sure what is the "perfect" architecture, but I can easily see
Mozilla splitting into half a dozen processes. That would _easily_
spread it across more CPUs in a multiprocessor context.
The same could be true for OpenOffice.org.
--
let name="cbbrowne" and tld="acm.org" in String.concat "@" [name;tld];;
http://www.ntlug.org/~cbbrowne/linuxdistributions.html
"My experience as a member of the APB (Accounting Principles Board)
taught me many lessons. A major one was that most of us have a
natural tendency and an incredible talent for processing new facts in
such a way that our prior conclusions remain intact."
-- Charles Horngren
|