[Caml-list] native threads not parallel?

[Caml-list] native threads not parallel?

[Markus Mottl]

Hello,

I am having problems using native threads (under Solaris; don't know
about other architectures): I can't get them to run in parallel on a
dual-processor machine even though I turn off the master lock on the
C-side around an external function that should execute in parallel.

There are four threads running (I actually create two only - ?) as I can
observe with "ps -L". The two created ones reach the external Fortran
routine (in LAPACK) at about the same time, obviously in parallel or at
least interleaved up this point as I can see in the logged checkpoints.

I turn off/on the lock around this routine as in:

  enter_blocking_section();

    some_really_expensive_function ();

  leave_blocking_section();

Unfortunately, the expensive function is executed sequentially only.

What could be the cause of the lack of parallelism? Am I just
misunderstanding how things work? If this could be a bug, I can send
you more information to the bug-tracker, of course.

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
-------------------
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

Re: [Caml-list] native threads not parallel?

[Xavier Leroy]

> I am having problems using native threads (under Solaris; don't know
> about other architectures): I can't get them to run in parallel on a
> dual-processor machine even though I turn off the master lock on the
> C-side around an external function that should execute in parallel.

The default thread library under Solaris is odd in the sense that, by
default, it doesn't take advantage of more than one processor.  (More
specifically, it creates only one "ligthweight process", i.e. kernel
thread, unless more are required for I/O purposes.)  Try to put the
following incantation somewhere in your code:

#include <thread.h>
#include <unistd.h>

   thr_setconcurrency(sysconf(_SC_NPROCESSORS_ONLN));

If that doesn't help, you might still want to look at how many LWPs
(not user threads) are active in your program, using whatever tools
Solaris provides for this purpose.  

- Xavier Leroy
-------------------
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

Re: [Caml-list] native threads not parallel?

[Markus Mottl]

On Fri, 15 Jun 2001, Xavier Leroy wrote:
> The default thread library under Solaris is odd in the sense that, by
> default, it doesn't take advantage of more than one processor.  (More
> specifically, it creates only one "ligthweight process", i.e. kernel
> thread, unless more are required for I/O purposes.)

Very odd, indeed...

> Try to put the
> following incantation somewhere in your code:
[snip]
> If that doesn't help, you might still want to look at how many LWPs
> (not user threads) are active in your program, using whatever tools
> Solaris provides for this purpose.  

Thanks for the code, but it unfortunately doesn't change anything (at
least not visibly to me).

The "ps"-command shows me that there are really four LWPs with different
LWP-ids running under the same PID. Or better: only one seems to
be actually executing code, the others do not consume LTIME. The
"mpstat"-tool tells me that user code consumes both CPUs at 100%, but
this means nothing, because the tool counts itself as already consuming
the capacity of one processor...

Maybe it's a configuration problem of the machine, I don't know, I am
not the administrator.

In any case, it doesn't seem to depend on my code. If anybody ever tries
my Lacaml-library on a machine with multiple processors, I'd like to
hear whether it works fine when executed in parallel.

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
-------------------
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

Re: [Caml-list] native threads not parallel?

[Markus Mottl]

On Fri, 15 Jun 2001, Markus Mottl wrote:
> In any case, it doesn't seem to depend on my code. If anybody ever
> tries my Lacaml-library on a machine with multiple processors, I'd
> like to hear whether it works fine when executed in parallel.

I have just been told that things work smoothly with dual-processor
machines under Linux, and it also turned out due to more experimentation
that the behaviour of native threads under Solaris is comparable to
a lottery: when running very long, it seems that multiple threads are
used. Sometimes. But sometimes you can also get bus errors. It's really
unpredictable. Better don't bother with native threads under Solaris...

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
-------------------
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

Re: [Caml-list] native threads not parallel?

[Markus Mottl]

On Fri, 15 Jun 2001, Markus Mottl wrote:
> I have just been told that things work smoothly with dual-processor
> machines under Linux, and it also turned out due to more experimentation
> that the behaviour of native threads under Solaris is comparable to
> a lottery: when running very long, it seems that multiple threads are
> used. Sometimes. But sometimes you can also get bus errors. It's really
> unpredictable. Better don't bother with native threads under Solaris...

