"Paul Boddie" <[EMAIL PROTECTED]> writes:
> What makes all of the following not "Pythonic"...?
> http://wiki.python.org/moin/ParallelProcessing
I'd say mainly that they don't allow sharing data between processes
except through expensive IPC mechanisms involving system calls.
> I'm sure one could
On 8 Mar, 10:48, Bryan Olson <[EMAIL PROTECTED]> wrote:
>
> That doesn't really work in Python. There have been projects to
> allow Pythonic coordination of processes -- POSH had some good
> ideas -- but none have reached fruition.
What makes all of the following not "Pythonic"...?
http://wiki.py
sturlamolden wrote:
[...]
> If you want to utilize the computing power of multiple CPUs, you
> should use multiple processes instead of threads. On Python this is
> mandatory due to the GIL. In any other language it it highly
> recommended. The de-factor standard for parallel multiprocessing (MPI)
Carl J. Van Arsdall wrote:
> Not necessarily, if he's on a full duplex ethernet connection,
> then there is some parallelity he can take advantage of. He has
> upstream and downstream.
Partly agreed. There is one bus to the network device, and CPU
should be very much faster than the network devi
On Feb 9, 4:00 pm, "S.Mohideen" <[EMAIL PROTECTED]>
wrote:
> I am sorry if I sound foolish.
> Suppose I split my Net application code using parallel python into several
> processes based upon the number of CPU available. That means a single socket
> descriptor is distributed across all processes.
"S.Mohideen" <[EMAIL PROTECTED]> writes:
> Suppose I split my Net application code using parallel python into
> several processes based upon the number of CPU available. That means a
> single socket descriptor is distributed across all processes. Is
> parallelity can be acheived using the processes
the single socket multiplexed
across all the processes.. I haven't tried it yet - would like to have any
past experience related to this.
- Original Message -
From: "Carl J. Van Arsdall" <[EMAIL PROTECTED]>
To:
Sent: Thursday, February 08, 2007 3:44 PM
Subjec
Bjoern Schliessmann wrote:
> [snip]
> What makes you think that'll be faster?
>
> Remember:
> - If you have one CPU, there is no parallelity at all.
> - If you do have multiple CPUs but only one network device, there is
> no parallel networking.
>
>
Not necessarily, if he's on a full duplex ethe
S.Mohideen wrote:
> There is a dictionary on which I store/read data values. I want to
> seperate the send and recv functionality on two different
> processes so that the parallel execution becomes fast.
What makes you think that'll be faster?
Remember:
- If you have one CPU, there is no paralle
S.Mohideen wrote:
> I would like to add my problem in this thread.
> I have a network application in Python which sends and recv using a single
> socket.
> There is a dictionary on which I store/read data values. I want to seperate
> the send and recv functionality on two different processes so t
Sergei Organov" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, February 07, 2007 1:03 PM
Subject: Re: multithreading concept
> "sturlamolden" <[EMAIL PROTECTED]> writes:
>> On Feb 7, 6:17 pm, John Nagle <[EMAIL PROTECTED]> wrote:
> [...]
>> MPI
Paul Boddie wrote:
> [snip]
>
> Take a look at the Python Wiki for information on parallel processing
> with Python:
>
> http://wiki.python.org/moin/ParallelProcessing
>
What a great resource! That one is book marked for sure. I was
wondering if anyone here had any opinions on some of the tec
On Feb 7, 8:03 pm, Sergei Organov <[EMAIL PROTECTED]> wrote:
> I fail to see how threads in general could perform worse than
> processes. I do understand that processes are inherently more
> safe/secure, but when it comes to speed I really can't imagine why it
> could happen that threads perform w
"sturlamolden" <[EMAIL PROTECTED]> writes:
> On Feb 7, 6:17 pm, John Nagle <[EMAIL PROTECTED]> wrote:
[...]
> MPI does not use threads on SMPs because it performs worse than using
> multiple processes.
I fail to see how threads in general could perform worse than
processes. I do understand that pr
On Feb 7, 6:17 pm, John Nagle <[EMAIL PROTECTED]> wrote:
> Multithread compute-bound programs on multiple CPUs are
> how you get heavy number-crunching work done on multiprocessors.
In the scientific community, heavy CPU-bound tasks are either
parallelized using MPI and/or written in Fortran
John Nagle wrote:
> sturlamolden wrote:
>> On Feb 7, 2:53 am, "S.Mohideen" <[EMAIL PROTECTED]>
>> wrote:
>> This has been discussed to death before. Win32 threads and pthreads
>> (which is what Python normally uses, depending on the platform) are
>> designed to stay idle most of the time. They are
sturlamolden wrote:
> On Feb 7, 2:53 am, "S.Mohideen" <[EMAIL PROTECTED]>
> wrote:
> This has been discussed to death before. Win32 threads and pthreads
> (which is what Python normally uses, depending on the platform) are
> designed to stay idle most of the time. They are therefore not a tool
> fo
On 7 Feb, 02:53, "S.Mohideen" <[EMAIL PROTECTED]>
wrote:
>
> Python is praised about - me too. But at one instance it fails. It fails to
> behave as a true multi-threaded application. That means utilizing all the
> CPUs parallely in the SMP efficiently stays as a dream for a Python
> Programmer.
T
On Feb 7, 2:53 am, "S.Mohideen" <[EMAIL PROTECTED]>
wrote:
> Python is praised about - me too. But at one instance it fails. It fails to
> behave as a true multi-threaded application. That means utilizing all the
> CPUs parallely in the SMP efficiently stays as a dream for a Python
> Programmer.
On Feb 7, 1:53 am, "S.Mohideen" <[EMAIL PROTECTED]>
wrote:
> Hi Folks,
>
> Python is praised about - me too. But at one instance it fails. It fails to
> behave as a true multi-threaded application. That means utilizing all the
> CPUs parallely in the SMP efficiently stays as a dream for a Python
>
20 matches
Mail list logo
