caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* [Caml-list] Newbie Ocaml performance questions
@ 2001-08-06  2:40 Luke Gorrie
  2001-08-06  3:04 ` Pixel
  0 siblings, 1 reply; 2+ messages in thread
From: Luke Gorrie @ 2001-08-06  2:40 UTC (permalink / raw)
  To: caml-list

G'day all,

As a programming exercise, I've ported an Erlang program to
Ocaml. It's the first caml code I've written, and the program is an
optimiser from the ICFP contest. I was quite pleased to see that most
of the program could be ported line-for-line straight into caml.

Now I'm having a look at the performance, and surprised to see that
the Caml (native) and Erlang ones run at about the same speed. I'm
curious about why this is and whether there are some simple things
that would make the Caml version a lot quicker without changing the
basic style.

The program is almost purely functional and spends its time doing list
traversals - sometimes building things on the stack, sometimes in an
accumulator - and pattern matching.

So I have a few questions:

- Is it reasonable to expect purely functional list-based code to run
  really fast (compared to bytecode interpreted systems like Erlang),
  or does one usually "go imperative" to get speed?
- Is there some common listy/recursive style that is particularly
  slow - e.g. deep recursions building up a stack?
- Is there an easy way to measure the number of milliseconds it takes
  to evaluate a certain expression?

And some miscellaneous:

- How do I print to stdout a text representation of an arbitrary
  object? (Like the way the shell prints results)
- Can I increase the stack size (for native and bytecode)? It seems to
  blow out on me at a depth of about 70,000 in simple functions - I'd
  like to be able to get about 100x deeper.

Thanks for any help! Ocaml is a fun language.

P.S., it's certainly not impossible that I've done something stupid
and ported it too naively, but it looks pretty straight forward.

-- 
"It seems possible that some sufficiently inquiring mind (loony) could
find meaning in this." -- Graham Gorrie
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Caml-list] Newbie Ocaml performance questions
  2001-08-06  2:40 [Caml-list] Newbie Ocaml performance questions Luke Gorrie
@ 2001-08-06  3:04 ` Pixel
  0 siblings, 0 replies; 2+ messages in thread
From: Pixel @ 2001-08-06  3:04 UTC (permalink / raw)
  To: Luke Gorrie; +Cc: caml-list

Luke Gorrie <luke@bluetail.com> writes:

[...]

> - Is there an easy way to measure the number of milliseconds it takes
>   to evaluate a certain expression?

As for me, the best solution to find out which program part takes time is to
call the part twice or thrice and note the difference on the whole program
execution time.
- ocamlcp is nice but doesn't give timings
- the output of gprof is usually very hard to use (mainly due to "cycles")

[...]

> - Can I increase the stack size (for native and bytecode)? It seems to
>   blow out on me at a depth of about 70,000 in simple functions - I'd
>   like to be able to get about 100x deeper.

haha. 

We (Equipe de merd team) had to remove quite a few non tail-recursive
functions to help stay in the stack.

For bytecode, this works:
Gc.set { (Gc.get()) with Gc.stack_limit = 50 * 1024 * 1024 }
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-08-06  3:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-06  2:40 [Caml-list] Newbie Ocaml performance questions Luke Gorrie
2001-08-06  3:04 ` Pixel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).