The Artima Developer Community
Sponsored Link

Weblogs Forum
Josh Bloch on the Semantic Gap

33 replies on 3 pages. Most recent reply: Oct 2, 2009 3:31 PM by Raoul Duke

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 33 replies on 3 pages [ 1 2 3 | » ]
Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Josh Bloch on the Semantic Gap (View in Weblogs)
Posted: Sep 18, 2009 11:32 PM
Reply to this message Reply
Summary
At the JVM Languages Summit, Josh Bloch expressed his concern about what he called the "semantic gap" between the source code we write and its performance at runtime: As performance improves, our ability to predict the performance consequences of our source code degrades.
Advertisement

As you write source code, you make choices on how to design and implement the task at hand. Although you may believe that "premature optimization is the root of all evil," as Donald Knuth once put it, you might sometimes allow performance concerns guide your choices. The reason is that not all early optimization is premature. Sometimes it is prudent. The trick is to be able to tell the difference between premature and prudent optimization.

Whether you are optimizing prematurely or prudently, you need a performance model: a conceptual model of how the different algorithm and implementation choices you are facing will perform at runtime. At this year's JVM Languages Summit, Josh Bloch lamented that as performance has increased, our ability to create accurate performance models has decreased, and that it is just going to get worse. Here's what he said:

The chip, the JVM, the libraries, and the language--all are growing more complex, which makes the performance model less and less transparent. Beyond a certain level, performance quality and performance-model quality are inversely related. To get increased performance, you complicate the system, resulting in reduced predictability and repeatability (i.e., decreased performance-model quality). I don't see any easy solution, I think it's just something we'll have to live with. The major coping strategy is measuring the performance, attempting to improve it, and remeasuring.

Cliff Click expressed the same sentiment this way:

Premature optimization is the root of all evil is more true today than ever before.

On the other hand, Bloch also said, "It helps to know the potential trouble spots." He called a workshop that brainstormed a list of some "performance gotchas" that exist today, which were documented on this wiki page:

http://wiki.jvmlangsummit.com/MindTheSemanticGap

What are your thoughts on the semantic gap?


Thomas Mueller

Posts: 18
Nickname: thomasm
Registered: Jan, 2009

Re: Josh Bloch on the Semantic Gap Posted: Sep 19, 2009 1:28 AM
Reply to this message Reply
When trying to optimize Skein [1], I found re-ordering statements can boost performance. So I wrote a 'pre-compiler' that reads the source code, randomly re-orders lines between //#start and //#end, runs the test, and keeps track of the fastest variant. The end result was about 10% faster than my version (which was already optimized).

[1] http://www.h2database.com/skein

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

Re: Josh Bloch on the Semantic Gap Posted: Sep 19, 2009 6:48 AM
Reply to this message Reply
This problem is both fundamental and unimportant. It is at the essence of software, and what makes it engineering. But common uses of software, coupled with surfeit of computer power, mean it is not noticeable.

The very basis of software development is processing and storing bits in available time and space. This doing particular things with available resources, and by logical, mathematical understanding, is what maps it to engineering generally. If you consider structural engineering, a basic capability of it is calculating resultant behaviour from forces across whole structures. In software, that translates to time and space needed for a whole computation. But software development lacks comparatively clear, predictive, understanding and control. The basic medium is entirely determinate; it is a lack of maturity in the field.

Common programming languages allow explicit, though not comprehensive, control of storage space. But where is computation time accounted for, where is it represented? Considering its fundamental importance, this perhaps constitutes a missing principle of language design. When this essential quantitative aspect seems non-existent in most software development, it is no surprise it seems less like engineering.

