[Beowulf] Stroustrup regarding multicore

[Robert G. Brown]

On Thu, 28 Aug 2008, Lux, James P wrote:

>
>
> Again, if you're building software for a real estate office it is
> straightforward for the programmer to just learn what your business is
> and in any case high performance isn't needed. If you are trying to
> simulate supernova explosions and you can barely cram the
> magnetohydrodynamics in a piss poor 2D version of the problem onto the
> biggest machines in existence and would really, really like to do the
> problem in 3D, I don't think you can operate on this model.
>
>
> ---- I think you egregiously underestimate the amount of work and judgement that goes into building software for a real estate office, or to sufficiently understand "what the business is". (speaking from personal experience here...<grin>)
>
> ---- There are many, many large software development projects for which it would be impossible (or at least impractical) for the software development team to understand the business. Would you expect the software team generating an application to process the payoff of a home mortgage to understand all the complexities and regulatory requirements imposed by 3000+ counties for doing the transaction?  Of course not. That's why there are processes for requirements validation, test case generation, user acceptance test, etc.  It is precisely the complexity and scale of the problem that drives the need to decompose the effort and set up interfaces (albeit, at greater overall cost).  Teams of 50 or 100 skilled software developers are not particularly unusual in business, and they're hardly "toy" applications, nor are they insensitive to performance considerations.
>
> ---- I wouldn't think it unreasonable (but not fair) for the "real software developers" in business to actually look down on the typical scientific development as an amusing little toy exercise with little or no financial consequence.  The regulatory implications and business costs of poor software development in a large business can literally be measured in billions of dollars and the aggravation of tens of thousands of people.
>
> --- Bcause of this large impact, they get large budgets, which is really the *ONLY* way to build large scale systems.  Brooks identified it decades ago, and it's been repeated over the years, big complex systems take lots of resources, and, I'd extend that to include that the management/design/implementation of such a system has to allow for the fact that many of your resources will be average.  Everyone has an example of two skilled guys go into the garage and come out a week later with a world-beater.  That model breaks down severely when the project is big enough to require 50 people.

I'm trying manfully to resist reentering, so let me just say Jim is dead
center on the money, correct, right, and understates the issues.  I have
explicit examples from my own work.  Anybody want to learn about finite
size scaling in second order phase transitions, dynamical critical
exponents, critical slowing down, and algorithm scaling in importance
sampling markov processes?  Just to get off the ground?

    rgb

>
>
>
>
>
>> For example, a scientist saying "you must use the PGI compiler" is
>> like the bridge building engineer saying "you must use Pennsylvania
>> coal in the blast furnace".
>
> What if a particular compiler is known to generate floating point code
> for certain kinds of inner loops that runs a factor of three faster
> than another? Would it be silly then? The coal you use has no effect
> on the resulting steel, but the compiler you use *does* alter the
> resulting machine code by a lot!
>
> ---- Actually, the coal DOES have a lot of effect on the resulting steel (particularly the sulfur content).  And in the specific example, there's nothing prohibiting the customer from passing on information, but they shouldn't necessarily be involved in the design of the system. At some point, their expertise is the science, not the computing, and a more efficient allocation of resources recognizes that distinction.
>
> --- Mind you, non-ideal situations always arise, and the fact that one can often subsidize one's research by contributing free labor has a huge effect on the project management.  But it's not sustainable in the long run, either from a institutional standpoint, or societal.  Yes, there may appear be an inexhaustible supply of willing grad students, but at some point, a specter starts to stalk the halls of academe, and the cry goes up to "unite!", "to the barricades", "Si se puede!", etc..  It's a particular issue at glamorous research institutions where a significant part of the job satisfaction and/or compensation is "working on cool stuff" (getting paid in "space dollars" is what it's called in the NASA world).  People are willing to work long hours for relatively little tangible compensation, literally to the point of illness or family breakdown, but they won't do it forever, and eventually they kick back.
>
>
>
> By the way, I even argue that often it is important for the bridge
> builder to know a bit about how the steel is made. Why? Because he
> might falsely assume that certain kinds of characteristics are
> impossible to achieve in the materials and thus not ask for them, and
> the steelmaker might have no way of knowing that certain
> characteristics would be desired by the market and thus won't offer to
> sell the perfect material for the job.
>
> --- Knowing "a bit" is actually the example I gave.  It's knowing how to run a factory and understanding worker's comp and all the other myriad administrative details that the engineer doesn't necessarily need to know.
>
>
> Jim Lux
>
> [1] http://dbacon.igc.org/Students/01gradst.htm
> [2] http://findarticles.com/p/articles/mi_hb5553/is_200312/ai_n22078176
> [3] http://www.democracynow.org/2005/12/2/nyu_grad_student_strike_a_debate
>
>
>
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
>

-- 
Robert G. Brown                            Phone(cell): 1-919-280-8443
Duke University Physics Dept, Box 90305
Durham, N.C. 27708-0305
Web: http://www.phy.duke.edu/~rgb
Book of Lilith Website: http://www.phy.duke.edu/~rgb/Lilith/Lilith.php
Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977