Typing system vs. Java

[Andy Freeman]

Donn Cave <donn at u.washington.edu> wrote in message news:<9kpdm3$hhk$1 at nntp6.u.washington.edu>...
> Quoth anamax at earthlink.net (Andy Freeman):
> | BTW - I would like to see an application that doesn't have significant
> | hotspots.  I doubt that there are very many.
> 
> That's only one of the issues, though.  No doubt you can identify
> a hotspot or two, depending on your criteria for significance.
> You still have to ask whether it's worthwhile to write an extension -
> maybe it would be not much harder to just write the whole thing in
> a faster language.

Let's do the arithmetic.

Pythoneers typically claim a 10x productivity advantage.  From my (brief)
experience, I'd say that 10x is conservative, but let's use 5x instead.

Hotspots are typically 5-10% of the code, but let's use 20%.

Suppose that writing the "all C from the beginning" version takes 10 time
units.

With the above assumptions, the all-python version will take 2.  But, we
still need to write the 20% in C.  Let's assume that the experience with
python for that 20% doesn't help us write the C extension, so writing
that takes 2 time units, just as it did in the "all C" version.

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.

> I have tried the "write C after first writing in Python" route, when
> an application was too big and slow.  It was a small application (but
> one that is run often), and I'm not sure the Python version saved me

Hmm, the application was "too big" and yet "small"....

I find that I don't get much benefit from power tools when I'm doing
"small" things.  To put it another way, "hello world" doesn't demonstrate
the differences between a langage which is good for programming in the
small and one which is good for programming in the large.

> 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?

> I think it's questionable how relevant Moore's law is here.  Interpreted
> languages have been around pretty much all along, and all along have
> presented the same kind of tradeoffs.

Interpreted or not isn't really the issue.  (FWIW, it is possible to
compile python bytecodes.  However, it isn't clear that such compilation
would make a significant difference.  Hmm - I shouldn't be so quick to
assume that.  And, I shouldn't concede much on the question of compile-time
dispatch determination, which is the only performance benefit of static
typing.)  The issue is ease of programming vs raw performance.

20 years ago, it was just becoming reasonable to write a WYSIWYG editor
in a scripting language, and then only if you had a fairly impressive
(for the time) computer, and it was quite expensive.  (And yet, at least
one of the most sophisticated text editors of that time was written in
an interpreted language.)  Today, it's hard to buy a $1000 computer that
can't run a such an editor acceptably fast.

Moore's law is taking care of applications that were slow because of
constant factors, such as the difference between scripting languages
and programming bare metal.  There are constant factor problems where
the constant factor is still too big, but every year there are fewer
of them.

Yes, there are quadratic, cubic, and worse problems.  And, if you're
lucky, a 10x speedup will let you handle a large enough N.  If the C
version is 10x as fast, but the problem is quadratic, you only get to
solve a version that is square-root(10) as large.  For cubic, the
the problem size increase is the cube root, and for exponential....

> still expensive.  Moore's law is another symptom of denial, "your
> program isn't really slow - just wait, it will be fast someday!"

Hmm.  Let's look at what this "moore's law denial" has gotten us.
3D games.  OCR.  Sound, photo and movie editing.  Sound, image, and
movie generation.  Digital control of mechanical things in general.
Primitive voice recognition.

Computers are "fast enough" for those applications, and they weren't
before.  Every year, more and more things become possible, because
newer computers tend to be faster for the same $.  Yet, recognizing
that fact is "denial".  Curious.

If it will take you 12 months to write a given application in C but
a Python implementation is 50% too slow today, well, you can do
the arithmetic.  By the time that C version is ready, a Pythoneer
will have delivered 3 applications that are all "fast enough" AND
had a nice long vacation.

My biggest objection to Python is that I don't know how to easily
integrate it from the bottom, as a python extension to a C program,
and I suspect that that's my ignorance.

-andy




  Twenty years ago our basement


Or, are you arguing that python-as-is could be faster
so someone should flog guido?
  When I want a more efficient solution,
> 



> | Christopher Barber <cbarber at curl.com> wrote in message news:<psoitg1md4l.fsf at jekyll.curl.com>...
> |> anamax at earthlink.net (Andy Freeman) writes:
> |>| Only if you've already exhausted algorithm/architecture/infrastructure
> |>| improvements and "decrease run-time at any cost" really is the primary
> |>| consideration.
> |> 
> |> It could be pretty expensive to move all of your code to a faster language if
> |> you discover that Python is not good enough.  Sometimes you can write C
> |> extensions for the slow parts, but in some cases you will have to start over.
> |
> | If experience is much of a guide, writing first in python and then
> | in C tends to be cheaper/faster than writing in C from the beginning.
> | Heck, writing in C then writing in C is often cheaper than writing in C.
> |
> | BTW - I would like to see an application that doesn't have significant
> | hotspots.  I doubt that there are very many.
> 
> That's only one of the issues, though.  No doubt you can identify
> a hotspot or two, depending on your criteria for significance.
> You still have to ask whether it's worthwhile to write an extension -
> maybe it would be not much harder to just write the whole thing in
> a faster language.
> 
> I have tried the "write C after first writing in Python" route, when
> an application was too big and slow.  It was a small application (but
> one that is run often), and I'm not sure the Python version saved me
> any great amount of time - C's storage is so different from Python's
> that you can't just add curly braces, you have to rethink the architecture
> at a fairly basic level to accommodate C.
> 
> There are lots of cases to the contrary, and in general partial or
> full migration to C is an important option for various reasons.
> 
> But it isn't a good enough option to make Python's performance
> unimportant.  When it's too slow, fixing that can waste a lot of
> time, and that bites the programmer who decided to use Python,
> and the organization that went along with that programmer, etc.
> The moral is not that you should be using C instead, but that
> Python should be faster.  When I want a more efficient solution,
> I don't want to hear that I have to go to C, I want to know what
> language has what I need, including efficient execution.
> 
> I think it's questionable how relevant Moore's law is here.  Interpreted
> languages have been around pretty much all along, and all along have
> presented the same kind of tradeoffs.  Twenty years ago our basement
> was full of one or two computers, with computing power embarrassingly
> surpassed by a common PC clone today.  Today, our basement is still
> full of computers - hundreds of much faster computers - and they're
> still expensive.  Moore's law is another symptom of denial, "your
> program isn't really slow - just wait, it will be fast someday!"
> 
> 	Donn Cave, donn at u.washington.edu