I couldn't resist and have done another test now. First, I have made
sure that multiple threads work under C. As Xavier has pointed out, this
requires setting the concurrency level to more than the default of 1.
Works fine (= in parallel).

Then I have written a small test program that tries to do the same under
OCaml - but no success...

Here are the the timings achieved by calling C via OCaml:

  Running sequentially:
  Wall clock time: 6.598713

  Running in parallel:
  Wall clock time: 6.601169


Here are the the timings achieved by using C only (clearly runs faster
with threads):

  Running sequentially
  Wall clock time: 6.995337

  Running in parallel
  Wall clock time: 3.910411

The only thing I can imagine is that OCaml somehow changes
scheduling so that the threads cannot run in parallel anymore, even if
"enter_blocking_section" is used. Is this possible? Or am I just making
some stupid mistake?

Regards,
Markus Mottl

P.S.:

The files I used in the test:

The C-only version:
---------------------------------------------------------------------------
#include <stdio.h>
#include <sys/time.h>
#include <unistd.h>
#include <pthread.h>

#define NUM_THREADS 2

double gtimeofday () {
  struct timeval t;
  gettimeofday(&t, NULL);
  return (t.tv_sec + t.tv_usec/1000000.0);
}

void init() {
  thr_setconcurrency(sysconf(_SC_NPROCESSORS_ONLN));
}

void calc_seq() {
  int i;
  for(i=0; i<=50000000; i++);
}

void * calc_par(void *threadid) {
  int i;
  for(i=0; i<=50000000; i++);
  pthread_exit(NULL);
}

void seq () {
  double t1, t2;

  printf("Running sequentially\n");

  t1 = gtimeofday();
    calc_seq(); calc_seq();
  t2 = gtimeofday();

  printf("Wall clock time: %f\n", (t2 - t1));
}

void par () {
  double t1, t2;
  pthread_t tids[NUM_THREADS];
  int rc, t, status;

  printf("Running in parallel\n");

  t1 = gtimeofday();
    for (t=0; t<NUM_THREADS; t++) {
      rc = pthread_create(&tids[t], NULL, calc_par, (void *) t);

      if (rc) {
        printf("pthread_create failed: return code: %d\n", rc);
        exit(-1);
      }
    }

    for (t=0; t<NUM_THREADS; t++) {
      rc = pthread_join(tids[t], (void **) &status);

      if (rc) {
        printf("pthread_join failed: return code: %d\n", rc);
        exit(-1);
      }
    }
  t2 = gtimeofday();

  printf("Wall clock time: %f\n", (t2 - t1));
}

int main(int argc) {
  init ();
  seq (); printf ("\n"); par ();
  pthread_exit(NULL);
}
---------------------------------------------------------------------------

The C-implementation for OCaml:
---------------------------------------------------------------------------
#include <stdio.h>
#include <pthread.h>

#include <caml/mlvalues.h>
#include <caml/alloc.h>
#include <caml/memory.h>
#include <caml/fail.h>
#include <caml/callback.h>

value test_init () {
  thr_setconcurrency(sysconf(_SC_NPROCESSORS_ONLN));
  return Val_unit;
}

value test_calc () {
  int i;

  enter_blocking_section();

    for (i=0; i<50000000; i++);

  leave_blocking_section();

  return Val_unit;
}
---------------------------------------------------------------------------

The OCaml-file to be used with the C-file right above:
---------------------------------------------------------------------------
open Printf
open Unix

external init : unit -> unit = "test_init" "noalloc"
external calc : unit -> unit = "test_calc" "noalloc"

let _ = init ()

let seq () =
  printf "Running sequentially:\n";

  let t1 = gettimeofday () in
    calc (); calc ();
  let t2 = gettimeofday () in

  printf "Wall clock time: %f\n" (t2 -. t1)

let par () =
  printf "Running in parallel:\n";

  let t1 = gettimeofday () in
    let tids = List.map (Thread.create calc) [(); ()] in
    List.iter Thread.join tids;
  let t2 = gettimeofday () in

  printf "Wall clock time: %f\n" (t2 -. t1)

let _ = seq (); print_newline (); par ()
---------------------------------------------------------------------------

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
-------------------
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

Re: [Caml-list] native threads not parallel?

[Shivkumar Chandrasekaran]

