Typing system vs. Java

[Andy Freeman]

Donn Cave <donn at drizzle.com> wrote in message news:<997418262.593664 at yabetcha.sttl.drizzle.com>...
> Quoth anamax at earthlink.net (Andy Freeman):
> | Now, I haven't accounted for the time to find that 20%, but I'm
> | ahead 4 to 10, so I'm somewhat skeptical that it would be generally
> | faster to have written it in C from the beginning.
> 
> You aren't accounting for the trouble of managing a program that
> now has both Python's and C's problems - it's platform dependent
> object code, and at the same time it needs an interpreter.  And
> note that your C extension requires extra work and some special
> skills to write.  Factoring out your 20% may not be as easy as
> you hope.

The "managing trouble" is largely a fixed cost, so if it's small
enough, I can ignore it.

> But anyway, did I say you should write the whole thing in C?
> I should bite my tongue, but actually I did not say that.
> I stay away from C when I can, and you should too.  I only
> said "a faster language".

Well, if we're restricting ourselves to statically typed mainstream
languages, they're all basically C for the purposes of this discussion.
If we allow other dynamically typed languages, then we've strayed from
the "we need typing for speed" argument.  (I find that lisp is faster,
and the development time is comparable, but extending and embedding
isn't as reasonable.)

Or, are we comparing Python to an non-existent language?  I don't think
that python is the best possible language (and there are applications
where there are better languages), but I can't use languages that don't
exist for my applications.

> |> The moral is not that you should be using C instead, but that
> |> Python should be faster.
> |
> | At what cost?  Be explicit - what would you change, and what would the
> | other side effects of those changes be?
> 
> Well, that's a good question.  Do we agree that it's worth the trouble
> to sort that stuff out, or does Moore's law make such things recede in
> importance faster than anyone can address them?

It doesn't make sense to answer the latter question in the abstract.  Some
stuff is probably worth sorting out.  Some stuff probably isn't.  And
in some cases, we won't know until we do it.

That's why I asked my question.  I'm perfectly happy with the idea that
there are worthwhile changes, but that's not a useful fact.  The useful
issue is what specific changes are worthwhile, in particular, what are
their specific costs and benefits.

> We got here talking about static type checking, and there is some reason
> to think that could open up some opportunities for optimization.

The notion that static type checking can improve performance is not
at issue.  The question is whether the costs of static type checking
are worth that performance.  Also, remember that stalin shows that
static type inference can bring many of the performance benefits of
static type checking to dynamically typed languages.  Implementing
such inference is largely a globally fixed cost and the benefits will
be received by all applications.  Static typing's costs are incurred
by all applications.

I'll suggest a middle ground that might work.  Declaring variables
but not their types might make python a lot more tractable.  (However,
the recent static scoping changes may may provide the same benefits
given reasonable analysis that isn't yet done.)  The interesting question
comes with methods.  In particular, are there reasonable constraints
on setattr and some of the other introspective functionality.

> That's all true, but what I want you to recognize is that these are
> the moving target that software has to meet.  As the capability
> expands, so do the expectations, and if your software is slower
> than its competitors, that hurts.

MY expectations haven't changed - I'm just getting more of them
satisfied.

I periodically inventory the applications that I rely on, and
performance is rarely a signficant factor.  Yes, I'd be happier if
Oracle was 2x faster, but I'm not willing to give up much for that.
Emacs is fast enough, as are word, excel, quicken, and my mail
readers and browsers.  (My connection isn't fast enough, but ....)

I see the same thing in business applications.  (One of the surprising
things that I learned a couple of years ago was that EDA folk won't
change the way that they work for a 100x run-time improvement, even
if the change also reduces development time.  Yet, they spend lots of
money on performance.)

So, how many of YOUR applications would be significantly improved
if they were 2x faster?  Be specific?  What would you give up for
that speed?

Yes, I know that benchmarks on 3d cards affect sales.  However, I'd
note that even insignificant differences on those benchmarks drive
those sales, so at least some of the effect is due to perception,
not performance.

-andy