[Eug-lug] Concurrency, (free lunch is over article)

[Mike Cherba]

I'm not trying to be argumentative here.  I just wanted to throw out
some counterpoints.  Most of my opinions here come from personal
experience in the embedded market recently.  However, some information
was gathered from my Father, (back in school working on his PhD in Comp
Eng.  AI and muliprocessor systems)  and my Brother (currently at
University of Michigan finishing undergrad studies in Comp Eng).  So my
perspective may bit a bit warped.  The best I can hope for is to call it
like I see it.

On Fri, 2005-01-07 at 13:38, Bob Miller wrote:
> Mike Cherba wrote:
> 
> > I find it interesting that the article only covers one percieved facet
> > of mutlicore performance and doesn't really cover effective division of
> > work as the number of processors goes toward infinity.  While SMP is a
> > good approach for 2 or even 4 processors, I do not believe it to be the
> > best approach for numbers of cores higher than that.  Especially
> > depending on the work to be done.  Once you have more than a few cores,
> > you can afford to specialize the tasks of each core at an even lower
> > level.  Certain functions work best with a single CPU focused on them.  
> 
> I don't understand what you're saying.  Are you advocating
> special-purpose functional units a la PlayStation or video card, or
> general-purpose CPUs given special jobs by system software?
> 
Both/either.  For example; One way we use multiple cores in our Network
security processor designs is to dedicate cores to providing a specific
stage of the network stack.  This allows much less cache thrashing and
more efficient usage than if all the cores were in an SMP session and
being used as available for whichever network processing needed to be
done.  We can repurpose cores as needed to balance capacity with demand.
The effectiveness of this and various other approaches does admittedly
rely heavily on the underlying hardware architecture.  Does each core
have its own cache?  how are bus accesses prioritiezed in hardware?  is
this a Load/Store architecture or and EIP implimentation?  Do any of the
cores have independant RAM?  I guess the real questin is going to be how
to best use whatever design Intel/AMD decide to sell us.

Personally I would not be sorry to see indiviual components become more
powerful.  For example, a network card with firewalling capability built
in which appears to the host PC as a simple NIC could work wonders in
improving the stability of windows systems, as well as free up CPU
cycles on the host for other purposes.  

The concept I suggest is one where all cores in the chip share the same
basic architecture.  Perhaps some have additional extensions to
accelerate specific tasks.  There is a main SMP session hosted on a
number of them. The Kernel uses the remaining pool of cores as dedicated
units for specific tasks.

> > My concerns are that most software developers today do not understand
> > how to design applications which effectively make use of multiple
> > processing units.  
> 
> I keep hearing this.  I personally know lots of people who can
> effectively design for SMP, NUMA or Beowulf systems.  Also, some
> frameworks are useful for hiding concurrency from application
> programmers (e.g., app servers, apache+mysql).  I don't think the
> brain shortage is as severe as it's made out to be.

Perhaps you have been dealing different engineers than I have.  Or maybe
I'm just a cynic.  I'd love to meet some of these people. ( well
actually I'd like to meet lots of people as I'm still new here and need
to get out more now that I'm working from home )  My personal experience
is that most of the engineers I've met who are responsible for creating
the mass market devices everyone buys at Walmart and Fry's are often
stretched to their limits simply gluing together the components they
licensed from other companies.  

I will grant that abstraction and obfuscation tools can go a long way
toward making concurrent design easier for some programmers.  However I
would submit that these tools can only take you so far.  There is no
substitute for understanding the layers that your work relies on.  

Thanks for reading all the way to the end of my little rant.  Feel free
to poke holes in any appropriate places.
			-Mike


-- 
"The danger from computers is not that they will eventually get as smart
as men, but that we will meanwhile agree to meet them halfway." -Bernard
Avashi