Re: Re: Pragmatic Requirements Summary : update

On Mon, 4 Aug 2003, Matt Lawrence wrote:

> On Mon, 4 Aug 2003, Brian Hurt wrote:
> 
> > On Mon, 4 Aug 2003, Eric Merritt wrote:
> > 
> > >  PL/I is still used just not much. I am pretty sure that one-to-
> > > allness wasnt the only thing wrong with PL/1
> > 
> > No.  But it was the only language I could think of besides C and assembly 
> > that has had (more or less) successfull OSs written in it (Multics).  And 
> > it was the first language- that I'm aware of- that was advertised as being 
> > all things to all people.
> 
> Thirty years ago Burroughs was writing OSes in an Algol dialect.  It 
> worked very well.  There has also been some OS stuff done in Forth that 
> seemed to go ok.

You are bolstering my point.  BTW, I've done a little work in Forth- it 
might as well be assembly language.

> 
> This brings me to an observation: dual stack machines seem to work very 
> well.  However, the memory model used in C uses a single stack _and_ most 
> of the CPU design over the last 15 years has been focussed on making C 
> code run really fast.  Thoughts?
> 

Well, C and Fortran anyways.  Although this is changing.  The real
"revolution" in CPU design wasn't RISC- it was the idea that CPU
implementors and designers should measure real code solving real problems
to make their design decisions.  Before that revolution, most CPU 
implementors just used WAGs to decide what tradeoffs to make, and what 
features to support.  Unfortunately, this can lead into feedback loops- 
CPU implementors influencing language implentors influencing application 
writters influencing CPU implementors.

Fortunately, the breakout of the feedback loop happens because most
application writters balance off ease of implementation with absolute
performance.  And generally the biggest performance gains come not from
hand-tuning the application to a specific CPU/system, but from algorithmic
optimizations.  I remember hearing stories of the TRS-80 beating the Cray
(the TRS-80 running an O(1) algorithm, the Cray running an O(n^3)  
algorithm, at 3,000 elements- the limit of what the TRS-80 could hold in
memory- the TRS-80 was faster).  So application implementors will
occassionally choose "suboptimal" (wrt performance) languages.

Widescale adoption of these languages then- ever so slowly- influence the 
CPU designers, as they change what subset of real programs they look at to 
include the new languages.  Spec- widely used by studies of what real 
applications use- is starting to include C++ programs in their mix.  This 
is starting to have important repurcussions in CPU design- calling 
functions via pointers is almost unknown in C programs, but is quite 
common in C++ programs (this is how virtual functions work).

My advice to you, if you're concerned about performance, is to two things:

1) Become very concerned with how easy it is to provide generic algorithm 
and datastructure libraries.  Complicated but efficient data structures 
(for example, priority search queues) may not be "worth it" for a single 
implementation, but very worthwhile if the "cost" of implementing them can 
be spread out over a large number of projects.  The most important thing a 
language can do, IMHO, is to make it easy to define reusable libraries.

2) Don't preclude optimization.  This is Java's problem.  To give one 
example: array bounds checking doesn't have to be expensive.  Consider the 
following java-ish code:

    for (int i = 0; i < n; i += 1) {
        a[i] = 0;
    }

You have to bounds check every single loop, right?  No.  The compiler can 
restructure the code so that it looks like this instead:

    for (int limit = max(n, a.length), i = 0; i < limit; i += 1) {
        a[i] = 0; /* no bounds check required here! */
    }
    if (n > a.length) {
       a[a.length] = 0; /* throws an exception always */
    }

Note that the programmer *could* write the more complicated verion, but 
why make him?  The compiler is perfectly capable of transforming the code 
(this is, in fact, a specific case of the more general optimization of 
strength reduction).  Except that Java demands strict semantics even in 
the face of multiple threads- a Java compiler cannot do this optimization 
unless it can prove that another thread won't come along and change the 
length of a part way through the loop.

They might have eased this restriction since last I looked.  But it serves 
as an example of how you can unintentionally limit the possibility of 
optimization.

Brian



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/sO0ANB/LIdGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
pragmatic_lang-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/