From: Mark Hayden <hayden@ispchannel.com>
To: Michael Hicks <mwh@dsl.cis.upenn.edu>
Cc: Brian Rogoff <bpr@best.com>, caml-list@inria.fr
Subject: Re: Subsequence references or substrings in OCaml
Date: Sun, 27 Dec 1998 21:03:15 +0000 [thread overview]
Message-ID: <3686A093.711890B2@ispchannel.com> (raw)
In-Reply-To: <l03010d04b2a41ba6f85b@[0.0.0.0]>
You'll also find support for management of sub-strings
in the Ensemble group communication toolkit written in Ocaml.
Most of the data that moves through our protocols is
message data contained in 'substring' data structures
and so their implementation turns out to heavily impact the
performance of the Ensemble protocols. The substring
implementation is described in a section of the paper
"Distributed Communication in ML", which can be found at
http://simon.cs.cornell.edu/Info/People/hayden/publications.htm
The "substring" module are in the buffer subdirectory
of the Ensemble distribution.
--Mark
Michael Hicks wrote:
>
> At 11:27 AM -0800 12/18/98, Brian Rogoff wrote:
> >Its simple enough to implement subsequence references as a user defined
> >type in OCaml, as I've done, but I am curious about whether anyone else
> >who has used similar libraries would find a built-in substring or
> >subsequence ref library useful.
>
> We've done this in our active network implementation to efficiently
> implement packet switching. The idea is that when the packet comes in, it
> has an Ethernet header that is stripped off before the packet is processed
> by the next level in the protocol stack. After doing this, it may turn out
> that the packet should be forwarded, in which case a new Ethernet header
> needs to be prepended to the currently headerless packet. By using the
> substring abstraction, we are able to the prepend efficiently because the
> space of the old header may be overwritten. The alternative would have us
> allocate a new buffer with the correct header and then copy the old payload
> into it. Using substrings is more efficient: there is no wasted copying of
> data; this is a time-savings in itself, but it also reduces the frequency
> of GC.
>
> Mike
>
> ------------------------------------------------------------------------------
> Michael Hicks
> Ph.D. candidate, the University of Pennsylvania
> mwh@gradient.cis.upenn.edu
> "I'm looking over
> A three-leaf clover,
> That I overlooked be-three ..." -- Bugs Bunny
prev parent reply other threads:[~1998-12-29 13:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-12-18 19:27 Brian Rogoff
1998-12-21 10:39 ` Christian Lindig
1998-12-21 15:49 ` Michael Hicks
1998-12-27 21:03 ` Mark Hayden [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=3686A093.711890B2@ispchannel.com \
--to=hayden@ispchannel.com \
--cc=bpr@best.com \
--cc=caml-list@inria.fr \
--cc=mwh@dsl.cis.upenn.edu \
/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).