When Python outruns C++ ...

[Max Khesin]

I personally question such beliefs 'a priori' from language design
perspective but justify them retrospectively in terms of soft
engineering/economis. What I mean is the following: a language that gives
you more of an access to the machine architecture (whether you like it or
not) is capable of no less optimization (and most likely more) than a
language that is further removed from it. Python vs. C is a particularly
poigniant example since Python is a C program. On a minute level such C++
techniques as compile-time loop unwinding, great control over memory
allocation, potential direct access to registers/special processor
instrucitons will still give you great advantage in areas such as image
processing. On the other hand, for many things that do not require great
speed or, considering programmer from an economic perspective, make slow
program + fast hardware more cost-effective, languages such as Python are
very appealing, end run-on sentence.

--
========================================
Max Khesin, software developer -
max at cNvOiSsPiAoMntech.com
[check out our image compression software at www.cvisiontech.com, JBIG2-PDF
compression @
www.cvisiontech.com/cvistapdf.html]


"Jacek Generowicz" <Jacek.Generowicz at cern.ch> wrote in message
news:tyfr88nwbx6.fsf_-_ at pcepsft001.cern.ch...
> Alex Martelli <aleax at aleax.it> writes:
>
> > I'm putting the final touches on a talk I'll give to PythonUK next
> > week (it's held together with the ACCU conference) on "Python for
> > C++ and Java programmers".  One example I give is a task for which
> > C++ is quite suited, with its standard library -- reading a text file,
> > breaking it into whitespace-separated 'words', building an index from
> > each word to the line numbers on which it appears, and showing the
> > index with words in alphabetical order, one per line, each followed
> > by the line numbers on which it appears.
> >
> > Thanks to the excellent support given for these tasks by the standard
> > library, the C++ source is ONLY twice as big as the Python source for
> > the same job (a more usual ratio is around 5:1).  This holds for both
> > the simplest versions, and the slightly more complicated ones with
> > somewhat better optimization.  The runtimes on my box (Linux Mandrake
> > 9.0, gcc 3.1, Python 2.3) are, when the programs are run on the 4.4 MB
> > of the "King James Bible" in plain ASCII text: 17.4 seconds for the
> > simplest C++, going down to 15 with optimizations; 11.2 seconds for the
> > simplest Python, going down to 8.1 with optimizations (CPU times are
> > in very similar ratios).
>
> Will you make this code public ?
>
> Having a few examples of this sort readily available could be very
> useful when trying to make the point that the belief that C++ is
> absolutely essential for writing fast code, is slightly, errm,
> misguided.
>
> > By writing Python first, you'll often get an application with
> > acceptable performance; if not, you profile it, find out the
> > hot-spots, optimize those in Python terms, and if that's still not
> > enough, it's EASY to recode the hot-spots in faster ways while still
> > leaving MOST of your application in Python.
>
> And it's even more difficult to convince people of this truth (just as
> it would be more difficult to write a demonstration of it, but it
> wouldn't surprise me if you had one of those too :-)