ICFP'00 programming contest

ICFP'00 programming contest

[Julian Assange]

While the domain of the challenge task has not been revealed,
presuming it's one well-suited to O'caml does anyone want enter an
O'caml team? Given that ICFP'{98,99} first places were won by domain
experts (although not necessarily the other winning categories!), a
good strategy seems to be putting together a team with a large number
of members on the hope that some of them will happen to be experts in
the domain of the challege. After the challenge has been revealed, the
remaining team members can then withdraw to support roles, trying
to break the models the domain experts have created.

Will Inria be entering this year?

Cheers,
Julian.

Re: ICFP'00 programming contest

[Xavier Leroy]

> While the domain of the challenge task has not been revealed,
> presuming it's one well-suited to O'caml does anyone want enter an
> O'caml team? Given that ICFP'{98,99} first places were won by domain
> experts (although not necessarily the other winning categories!), a
> good strategy seems to be putting together a team with a large number
> of members on the hope that some of them will happen to be experts in
> the domain of the challege.

That's one strategy.  So far, teams have been relatively small and
composed of members of the same institution -- it helps to be able to
work in the same room!  But maybe a big, distributed team can also do well.

At any rate, I encourage everyone to participate in the challenge (and
use OCaml for it, of course).  Here is the URL for this year's
contest:

        http://www.cs.cornell.edu/icfp/

Teams must register in advance, it seems.

> Will Inria be entering this year?

Yes, of course!

- Xavier Leroy

Re: ICFP'00 programming contest

[Julian Assange]

> That's one strategy.  So far, teams have been relatively small and
> composed of members of the same institution -- it helps to be able to
> work in the same room!  But maybe a big, distributed team can also do well.

Effectively you would end up with a small team, self assembling out of the
large one once the problem was revealed (most people could even resign from
the team at that point). The idea is to have people ready just incase their
skills have a match. This also encourages more people to be involved who
wouldn't otherwise enter.

> > Will Inria be entering this year?
> 
> Yes, of course!
> 
> - Xavier Leroy

I thought you said it was just a pissing contest :)

Cheers,
Julian.

Re: ICFP'00 programming contest

[Xavier Leroy]

> > > Will Inria be entering [the ICFP programming contest] this year?
> > Yes, of course!
> I thought you said it was just a pissing contest :)

I said that, yes, and to some extent it is -- like all contests.
Nonetheless (or because of that?), it's quite enjoyable :-)

Have fun!

- Xavier Leroy

Re: ICFP'00 programming contest

[Julian Assange]

Xavier Leroy <Xavier.Leroy@inria.fr> writes:

> > Will Inria be entering this year?
> 
> Yes, of course!
> 
> - Xavier Leroy

How'd you go? This was an excellent multi-dimensional test of rapid
software design, but the juding criteria seems somewhat arbitary.

Cheers,
Julian.

Re: ICFP'00 programming contest

[Xavier Leroy]

> How'd you go? This was an excellent multi-dimensional test of rapid
> software design, but the juding criteria seems somewhat arbitary.

You can see our entry at http://caml.inria.fr/icfp00-contest/,
including some cool test images.  The topic (ray tracing) wasn't
exactly our cup or tea, but we had a big team (7 persons) that
self-organized rather efficiently along the "surgical team" model,
and fortunately included one excellent mathematician who zipped
through all the 3D geometric nonsense with amazing speed.  We'll see
how it goes in a few weeks...

- Xavier Leroy

Re: ICFP'00 programming contest

[Francois Rouaix]

> You can see our entry at http://caml.inria.fr/icfp00-contest/,
> including some cool test images.

You guys rule.
It would be nice to have the computation times for those test images, 
especially for those of us who won't be able to go to ICFP.

--f

Re: ICFP'00 programming contest

[Xavier Leroy]

> > You can see our entry at http://caml.inria.fr/icfp00-contest/,
> > including some cool test images.
> 
> You guys rule.

Thank you!

> It would be nice to have the computation times for those test images, 
> especially for those of us who won't be able to go to ICFP.