Not sure if this issue from an earlier discussion was fully resolved or 
not. But I seem to have the same problem as discussed by Markus Mottl 
(see attachment below) on Mac OS X 10.2.4 on a dual processor G4 
machine. An earlier message in that thread mentioned that there was no 
such problem on dual-processor Linux machines.

I have two questions:

1. Has anybody else figured out how to get parallelism using native 
threads on Mac OS X?

2. Will I get the parallelism if I switch to LinuxPPC?

Thanks,

--shiv--

PS: Does ocaml work properly on LinuxPPC?




> Re: [Caml-list] native threads not parallel?
> To :Xavier Leroy < Xavier.Leroy@inria.fr >
> Subject :Re: [Caml-list] native threads not parallel?
> From :Markus Mottl < mottl@miss.wu-wien.ac.at >
> Date: Thu, 21 Jun 2001 15:43:16 +0200
> Cc: OCAML < caml-list@inria.fr >
> Content-Disposition: inline
> In-Reply-To: < 20010615233325.B24915@miss.wu-wien.ac.at >; from 
> mottl@miss.wu-wien.ac.at on Fri, Jun 15, 2001 at 23:33:26 +0200
> References: < 20010615184931.A25835@miss.wu-wien.ac.at > < 
> 20010615191046.A20258@pauillac.inria.fr > < 
> 20010615204218.C25835@miss.wu-wien.ac.at > < 
> 20010615233325.B24915@miss.wu-wien.ac.at >
> User-Agent: Mutt/1.2.5i
> On Fri, 15 Jun 2001, Markus Mottl wrote:
> > I have just been told that things work smoothly with dual-processor
> > machines under Linux, and it also turned out due to more 
> experimentation
> > that the behaviour of native threads under Solaris is comparable to
> > a lottery: when running very long, it seems that multiple threads are
> > used. Sometimes. But sometimes you can also get bus errors. It's 
> really
> > unpredictable. Better don't bother with native threads under 
> Solaris...
>
> I couldn't resist and have done another test now. First, I have made
> sure that multiple threads work under C. As Xavier has pointed out, 
> this
> requires setting the concurrency level to more than the default of 1.
> Works fine (= in parallel).
>
> Then I have written a small test program that tries to do the same 
> under
> OCaml - but no success...
>
> Here are the the timings achieved by calling C via OCaml:
>
>   Running sequentially:
>   Wall clock time: 6.598713
>
>   Running in parallel:
>   Wall clock time: 6.601169
>
>
> Here are the the timings achieved by using C only (clearly runs faster
> with threads):
>
>   Running sequentially
>   Wall clock time: 6.995337
>
>   Running in parallel
>   Wall clock time: 3.910411
>
> The only thing I can imagine is that OCaml somehow changes
> scheduling so that the threads cannot run in parallel anymore, even if
> "enter_blocking_section" is used. Is this possible? Or am I just making
> some stupid mistake?
>
> Regards,
> Markus Mottl

--shiv--

-------------------
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

Re: [Caml-list] native threads not parallel?

[Jacques Garrigue]

From: Shivkumar Chandrasekaran <shiv@ece.ucsb.edu>

> not. But I seem to have the same problem as discussed by Markus Mottl 
> (see attachment below) on Mac OS X 10.2.4 on a dual processor G4 
> machine. An earlier message in that thread mentioned that there was no 
> such problem on dual-processor Linux machines.

Let's answer again, since this is a frequent question: ocaml threads
do not not support parrallelism. Only one ocaml thread will run at a
time, independently of the number of processors, and this on any
architecture/OS.

> > From :Markus Mottl < mottl@miss.wu-wien.ac.at >
> > The only thing I can imagine is that OCaml somehow changes
> > scheduling so that the threads cannot run in parallel anymore, even if
> > "enter_blocking_section" is used. Is this possible? Or am I just making
> > some stupid mistake?

enter_blocking_section only happens in C code, and is followed by a
leave_blocking_section before returning to caml code. Since the
leave_blocking_section reacquires the lock, no more than one ocaml
thread can run simultaneously.
Easy way to crash the runtime: call a caml callback immediately after
an enter_blocking_section.  The two caml threads will start to
allocate simultaneously on the same heap, without any locking...

Jacques Garrigue
-------------------
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

Re: [Caml-list] native threads not parallel?

[shivkumar chandrasekaran]

