On 01/14/2012 12:28 AM, Sturla Molden wrote:
> Den 13.01.2012 22:42, skrev Sturla Molden:
>> Den 13.01.2012 22:24, skrev Robert Kern:
>>> Do these systems have a ramdisk capability?
>> I assume you have seen this as well :)
>>
>> http://www.cs.uoregon.edu/Research/paracomp/papers/iccs11/iccs_paper_
Den 13.01.2012 22:42, skrev Sturla Molden:
> Den 13.01.2012 22:24, skrev Robert Kern:
>> Do these systems have a ramdisk capability?
> I assume you have seen this as well :)
>
> http://www.cs.uoregon.edu/Research/paracomp/papers/iccs11/iccs_paper_final.pdf
>
This paper also repeats a common mistak
On Fri, Jan 13, 2012 at 21:42, Sturla Molden wrote:
> Den 13.01.2012 22:24, skrev Robert Kern:
>> Do these systems have a ramdisk capability?
>
> I assume you have seen this as well :)
>
> http://www.cs.uoregon.edu/Research/paracomp/papers/iccs11/iccs_paper_final.pdf
I hadn't, actually! Good find
On 1/13/12 1:58 PM, Dag Sverre Seljebotn wrote:
>
>It's actually not too difficult to do something like
>
>LD_PRELOAD=myhack.so python something.py
>
>and have myhack.so intercept the filesystem calls Python makes (to libc)
>and do whatever it wants. That's a solution that doesn't interfer with
>ho
On 01/13/2012 10:20 PM, Langton, Asher wrote:
> On 1/13/12 12:38 PM, Sturla Molden wrote:
>> Den 13.01.2012 21:21, skrev Dag Sverre Seljebotn:
>>> Another idea: Given your diagnostics, wouldn't dumping the output of
>>> "find" of every path in sys.path to a single text file work well?
>>
>> It prob
On 1/13/12 1:24 PM, Robert Kern wrote:
>On Fri, Jan 13, 2012 at 21:20, Langton, Asher wrote:
>
>> 2) More generally, dealing with this as well as other library-loading
>> issues at the system level, perhaps by putting a small disk near a node
>>or
>> small collection of nodes, along with a command
It is a straightforward thing to implement a "registry mechanism" for Python
that by-passes imp.find_module (i.e. using sys.meta_path). You could imagine
creating the registry file for a package or distribution (much like Dag
described) and push that to every node during distribution.
The
Den 13.01.2012 22:24, skrev Robert Kern:
> Do these systems have a ramdisk capability?
I assume you have seen this as well :)
http://www.cs.uoregon.edu/Research/paracomp/papers/iccs11/iccs_paper_final.pdf
Sturla
___
NumPy-Discussion mailing list
NumP
On Fri, Jan 13, 2012 at 21:20, Langton, Asher wrote:
> 2) More generally, dealing with this as well as other library-loading
> issues at the system level, perhaps by putting a small disk near a node or
> small collection of nodes, along with a command to push (broadcast) some
> portions of the fi
On 1/13/12 12:38 PM, Sturla Molden wrote:
>Den 13.01.2012 21:21, skrev Dag Sverre Seljebotn:
>> Another idea: Given your diagnostics, wouldn't dumping the output of
>> "find" of every path in sys.path to a single text file work well?
>
>It probably would, and would also be less prone to synchroniza
Den 13.01.2012 21:21, skrev Dag Sverre Seljebotn:
> Another idea: Given your diagnostics, wouldn't dumping the output of
> "find" of every path in sys.path to a single text file work well?
It probably would, and would also be less prone to synchronization
problems than using an MPI broadcast. Ano
On 01/13/2012 09:19 PM, Dag Sverre Seljebotn wrote:
> On 01/13/2012 02:13 AM, Asher Langton wrote:
>> Hi all,
>>
>> (I originally posted this to the BayPIGgies list, where Fernando Perez
>> suggested I send it to the NumPy list as well. My apologies if you're
>> receiving this email twice.)
>>
>> I
On 01/13/2012 02:13 AM, Asher Langton wrote:
> Hi all,
>
> (I originally posted this to the BayPIGgies list, where Fernando Perez
> suggested I send it to the NumPy list as well. My apologies if you're
> receiving this email twice.)
>
> I work on a Python/C++ scientific code that runs as a number o
On Fri, Jan 13, 2012 at 19:41, Sturla Molden wrote:
> Den 13.01.2012 02:13, skrev Asher Langton:
>> intern try a few of these approaches. It turned out that the problem
>> wasn't so much the simultaneous module loads, but rather the huge
>> number of failed open() calls (ENOENT) as the interpreter
Den 13.01.2012 02:13, skrev Asher Langton:
> intern try a few of these approaches. It turned out that the problem
> wasn't so much the simultaneous module loads, but rather the huge
> number of failed open() calls (ENOENT) as the interpreter tries to
> find the module files.
It sounds like there i
Hi all,
(I originally posted this to the BayPIGgies list, where Fernando Perez
suggested I send it to the NumPy list as well. My apologies if you're
receiving this email twice.)
I work on a Python/C++ scientific code that runs as a number of
independent Python processes communicating via MPI. Unf
16 matches
Mail list logo