Alternative approaches do actually exist, but are marginal, specialist, in industry and academia. There is the area of 'stochastic process algebras' ( http://www.dcs.ed.ac.uk/pepa/ ) where time properties can be predicted; although the main available tool works from UML not code. Also, there are various 'synchronous languages' such as Lustre ( http://www-verimag.imag.fr/SYNCHRONE/index.php?page=lang-design#lustrecore ), where program modules react to, and fit into, a stream of event points.

Further development and spread of these lesser known techniques would strengthen software development as engineering. But for a lot, maybe most, of software it probably is not important enough.

John Cowan

Posts: 36
Nickname: johnwcowan
Registered: Jul, 2006

Re: Josh Bloch on the Semantic Gap Posted: Sep 19, 2009 8:37 AM
Reply to this message Reply
> The very basis of software development is processing and
> storing bits in available time and space. This doing
> particular things with available resources, and by
> logical, mathematical understanding, is what maps it to
> engineering generally. If you consider structural
> engineering, a basic capability of it is calculating
> resultant behaviour from forces across whole structures.
> In software, that translates to time and space needed for
> a whole computation. But software development lacks
> comparatively clear, predictive, understanding and
> control. The basic medium is entirely determinate; it is a
> lack of maturity in the field.

Structural engineering is not properly comparable with programming. The models of structural engineering are based on analysis (in the mathematical sense), a field where broad-based deep tools are available; in structural engineering, one may almost always assume that small errors will cancel out. Programming, on the other hand, is an activity in which the result of the whole depends intimately on the state of the parts. A single alpha particle from within a memory chip (uranium and thorium are everywhere, alas) that flips a single bit may cause a program to produce results whose error is arbitrarily large.

So much is commonplace. Alas, the real problem is far more deep-seated; it lies in the fundamental intractability of discrete mathematics as compared with continuous mathematics. Problems in discrete mathematics may defy solution for centuries, because those broad-based tools of analysis are simply not available.

Number theory is quirky: what we know, we know; but what we do not know, we depend on fundamental insight to discover, and fundamental insight comes when it wants to, not when we need it to. It's no accident that Goedel chose the domain of integers to make his famous proof of incompleteness. In the domain of the real numbers, on the contrary, arithmetic is in fact complete (it is not possible to find theorems that are true but not provable).

Or Fermat's last theorem: how easy to state, how hard to prove! And when the proof came, it came from outside number theory altogether, precisely by finding an ingenious method of applying continuous mathematics (of a kind utterly inconceivable to Fermat) to the problem in such a way that the theorem would fall out of it as a special case.

As long as we employ digital methods, with their unmatched accuracy when correct, I fear we will have to live with their unmatched potential for nonsense when incorrect.

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

Re: structural engineering and discrete mathematics Posted: Sep 19, 2009 11:18 AM
Reply to this message Reply
> Structural engineering is not properly comparable with programming.

Well, this is only true in the fine detail. As I believe you recognise, physical materials are not entirely well-behaved, and there are still gaps in understanding (e.g. resonance in the millenium bridge, London). But it is part of engineering to accommodate or avoid these, just as noisy copper wire networks and optical disk errors are for software. Engineering finds and makes a set of elements that are sufficiently determinate to make 'building' practical. This is substantially true of software development. Ultimately, software is obviously, in every-day and even special-duty, uses, very reliable and predictable in operation. What we get to use and develop on is highly determinate.

We need not make fundamental advances in mathematics, we just need to add up clock cycles. That has become more difficult, but only in a clerical sense -- and that is what computers are built for, after all. It would only take the will to do it, but the demand doesn't seem enough.

Kirk Pepperdine

Posts: 5
Nickname: kcpeppe
Registered: Jun, 2003

Re: Josh Bloch on the Semantic Gap Posted: Sep 19, 2009 10:24 PM
Reply to this message Reply
Nice post but one correction. Tony Hore was the author of the root of all evil quote.

Regards,
Kirk

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Josh Bloch on the Semantic Gap Posted: Sep 20, 2009 11:12 AM
Reply to this message Reply
Not, it seems, according to Tony Hoare.

http://hans.gerwitz.com/2004/08/12/premature-optimization-is-the-root-of-all-evil.html

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Josh Bloch on the Semantic Gap Posted: Sep 20, 2009 7:01 PM
Reply to this message Reply
> As long as we employ digital methods, with their unmatched
> accuracy when correct, I fear we will have to live with
> their unmatched potential for nonsense when incorrect.

Hear, hear!

Jiri Goddard

Posts: 54
Nickname: goddard
Registered: May, 2007

Re: Josh Bloch on the Semantic Gap Posted: Sep 21, 2009 1:09 AM
Reply to this message Reply
I'm afraid that Josh didn't tell anything new. Just take all the low, mid and high-level languages in account and you have to realize that the higher level languages hide more complexity but they're not removing it. At all.

Fred Finkelstein

Posts: 48
Nickname: marsilya
Registered: Jun, 2008

Re: Josh Bloch on the Semantic Gap Posted: Sep 21, 2009 2:16 AM
Reply to this message Reply
>> you have to realize that the higher level languages hide more complexity but they're not removing it. At all.

Of course they take complexity away. Why would you use higher level languages if they did not? For example they allow the programmer to define higher-level abstractions (classes, structs etc), and that's a well-known way to tackle complexity.

Jiri Goddard

Posts: 54
Nickname: goddard
Registered: May, 2007

Re: Josh Bloch on the Semantic Gap Posted: Sep 21, 2009 2:27 AM
Reply to this message Reply
You only wish. They hide it and they do a good job and that's why you would use them. On the other hand, and that's what Josh said, there're some implications. You can write code easier (having good abstractions at hand), but there still things hidden from you so you can do it. And that's the hidden, not-removed complexity.

Fred Finkelstein

Posts: 48
Nickname: marsilya
Registered: Jun, 2008

Re: Josh Bloch on the Semantic Gap Posted: Sep 21, 2009 3:21 AM
Reply to this message Reply
>> You can write code easier (having good abstractions at hand), but there still things hidden from you so you can do it. And that's the hidden, not-removed complexity.

ok, fine, but what do you want to say practically? If I can write code easier and if I have to write much less code than I will choose this option. Because if I write less code, the probability that I will make a mistake is also lower.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Josh Bloch on the Semantic Gap Posted: Sep 21, 2009 3:27 AM
Reply to this message Reply
> >> you have to realize that the higher level languages
> hide more complexity but they're not removing it. At all.
>
>
> Of course they take complexity away. Why would you use
> higher level languages if they did not? For example they
> allow the programmer to define higher-level abstractions
> (classes, structs etc), and that's a well-known way to
> tackle complexity.

Higher level languages move the complexity from the programmer to the compiler. The complexity is still there.

Fred Finkelstein

Posts: 48
Nickname: marsilya
Registered: Jun, 2008

Re: Josh Bloch on the Semantic Gap Posted: Sep 21, 2009 5:39 AM
Reply to this message Reply
> Higher level languages move the complexity from the programmer to the compiler. The complexity is still there.

But practically speaking the complexity decreases - I mean the complexity I (as a programmer) have to tackle. The overall complexity is of course still the same because the problem I want to solve is the same.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Josh Bloch on the Semantic Gap Posted: Sep 21, 2009 7:07 AM
Reply to this message Reply
> > Higher level languages move the complexity from the
> programmer to the compiler. The complexity is still there.
>
>
> But practically speaking the complexity decreases - I mean
> the complexity I (as a programmer) have to tackle. The
> overall complexity is of course still the same because the
> problem I want to solve is the same.

It is true only if the higher level language truly hides the complexity. From my experience, it is not so in C, C++ and (less in) Java.

Flat View: This topic has 33 replies on 3 pages [ 1  2  3 | » ]
Topic: Speaking At Developer Day in Boulder Previous Topic   Next Topic Topic: Discover and Promote What Works

Sponsored Links



Google
  Web Artima.com   

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