On Thu, 2003-02-20 at 16:15, Jacques Garrigue wrote:
> From: Shivkumar Chandrasekaran <shiv@ece.ucsb.edu>
> 
> > not. But I seem to have the same problem as discussed by Markus Mottl 
> > (see attachment below) on Mac OS X 10.2.4 on a dual processor G4 
> > machine. An earlier message in that thread mentioned that there was no 
> > such problem on dual-processor Linux machines.
> 
> Let's answer again, since this is a frequent question: ocaml threads
> do not not support parrallelism. Only one ocaml thread will run at a
> time, independently of the number of processors, and this on any
> architecture/OS.
> 

Sorry, but let me ask again. I *know* that ocaml threads cannot use
multiple processors. That was not the subject of the thread I cited. I
should have been clearer.

If I am recalling correctly, Xavier has mentioned before that in
*native-code* (see subject) ocaml will allow C code to run in parallel.
Markus' email was precisely on that point as was mine. I have C code
that I would like to execute on a processor different from the ocaml
thread one. Apparently, as I gather from the cited email of Markus
Mottl, this did occur (at least on some dual processor Linux machines)
when the corresponding C code was bracketed with "enter/leaving_blocking
section ()" calls, and, *I assume*, calling the C-code from a separate
ocaml thread using Thread.create.

I understand the dangers about calling back into caml from the bracketed
C-code. The preceding thread I cited discussed this as well, as you
mentioned.

Thanks,

--shiv--


> > > From :Markus Mottl < mottl@miss.wu-wien.ac.at >
> > > The only thing I can imagine is that OCaml somehow changes
> > > scheduling so that the threads cannot run in parallel anymore, even if
> > > "enter_blocking_section" is used. Is this possible? Or am I just making
> > > some stupid mistake?
> 
> enter_blocking_section only happens in C code, and is followed by a
> leave_blocking_section before returning to caml code. Since the
> leave_blocking_section reacquires the lock, no more than one ocaml
> thread can run simultaneously.
> Easy way to crash the runtime: call a caml callback immediately after
> an enter_blocking_section.  The two caml threads will start to
> allocate simultaneously on the same heap, without any locking...
> 
> Jacques Garrigue
> -------------------
> 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
-- 
Professor Shivkumar Chandrasekaran            || phn: 805.893.7542
Electrical & Computer Engineering Department  || fax: 805.893.3262
University of California                      || Office: 3109, Eng. I
Santa Barbara, CA 93106-9560                  || email:
shiv@ece.ucsb.edu

-------------------
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

Re: [Caml-list] native threads not parallel?

[Markus Mottl]

On Thu, 20 Feb 2003, shivkumar chandrasekaran wrote:
> If I am recalling correctly, Xavier has mentioned before that in
> *native-code* (see subject) ocaml will allow C code to run in parallel.
> Markus' email was precisely on that point as was mine. I have C code
> that I would like to execute on a processor different from the ocaml
> thread one. Apparently, as I gather from the cited email of Markus
> Mottl, this did occur (at least on some dual processor Linux machines)
> when the corresponding C code was bracketed with "enter/leaving_blocking
> section ()" calls, and, *I assume*, calling the C-code from a separate
> ocaml thread using Thread.create.

Looking back at the old discussion, I remember that this was really
a Solaris-only problem. Executing C-code from OCaml in parallel
(requires native threads, of course) by using enter_blocking_section
and leave_blocking_section appropriately should work without problems
on other platforms, well, at least Linux. As Jacques correctly pointed
out, of course, messing with the OCaml-heap within such sections, e.g.
by calling callbacks, is a guarantee for sudden death.

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
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

Re: [Caml-list] native threads not parallel?

[Jacques Garrigue]

From: shivkumar chandrasekaran <shiv@ece.ucsb.edu>
> Sorry, but let me ask again. I *know* that ocaml threads cannot use
> multiple processors. That was not the subject of the thread I cited. I
> should have been clearer.
>
> If I am recalling correctly, Xavier has mentioned before that in
> *native-code* (see subject) ocaml will allow C code to run in parallel.
> Markus' email was precisely on that point as was mine. I have C code
> that I would like to execute on a processor different from the ocaml
> thread one. Apparently, as I gather from the cited email of Markus
> Mottl, this did occur (at least on some dual processor Linux machines)
> when the corresponding C code was bracketed with "enter/leaving_blocking
> section ()" calls, and, *I assume*, calling the C-code from a separate
> ocaml thread using Thread.create.

