Newsgroups: comp.lang.java,comp.lang.lisp,comp.lang.lisp.x,comp.lang.perl.misc,comp.lang.python,comp.lang.scheme,comp.lang.scheme.c,comp.lang.tcl
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!newsfeed.internetmci.com!mr.net!news.mr.net!timbuk.cray.com!driftwood.cray.com!roehrich
From: roehrich@cray.com (Dean Roehrich)
Subject: Re: A language extensibility benchmark
Message-ID: <1996Feb3.213953.11512@driftwood.cray.com>
Lines: 84
Nntp-Posting-Host: poplar501
Organization: Cray Research, Inc.
References: <DLuKxo.DnE@world.std.com> <4ejcf0$52d@nntpa.cb.att.com> <1996Jan31.122912.6567@driftwood.cray.com> <4evgfe$ack@merlin.delphi.com>
Distribution: inet
Date: 3 Feb 96 21:39:53 CST
Xref: glinda.oz.cs.cmu.edu comp.lang.java:21215 comp.lang.lisp:20700 comp.lang.lisp.x:1718 comp.lang.perl.misc:19545 comp.lang.python:8419 comp.lang.scheme:14966 comp.lang.scheme.c:734 comp.lang.tcl:42099

In article <4evgfe$ack@merlin.delphi.com>,
George J. Carrette <gjc@mci.newscorp.com> wrote:
>roehrich@cray.com (Dean Roehrich) wrote:

>>Here's my attempt at the benchmark.  
>
>Great. I would like to try it as soon as you provide the commands
>needed to "make" the extension module. 
>
>>[1] the makefile section required.
>>/* [1] not needed--automated */
>>step [1] is basically a
>>null-op.
>
>Even if it is "basically" a no-op, a person who is unfamiliar with Perl 5
>extensions (I've only done Perl 4 extensions for example) would still need to be
>given an explicit sequence of commands to execute in order to compile and 
>link the extension. 

You're right, I omitted the automated parts.

Any and all Perl extensions begin this way (exact choice of options may vary
depending on what is needed in the template, the following will be
sufficient for the extension I supplied):

	$ h2xs -An Soidx  (creates templates for the extension's pieces)
	$ cd Siodx
	< fill in the Siodx.xs and test.pl files with the stuff I provided >
	$ perl5 Makefile.PL  (creates a makefile)
	$ make  (somewhere in here step [3] happens--automatically)

This process is covered in the perlxstut manpage.

>>you'll have to forgive me for deviating from it and writing C code as if it
>>were...well, C code. 
>
>Is it really C code that you wrote? I thought it was "Perl Extension Language"
>something that needs to be run through a specialized pre-processor before
>it can be compiled by a C compiler.

The language (what there is of it) is called XS.  The CODE: blocks and fib()
function were C.

My comment about writing C as C was a jab aimed at the benchmark's lisp
solution and its lispy style of formatting C, a style which caused me some
pain while I was trying to decipher it.  I was uncertain that I had properly
interpreted what was supposed to be happening in those functions.

I still believe that the benchmark was not objective.  Siod is a lisp
interpreter (as far as I can tell), so the lisp solution did not have to
translate between siod arrays and lisp arrays.  Both Perl and Python (and
Tcl, when someone gets around to it) will have to include this translation,
in some form, at which point the benchmark is no longer the same one that
the lisp solution applies to.

As it is now, the Python and Perl solutions don't fit the benchmark.  If the
benchmark is ever reformed I would like it to be more specific, and less
biased, about the datatype or function that is to be interfaced.  Try
something that will really show the API of the language being benchmarked.
Maybe something like building, destroying, and walking a linked list of C
structures (or an array of them--that would be interesting, too) and
accessing fields in those structures.  This benchmark should be done by
calling C functions which are in a separate library, or module, and which
know how to manipulate the structures (Perl's pack/unpack, and the
equivalent in any other language, do not fit the benchmark)-- thus
demonstrating how the high level language can use C's complex datatypes.

The benchmark missed other important points on language extensions: how easy
is it to build the extension for static linking?  for dynamic linking
(assume it's available)?  What if the extension is handed to John Doe, who
hasn't heard of dynamic linking until now and who has a different OS with
different ld and cc options?  How long will it take him to get the makefile
into working order so the extension will build static?  dynamic?

If the Python version is reworked, I'd like it to stick to the scope of the
benchmark, rather than cluttering it with the capability to handle every
possible Python datatype :)  That's cool, but it's not what the benchmark
was about.  This benchmark would also be a good way to show off PyMaker,
which I wouldn't mind seeing in action.

(Please, someone, show us a Java solution after this benchmark is reworked.)

Dean
roehrich@cray.com
