caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Asfand Yar Qazi <email@asfandyar.cjb.net>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] STM support in OCaml
Date: Wed, 08 Mar 2006 11:52:05 +1100	[thread overview]
Message-ID: <1141779125.20944.405.camel@budgie.wigram> (raw)
In-Reply-To: <440DD982.8080800@asfandyar.cjb.net>

On Tue, 2006-03-07 at 19:05 +0000, Asfand Yar Qazi wrote:

> You make several claims:
> 
> STM is not lock free.
> STM is not useful on a small number of processors
> 
> As for claim 1.  "Lock-free" doesn't mean what you think it does. 

I know what STM does, thank you: I intend to implement it
myself in my own programming language. Maybe you should
read more carefully.

I said "protected by a mutex under the hood." which means
sure, the programmer is not writing locks, but they're used
in the implementation and the associated costs are still paid.

I really hate it when people try to throw papers against
simple logic. I said what the tradeoffs where:

"It simply limits the locking period
 to a bounded time, at the expense of the whole transaction
taking unbounded time."

and then elaborated the conditions under which this
made sense.

Long locking period on a Uniprocessor not only do not
cause problems they can actually IMPROVE performance by preventing
expensive context switches. 

A paper is cached here on my website, probably one of the
ones you cited.

http://felix.sourceforge.net/papers/ea8-composablememory_stm.pdf

It's quite interesting and I've bought a dual core CPU specifically
to test it out. The only numbers I can give you are based on a simple
lock test on a dual core G5 incrementing an integer: 15x SLOWER
on a dual processor than a uniprocessor with two threads.

No doubt because of the weak support provided by Linux.
Windows may do better, haven't tried yet, but I doubt anything
older than Vista has suitable API support.

In the end, fast concurrency is going to depend on both CPU and 
board design and OS support. The point of the above paper is 
not performance: the point is as I said, Sebastian said, 
AND the paper emphasises: it provides a model which 
supports composition.

I point out that in fact, under the right conditions -- lots
of processors and lots of variables -- it will probably provide better
performance too. However this is hard to test -- not many
of us have access to >2 cores on the same board. There certainly
no way POSIX can deliver good performance: mutexes have to be
synchronisation points and that requires ALL the CPUs to 
flush their caches -- it doesn't scale. Message passing does,
since sender and receiver only need to sync the message.
Explicit coupling, and both the subset of processor and
memory are limited.

Oh, and Ocaml supports message passing between processes .. :)

-- 
John Skaller <skaller at users dot sourceforge dot net>
Async PL, Realtime software consultants
Checkout Felix: http://felix.sourceforge.net


  reply	other threads:[~2006-03-08  0:43 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-07 16:18 Asfand Yar Qazi
2006-03-07 16:50 ` [Caml-list] " Sebastian Egner
2006-03-07 17:44   ` Michael Hicks
2006-03-08  0:37     ` Asfand Yar Qazi
2006-03-08  5:05       ` Erick Tryzelaar
2006-03-11 19:43     ` Deadlock free locking scheme (was: Re: [Caml-list] STM support in OCaml) David MENTRE
2006-03-07 17:15 ` [Caml-list] STM support in OCaml skaller
2006-03-07 19:05   ` Asfand Yar Qazi
2006-03-08  0:52     ` skaller [this message]
2006-03-08  7:08       ` Bardur Arantsson
2006-03-08 10:38       ` [Caml-list] " Asfand Yar Qazi
2006-03-08 19:36       ` William Lovas
2006-03-08 20:45         ` Brian Hurt
2006-03-08 21:14           ` Paul Snively
2006-03-08 22:06           ` skaller
2006-03-08 22:10             ` Gerd Stolpmann
2006-03-08 23:48               ` skaller
2006-03-09  7:45               ` Andrae Muys
2006-03-09  9:18                 ` David Brown
2006-03-08 22:11             ` Brian Hurt
2006-03-08 23:05               ` Lodewijk Vöge
2006-03-09  3:13                 ` Brian Hurt
2006-03-08 23:45               ` Robert Roessler
2006-03-09  0:23               ` skaller
2006-03-09  3:19                 ` Brian Hurt
2006-03-09  4:32                   ` skaller
2006-03-09 10:38                     ` John Chu
2006-03-09 16:53                     ` Stefan Monnier
2006-03-11 15:26             ` [Caml-list] " Florian Weimer
2006-03-08 10:11 yoann padioleau
2006-03-08 10:41 ` Asfand Yar Qazi
2006-03-08 12:23   ` skaller
2006-03-08 23:02     ` Asfand Yar Qazi
2006-03-09  0:36       ` skaller
2006-03-08 11:32 ` Gerd Stolpmann
2006-03-08 12:04   ` skaller
2006-03-08 19:22     ` Dan Grossman
2006-03-08 22:10       ` skaller

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=1141779125.20944.405.camel@budgie.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@yquem.inria.fr \
    --cc=email@asfandyar.cjb.net \
    /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).