I see, after rereading carefully the original mail, I could understand
what this is about.

IIRC, the distinction is not between native code and bytecode, but
between native threads and caml threads. You can use native threads in
bytecode, and it should work also (but I might be wrong).

About the problem Markus is describing, and if he is using
Thread.create as you suggest, I may see a cause.  Seeing that the code
for caml_thread_new in posix.c contains no enter_blocking_section, if
you create a thread with Thread.create, it will immediately block
trying to get the caml mutex. It will get it eventually from the main
caml thread through a yield, but a clever scheduler will schedule this
thread on the same processor (it starts just when the previous one
stops). As Markus says, after a long time the scheduler may realize
this choice was wrong and change the processor, but this is scheduler
dependent.

I may be utterly wrong in my inference, but if this is right, a better
solution would be to explicitely start the thread with pthread_start
from the C side.

Jacques Garrigue
-------------------
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

Re: [Caml-list] native threads not parallel?

[Markus Mottl]

On Sat, 22 Feb 2003, Jacques Garrigue wrote:
> About the problem Markus is describing, and if he is using
> Thread.create as you suggest, I may see a cause.  Seeing that the code
> for caml_thread_new in posix.c contains no enter_blocking_section, if
> you create a thread with Thread.create, it will immediately block
> trying to get the caml mutex. It will get it eventually from the main
> caml thread through a yield, but a clever scheduler will schedule this
> thread on the same processor (it starts just when the previous one
> stops). As Markus says, after a long time the scheduler may realize
> this choice was wrong and change the processor, but this is scheduler
> dependent.
> 
> I may be utterly wrong in my inference, but if this is right, a better
> solution would be to explicitely start the thread with pthread_start
> from the C side.

Thanks, this seems to be a good explanation for the strange behaviour
of native threads under Solaris. Maybe another solution would be to
set different scheduler flags, but I haven't read up on this, since our
Solaris machines are going to be replaced by Linux ones at our place.

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
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

Re: [Caml-list] native threads not parallel?

[Shivkumar Chandrasekaran]

This seems to match the observed behavior on my machine. I could infer 
that the two threads were being executed in parallel; just not on 
different processors simultaneously. Thank you very much!!

On Friday, February 21, 2003, at 07:11 AM, Jacques Garrigue wrote:

> I see, after rereading carefully the original mail, I could understand
> what this is about.
>
> IIRC, the distinction is not between native code and bytecode, but
> between native threads and caml threads. You can use native threads in
> bytecode, and it should work also (but I might be wrong).
>
> About the problem Markus is describing, and if he is using
> Thread.create as you suggest, I may see a cause.  Seeing that the code
> for caml_thread_new in posix.c contains no enter_blocking_section, if
> you create a thread with Thread.create, it will immediately block
> trying to get the caml mutex. It will get it eventually from the main
> caml thread through a yield, but a clever scheduler will schedule this
> thread on the same processor (it starts just when the previous one
> stops). As Markus says, after a long time the scheduler may realize
> this choice was wrong and change the processor, but this is scheduler
> dependent.
>
> I may be utterly wrong in my inference, but if this is right, a better
> solution would be to explicitely start the thread with pthread_start
> from the C side.
>
> Jacques Garrigue
> -------------------
> 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
>
--shiv--

-------------------
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

Re: [Caml-list] native threads not parallel?

[Chris Uzdavinis]

Shivkumar Chandrasekaran <shiv@ece.ucsb.edu> writes:

> Not sure if this issue from an earlier discussion was fully resolved
> or not. But I seem to have the same problem as discussed by Markus
> Mottl (see attachment below) on Mac OS X 10.2.4 on a dual processor
> G4 machine. An earlier message in that thread mentioned that there
> was no such problem on dual-processor Linux machines.
> 
> I have two questions:
> 
> 1. Has anybody else figured out how to get parallelism using native
> threads on Mac OS X?
> 
> 2. Will I get the parallelism if I switch to LinuxPPC?

Here's the best/most detailed answer to your question that I've seen:
http://makeashorterlink.com/?P28725B83

...which expands to:
http://groups.google.com/groups?selm=fa.dlqoshv.1a66ho7%40ifi.uio.no&output=gplain

