ICFP who won?
TLOlczyk
The title says it all.
Mark Alexander Wotton
> Do I really have to put anything here?
> The title says it all.
An undergraduate writing in C++. 346 lines, apparently, and took
full advantage of a large number of v. fast machines...
mrak
--
realise your life was only bait for a bigger fish
-- aesop rock
George Russell
> Do I really have to put anything here?
> The title says it all.
Some browsing on the ICFP contest page and forum indicates that the
winner is this candidate:
http://www.cs.utexas.edu/users/ahudson/
A student first-timer, working by himself, in C++. Amazing!
I guess I'd better throw out Glasgow Haskell and switch to using
C++ instead ...
TLOlczyk
I know Hudson claims to have won. He probably has, but forgive me
for wanting proof other then someone claiming he has won.
007
> Do I really have to put anything here?
> The title says it all.
Hi all
Can u tell me what this ICFP contest or what-ever it was, si all about??
Thanks
gr...@cs.uwa.edu.au
: A student first-timer, working by himself, in C++. Amazing!
: I guess I'd better throw out Glasgow Haskell and switch to using
: C++ instead ...
I'm with you, if it means someone will buy me the "large number of
v. fast machines". Seriously, though, as cool as this year's problem
was, it didn't really test programming, just experience with heuristic
search techniques, access to computing power, and (to a small extent)
understanding of one's language's numerics.
-Greg
TLOlczyk
(Mark Alexander Wotton) wrote:
>On Wed, 27 Aug 2003 11:48:05 -0500, TLOlczyk posted:
>> Do I really have to put anything here?
>> The title says it all.
>
>An undergraduate writing in C++. 346 lines, apparently, and took
>full advantage of a large number of v. fast machines...
>
And the excuse for C++ taking second prize?
( And even the Judges prize where the code was done in a combination
of C++ and Dylan. )
Daniel C. Wang
gr...@cs.uwa.edu.au writes:
Um..yeah right and the majority of the "real world" programming problems are
much more suited to FPLs.
So what would be a good test of "programming". FPLs fit a niche. They fit
this nice very well, but the niche is still a small fraction of the "real world".
TLOlczyk
First. The understanding of a languages's numerics had very little to
do with it. The numerics of every language could handle it with little
problem. Since most languages support bignums. ( In fact C++ might
be the nastiest if your platform does not support long long. )
Second. I would hardly call Dual 1.8 M Xeons very fast.
I would not be suprised if a profesional programmer had two [1 ] Dual
1.8M Antlons at home which would be comparable to Dual 1.8M PIVs.
The Xeons have a larger cache and therefore speed up the processing.
So the machines would be slightly faster than what you would see
in the home of a professional programmer ( or onhis desk at work ).
I would also contend with "large number" since that implies something
like a 100. A lot might be acceptable, but I would believe that a team
of four programmers might actually have more computing power (
including laptops and old machines ). BTW he could easily pick the
wrong approach and set his machines to solving the problem with an
inferior solution and watched. Then waste the rest of his time
watching.
Third. I saw several people who were unable to submit anything because
they were not able to reliably generate a trace ( including me ), so
they never even submitted a bad entry. It took quite some skill to get
that far. ( Alltough I had very rough descriptions in computer form,
which could have been polished and generate some traces. I knew these
traces would not be that good, and work to get better traces. )
Fourth. I believe that an optimal approach is to find some sort of
path which approximates the fastest path. A* will find you the
shortest path, but the shortest path may not be the fastest path,
so you need some sort of weighted A*. Once you have the approximate
path then you do an A* on the path ih phase space with very brutal
pruning. ( In the end every approach is really just doing A* on the
phase space, with some sort of pruing. The big question is what kind
of pruning works best? )
So it was a fair test of programming. I can't help but wonder if C++
won last years competition and Haskell this years, you wouldn't be
saying last year was a poor test and this year was a good one.
[1] I'm not being redundant. I mean 2 machines with dual processors.
Artie Gold
Could you elaborate?
--ag
--
Artie Gold -- Austin, Texas
felix
"C++ is the programming tool of choice for discriminating hackers."
The irony is breathtaking. ;-)
cheers,
felix
TLOlczyk
I would have liked to see the faces of the attendees.
gr...@cs.uwa.edu.au
: gr...@cs.uwa.edu.au writes:
:> Seriously, though, as cool as this year's problem was, it didn't
:> really test programming, just experience with heuristic search
:> techniques, access to computing power, and (to a small extent)
:> understanding of one's language's numerics.
: So what would be a good test of "programming".
I don't know if I could give you a "good" test in an absolute sense,
but I think some of the previous tasks have been "better" tests.
-Greg
TLOlczyk
Any definition has to include the following rule, if a person using
C++ wins then it is not a good test.
Oleg Trott
gr...@cs.uwa.edu.au
: On Thu, 28 Aug 2003 03:27:38 +0000 (UTC), gr...@cs.uwa.edu.au wrote:
:> Seriously, though, as cool as this year's problem was, it didn't
:> really test programming, just experience with heuristic search
:> techniques, access to computing power, and (to a small extent)
:> understanding of one's language's numerics.
: First. The understanding of a languages's numerics had very little to
: do with it. The numerics of every language could handle it with little
: problem.
You did have to understand exactly how your language's numbers worked,
though, or how to get bignums and DIY it. I wasn't suggesting that the
way you language did it was a factor - quite the opposite.
: Second. I would hardly call Dual 1.8 M Xeons very fast.
: I would also contend with "large number" since that implies something
: like a 100.
: BTW he could easily pick the wrong approach and set his machines
: to solving the problem with an inferior solution and watched.
I haven't looked at the specifics of the winning entry (yes, I know
you're not speaking to me directly here), but a heuristic search on
one's own hardware definitely presents an opportunity for brawn to
augment or replace brain. Obviously the winner is _likely_ to be
someone with a good combination of both.
: Third. I saw several people who were unable to submit anything because
: they were not able to reliably generate a trace ( including me ), so
: they never even submitted a bad entry.
Well yes, that is obviously where programming skill and language
did come into it - and of course you could only do your search in
the time remaining. I don't doubt at all that skill came into the
equation, but I think it was a weaker factor than in other years.
: So it was a fair test of programming. I can't help but wonder if C++
: won last years competition and Haskell this years, you wouldn't be
: saying last year was a poor test and this year was a good one.
I don't even remember which language won last year - I'm speaking
quite generally:
In past years, the programs were run on a central server, and on
unknown input, so the grunt factor didn't come into it. I also think
that there was _usually_ more programming content and less
domain-specific knowledge - but not last year, for example. (Though
that said, the originality and complexity of last year's problem
probably gave the experienced searchers less of a handle on it.)
-Greg
Ketil Malde
> I haven't looked at the specifics of the winning entry (yes, I know
> you're not speaking to me directly here), but a heuristic search on
> one's own hardware definitely presents an opportunity for brawn to
> augment or replace brain. Obviously the winner is _likely_ to be
> someone with a good combination of both.
Brawn is a valid way to go. It is perhaps a weakness of functional
languages (and functional programmers!) that they do not support
clusters/parallel machines well?
In one way, I'm happy that C++ did so well. It's like chess; you
learn more from losing than from winning. So while we lose the
opportunity to gloat, we gain an opportunity to reveal and remedy
weaknesses. Which I think is more imporant in the long run.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
Markus Mottl
> Second. I would hardly call Dual 1.8 M Xeons very fast.
> I would not be suprised if a profesional programmer had two [1 ] Dual
> 1.8M Antlons at home which would be comparable to Dual 1.8M PIVs.
> The Xeons have a larger cache and therefore speed up the processing.
> So the machines would be slightly faster than what you would see
> in the home of a professional programmer ( or onhis desk at work ).
> I would also contend with "large number" since that implies something
> like a 100. A lot might be acceptable, but I would believe that a team
> of four programmers might actually have more computing power (
> including laptops and old machines ). BTW he could easily pick the
> wrong approach and set his machines to solving the problem with an
> inferior solution and watched. Then waste the rest of his time
> watching.
You should read Andrew Hudson's statement on his write-up page:
Also I used 16 Dual XEON 1.8Ghz machines.
So we are speaking of 32 fast processors, which already makes a big
difference. Andrew's solution is actually quite simple but clever. It's
just perfect for exploiting "raw metal", and it's certainly a valid entry
in the competition. There is no reason to talk down his performance:
he did the right thing.
I suppose that most people in the competition have access to large lab
networks and might therefore have exploited more of their available
resources. If I had participated, gone for a "brute force"-approach and
really stretched it, I could have put up almost 100 fast processors. Since
it seems hardly possible to come up with search algorithms that perform
significantly better, resources do matter greatly.
That's why I think that it was an unwise decision by the jury to allow the
use of all available computing power: that's not a level playing field!
Regards,
Markus Mottl
--
Markus Mottl http://www.oefai.at/~markus mar...@oefai.at
Markus Mottl
> Brawn is a valid way to go. It is perhaps a weakness of functional
> languages (and functional programmers!) that they do not support
> clusters/parallel machines well?
That's not true: e.g. OCaml has very good bindings to PVM and MPI. Read
this article for example:
http://caml.inria.fr/archives/200307/msg00139.html
Toni Nikkanen
> So we are speaking of 32 fast processors, which already makes a big
> difference. Andrew's solution is actually quite simple but clever. It's
> just perfect for exploiting "raw metal", and it's certainly a valid entry
> in the competition. There is no reason to talk down his performance:
> he did the right thing.
In fact, the contest assignment sort of asked for anyone to use
supercomputers or big clusters, if they had access to one. This
guy had, and used them.
Nick Name
"Markus Mottl" <mar...@oefai.at> wrote:
> That's not true: e.g. OCaml has very good bindings to PVM and MPI
Not to speak about SISAL and Parallel Haskell !
V.
Ketil Malde
At our department, I can probably pick 20 people who are very
proficient in writing compute-intensive, parallel software and running
it on clusters and large NUMA computers. They use C, C++, and
Fortran. I'll be surprised if even one of them knows Haskell, ML, or
OCaml.
Is this atypical?
Judging from the Google archives of comp.parallel, SISAL was very
interesting -- back in 1993 or so -- a couple of announcements mention
Haskell, and OCaml seems to be virtually unknown.
I would like to have GPH (or even just GHC; I'll try to bootstrap it
myself, when I can find the time for it) for IBM Regatta or SGI
Altix, but so far I've no success. Any pointers?
Mark Alexander Wotton
I guess the most obvious thing that was different about this year's contest
is that correctness didn't play such a big part. All the inputs were known,
so behaviour on unknown inputs wasn't a problem. Wasn't that what got rid of
a lot of imperative entries in previous years?
Torben Ægidius Mogensen
> I suppose that most people in the competition have access to large lab
> networks and might therefore have exploited more of their available
> resources. If I had participated, gone for a "brute force"-approach and
> really stretched it, I could have put up almost 100 fast processors. Since
> it seems hardly possible to come up with search algorithms that perform
> significantly better, resources do matter greatly.
>
> That's why I think that it was an unwise decision by the jury to allow the
> use of all available computing power: that's not a level playing field!
That, and the fact that it seems a very successful approach is to
manually create a good solution and then "just" let the computer
improve on this. This puts the focus away from programming.
It would have been better if the web-page had a number of sample
problems, but that the programs would be tested on problems that
weren't published before the deadline. This would, as in previous
years, require the programs to be run by the committee on their own
machines.
Alternatively, increase the number of problems to solve to such a
large number that it is unfeasible to do any preprocessing by hand for
each problem. You can reduce the size of each problem so the total
required running time isn't increased.
If I had competed, I think I would have solved the problem in plain C
(not C++). I have often used it for similar optimisation problems
(such as fitting splines to bitmaps).
Torben
TLOlczyk
<mar...@oefai.at> wrote:
>
>You should read Andrew Hudson's statement on his write-up page:
>
> Also I used 16 Dual XEON 1.8Ghz machines.
>
Indeed in my old age, I misread the 16 as a 10. Otherwise...
>So we are speaking of 32 fast processors,
No, They are essential 18Ghz PII's with a large cache.
I'm sure the caches helped. And if he tweaked the program
four hours before the end, he was gauranteed that he
could submit solutions based on the new program.
In fact there's good evidence that the extra processing power
was ineffecticve. His algorithm was single threaded, so the
dual CPU's didn't help much ( marginally they would have made memory
management more efficient ). He could run simulations
of each problem simultaneously, but when he tweaked his algorithm
he would flush that computer time. He could run different algorithms
on the smae problem. I'm sure that helped some.
( BTW the one thing that does make a big difference is memory.
The more memory the more simulations ( which explode exponentially)
you can run. )
>which already makes a big
>difference. Andrew's solution is actually quite simple but clever. It's
>just perfect for exploiting "raw metal", and it's certainly a valid entry
>in the competition. There is no reason to talk down his performance:
>he did the right thing.
>
I'm not trtying to talk down his preformance. He did the best with
he had.
His solution is simple and medium clever.
With more work he probably would have come up with a better solution
that uses less computing power, but I suspect he was preoccupied
with baby sitting his programs.
>I suppose that most people in the competition have access to large lab
>networks and might therefore have exploited more of their available
>resources. If I had participated, gone for a "brute force"-approach and
>really stretched it, I could have put up almost 100 fast processors. Since
>it seems hardly possible to come up with search algorithms that perform
>significantly better, resources do matter greatly.
>
Actually there are parts of the problem that are NP if you use a brute
force approach. If you look at RedTeam ( the second place winners ),
you will find that they did not have the large lab. They used their
brains, which is the best way to program when you are walking in
the valley of NP.
>That's why I think that it was an unwise decision by the jury to allow the
>use of all available computing power: that's not a level playing field!
Sure it is. If I had been smart and rigged up a simulation the first
few hours, I would probably have found a better solution. The thing is
that I just assumned that the scale was what I thought it was ( I
would have been suprised if the slowest track took 1000 turns, when
it turned out that the fast was approximately 8500 turns ),
TLOlczyk
(Mark Alexander Wotton) wrote:
>I guess the most obvious thing that was different about this year's contest
>is that correctness didn't play such a big part.
Yes it did. It's easy to write an incorrect simulation and have the
car not finish properly.
George Russell
> I'm with you, if it means someone will buy me the "large number of
> v. fast machines". Seriously, though, as cool as this year's problem
> was, it didn't really test programming, just experience with heuristic
> search techniques, access to computing power, and (to a small extent)
> understanding of one's language's numerics.
Do I detect a slight tinge of sour grapes?
Actually, according to Hudson's web page, he used 16 1.8 GHz machines.
This amount of computing power can easily be got over a weekend in
summer at a university by taking over a few of the student terminal
rooms, surely?
George Russell
> Any definition has to include the following rule, if a person using
> C++ wins then it is not a good test.
It is simply a fact that there are some problems, such as this one,
for which functional languages offer very little advantage, if any.
As I wrote in my contribution to this newsgroup on 1st July:
> I will stick out my neck and predict that this is going to be the year
> a non-functional programming language wins, because raw power will tell.
> But the final result will be close ...
George Russell
> Not to speak about SISAL and Parallel Haskell !
The trouble is that neither SISAL nor parallel Haskell compilers have the same sort
of development effort going into them as goes into the best C compilers.
I wonder which compiler Andrew Hudson used. gcc is not the best these days I
think, Intel has ones which produce faster code.
George Russell
> Sure it is. If I had been smart and rigged up a simulation the first
> few hours, I would probably have found a better solution.
To which I have to answer "oh yeah?" There are quite a lot of bits in
Andrew Hudson's description of his solution which require a fair amount of
finesse, for example the "do more moves" bit and the hash function.
George Russell
> Can u tell me what this ICFP contest or what-ever it was, si all about??
> Thanks
>
Have a look at this year's contest page:
George Russell
> "C++ is the programming tool of choice for discriminating hackers."
>
>
> The irony is breathtaking. ;-)
The fact is that there *are* some programming problems where C++ is the
programming tool of choice for discriminating hackers. Discriminating
hackers are aware that there are some problems for which Haskell is
the programming tool of choice, and some problems for which C++ is.
George Russell
interesting:
http://www.hoult.org/bruce/icfp2003/
It looks as if PhilAndSimon are mainly responsible for Andrew Hudson's
entry winning, which is rather an amusing irony ...
Mark Alexander Wotton
Yes, but you need only submit the trace: if you get an error, you can work
out what went wrong and fix it. This is only possible because there are no
unknown inputs.
Matthias Blume
Did you actually look at this year's task? I guess not, judging from
your statement.
Matthias
Joe Marshall
I am unaware of *any* problem for which C++ is the programming tool of
choice (well, other than the specific problem of turning C++ code into
an executable. A C++ compiler is exactly what you need for that. On
the other hand, the compiler need not be written in c++.)
I guess I'm not a discriminating hacker.
George Russell
> I am unaware of *any* problem for which C++ is the programming tool of
> choice (well, other than the specific problem of turning C++ code into
> an executable. A C++ compiler is exactly what you need for that. On
> the other hand, the compiler need not be written in c++.)
>
> I guess I'm not a discriminating hacker.
C is easier to justify than C++ I suppose. The three main Haskell compilers
(nhc, Hugs, and GHC) all use C to some extent. I'm also not sure if Andrew
Hudson's solution actually benefitted at all from the features of C++ which C
wouldn't have. Perhaps his priority-queue implementation was actually a
pre-existing C++ class?
Anton van Straaten
> Um..yeah right and the majority of the "real world" programming problems
are
> much more suited to FPLs.
>
> So what would be a good test of "programming". FPLs fit a niche. They fit
> this nice very well, but the niche is still a small fraction of the "real
world".
Any language only addresses a fraction of the "real world". The FPL niche
may be some fraction of the "real world", but how small that fraction is
currently is a function of history, not a reflection on the capabilities and
strengths of FPLs.
I recently used SML/NJ to help perform an analysis of reinsurance premium
and claim flows. The data consisted of complex multi-party transactions -
often involving a dozen or more parties in a hierarchy of relationships
which affect the nature of their participation in the transaction.
SML/NJ - even though it's perhaps not the most non-academic FPL out there -
proved to be an excellent tool for the job, far better than Java or SQL,
which are the most commonly used languages in this system. The code was
concise, high-level, and easy to write - certainly much easier than the
corresponding SQL, and dramatically more concise than the corresponding
Java.
Some of this data analysis is a one-off as part of a transition to a new
system, so creating test suites and the like can be a burden - the cost of
creating test suites will not be amortized over future development of the
system. In this case, testing is being done by humans who examine the data,
and ultimately by auditors who spot-check it and perform other tests. To
maximize correctness before handing off to testers, static typing is
helpful. You want to avoid adding incompatible values and ending up with
nonsense answers, for example, which can be an easy mistake to make with
this sort of data. With current "real-world" languages, you'd need a static
type system to help with that. But that's exactly one of the things which
leads to the verbosity in Java. An FPL with type inference helps strike a
middle ground, making the code more like it would be in a dynamic language,
while at the same time proving assumptions about the types involved.
More generally, there are quite a few reasons why an FPL makes sense in
financial work, at least. As one example, the idea of avoiding mutation is
common when dealing with financial transactions: the ability to go back and
change an old transaction must be disallowed, since that would lose
auditability and create the possibilty for fraud. The argument could be
made that financial processing should be done in a pure, side-effect free
language. Although it's really the database that ultimately needs to impose
such restrictions, having them in the language should help encourage the
appropriate mode of thinking amongst programmers, i.e. the idea that going
back and changing old values is Bad.
Just because very few people have yet applied FPLs to these kinds of tasks,
doesn't mean they're not suited to them.
Anton
Matthias
> I am unaware of *any* problem for which C++ is the programming tool of
> choice (well, other than the specific problem of turning C++ code into
> an executable. A C++ compiler is exactly what you need for that. On
> the other hand, the compiler need not be written in c++.)
>
> I guess I'm not a discriminating hacker.
In this year's contest C++ was the tool of choice for the winner, the second
best entry, and (along with Dylan) for the team winning the Judge's price.
I think it's fair to say that this year's problem is an example where C++
is the programming tool of choice.
Michael Sperber
Anton> More generally, there are quite a few reasons why an FPL makes sense in
Anton> financial work, at least. As one example, the idea of avoiding mutation is
Anton> common when dealing with financial transactions: the ability to go back and
Anton> change an old transaction must be disallowed, since that would lose
Anton> auditability and create the possibilty for fraud.
In certain sub-areas of "financial work" (insurance for example), it's
actually very common to make changes to financial transactions "after
the fact." (And all those PL/SQL software engineers out there have a
bitch of a time getting things like this right.) Pure functional
programming is attractive here because it forces (and empowers) the
developers to make state explicit, and the auditing requirements then
force them to make it reifiable---which in turn makes rollbacks pretty
easy.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
Anton van Straaten
You're right - I stated what I was trying to say badly. My point was that
changing old transactions needs to be done without losing the original
transaction data, whereas a mutation-oriented-mindset tends to think in
terms of changing the original data. I've seen design errors being made in
systems around this issue, and I think a more functional mindset would help
avoid such errors.
Anton
be...@sonic.net
It's not as though he didn't do a very clever search.
integrating a hash table into his search was good, and
the "divide and conquer" approach he used (first solving
a simplified version, then scaling up and refining the
solution) was actually a very good approach to big nasty
problems like this.
He also did the math, in terms of theorem proving, to see
that for his search space direction was actually not a
relevant criterion; that reduced his search by several
orders of magnitude.
Credit where credit's due, guys; he didn't just throw
brute force at it; his code is actually quite clever.
Bear
Christian Szegedy
> In this year's contest C++ was the tool of choice for the winner, the second
> best entry, and (along with Dylan) for the team winning the Judge's price.
> I think it's fair to say that this year's problem is an example where C++
> is the programming tool of choice.
Hmmm, I would not think so. I would simply say that this years problem is
an example where the choice of language did not really matter.
Last year, there were more submissions in C/C++/Java/Pyhton than in
functional languages. Even so, solutions in functional languages were
overproportionally represented among the good solutions.
As the popularity of ICFP grows, the proportion of submissions in
non-functional languages will grow, which means that the chance that
a non-functional solution wins, will get higher also.
Besides that, if the problem can be solved well enough without the
use of sophisticated algorithms (which was appearently the case, this
year) then the use of a functional language won't help too much.
George Russell
> Hmmm, I would not think so. I would simply say that this years problem is
> an example where the choice of language did not really matter.
It wouldn't matter, were it not that compilers for Haskell or OCaml are not
as good at delivering raw power as compilers for C++.
> Besides that, if the problem can be solved well enough without the
> use of sophisticated algorithms (which was appearently the case, this
> year) then the use of a functional language won't help too much.
I think that's rather unfair. It's a mistake to think that because an
algorithm is short, it is not sophisticated. The winning algorithm
*was* sophisticated, in for example the choice to reduce the
state space by not hashing the direction. However to get that sort
of choice right, first time, you don't need a functional language,
you need either brains, experience or luck.
I not would have hit on Andrew Hudson's algorithm. Although I didn't
compete, I thought the best way would be to manually pick the approximate
best route, and then use brute force to refine it. I am very impressed
that Andrew Hudson managed to solve the problem without manual
intervention by brute force, by cleverly picking the right hash function.
This may have nothing to do with functional programming, but I take my
hat off to him all the same.
George Russell
(the result doesn't seem to have appeared on the contest web page yet),
the languages and sizes of the winning teams to date are:
Year Language Size
1998 Cilk 8
1999 OCaml 5
2000 OCaml 5
2001 Haskell 2
2002 OCaml 3
2003 C++ 1
Joachim Durchholz
> Besides that, if the problem can be solved well enough without the
> language won't help too much.
I don't know what you really wanted to say, but what I understood
doesn't make the least sense to me.
1. Most new algorithms are still published in imperative form. Even if
they are high-level pseudocode. It's obvious that sophisticated
algorithms are independent of whether they are expressed imperatively or
in a functional manner.
2. FPLs don't help with sophisticated algorithms. They help with
managing and rearranging dynamic data, and they help avoid some common
mistakes when manipulating it. This is quite far from "sophisticated
algorithms".
Just my 2 points.
Regards,
Jo
Daniel C. Wang
George Russell <g...@tzi.de> writes:
> Christian Szegedy wrote (snipped):
>
> > Hmmm, I would not think so. I would simply say that this years problem is
> > an example where the choice of language did not really matter.
>
> It wouldn't matter, were it not that compilers for Haskell or OCaml are not
> as good at delivering raw power as compilers for C++.
Hey, don't bad mouth the OCaml compiler. It generates very good code,
competitive with gcc. I guarantee that most of the work placed in C++
compilers is getting the frontend to work correctly, people aren't investing
lots of time doing super fancy optimizations for C++ code. Also, ghc
genreates code that is compiled by gcc.
So it's not the quality of the compilers tight inner loops that are hurting
performance. I'd imagine its more system level issues like memory allocation
and the effect of garbage collection on memory locality (i.e. the runtime
system and runtime model.)
{stuff deleted}
George Russell
> Hey, don't bad mouth the OCaml compiler. It generates very good code,
> competitive with gcc.
gcc is not state of the art. I think for raw speed, Intel's compiler
often beats it. A quick web-search reveals the following comparisons:
http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html
> I guarantee that most of the work placed in C++
> compilers is getting the frontend to work correctly, people aren't investing
> lots of time doing super fancy optimizations for C++ code. Also, ghc
> genreates code that is compiled by gcc.
Well actually ghc mostly uses its own native generator these days.
I think a consequence of Haskell's laziness is that you get very
few lengthy sections of straight-line code, or simple loops, making
conventional optimisations on Haskell hard to do.
Unfortunately these conventional optimisations are highly important
and a lot of work. For example, they need to be tuned for
all possible varieties of Pentium, which is the sort of thing I
expect Intel C++ does best. If OCaml does that, I can only say
I'm surprised.
> So it's not the quality of the compilers tight inner loops that are hurting
> performance. I'd imagine its more system level issues like memory allocation
> and the effect of garbage collection on memory locality (i.e. the runtime
> system and runtime model.)
Indeed for functional languages you have to pay a fairly heavy price
for garbage-collection, for example because you need some way of keeping
track of what's pointer and what's data.
Daniel C. Wang
> Daniel C. Wang wrote (snipped) :
>
> > Hey, don't bad mouth the OCaml compiler. It generates very good code,
> > competitive with gcc.
>
> gcc is not state of the art. I think for raw speed, Intel's compiler
> often beats it. A quick web-search reveals the following comparisons:
>
> http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html
gcc is not that much behind the curve. If gcc is good enough for compiling
the Linux kernel and large parts of MacOS X. I'd imagine the code quality
is quite good.
> Well actually ghc mostly uses its own native generator these days.
> I think a consequence of Haskell's laziness is that you get very
> few lengthy sections of straight-line code, or simple loops, making
> conventional optimisations on Haskell hard to do.
The last time I downloaded the relase for Win32 ghc came with gcc so it
could compile the code.
> Unfortunately these conventional optimisations are highly important
> and a lot of work. For example, they need to be tuned for
> all possible varieties of Pentium, which is the sort of thing I
> expect Intel C++ does best. If OCaml does that, I can only say
> I'm surprised.
As with all compiler optimizations there is an issue of diminishing
returns. I think it's fair to say the OCaml is generating good enough code
that the place to optimize is not the code generator.
{stuff deleted}
> > So it's not the quality of the compilers tight inner loops that are hurting
> > performance. I'd imagine its more system level issues like memory allocation
> > and the effect of garbage collection on memory locality (i.e. the runtime
> > system and runtime model.)
>
> Indeed for functional languages you have to pay a fairly heavy price
> for garbage-collection, for example because you need some way of keeping
> track of what's pointer and what's data.
Yep, these are the nagging little details that make FPLs slower than
C/C++. Its not an issue of code quality. The issues are largerly data
representations imposed by the runtime model and the runtime model
itself.
Joachim Durchholz
> Indeed for functional languages you have to pay a fairly heavy price
> for garbage-collection, for example because you need some way of keeping
> track of what's pointer and what's data.
Indeed?
AFAIK the overhead for garbage collection per se isn't "heavy" (at least
when compared to manual garbage collection via malloc/free; the results
are, at best, inconclusive).
My suspicion is that functional programs tend to create more tiny memory
blocks that must be garbage collected afterwards. Those ubiquitous
linear lists are a particularly nasty example: they are everywhere,
created on a temporary basis and often immediately forgotten, and they
carry an overhead of a memory block with two pointers for each list element.
Like all suspicions about performance, this should be verified using a
profiler before anybody goes out and starts to optimize...
Regards,
Jo
George Russell
> George Russell wrote:
>
>> Indeed for functional languages you have to pay a fairly heavy price
>> for garbage-collection, for example because you need some way of keeping
>> track of what's pointer and what's data.
>
>
> Indeed?
> AFAIK the overhead for garbage collection per se isn't "heavy" (at least
> when compared to manual garbage collection via malloc/free; the results
> are, at best, inconclusive).
Well most functional language implementations I know of have one of two approaches.
Either all integers (and lots of other things) are boxed, so that you can be
sure they are data. This adds an extra indirection to every operation, which is
a right pain with numerical code. Or they are tagged, meaning your integers only
have 31 bits rather than 32, and all sorts of basic arithmetic operations have
to be used to perform additional shifts and so on.
This has to be done as otherwise it is seriously hard work for the RTS to work
out in the presence of run-time polymorphism if something is an integer or a
pointer.
In any case "manual garbage collection via malloc/free" is rarely the best
option if you are going all-out for performance in a language like C. It
is very often the case that you can use a stack, or chains of memory blocks all
the same size or clever algorithms. As far as I can see, Andrew Hudson's
algorithm could be implemented without any malloc/free at all. If you read
any numerical analysis book on sparse matrix algorithms you will find
allocation strategies that make your hair stand on end ....
In defence of garbage collection it should be said that compacting does improve
locality of reference, which is a win the other way.
Of course, in the real world we rarely care about the cost of garbage collection,
and regard not having our programs core-dump cheap at the price.
Daniel C. Wang
Joachim Durchholz <joachim....@web.de> writes:
http://citeseer.ist.psu.edu/tarditi94measuring.html
Abstract: We study the cost of storage management for garbagecollected
programs compiled with the Standard ML of New Jersey compiler. We show that
the cost of storage management is not the same as the time spent garbage
collecting. For many of the programs, the time spent garbage collecting is
less than the time spent doing other storage management tasks. 1
Introduction We study the cost of storage management for garbagecollected
programs compiled with the Standard ML of New Jersey compiler
[3].
Admittedly this is a little dated, but as you read through it you realize
the GC has lots of hidden costs. The cost of a write barrier can easily slow
a tight inner loop down by quite a bit, compared to the naive C version.
Daniel C. Wang
George Russell <g...@tzi.de> writes:
{stuff deleted}
> In defence of garbage collection it should be said that compacting does improve
> locality of reference, which is a win the other way.
I don't think this actually buys you much in practice. The GC itself does
all sorts of other things that destroy locality. The whole FP programming
style typically doesn't exploit locality as well as an imperative update in
place style.
>
> Of course, in the real world we rarely care about the cost of garbage collection,
> and regard not having our programs core-dump cheap at the price.
Yep... garbage collection speeds up programmers, but not so much
programs. :)
However, if you are in an embedded or really high-performance environment,
you tend to avoid dynamic allocation at all. Let's not forget that people
use to get buy writting really tight Fortran codes, and didn't have the
benefit of a stack yet alone a heap.
It would be nice to have a system where I get the benefits of GC when I want
it, but don't pay for the cost of it in terms of the 101 little performance
degradations when I don't.
gr...@cs.uwa.edu.au
: gr...@cs.uwa.edu.au wrote (snipped):
:> I'm with you, if it means someone will buy me the "large number of
:> v. fast machines". Seriously, though, as cool as this year's problem
:> was, it didn't really test programming, just experience with heuristic
:> search techniques, access to computing power, and (to a small extent)
:> understanding of one's language's numerics.
: Do I detect a slight tinge of sour grapes?
No, I didn't compete. I had a birthday party and a volleyball tournament.
: Actually, according to Hudson's web page, he used 16 1.8 GHz machines.
: This amount of computing power can easily be got over a weekend in
: summer at a university by taking over a few of the student terminal
: rooms, surely?
Unquestionably. I'd have no trouble doing that here, but there are
others who might not be so lucky.
-Greg
Thomas Lindgren
danw...@hotmail.com (Daniel C. Wang) writes:
> The GC itself does all sorts of other things that destroy
> locality. The whole FP programming style typically doesn't exploit
> locality as well as an imperative update in place style.
Um? Please do tell more. To set the stage, from what I've read in the
literature, FP has very good locality (excepting write misses). For
example, Tarditi and Morrisett on SML/NJ and Reinhold on Scheme.
1. An FP allocator normally just increments the heap pointer, so
allocations go in a straight line, which is the best case for a
cache. (Since there is little reuse, there can be many write
misses. These are easily tolerated.)
2. Apparently, measurements show that the data are read in an orderly
fashion, hence not causing too many read misses.
3. Finally, the GC normally compacts the live data, so improving locality
and cache/TLB usage beyond what a malloc/free allocator would.
My impression, from some similar experience a few years ago, is that
this is largely correct. But things change, so I'm interested in
hearing more.
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
Christian Szegedy
> Christian Szegedy wrote:
>
>> Besides that, if the problem can be solved well enough without the use
>> of sophisticated algorithms [...] then the use of a functional
>> language won't help too much.
>
>
> I don't know what you really wanted to say, but what I understood
> doesn't make the least sense to me.
>
> 1. Most new algorithms are still published in imperative form. Even if
> they are high-level pseudocode. It's obvious that sophisticated
> algorithms are independent of whether they are expressed imperatively or
> in a functional manner.
I don't agree that new algorithms are published in imperative form.
Normally it is a mix of imperative/functional style/common language.
>
> 2. FPLs don't help with sophisticated algorithms. They help with
> managing and rearranging dynamic data, and they help avoid some common
> mistakes when manipulating it. This is quite far from "sophisticated
> algorithms".
I agree. However, if your code gets more complicated, this helps
you (and some other syntactical feature, such as closures) to
concentrate on the algorithm instead of the implementation details.
If your code is short (or does not require long code), the effort put
into the implementation will be neglectible compared to the other
efforts.
Christian Szegedy
>
>> Besides that, if the problem can be solved well enough without the
>> use of sophisticated algorithms (which was appearently the case, this
>> year) then the use of a functional language won't help too much.
>
>
> I think that's rather unfair. It's a mistake to think that because an
> algorithm is short, it is not sophisticated. The winning algorithm
> *was* sophisticated, in for example the choice to reduce the
> state space by not hashing the direction. However to get that sort
> of choice right, first time, you don't need a functional language,
> you need either brains, experience or luck.
OK. it was a misformulation. I meant by "sophisticated"
"not too easy to implement".
I did not want to say, that it was easy to come up with the solution,
however, after having the idea, it was not too complicated to implement
it in any language you like. You could have even implemented it in
assembler without a lot of additional effort, and you could have
implemented it in Ocaml without making it much slower.
I don't want to downplay his achievment. It was a well focused,
fully automatized very clever solution.
Alaric B Snell
> My suspicion is that functional programs tend to create more tiny memory
> blocks that must be garbage collected afterwards. Those ubiquitous
> linear lists are a particularly nasty example: they are everywhere,
> created on a temporary basis and often immediately forgotten, and they
> carry an overhead of a memory block with two pointers for each list
> element.
One of the other things that makes me wax lyrical about how lovely
uniqueness typing can be is that, as well as allowing mutating updates
without breaking referential transparency, it can also eliminate a lot
of garbage collection. 'coz when a unique value is used, your code will
always either reuse the space to set up a return value of the same type,
or know that the space will never be used again, so it can be tacked
right back onto the free list.
Which is nice. Particularly since lots of 'temporary' values can be
decided to be unique by the compiler upon inspection, without needing
explicit annotation by the programmer.
>
> Regards,
> Jo
>
ABS
George Russell
> http://citeseer.ist.psu.edu/tarditi94measuring.html
>
> Abstract: We study the cost of storage management for garbagecollected
> programs compiled with the Standard ML of New Jersey compiler. We show that
> the cost of storage management is not the same as the time spent garbage
> collecting. For many of the programs, the time spent garbage collecting is
> less than the time spent doing other storage management tasks. 1
> Introduction We study the cost of storage management for garbagecollected
> programs compiled with the Standard ML of New Jersey compiler
> [3].
>
> Admittedly this is a little dated, but as you read through it you realize
> the GC has lots of hidden costs. The cost of a write barrier can easily slow
> a tight inner loop down by quite a bit, compared to the naive C version.
Fascinating paper, thank you!
I wonder if we will ever get processors which will support GC properly. This
could make a lot of things, for example write barriers, a lot cheaper.
George Russell
> One of the other things that makes me wax lyrical about how lovely
> uniqueness typing can be is that, as well as allowing mutating updates
> without breaking referential transparency, it can also eliminate a lot
> of garbage collection.
'Twould be nice if compilers would infer uniqueness types. But maybe that
is not too easy.
In any case, mutating data is always going to be a pain for many garbage collectors,
for example generational ones which I think many functional language compilers
use.
Christian Szegedy
>
> 'Twould be nice if compilers would infer uniqueness types. But maybe that
> is not too easy.
If I remember correctly, Clean has automatic
inference for most cases of uniqueness typing.
(Of course uniqueness types in type declarations
can not be inferred.)
Bruce Hoult
Christian Szegedy <sze...@nospam.or.uni-bonn.de> wrote:
> Matthias wrote:
>
> > In this year's contest C++ was the tool of choice for the winner, the
> > second
> > best entry, and (along with Dylan) for the team winning the Judge's price.
> > I think it's fair to say that this year's problem is an example where C++
> > is the programming tool of choice.
>
> Hmmm, I would not think so. I would simply say that this years problem is
> an example where the choice of language did not really matter.
I agree. We could have done our OpenGL driving game/simulator in Dylan
easily enough -- or in FORTRAN. It really didn't matter. But Keith
happened to be most familiar with doing OpenGL from C++, so why not make
use of that? It all depends on whether you want to try to win the
contest, or be some sort of total language chauvinist.
> Last year, there were more submissions in C/C++/Java/Pyhton than in
> functional languages. Even so, solutions in functional languages were
> overproportionally represented among the good solutions.
>
> As the popularity of ICFP grows, the proportion of submissions in
> non-functional languages will grow, which means that the chance that
> a non-functional solution wins, will get higher also.
There is also the chance that one of those massive number of C++ entries
is going to fluke it. Will Hudson be there next year? That'll be
interesting to see.
OTOH, Tom Rokicki has now gotten 2nd two years in a row (and a pretty
good entry the year before that). He's clearly *good*. Hell, my Dylan
team has picked up a 2nd and a Judges' Prize for two mentions in the
last three years. We're pretty happy too.
-- Bruce
Joachim Durchholz
> I wonder if we will ever get processors which will support GC
> properly.
As soon as language with GC become more widespread.
And it's NOT a chicken-and-egg problem: Languages with GC are already
becoming more widespread. Microsoft Windows has adopted a GC'ed common
runtime environment (under the umbrella of the general .net hype).
If (when) .net programs become commonplace, benchmarks will add a .net
section, then Intel and/or AMD will start to think about the issue, at
which point any mechanism for GC will make it into hardware.
Microsoft could speed up the process by doing and publishing their own,
.net-centric benchmarks.
Regards,
Jo
Daniel C. Wang
> danw...@hotmail.com (Daniel C. Wang) writes:
>
> > The GC itself does all sorts of other things that destroy
> > locality. The whole FP programming style typically doesn't exploit
> > locality as well as an imperative update in place style.
>
> Um? Please do tell more. To set the stage, from what I've read in the
> literature, FP has very good locality (excepting write misses). For
> example, Tarditi and Morrisett on SML/NJ and Reinhold on Scheme.
Very good (except ...) is not the same as very good. :)
In general, I was thinking about "update in place" vs. allocate a fresh
modified copy.
> 1. An FP allocator normally just increments the heap pointer, so
> allocations go in a straight line, which is the best case for a
> cache. (Since there is little reuse, there can be many write
> misses. These are easily tolerated.)
The cost of cache penalties have gotten higher relative to processor
speeds, so those write misses do hurt you more these days.
> 2. Apparently, measurements show that the data are read in an orderly
> fashion, hence not causing too many read misses.
>
> 3. Finally, the GC normally compacts the live data, so improving locality
> and cache/TLB usage beyond what a malloc/free allocator would.
GC also destorys locality during some phases of it's operation, so I'm not
sure if it's a net win.
> My impression, from some similar experience a few years ago, is that
> this is largely correct. But things change, so I'm interested in
> hearing more.
I don't have any new hard data, this is just my semi-informed
impression. Lots of things have changed since the mid to late 90s so it
would be interesting to see an updated view of the cost of GC.
There are enough little details about GC implementation that it's hard to
say if it's a net win or not.
However, I think it's pretty clear that GC leads to less buggy easier to
maintain programs. I tend to focus on the software engineering benefits of
GC rather than performance wins. I guess my new slogan is that GC was
designed to make *programming faster* not necessarily programs.
P.S. If I want my programs to go faster, I usually just wait 18 months for
the next generation x86. :)
Thomas Lindgren
danw...@hotmail.com (Daniel C. Wang) writes:
> Thomas Lindgren <***********@*****.***> writes:
>
> > danw...@hotmail.com (Daniel C. Wang) writes:
> >
> > > The GC itself does all sorts of other things that destroy
> > > locality. The whole FP programming style typically doesn't exploit
> > > locality as well as an imperative update in place style.
> >
> > Um? Please do tell more. To set the stage, from what I've read in the
> > literature, FP has very good locality (excepting write misses). For
> > example, Tarditi and Morrisett on SML/NJ and Reinhold on Scheme.
>
> Very good (except ...) is not the same as very good. :)
Oh, but even the lowly UltraSparc gets _that_ right :-) Write misses
are in general easy to handle, for example by putting the missed store
aside and letting the processor proceed while it is resolved. (The US
has a write buffer for this purpose.)
Of course, there is no guarantee that the hardware designers thought
of this.
> > 3. Finally, the GC normally compacts the live data, so improving locality
> > and cache/TLB usage beyond what a malloc/free allocator would.
>
> GC also destorys locality during some phases of it's operation, so I'm not
> sure if it's a net win.
Do you mean the GC itself suffers from excessive misses? Or that most
GCs do basically breadth-first traversals, rather than some order that
might be better? (I *think* Paul Wilson wrote a paper about the second
sort.)
> P.S. If I want my programs to go faster, I usually just wait 18 months for
> the next generation x86. :)
An acquaintance of mine had the habit of comparing the time needed to
write an optimization vs Moore's law.
Let's see ... if we say speed doubles in 540 days, then this means an
improvement of 0.128 percent per day. So a compiler optimization
yielding a 10% speedup would have to be done in, um, 74 days, or we
might as well have waited for the rising tide. (Well, yes, it's a bit
specious :-)
Ken Rose
> I wonder if we will ever get processors which will support GC properly.
> This
> could make a lot of things, for example write barriers, a lot cheaper.
>
I read the paper many years ago. What things should hardware do to
support GC better?
Thanks
- ken
George Russell
I am not an expert at all, and in any case it would depend on the
sort of GC you wanted to support. But for example suppose you wanted
to support generational GC, without extensive software checks for
modifications to pointers in old generations setting them to point
to new generations. Then perhaps you could attach an optional
generation number to each page and to each register. load-to-register
could have an option to attach to the register the generation of the
target point, store-from-register could have an option to check the
generation number and generate a hardware exception (or perhaps simply
set a condition code) when storing a pointer to a newer generation in
an older generation. This would I think make generational GC much
more attractive when a lot of mutable state is around.
Another much simpler suggestion would be to smuggle in an extra bit somewhere,
so that garbage collectors to distinguish pointers and data, EG store things
in 33 bit words, but make pointers and integers only use 32 bits. But I don't
know if that would be acceptable.
But of course this is totally off-the-top-of-my-head, one could probably
come up with 20 better ways of improving GC, and it would take a lot
of work to find out which would provide the best performance improvement
for the amount of silicon.
Matthias Blume
> danw...@hotmail.com (Daniel C. Wang) writes:
>
> > Thomas Lindgren <***********@*****.***> writes:
> >
> > > danw...@hotmail.com (Daniel C. Wang) writes:
> > >
> > > > The GC itself does all sorts of other things that destroy
> > > > locality. The whole FP programming style typically doesn't exploit
> > > > locality as well as an imperative update in place style.
> > >
> > > Um? Please do tell more. To set the stage, from what I've read in the
> > > literature, FP has very good locality (excepting write misses). For
> > > example, Tarditi and Morrisett on SML/NJ and Reinhold on Scheme.
> >
> > Very good (except ...) is not the same as very good. :)
>
> Oh, but even the lowly UltraSparc gets _that_ right :-) Write misses
> are in general easy to handle, for example by putting the missed store
> aside and letting the processor proceed while it is resolved. (The US
> has a write buffer for this purpose.)
Unfortunately, other architectures don't do that, or they do
write-around -- which then causes a read miss on the next access. (I
remember some early(?) versions of the Alpha suffering from this
problem.)
Andrew Appel, back then, came up with a cute little trick: prefetching
"garbage" (by occasionally reading ahead of the allocation pointer and
throwing the result away) can bring memory soon to be written into the
cache, eliminating subsequent misses. (Of course, this requires that
the processor does not stall on the prefetch itself.)
I know he wrote this up some time, but I'm not sure if it ever got
published anywhere.
Matthias
Thomas Lindgren
Matthias Blume <fi...@my.address.elsewhere> writes:
> > Oh, but even the lowly UltraSparc gets _that_ right :-) Write misses
> > are in general easy to handle, for example by putting the missed store
> > aside and letting the processor proceed while it is resolved. (The US
> > has a write buffer for this purpose.)
>
> Unfortunately, other architectures don't do that, or they do
> write-around -- which then causes a read miss on the next access. (I
> remember some early(?) versions of the Alpha suffering from this
> problem.)
(Let me mention that the next sentence in the message you quoted read
> > Of course, there is no guarantee that the hardware designers thought
> > of this.
)
As I recall, Tarditi and Morrisett mention a collection of hardware
techniques to tolerate write misses. I believe another example of an
architecture that got this right was a MIPS workstation they used. What
about current x86:es?
Thomas Lindgren
One thing that seems to work well:
* The memory subsystem should tolerate write misses well.
Another item that's probably useful is:
* Support for multiple load/stores per cycle
To speculate a bit, I think the following could help, though it's an
open question how much.
* Cheap, simple, useful user-space exceptions
* Cheap and flexible memory protection
Purpose: You can set up and modify write barriers, heap
limits, etc. easily. And recover from going out of bounds quickly.
It saves on various bounds-checks, at least.
The danger with hardware support for GC is that state of the art in GC
algorithms and data representation changes over time. Thus,
instructions or features that help with a too specific problem may
well become useless. Hardware guys seem to hate that.
Marshall Spight
> George Russell wrote:
> > I wonder if we will ever get processors which will support GC
> > properly.
>
> As soon as language with GC become more widespread.
> And it's NOT a chicken-and-egg problem: Languages with GC are already
> becoming more widespread. Microsoft Windows has adopted a GC'ed common
> runtime environment (under the umbrella of the general .net hype).
Plus I occasionally hear mention of a new language called "Java" which
(so I hear) also is garbage collected.
Marshall
Feuer
> Plus I occasionally hear mention of a new language called "Java" which
> (so I hear) also is garbage collected.
That's just a rumor. The garbage collector for Java is pure vaporware.
David
Joachim Durchholz
>
> The danger with hardware support for GC is that state of the art in GC
> algorithms and data representation changes over time. Thus,
> instructions or features that help with a too specific problem may
> well become useless. Hardware guys seem to hate that.
That's true.
The reason is simple: whatever they implement, they'll have to support
it in all eternity. And for them, compatibility is not just a few cheap
largely-unused bytes on a harddisk, it's a lot of not-so-cheap
largely-unused silicon estate.
Regards,
Jo
Joachim Durchholz
I assume you forgot a smiley here, right?
Regards,
Jo
Jerzy Karczmarczuk
> On 27 Aug 2003 22:31:57 -0700, fe...@proxima-mt.de (felix) wrote:
...
>>"C++ is the programming tool of choice for discriminating hackers."
>>
>>
>>The irony is breathtaking. ;-)
>
>
> I would have liked to see the faces of the attendees.
Well, I was there, sitting and enjoying.
Next time I will take some photos. But the result will be always the same.
People smile and are relaxed, whatever the results might be. Mind you,
this is a game. Sometimes it promotes people who happen to be *very*
knowledgeable, sometimes the computer resources, sometimes some nice
ideas, or a bit of craziness.
One of not so bad entries was based on a "drunken" protocol. You accelerate
as strongly as you can, and then, having to turn, you make some loops, you
roll over, producing a truly crazy trajectory. This team didn't win, but
they made us laugh, and we will remember them. Thank you folks, if you are
reading this. Your entry *was* important.
Sometimes we learn other things, about the milieu itself rather than
about comp.sci. Two small teams from Poland got to the top. One had
the fourth prize, other won the blitz category. After the presentation
was over, somebody told me: "I didn't know that young people in Poland
are interested in this kind of 'academic' computer science...". What
could I say? That Polish youngs are not (yet?) complete business-oriented
troglodytes?
Ketil Malde says that the fact that C++ won was good for FP, because we
learn by losing. No, I don't think that this contest had anything to do
with a claim "C++ won with Haskell". Of course it proves that some people
are unhappy with the domination of imperative languages, but it doesn't
say anything about the "weakness" of FL.
Actually this contest doesn't teach much. But in several cases it proves
how important is the organization of the work within a many-person team.
And sometimes prove that if the subject is very concrete, one person can
do better than a division of Marines, because there is no need for
splitting/modularization.
Anyway, a game is a game is a game.
Jerzy Karczmarczuk
Caen, France
Norman Ramsey
Daniel C. Wang <danw...@hotmail.com> wrote:
>As with all compiler optimizations there is an issue of diminishing
>returns. I think it's fair to say the OCaml is generating good enough code
>that the place to optimize is not the code generator.
I couldn't agree more. A wise man once said that if you want to run
benchmarks fast, you work on your optimizer. If you want to run
users' codes fast, you work on your profiler.
Heap profiling for Caml anyone?
--
Norman Ramsey
http://www.eecs.harvard.edu/~nr