Weblogs Forum - The Problem of Overspecification

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
The Problem of Overspecification

25 replies on 2 pages. Most recent reply: Jul 28, 2006 3:01 AM by Achilleas Margaritis

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 25 replies on 2 pages [ « | 1 2 ]

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

Re: The Problem of Overspecification

Posted: Jul 21, 2006 9:17 AM

Reply

Advertisement

I can't help regarding this as an insignificant optimization issue. How often do you think will adding up numbers in an array present a performance bottleneck in a real world application? In my view this is not a good example to discuss "the problem of overspecification".

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: The Problem of Overspecification

Posted: Jul 21, 2006 10:42 AM

Reply

> I can't help regarding this as an insignificant
> optimization issue. How often do you think will adding up
> numbers in an array present a performance bottleneck in a
> real world application? In my view this is not a good
> example to discuss "the problem of overspecification".

The point of the article is not the example, but the idea. The example is merely for illustration.

However if you want to critique this particular example, consider the issues of summing millions of numbers on a multi-core processor? Maybe not important to you, but emphatically very important to numerous application domains, for example: games, scientific computing, financial computing, writing web servers, operating systems, CAD, air-traffic control, airplane simulator ... need I go on?

Sean Conner

Posts: 19
Nickname: spc476
Registered: Aug, 2005

Re: The Problem of Overspecification

Posted: Jul 21, 2006 12:07 PM

Reply

You might also want to Google “Google map reduce” and see how Google uses it.

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

Re: The Problem of Overspecification

Posted: Jul 21, 2006 12:31 PM

Reply

I don't disagree that for some applications, it does matter to optimize the summing operation and I'd expect those applications to use optimized math modules. I wouldn't expect them to rely on the compiler to magically perform this kind of optimization. This example just seems too specialized to me to make a general point.

"Two of the cardinal sins of programming are overspecification and underspecification. Today I will discuss the one most programmers are guilty of: overspecification."

In my view, the example illustrates issues of language expressiveness, not "cardinal sins of programming". Programmers are not "guilty of a sin" if they have no better choice.

Rupert Kittinger-Sereinig

Posts: 21
Nickname: rkit
Registered: Dec, 2005

Re: The Problem of Overspecification

Posted: Jul 21, 2006 1:37 PM

Reply

> However if you want to critique this particular example,
> consider the issues of summing millions of numbers on a
> multi-core processor? Maybe not important to you, but
> emphatically very important to numerous application
> domains, for example: games, scientific computing,
> financial computing, writing web servers, operating
> systems, CAD, air-traffic control, airplane simulator ...
> need I go on?

I think it's just the other way around. For top performance, one would need to be even more specific, e.g. loop unrolling, cache prefetching, etc. Or even better, use libraries for high performance computing like IPP, optimized BLAS implementations, etc. These are very probably written in assembler, and fine-tuned to the exact cpu model. It's hard to get more specific than that :-)

cheers,
Rupert

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: The Problem of Overspecification

Posted: Jul 21, 2006 1:54 PM

Reply

I'd argue that the real danger isn't overspecification or underspecification but rather the difficulty of changing the level of specification when you need to.

If it can become easy enough to make changes, the problem becomes moot.

Cleo Saulnier

Posts: 77
Nickname: vorlath
Registered: Dec, 2005

Re: The Problem of Overspecification

Posted: Jul 21, 2006 10:54 PM

Reply

Mr. Diggins, I wished you worked somewhere else, so I'll just mention this because I do like what you've done in the past. You're dancing around the "core" issue over and over. (Pardon the pun.) Do you want to be more general where it doesn't matter how many cores there are in the computer? Then look at real life for how lots of "workers" are managed. Then ask yourself if the workers' instructions come from the same place as where the overall project goal and design comes from (in real life). This problem has been solved time and again, even on computers for a VERY long time.

You have the answers right before your eyes. You've had it for a very long time, even before I knew it. Everyone is just scared to accept what it means. All roads lead to Rome no matter how hard people try to turn away.

Robert Parnell

Posts: 22
Nickname: robparnl
Registered: Jul, 2005

Re: The Problem of Overspecification

Posted: Jul 22, 2006 3:13 PM

Reply

Well, any real compiler would know.

int done = (x*x+x)/2.

No multi-core, threading, or weird languages required.

PS. I think a language called "dog" based on a set of queues would work - really well. But, if I'd ever get it done, or "ever actually know" what it does? Who knows - Chris. Sure though, you can take this idea and run with it - til lthe scissor principle catches you up.

** I'd have to agree with Mr. Saulnier

RobP

Vladimir Nesov

Posts: 27
Nickname: robotact
Registered: Aug, 2005

Re: The Problem of Overspecification

Posted: Jul 23, 2006 5:51 AM

Reply

Understanding (by compiler) such loops is one problem (not a problem for such simple cases as in example). Other problem is that optimizing such things in a way which actually will give performace gain is dubious. It'll work only on big enough array without prespecified setup, as such setup will give too big overhead. For all other array lengths it'll be just one more "if(length<SELECTOR)" instruction to run and less local code to cache. General compiler just wouldn't do that. So it's rather underspecification, there should be a way to express that this loop is going to take long time, and that is not. Which is effectively what gets done after finding bottlenecks.

Keith Ray

Posts: 658
Nickname: keithray
Registered: May, 2003

Re: The Problem of Overspecification

Posted: Jul 23, 2006 7:11 AM

Reply

The solution is to encapsulate the desired result behind an interface, permitting the concrete realization of that interface to be optimized as desired.

For example, instead of asking an array for its length, and asking for its individual elements, and summing them, define a "sumElements" method in the array class... which can in turn delegate further to other methods or even other classes.

int IntArray::sumElements()
{
if ( CPUisMultiProcessor() and this->size() > kSomeLargeNumber )
return this->multiThreadSum();
//else
return this->singleThreadSum();
}

Somewhere on the internet there's a rather interesting comparison of STL vector and Cocoa's NSArray. For certain sizes, NSArray appears to change its internal algorithms for certain operations, outperforming std::vector.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: The Problem of Overspecification

Posted: Jul 28, 2006 3:01 AM

Reply

> The point of the article is not the example, but the idea.
> The example is merely for illustration.

These problems have been long solved in Fortran (the compiler automatically vectorizes loops), and in some functional languages.

Flat View: This topic has 25 replies on 2 pages [ « | 1 2 ]

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use