benchmark

[Terry Reedy]

Dhananjay wrote:
> On Aug 7, 11:58 pm, Terry Reedy <tjre... at udel.edu> wrote:
>> M8R-n7v... at mailinator.com wrote:
>>  > Are there any implications of using psyco ?
>>
>> It compiles statements to machine code for each set of types used in the
>> statement or code block over the history of the run.  So code used
>> polymorphically with several combinations of types can end up with
>> several compiled versions (same as with C++ templates).  (But a few
>> extra megabytes in the running image is less of an issue than it was
>> even 5 or so years ago.)  And time spent compiling for a combination
>> used just once gains little.  So it works best with numeric code used
>> just for ints or floats.
>>
>> Terry J. Reedy
> 
> But if site caching is indeed being adopted by so many dynamic language
> runtime environments, I kind of wonder what makes python hold back from
> bringing it in to its core. Is it that a question of time and effort,

Yes, and of priorities of the *current* volunteer developers, and of 
complexity and maintainability and their impact on being dependably correct.

> or is there something that doesn't make it appropriate to python ?

How about less necessary.  Python was designed to be extended by native 
code.  The built-in functions and classes are built-in extensions.  The 
built-in extensions in the stdlib are importable extensions**.  *So are 
native-code 3rd party extensions*!

Numeric, Python's first killer app, and now numpy, which both wrap 
standard Fortran and C libraries, have been standard associated parts of 
'Python' (CPython) as used in the science, engineering, and technical 
community for over a decade.  There are features in Python that were 
introduced for their use.  Python 3.0 has (if plans get fulfilled) a new 
multi-dimensional buffer class/interface/C-API (not sure of the details 
;-) introduced by Travis Oliphant of NumPy for use by extension writers 
so extensions, built-in or 3rd-party, can work together (share C level 
date) without copying.  For instance, the C-level data for an image 
imported into a cooperating image program could be directly manipulated 
by NumPy and then directly blitted on the screen by a display manager.


About benchmarks: machine speed benchmarks miss the point that the real 
limiting factor in information processing is programmer availability and 
writing and debugging speed.  Python was optimized for *this*, not 
machine speed per se, knowing that most machine bottlenecks could be 
rewritten in C or another low-level language.  Why reinvent that wheel? 
  Measuring programmer productivity is hard, but it is real.

Number-crunching benchmarks which disallow NumPy because it is not 
distributed with the 'core' by PSF (although it *is* by other 
packagers), are simply braindead.  If a scientist/engineer/technologist 
saves half an hour setting up a 10-hour run by using Python instead of 
C, it is *completely irrelevant* that the C interface to the 
number-crunching libraries might run in a 1/10 second instead of, say, 
10 seconds.  That is why such people developed Numeric and then NumPy.


None of this is to say that continued development of Psyco or equivalent 
for new versions would not be great.  But that comes down to *someone* 
volunteering the resources.

Terry Jan Reedy