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 is a
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 of
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 work on a
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.
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 synchronization
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
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
On 1/13/12 1:24 PM, Robert Kern wrote:
On Fri, Jan 13, 2012 at 21:20, Langton, Asher langt...@llnl.gov 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
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 probably would,
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
how
On Fri, Jan 13, 2012 at 21:42, Sturla Molden stu...@molden.no 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!
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 mistake
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_final.pdf
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.
14 matches
Mail list logo
