From rjvbertin at gmail.com  Fri Oct 20 16:11:11 2006
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J.V._Bertin?=)
Date: Fri, 20 Oct 2006 16:11:11 +0200
Subject: [Rd] [R] multithreading calling from the rpy Python package
In-Reply-To: <F722604B-31E6-43B0-B215-3E3CCB96780F@r-project.org>
References: <797664590610120908k3f8090d4p61a850cf6be60ccc@mail.gmail.com>
	<452E7095.40804@wald.ucdavis.edu>
	<797664590610121012g430c58f1x91756c2437e7510d@mail.gmail.com>
	<F722604B-31E6-43B0-B215-3E3CCB96780F@r-project.org>
Message-ID: <797664590610200711w46a60957s44cd805ea7909a5b@mail.gmail.com>

Since Python has been mentioned in this context: Could not Python's
threading model and implementation serve as a guideline?

>From a few simple benchmarks I've run, it seems as if the Python
interpreter itself is thread-safe but not threadable. That is, when I
run something "pure Python" like a recursive function that returns the
nth Fibonacci number in parallel, there is no speed-up for 2 threads
on a dual-processor machine. However, calling sleep in parallel does
scale down with the number of threads, even on a single-processor ;)

Real-life code does tend to speed up somewhat, though never as much as
one would hope.

Just an idea...

Ren?




[Rd] [R] multithreading calling from the rpy Python package
=?ISO-8859-1?Q?Ren=E9_J.V._Bertin?=