caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: David Allsopp <dra-news@metastack.com>
Cc: 'kirillkh' <kirillkh@gmail.com>, caml-list@yquem.inria.fr
Subject: RE: [Caml-list] best and fastest way to read lines from a file?
Date: Wed, 03 Oct 2007 08:23:17 +1000	[thread overview]
Message-ID: <1191363797.6668.103.camel@rosella.wigram> (raw)
In-Reply-To: <004601c80539$6a8a4360$017ca8c0@countertenor>

On Tue, 2007-10-02 at 22:15 +0100, David Allsopp wrote:
> > A little weird to see such inherently functional construct as fold
> implemented imperatively. But it's fine with me, as long as it does the job.
> I
> > wonder, though, how would the performance of a line counter based on your
> code compare with the one suggested by Brian. 
> 
> It's faster, though only slightly - I was going to post an imperative
> solution earlier, too. Even in Ocaml, a recursive call (tail or otherwise)
> has some costs not present in a simple loop. However, I don't agree that
> it's more natural - "ugly" is more the word I'd use!

In Felix, tail-rec calls are generally faster than loops.
The reason is that the compiler is better able to reason
about the semantics and so it can do better optimisations.
OTOH loops degenerate to conditional goto-spaghetti and
would require SSA analysis to recover.

For example, given:

	fun f(x,y) ... f (a,b)

the implementation generates

	var x,y; 
	set_initial_values(x,y);
	start:
		...
		paropt x,y = a,b;
		goto start;

where 'paropt' serialises the parallel assignment
using an optimisation algorithm which tries to minimise
the number of assignments and temporaries used.

this has a significant impact on performance .. Felix version
of Ackermann's function is more then 2.5x faster than Ocamlopt,
and almost 2x faster than C. Ackermann has 2 tail-rec calls.

Trying to do this with loops is much harder because, unlike
the tail-rec formulation, the 'inputs' and 'outputs' connected
by the loops are not explicit, as they are when a function
is used and parameters and arguments define the input/output
relationship (and everything else local is a temporary with no
persistence: Felix doesn't not allow functions to have side
effects, so only local data is mutable).

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


      reply	other threads:[~2007-10-02 22:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-01 21:27 YC
2007-10-01 21:55 ` [Caml-list] " Daniel Bünzli
2007-10-01 22:29   ` YC
2007-10-01 21:55 ` Olivier Roussel
2007-10-02 12:39   ` Mattias Engdegård
2007-10-02 12:56     ` Brian Hurt
2007-10-02 16:15       ` kirillkh
2007-10-02 17:10         ` verlyck, Bruno.Verlyck
2007-10-02 18:02         ` kirillkh
2007-10-02 19:35           ` skaller
2007-10-02 21:05             ` kirillkh
2007-10-02 21:07               ` Jon Harrop
2007-10-02 20:23           ` Olivier Andrieu
2007-10-02 20:49             ` kirillkh
2007-10-02 21:10               ` Jon Harrop
2007-10-02 21:15               ` David Allsopp
2007-10-02 22:23                 ` skaller [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1191363797.6668.103.camel@rosella.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@yquem.inria.fr \
    --cc=dra-news@metastack.com \
    --cc=kirillkh@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).