On 6/27/08 8:53AM , "Laurent Gautier" <[EMAIL PROTECTED]> wrote:
> There should definitely be a way to enforce one communication at a time.
>
> Having a thread master that conducts communications with an R process
> would be helpful in helping someone build a multi-threaded application.
>
>
There should definitely be a way to enforce one communication at a time.
Having a thread master that conducts communications with an R process
would be helpful in helping someone build a multi-threaded application.
What I am wondering is whether this should be the default mode of operation
(as it
Hi to all
I am working on Geostatistics and WPS and I was using Rpy to access
Gstat and run geostatistics interpolations. This was working fine but R
only runs on one core so things where going very slowly. So I looked at
several possibilities and the best was RSOAP.
My current system makes
Hi Laurent,
It does seem desirable to include an component with Rpy for handling
multi-threading and R. We should think a bit about the right way to
implement this. I think it would be good to make sure and use an code
implementation that is a good match for the right conceptual model. To this
e
Several years ago I used Rpy plus RPVM to distributed R computations across
multiple processing nodes (inluding multiple CPU¹s on a single Sun SMP
server), so this should work OK. Note, however, that requires
writing/utilizing code that has been explicitly parallelized.
-Greg
On 6/26/08 12:29P
Side note: I developed the RSOAP package to allow a single multi-threaded
python application to interact with multiple independent R processes
cleanly. Take a look at http://rsoap.sourceforge.net or
http://sourceforge.net/projects/rsoap/
-Greg
On 6/26/08 11:17AM , "laurent oget" <[EMAIL PROTE
I think that Rmpi creates processes and passes messages between them.
It *should* work without problems with rpy.
Although, two threads worth a look at:
https://stat.ethz.ch/pipermail/r-devel/2006-October/043218.html
http://tolstoy.newcastle.edu.au/R/e3/devel/07/11/0291.html
2008/6/26 Sean D
On Thu, Jun 26, 2008 at 12:05 PM, Laurent Gautier <[EMAIL PROTECTED]> wrote:
> yes.
Unless you use a package like Rmpi. I have NO idea how that would
work with Rpy, but it is another possibility. Also, I think there has
been some work to vectorize the math libraries.
Sean
> 2008/6/26 laurent o
yes.
2008/6/26 laurent oget <[EMAIL PROTECTED]>:
> So if I want to take advantage of my two cores, i need two processes, right?
>
> 2008/6/26 Gregory Warnes <[EMAIL PROTECTED]>:
>>
>> Hello Laurent,
>>
>> The R system itself is not thread safe, and has quite a bit of persistent
>> state. Therefor
So if I want to take advantage of my two cores, i need two processes, right?
2008/6/26 Gregory Warnes <[EMAIL PROTECTED]>:
>
> Hello Laurent,
>
> The R system itself is *not* thread safe, and has quite a bit of
> persistent state. Therefore if you want to use R from multiple threads, you
> will
Speaking of which, it would be nice if rpy was shipped with a vanilla
locking mechanism.
R remaining probably thread-unsafe for the foreseeable future, I was
thinking of having something
like a two-locks mechanism that would lock R and release Python's GIL
whenever an access to R is made.
The exp
Hello Laurent,
The R system itself is not thread safe, and has quite a bit of persistent
state. Therefore if you want to use R from multiple threads, you will need
to arrange to have a single thread interact with R at a time via appropriate
locking or delegation.
-G
On 6/26/08 11:17AM , "lau
fellows,
did anybody experiment with running rpy in 2 threads?
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/b
13 matches
Mail list logo