Good idea.  I added some timings to the Web page above.  Not being
familiar with the state of the art in ray tracing, we have no idea if
these are good or bad timings.  But from examination of the code
produced by ocamlopt, I can say that those floating-point
optimizations finally paid off...

- Xavier Leroy

Re: ICFP'00 programming contest

[Xavier Leroy]

> I tried to compile the raytracer ...
> > /tmp/camlasm0.s: Assembler messages:
> > /tmp/camlasm0.s:235: Error: suffix or operands invalid for `fld'
> Did you use a special version of ocamlopt ?

Actually, we used a post-3.00 development version.

I'm embarrassed to admit it, but the ray-tracer actually triggers a
rather unlikely bug in the ocamlopt 3.00 compiler.
(The development version we used still has the bug, but by sheer luck
doesn't trigger it.)

So, this programming contest actually has some technical value as a
bug finder, in addition to its amusement value :-)

I modified the source code available on the Web site so that it
doesn't run into the bug.  (The bug pops up in a function that is
not normally called, anyway.)

Enjoy,

- Xavier Leroy

Re: ICFP'00 programming contest

[Patrick M Doane]

On Thu, 31 Aug 2000, Xavier Leroy wrote:

> > How'd you go? This was an excellent multi-dimensional test of rapid
> > software design, but the juding criteria seems somewhat arbitary.
> 
> You can see our entry at http://caml.inria.fr/icfp00-contest/,
> including some cool test images. 

For those interested in seeing another Caml entry to the contest, check
out:

  http://lyren.penguinpowered.com/icfp2000/

The Inria team definitely has us beat!

I thought I'd take this contest as an opportunity to evangelize Caml and
put together a team from friends at work that had little or no previous
experience with Caml programming. 

We were able to implement the Tier 1 features, and most of the Tier 2 and
Tier 3 functionality while still taking time out for the work days.

None of us had any solid experience writing ray tracers, and only a couple
had some 3d programming background. 

While we certainly won't win the contest, everyone on my team was amazed
to see how much we did accomplish. We all felt that the Caml language
made a big contribution to rapid development.

The contest was a lot of fun, except for the many modifications/changes to
the document. I'm glad to see it getting much more exposure this year.

Good luck to the Inria team. It looks like you have a nice elegant
solution there!

Patrick

Re: ICFP'00 programming contest

[Pascal Grosse]

On Fri, 1 Sep 2000, Xavier Leroy wrote:

> > I tried to compile the raytracer ...
> > > /tmp/camlasm0.s: Assembler messages:
> > > /tmp/camlasm0.s:235: Error: suffix or operands invalid for `fld'
> > Did you use a special version of ocamlopt ?
> 
> Actually, we used a post-3.00 development version.
> 
> I'm embarrassed to admit it, but the ray-tracer actually triggers a
> rather unlikely bug in the ocamlopt 3.00 compiler.
> (The development version we used still has the bug, but by sheer luck
> doesn't trigger it.)
> 
> So, this programming contest actually has some technical value as a
> bug finder, in addition to its amusement value :-)
> 
> I modified the source code available on the Web site so that it
> doesn't run into the bug.  (The bug pops up in a function that is
> not normally called, anyway.)
> 

I found that by removing the '-inline 20' in the makefile, the error is
not triggered by ocamlopt v3.00.

Pascal Grossé

Re: ICFP'00 programming contest

[John Max Skaller]

Xavier Leroy wrote:

> Good idea.  I added some timings to the Web page above.  Not being
> familiar with the state of the art in ray tracing, we have no idea if
> these are good or bad timings.  But from examination of the code
> produced by ocamlopt, I can say that those floating-point
> optimizations finally paid off...

It would be interesting to see how good ocaml is now with FP.
I believe Fortran is king, with C being roughly 50% slower.
If ocaml were 100% slower than Fortran, it would be a significant
achievement: many numerical people are looking for better
_structured_ programs than one can get with Fortran and will pay
with some loss of performance: C++ has been used by many for this
reason. But much numerical programming is 'conceptually functional'
with some crucial optimisations to objects, which would make
ocaml a far better choice if it can achieve reasonable performance.

