Yup: Eugen Leitl also sent a pointer to this the other day. Very
interesting.
I haven't had a chance to read the main article yet, but I was struck by
the line:
> • To maximize programmer productivity, future programming
> models must be more human-centric than the conventional focus
> on hardware or applications.
I have been hammering away at this issue for a very long time. The
programming tools used to build software in general, and parallel
software in particular, are nothing short of atrocious. The reason, I
think, is that the people who use such tools are not necessarily the
best judges of what the tools should be like.
I know that sounds crazy, but I think it does make sense if you take a
larger view: after all, since when did a typewriter engineer have to be
a great writer?
I am not making the suggestion simply *because* of the historical
analogy, of course, but because the psychologist part of me sees things
in the practical craft of software development that, frankly, look as
though they were almost designed to make it difficult for the software
engineer (or architect) to work quickly and safely.
For example, one thing that we know causes people to lose track of what
they are doing is when they are forced to engage in large amounts of
context switching -- so forcing the programmer to continually switch
tasks to deal with finicky little details is a good way to guarantee
trouble. Finding ways to prevent this context switching is not at all
easy, but there are very few people whose job it is to sit down and
think about how the context switching occurs, and find ways to fix it.
These people need to be specialists in that problem - typewriter
engineers, not authors.
Going back to the parallel computing issue, there are ways to conceive
of parallel computing that make it easier to handle the problems that
arise. One is the CSP/occam approach, although that is not perfect.
Another is the one that I am working on, which is less efficient but may
end up being more secure.
I have been trying to interest various people in taking the programmer
psychology problem seriously for many years, but there seems to be a bit
of a turf-war or machismo problem at work here. Software engineers
maybe think that "psychology" is such a feeble-minded science that it
could hardly have anything to teach people engaged in a real engineering
discipline. Something, at any rate, makes them decide that it should
get the lowest conceivable priority. I honestly think that software
engineers are personally insulted by the idea that anyone except
themselves should know how to write software tools.
Interesting.
Richard Loosemore
David Hart wrote:
Hi All,
A recent paper which contains many topics worthy of discussion here, and
which integrates knowledge from semiconductor design, scientific
computing, machine learning, embedded systems, and others:
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.pdf
Accompanying wiki: http://view.eecs.berkeley.edu/wiki/
<http://view.eecs.berkeley.edu/wiki/Main_Page>
ABSTRACT & EXCERPTS
(http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.html)
The recent switch to parallel microprocessors is a milestone in the
history of computing. Industry has laid out a roadmap for multicore
designs that preserves the programming paradigm of the past via binary
compatibility and cache coherence. Conventional wisdom is now to double
the number of cores on a chip with each silicon generation.
A multidisciplinary group of Berkeley researchers met nearly two years
to discuss this change. Our view is that this evolutionary approach to
parallel hardware and software may work from 2 or 8 processor systems,
but is likely to face diminishing returns as 16 and 32 processor systems
are realized, just as returns fell with greater instruction-level
parallelism.
We believe that much can be learned by examining the success of
parallelism at the extremes of the computing spectrum, namely embedded
computing and high performance computing. This led us to frame the
parallel landscape with seven questions, and to recommend the following:
• The overarching goal should be to make it easy to write programs that
execute efficiently on highly parallel computing systems • The target
should be 1000s of cores per chip, as these chips are built from
processing elements that are the most efficient in MIPS (Million
Instructions per Second) per watt, MIPS per area of silicon, and MIPS
per development dollar. • Instead of traditional benchmarks, use 13
"Dwarfs" to design and evaluate parallel programming models and
architectures. (A dwarf is an algorithmic method that captures a pattern
of computation and communication.) • "Autotuners" should play a larger
role than conventional compilers in translating parallel programs. • To
maximize programmer productivity, future programming models must be more
human-centric than the conventional focus on hardware or applications. •
To be successful, programming models should be independent of the number
of processors. • To maximize application efficiency, programming models
should support a wide range of data types and successful models of
parallelism: task-level parallelism, word-level parallelism, and
bit-level parallelism. • Architects should not include features that
significantly affect performance or energy if programmers cannot
accurately measure their impact via performance counters and energy
counters. • Traditional operating systems will be deconstructed and
operating system functionality will be orchestrated using libraries and
virtual machines. • To explore the design space rapidly, use system
emulators based on Field Programmable Gate Arrays (FPGAs) that are
highly scalable and low cost.
Since real world applications are naturally parallel and hardware is
naturally parallel, what we need is a programming model, system
software, and a supporting architecture that are naturally parallel.
Researchers have the rare opportunity to re-invent these cornerstones of
computing, provided they simplify the efficient programming of highly
parallel systems.
-----
David
------------------------------------------------------------------------
This list is sponsored by AGIRI: http://www.agiri.org/email
To unsubscribe or change your options, please go to:
http://v2.listbox.com/member/?list_id=303
-----
This list is sponsored by AGIRI: http://www.agiri.org/email
To unsubscribe or change your options, please go to:
http://v2.listbox.com/member/?list_id=303
