From: Lex Stein <stein@eecs.harvard.edu>
To: Ocaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] comparison with C performance
Date: Thu, 1 May 2003 14:24:40 -0400 (EDT) [thread overview]
Message-ID: <Pine.BSF.4.51.0305011359200.64908@bowser.eecs.harvard.edu> (raw)
In-Reply-To: <1051811713.25152.1.camel@car.pixar.com>
Yes, there will be additional context switch costs for a user-land
implementation. However, where a disk I/O costs a luxury yacht a context
switch might cost a used bicycle. So I think filesystem designers are in
the position of not worrying about the old bike because it's best to focus
negotiating efforts on the yacht. So I guess the question on our mind was;
is OCaml another luxury yacht?
(With the NFS metadata operations in BDBFS there were synchronous I/O
operations on the path. These will make a context switch insignificant.
Consider the milliseconds required for an I/O.)
To narrow the experiment to isolating the language cost, I eliminated the
synchronous I/O by placing the DB->put()s outside of a transaction, with
no commit. As I'm sure you realised, all of the C and OCaml Native and
Bytecode experiments were run in user-land so all had additional context
switches above a kernel-level implementation. However, given I/O costs in
filesystems, context switch costs are insignificant.
Lex
On Thu, 1 May 2003, Miles Egan wrote:
> On Thu, 2003-05-01 at 10:29, Lex Stein wrote:
> > Hi,
> >
> > A while ago I built an NFS server in OCaml (BDBFS) and the performance
> > stunk. It was 10x slower than the BSD in-kernel NFS server for metadata
> > operations. There was some speculation about what was causing this
> > slowness. It could have been a number of things. So in order for my
> > Advisor to let me continue programming in OCaml, I set out to show that it
> > wasn't due to the choice of OCaml.
>
> Wouldn't you expect any userspace nfs server to be much slower than the
> kernel-based implementation due to the overhead of all the extra
> context-switching?
>
> --
> Miles Egan <miles@caddr.com>
>
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next prev parent reply other threads:[~2003-05-01 18:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-01 15:27 [Caml-list] OT: Java Performance Brian Hurt
2003-05-01 17:29 ` [Caml-list] comparison with C performance Lex Stein
2003-05-01 17:55 ` Miles Egan
2003-05-01 18:24 ` Lex Stein [this message]
2003-05-01 18:48 ` Miles Egan
2003-05-01 18:38 ` Lex Stein
2003-04-27 19:04 ` Chet Murthy
2003-05-01 19:08 ` Brian Hurt
2003-05-01 19:13 ` Eray Ozkural
2003-05-02 6:02 Gregory Morrisett
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=Pine.BSF.4.51.0305011359200.64908@bowser.eecs.harvard.edu \
--to=stein@eecs.harvard.edu \
--cc=caml-list@inria.fr \
/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).