I'm not a numerical programmer, but I have considerable 'sympathy'
for that art form, so I'd like to thank the ocaml team for the
hard work of tuning ocaml to make it suitable for numerical
programming use. Thanks!


-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: ICFP'00 programming contest

[Xavier Leroy]

> It would be interesting to see how good ocaml is now with FP.
> I believe Fortran is king, with C being roughly 50% slower.

I have few numerical benchmarks in Caml, and even fewer for which
equivalent C code is available.  Here are figures for two such
benchmarks, Pseudoknot (an ADN conformation thing with lots of 3D
geometry) and FFT (fast Fourier transform):

                C          OCamlopt      OCamlopt
                        w. bounds checks wo. bounds checks

PentiumIII 450Mhz

FFT             0.43s       0.62s        0.55s
Nucleic         0.12s       0.17s        0.17s

Alpha 21264 500Mhz

FFT             0.28s       0.27s        0.26s
Nucleic         0.06s       0.07s        0.07s

So, OCaml is doing quite well on code that uses records of floats and
one-dimensional float arrays.  I don't have good benchmarks for
multidimensional arrays, but I'd expect the results to be not as good,
since the default representation of multidimensional arrays as arrays
of arrays can be expensive; however, the new "Bigarray" module
provides flat multidimensional float arrays, with some support in
ocamlopt to generate decent (if not really optimized) code.

> I'm not a numerical programmer, but I have considerable 'sympathy'
> for that art form, so I'd like to thank the ocaml team for the
> hard work of tuning ocaml to make it suitable for numerical
> programming use.

I, too, have sympathy for numerical applications, and we have very
interesting feedback from some members of this community.  They seem
quite open towards high-level languages with a mathematical flavor,
probably more so than most IT professionals.

In the same vein, you could have a look at the PSCICO project at CMU
(http://www.cs.cmu.edu/~pscico/)

- Xavier Leroy

Re: ICFP'00 programming contest

[ortmann]

Last year one of IBM's simulator developers discovered that a Fortran
version
of the simulator was faster because the generated code happened to fit well
into the processor code/data cache.  The performance difference was
substantial.

:-/

--
Daniel Ortmann, IBM Circuit Technology, Rochester, MN 55901-7829
ortmann@us.ibm.com / internal 8.553.6795 / external 507.253.6795
ortmann@isl.net home 507.288.7732

"The answers are so simple, and we all know where to look,
but it's easier just to avoid the question." -- Kansas




John Max Skaller <skaller@maxtal.com.au> on 09/06/2000 12:21:54 AM

To:   Xavier Leroy <Xavier.Leroy@inria.fr>
cc:   frouaix@liquidmarket.com, caml-list@inria.fr
Subject:  Re: ICFP'00 programming contest




Xavier Leroy wrote:

> Good idea.  I added some timings to the Web page above.  Not being
> familiar with the state of the art in ray tracing, we have no idea if
> these are good or bad timings.  But from examination of the code
> produced by ocamlopt, I can say that those floating-point
> optimizations finally paid off...

It would be interesting to see how good ocaml is now with FP.
I believe Fortran is king, with C being roughly 50% slower.
If ocaml were 100% slower than Fortran, it would be a significant
achievement: many numerical people are looking for better
_structured_ programs than one can get with Fortran and will pay
with some loss of performance: C++ has been used by many for this
reason. But much numerical programming is 'conceptually functional'
with some crucial optimisations to objects, which would make
ocaml a far better choice if it can achieve reasonable performance.

I'm not a numerical programmer, but I have considerable 'sympathy'
for that art form, so I'd like to thank the ocaml team for the
hard work of tuning ocaml to make it suitable for numerical
programming use. Thanks!


--
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: ICFP'00 programming contest

[Damien Doligez]

>From: Julian Assange <proff@iq.org>

>Will Inria be entering this year?


We have registered a team.

-- Damien