[m-dev.] [petdr at miscrit.be: Report on the ICFP 2000 prog contest]

[Peter Ross]

Here is a report I wrote about our ICFP entry for those interested at
MC.

Feel free to do anything you want with it.

Pete

----- Forwarded message from Peter Ross <petdr at miscrit.be> -----

Date: Mon, 4 Sep 2000 12:51:07 +0200
From: Peter Ross <petdr at miscrit.be>
To: MisCrit - Tech <mct at miscrit.be>
Subject: Report on the ICFP 2000 prog contest

Is there anything else anybody would like to know?

==========================================================================

The ICFP 2000 programming contest (http://www.cs.cornell.edu/icfp/) was
to implement a ray tracer.

The input to the ray tracer was a scene description written in a simple
functional language, called GML.  Execution of a GML program produces
zero, or more, image files, which are in PPM format.  The feature set of
GML was organized into three tiers, all of which were implemented by the
Mercury entry.

GML has primitives for defining simple geometric objects (e.g., planes,
spheres, and cubes) and lighting sources. The surface properties of the
geometric objects used to render the objects are specified as functions
in GML itself.  GML also defined operators for combining the simple geometric
objects to create more complex objects.  In addition to supporting scene
description, GML also has a render operator that renders a scene to an
image file. For each pixel in the output image, the render command must
compute a color.  Conceptually, this color is computed by tracing the
path of the light backwards from the eye of the viewer, to where it
bounced off an object, and ultimately back to the light sources.

The contest rules stated that a team had 72 hours to implement a ray
tracer.  The ray tracer could be implemented in any language, and the
team could consist of any size.  The short time frame of the contest
meant that programming languages that help programmers to build complex
systems quickly, should be more advantageous to use then more efficient
but less software engineering friendly languages (see the report on the
1999 programming contest at http://www.eecs.harvard.edu/~nr/icfp/results.html
for more information).

Mercury is a new logic/functional programming language designed for
building large scale software systems (http://www.mercury.cs.mu.oz.au),
so should be an ideal candidate for use in the programming contest.

The Mercury entry was produced by a team of 13 members (at least 10 of
which contributed code to the ray tracer).  The team was also distrubted
over three countries (Australia (11 members), England (1 member) and
Belgium (1 member)).  Both the members of the team in England and
Belgium contributed significant amounts of code.  Nearly all the
communication between distrubuted team members took place via email (the
England and Belgium team members spoke occasionally by phone).

The distrubuted nature of the entry and the lack of problems encountered
due to the distrubution of team members is a feather in the cap of the
Mercury language.  The strong type and mode system ensured that if an
interface between distinct parts of the ray tracer changed, the spots
which were impacted by the change were reported by the Mercury compiler,
and could quickly be corrected.  It also meant that different team
members could work on different solutions to the same problem, as long
as both solutions agreed on a common interface, and the best one could
be chosen.

The statistics for all the source files (including source files which
were used to debug individual components of the ray tracer) are as
follows:

Number of types:                    64
Number of insts:                     2
Number of predicates:              162
Number of functions:               133

Number of predmodes:               102
Number of funcmodes:                 0
Number of separate modes:           66
Number of implicit function modes:    ?
Total number of modes:       >=    168
                             =<    301
        - det:                     122 ( 72.62%)
        - semidet:                  40 ( 23.81%)
        - nondet:                    0 (  0.00%)
        - multi:                     0 (  0.00%)
        - cc_nondet:                 0 (  0.00%)
        - cc_multi:                  2 (  1.19%)
        - erroneous:                 8 (  4.76%)
        - failure:                   0 (  0.00%)
Average modes per predicate: >=  1.037
                             =<  1.037

Blank lines:                      1263 ( 20.57%)
Comment lines:                     537 (  8.74%)
Total whitespace/comment lines:   1800 ( 29.31%)

Function declaration lines:        147 (  2.39%)
Predicate declaration lines:       260 (  4.23%)
Mode declaration lines:             67 (  1.09%)
Type declaration lines:            308 (  5.02%)
Inst declaration lines:             13 (  0.21%)
Other declaration lines:           223 (  3.63%)
Total declaration lines:          1018 ( 16.58%)

Code lines:                       3323 ( 54.11%)

Total number of lines:            6141 (100.00%)

Mercury provides an interface to the C language.  This interface was
used once to do an efficient ray-box intersection test.  The C code for
this was located from the web, and rather then recoding the algorithm in
Mercury we used the C code verbatim.

The actual ray tracer source is available by anonymous CVS in the module
icfp2000.  The CVSROOT environment variable should be set to
:pserver:guest at hydra.cs.mu.oz.au:/home/mercury1/repository. The password
is `guest'.

----- End forwarded message -----
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------