Typing system vs. Java

[Alex Martelli]

"Andy Freeman" <anamax at earthlink.net> wrote in message
news:8bbd9ac3.0108042147.5f0c4059 at posting.google.com...
> Christopher Barber <cbarber at curl.com> wrote in message
> > You didn't respond to my comments on potential for performance gains.
Can I
> > assume that I scored a point?  ;-)
>
> Only if you've already exhausted algorithm/architecture/infrastructure
> improvements and "decrease run-time at any cost" really is the primary
> consideration.

"decrease run-time at ANY cost" is never really a target: you have to
insert constraints about meeting functional specs, otherwise program
    pass
is a huge performance increase (at the cost of not doing anything,
sure, but, if one DOES mean ANY cost...).

Also, it's not normally an issue of "exhausting" potential infrastructure
(hardware) improvements, but rather one of ROI (Return On Investment)
for the various kinds of improvements.  E.g., given a problem of the
embarassingly parallel kind, running it on a cluster of a thousand PC's
would speed it up by hundreds of times -- at least as much as recoding
it from Python into C or whatever and running it on a single PC.  But what
is the cost of the infrastructure improvement versus that of the rewrite?

A couple million dollars per installation vs a lump sump of (say) roughly
$10 per debugged line of C code.  For many programs, recoding will
have a superior ROI even if they're intended to run at a single site --
and if you consider a program that is intended to be installed in many
thousands of sites, recoding's going to come on top most often, as the
most cost-effective way to achieve performance improvements.


> I figure that there are about five applications in the world that qualify,

At this point I have to suspect we're not talking about the same thing.

Modeling solids and surfaces for 3D mechanical CAD surely does 'qualify'
as insatiably hungry for any kind of performance improvement -- the
more the merrier, of course: we're continuously developing algorithmic
improvements, the programs typically run on reasonably powerful boxes,
AND the performance bottlenecks need to be carefully coded to afford
the highest possible performance (including language choice).

> and they're written in assembler.

That would be the wrong tack to take in this case: a top-notch compiler
for a language such as C or C++ can optimize better, for programs of
a few tens of thousands of lines -- it can target the latest and greatest
CPU at any time (where assembler would need recoding and slow time
to market considerably) -- and so offers better ROI.

> (The other candidates have migrated to hardware.)

There are aspects of 3D programs that "have migrated to hardware",
but that's basically the rendering part; the modeling hasn't, and I
confidently predict that it won't.

> They, and their techniques, are less relevant to most
> of us than F1 racecars.

FIAT is selling a middle-price car with a gearbox using techniques
that were pioneered a few years ago in F1 racecars.  Shell is selling
(at all of its Italian outlets) a premium brand of petrol developed
together with Ferrari (allegedly maximizing engine performance: I
am not qualified to evaluate this claim).  And of course Ferrari uses
3D CAD programs to design its cars (both the F1 racecars, and those
it sells to the public, typically using technologies pioneered on the
F1 racetracks) -- as, admittedly, does Minardi, even though _their_
F1 cars are typically last while Ferrari's are often first.  In other
words, I think you're somewhat off in implying F1 technology is
not very relevant "to most of us" -- and even more off in stating
the same about programs that do need very high performance.

(Of course, I'm biased, since think3 does sell 3D MCAD programs,
and geographically happens to lie about in the middle of a region
very keen on racing -- Ferrari, Minardi, and Ducati for motorbikes,
all happen to be within 20-30 miles from our main SW development
lab, as do the homes of Pantani, bicycle racing champ, and Tomba,
ski racing champ...:-).

> Type systems have certain benefits.  They also have certain costs.
> For almost all of us, the performance "potential" isn't a benefit.

I believe you're vastly overstating "the case against performance".

Getting better peformance IS a benefit -- possibly a _minor_ one
in many cases, but there's a huge difference between it being a
minor benefit, and it NOT being a benefit at all!

> I suppose someone should have mentioned the costs of inappropriate
> attention to performance.

Of _premature_ attention to performance, typically.

> Chosing a language because you hope that
> its type system will help with performance seems to qualify.

Prototyping in a language whose main attraction is that its
compilers can easily generate well-performing code would
qualify.  Once the prototype is done, however, if performance
problems loom, language choice for the performance hotspots
must be made, so it cannot be premature to make it at this
point.  If the influence of strict typing were as weak as a HOPE
for better performance, you'd have a point -- Java, to get back
to the subject of this thread, proves that you can have reasonably
strict and confining typing and still get pretty bad performance,
just as the stalin compiler for Scheme proves you can get pretty
good performance without static typing.  But, _in practice_, C,
C++, O'Caml and other statically typed languages show good
performance characteristics -- a practising engineer would have
to choose on the basis of actual performance, as well as future
potential if the application can be long-lived.

Many people strongly believe that using a single language for
an application is best -- I guess those same people use a
single Swiss Army knife instead of a normal toolbox for their
mechanical work.  I was in Lugano recently, and had a good
look at the newest Swiss knives -- they're amazingly clever,
with a dozen different screwdrivers and so on.  Unfortunately,
they're unwieldy in the extreme, exactly because they have
to incorporate so many blades & other accessories.  So, I'll
stick with my small toolbox -- separate flat-head screwdrivers
and Phillips-head ones, pincers that don't try to double up
as scissors, and so on.  Sure, it's a (very minor) bother to
have to carry around half a dozen tool and use the right one,
but using a single tool that does everything is a far larger
bother because it's never as good as the specialized tool for
any given single task.

If I wanted a Swiss Army knife language, it would probably
be C++, maybe O'Caml.  I'd rather have my little toolbox,
though, with Python for most things, C++ (or, sigh, C if I
must) for speed, Haskell when a lazy-functional approach
cries out to be used... but *as long as language complexity
didn't become a problem*, I wouldn't object to Python
having a little extra performance potential here and there,
just as I don't object to the little functional traits it has
borrowed from Haskell and other FP tools (even though
lambda IS a minor annoyance:-).


Alex