-- 
Chris

-------------------
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

Re: [Caml-list] native threads not parallel?

[james woodyatt]

On Thursday, Feb 20, 2003, at 16:32 US/Pacific, Chris Uzdavinis wrote:
>
> Here's the best/most detailed answer to your question that I've seen:
> <http://groups.google.com/ 
> groups?selm=fa.dlqoshv.1a66ho7%40ifi.uio.no&output=gplain>

On Mon, 25 Nov 2002 10:04:54 GMT, Xavier Leroy <xavier.leroy@inria.fr>  
wrote:
> It seems that the annual discussion on threads started again.  Allow
> me to deliver again my standard lecture on this topic.
>
> Threads have at least three different purposes:
>
> 1- Parallelism on shared-memory multiprocessors.
> 2- Overlapping I/O and computation (while a thread is blocked on a  
> network
>    read, other threads may proceed).
> 3- Supporting the "coroutine" programming style
>    (e.g. if a program has a GUI but performs long computations,
>     using threads is a nicer way to structure the program than
>     trying to wrap the long computation around the GUI event loop).
>
> The goals of OCaml threads are (2) and (3) but not (1) (for reasons
> that I'll get into later), with historical emphasis on (2) due to the
> MMM (Web browser) and V6 (HTTP proxy) applications.
> [...]
> In summary: there is no SMP support in OCaml, and it is very very
> unlikely that there will ever be.  If you're into parallelism, better
> investigate message-passing interfaces.

And I'm not sure that (2) is better done with threads and shared memory  
than with message passing and processes-- especially if you've a got a  
good solution for just doing (3) with a userland continuation  
scheduler.  (Now that I've learned a few more things about FP, I'm  
working on another pass at this that will hopefully not suck wind like  
my previous offering did.)

If you have a good userland scheduler, i.e. something that just throws  
around continuations in a reasonable way, and you're willing to go to  
message passing to get overlapping I/O and computation, then you can  
get parallelism on MP machines by just passing messages around between  
processes in the kernel.

However, I can think of a fourth purpose for SMP support: to permit  
OCaml functions to be usable as plugins to multi-threaded application  
programming frameworks in other languages, e.g. C, C++, Obj-C, Java,  
C#, etc. without having to make the OCaml runtime environment a  
critical section for every thread in the application.  I'm hard pressed  
to think of a good example where this might be worth doing, though...

Personally, I'm happy to continue expecting to get parallelism from  
message passing between distributed processes.  Fifteen years of coding  
under VxWorks (and Solaris with POSIX threads) has cured me of the  
desire for more preemptive multithreading with shared memory.


-- 
j h woodyatt <jhw@wetware.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

Re: [Caml-list] native threads not parallel?

[shivkumar chandrasekaran]

Thanks, I was aware of that email. My question was really much more
restrictive. I am only trying to run C-code in parallel. Of course the
C-code (with no callbacks) is being called from caml. Please see Markus'
message which my first email referred to.

Thanks,

--shiv--


On Thu, 2003-02-20 at 16:32, Chris Uzdavinis wrote:
> Shivkumar Chandrasekaran <shiv@ece.ucsb.edu> writes:
> 
> > Not sure if this issue from an earlier discussion was fully resolved
> > or not. But I seem to have the same problem as discussed by Markus
> > Mottl (see attachment below) on Mac OS X 10.2.4 on a dual processor
> > G4 machine. An earlier message in that thread mentioned that there
> > was no such problem on dual-processor Linux machines.
> > 
> > I have two questions:
> > 
> > 1. Has anybody else figured out how to get parallelism using native
> > threads on Mac OS X?
> > 
> > 2. Will I get the parallelism if I switch to LinuxPPC?
> 
> Here's the best/most detailed answer to your question that I've seen:
> http://makeashorterlink.com/?P28725B83
> 
> ...which expands to:
> http://groups.google.com/groups?selm=fa.dlqoshv.1a66ho7%40ifi.uio.no&output=gplain
> 
> -- 
> Chris
> 
-- 
Professor Shivkumar Chandrasekaran            || phn: 805.893.7542
Electrical & Computer Engineering Department  || fax: 805.893.3262
University of California                      || Office: 3109, Eng. I
Santa Barbara, CA 93106-9560                  || email:
shiv@ece.ucsb.edu

-------------------
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