Re: Will Python 3.0 remove the global interpreter lock (GIL)

Ben Finney a écrit : (snip) > One common response to that is "Processes are expensive on Win32". My > response to that is that if you're programming on Win32 and expecting > the application to scale well, you already have problems that must > first be addressed that are far more fundamental than th

Re: Will Python 3.0 remove the global interpreter lock (GIL)

"Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message news:[EMAIL PROTECTED] | It does sound like removing the GIL from CPython would have very high | costs in more than one area. Is my hope that Python will transition | from CPython to PyPy overoptimistic? I presume you mean 'will the

Re: Will Python 3.0 remove the global interpreter lock (GIL)

"Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message news:[EMAIL PROTECTED] | funding into PyPy development, since I think I saw something about the | EU funding being interrupted. As far as I know, the project was completed and promised funds paid. But I don't know of any major foll

Re: Will Python 3.0 remove the global interpreter lock (GIL)

"Chris Mellon" <[EMAIL PROTECTED]> writes: > > The compute intensive stuff (image rendering and crunching) has > > already had most of those skerricks pulled out. It is written in C > > and assembler > That means that this part is also unaffected by the GIL. Right, it was a counterexample against

Re: Will Python 3.0 remove the global interpreter lock (GIL)

"Chris Mellon" <[EMAIL PROTECTED]> writes: > No. Python has threads, and they're wrappers around true OS level > system threads. What the GIL does is prevent *Python* code in those > threads from running concurrently. Well, C libraries can release the GIL if they are written for thread safety, but

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On 20 Sep 2007 07:43:18 -0700, Paul Rubin <"http://phr.cx"@nospam.invalid> wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: > > That's why your "comparatively wimpy site" preferred to throw extra web > > servers at the job of serving webpages rather than investing in smarter, > > harder-working

Re: Will Python 3.0 remove the global interpreter lock (GIL)

Steven D'Aprano <[EMAIL PROTECTED]> writes: > That's why your "comparatively wimpy site" preferred to throw extra web > servers at the job of serving webpages rather than investing in smarter, > harder-working programmers to pull the last skerricks of performance out > of the hardware you alread

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On 2007-09-20, TheFlyingDutchman <[EMAIL PROTECTED]> wrote: > Is the only point in getting rid of the GIL to allow multi-threaded > applications? That's the main point. > Can't multiple threads also provide a performance boost versus > multiple processes on a single-core machine? That depends o

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On 9/19/07, TheFlyingDutchman <[EMAIL PROTECTED]> wrote: > On Sep 19, 5:08 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > > "Terry Reedy" <[EMAIL PROTECTED]> wrote in message > > This is a little confusing because google groups does not show your > original post (not uncommon for them to lose a pos

Re: Will Python 3.0 remove the global interpreter lock (GIL)

TheFlyingDutchman a écrit : (snip) > I am confused about the benefits/disadvantages of the "GIL removal". > Is it correct that the GIL is preventing CPython from having threads? > > Is it correct that the only issue with the GIL is the prevention of > being able to do multi-threading? http://doc

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On 20 Sep, 00:59, TheFlyingDutchman <[EMAIL PROTECTED]> wrote: > > Paul it's a pleasure to see that you are not entirely against > complaints. Well, it seems to me that I'm usually the one making them. ;-) > The very fastest Intel processor of the last 1990's that I found came > out in October 19

Re: Will Python 3.0 remove the global interpreter lock (GIL)

"Steven D'Aprano" <[EMAIL PROTECTED]> wrote: > > I think a better question is, how much faster/slower would Stein's code > be on today's processors, versus CPython being hand-simulated in a giant > virtual machine made of clockwork? This obviously depends on whether or not the clockwork is o

Re: Will Python 3.0 remove the global interpreter lock (GIL)

2 On Sep 19, 5:08 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > "Terry Reedy" <[EMAIL PROTECTED]> wrote in message > > > This assumes that comparing versions of 1.5 is still relevant. As far as I > know, his patch has not been maintained to apply against current Python. > This tells me that no

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Sep 19, 5:08 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > "Terry Reedy" <[EMAIL PROTECTED]> wrote in message This is a little confusing because google groups does not show your original post (not uncommon for them to lose a post in a thread - but somehow still reflect the fact that it exists

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Sep 19, 8:54 pm, Steven D'Aprano <[EMAIL PROTECTED] cybersource.com.au> wrote: > On Wed, 19 Sep 2007 19:14:39 -0700, Paul Rubin wrote: > > > etc. is at best an excuse for laziness. > > What are you doing about solving the problem? Apart from standing on the > side-lines calling out "Get yer la

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Wed, 19 Sep 2007 19:14:39 -0700, Paul Rubin wrote: > We get cpu speed increases now through parallelism, not mhz. Intel and > AMD both have 4-core cpu's now and Intel has a 16-core chip coming. > Python is at a serious disadvantage compared with other languages if the > other languages keep u

Re: Will Python 3.0 remove the global interpreter lock (GIL)

TheFlyingDutchman <[EMAIL PROTECTED]> writes: > The very fastest Intel processor of the last 1990's that I found came > out in October 1999 and had a speed around 783Mhz. Current fastest > processors are something like 3.74 Ghz, with larger caches. Memory is > also faster and larger. It appears tha

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Wed, 19 Sep 2007 15:59:59 -0700, TheFlyingDutchman wrote: > Paul it's a pleasure to see that you are not entirely against > complaints. I'm not against complaints either, so long as they are well-thought out. I've made a few of my own over the years, some of which may have been less well-tho

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Wed, 19 Sep 2007 11:07:48 -0700, TheFlyingDutchman wrote: > On Sep 19, 8:51 am, Steven D'Aprano <[EMAIL PROTECTED] > cybersource.com.au> wrote: >> On Tue, 18 Sep 2007 18:09:26 -0700, TheFlyingDutchman wrote: >> > How much faster/slower would Greg Stein's code be on today's >> > processors versu

Re: Will Python 3.0 remove the global interpreter lock (GIL)

"Terry Reedy" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | | "TheFlyingDutchman" <[EMAIL PROTECTED]> wrote in message | news:[EMAIL PROTECTED] | Since Guido wrote that, there have been put forth more ideas and interest | and promises of efforts to remove or revise the GIL or do

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Sep 19, 3:41 pm, Paul Boddie <[EMAIL PROTECTED]> wrote: > On 19 Sep, 03:09, TheFlyingDutchman <[EMAIL PROTECTED]> wrote: > > > > > How much faster/slower would Greg Stein's code be on today's > > processors versus CPython running on the processors of the late > > 1990's? And if you decide to ans

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On 19 Sep, 03:09, TheFlyingDutchman <[EMAIL PROTECTED]> wrote: > > How much faster/slower would Greg Stein's code be on today's > processors versus CPython running on the processors of the late > 1990's? And if you decide to answer, please add a true/false response > to this statement - "CPython in

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Sep 19, 8:51 am, Steven D'Aprano <[EMAIL PROTECTED] cybersource.com.au> wrote: > On Tue, 18 Sep 2007 18:09:26 -0700, TheFlyingDutchman wrote: > > How much faster/slower would Greg Stein's code be on today's processors > > versus CPython running on the processors of the late 1990's? > > I think a

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Tue, 18 Sep 2007 18:09:26 -0700, TheFlyingDutchman wrote: > How much faster/slower would Greg Stein's code be on today's processors > versus CPython running on the processors of the late 1990's? I think a better question is, how much faster/slower would Stein's code be on today's processors,

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On 2007-09-19, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > On Tue, 18 Sep 2007 18:09:26 -0700, TheFlyingDutchman wrote: > >> How much faster/slower would Greg Stein's code be on today's >> processors versus CPython running on the processors of the >> late 1990's? > > I think a better question is,

Re: Will Python 3.0 remove the global interpreter lock (GIL)

"TheFlyingDutchman" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | On Sep 2, 5:38 pm, "Eduardo O. Padoan" <[EMAIL PROTECTED]> | wrote: | > > No.http://www.artima.com/weblogs/viewpost.jsp?thread=211430 | > | > Ops, I meant:http://www.artima.com/forums/threaded.jsp?forum=106&thread=

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Sep 2, 5:38 pm, "Eduardo O. Padoan" <[EMAIL PROTECTED]> wrote: > > No.http://www.artima.com/weblogs/viewpost.jsp?thread=211430 > > Ops, I meant:http://www.artima.com/forums/threaded.jsp?forum=106&thread=211200 > > --http://www.advogato.org/person/eopadoan/ > Bookmarks:http://del.icio.us/edcrypt

Re: Will Python 3.0 remove the global interpreter lock (GIL)

I was wondering (and maybe i still do) about this GIL "problem". I am relatively new to Python (less than a year) and when i started to think about it i said: "Oh, this IS a problem". But when i dig a little more, i found that "Ah, maybe it isn't". I strongly believe that the best usage of multiple

Re: Will Python 3.0 remove the global interpreter lock (GIL)

I was wondering (and maybe i still do) about this GIL "problem". I am relatively new to Python (less than a year) and when i started to think about it i said: "Oh, this IS a problem". But when i dig a little more, i found that "Ah, maybe it isn't". I strongly believe that the best usage of multiple

Re: Will Python 3.0 remove the global interpreter lock (GIL)

I was wondering (and maybe i still do) about this GIL "problem". I am relatively new to Python (less than a year) and when i started to think about it i said: "Oh, this IS a problem". But when i dig a little more, i found that "Ah, maybe it isn't". I strongly believe that the best usage of multiple

Re: Will Python 3.0 remove the global interpreter lock (GIL)

Michele Simionato <[EMAIL PROTECTED]> writes: > On Sep 3, 2:21 am, llothar <[EMAIL PROTECTED]> wrote: > > I'm afraid that the GIL is killing the usefullness of python for > > some types of applications now where 4,8 oder 64 threads on a chip > > are here or comming soon. > > This is FAQ. You will

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Sep 3, 9:15 am, Michele Simionato <[EMAIL PROTECTED]> wrote: > On Sep 3, 2:21 am, llothar <[EMAIL PROTECTED]> wrote: > > My personal opinion (and I am not the only one in the Python > community) is that > if you want to scale the way to go is to use processes, not threads, > so removing the GIL

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Sep 3, 2:21 am, llothar <[EMAIL PROTECTED]> wrote: > I'm afraid that the GIL is killing the usefullness of python for some > types of applications now where 4,8 oder 64 threads on a chip are here > or comming soon. > > What is the status about that for the future of python? This is FAQ. You wil

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Sun, 2007-09-02 at 17:21 -0700, llothar wrote: > I'm afraid that the GIL is killing the usefullness of python for some > types of applications now where 4,8 oder 64 threads on a chip are here > or comming soon. > > What is the status about that for the future of python? The GIL is an implement

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On Sep 2, 11:16 pm, llothar <[EMAIL PROTECTED]> wrote: > On 3 Sep., 07:38, "Eduardo O. Padoan" <[EMAIL PROTECTED]> > wrote: > > > > No.http://www.artima.com/weblogs/viewpost.jsp?thread=211430 > > > Ops, I > > meant:http://www.artima.com/forums/threaded.jsp?forum=106&thread=211200 > > Thanks. I whi

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On 3 Sep., 07:38, "Eduardo O. Padoan" <[EMAIL PROTECTED]> wrote: > > No.http://www.artima.com/weblogs/viewpost.jsp?thread=211430 > > Ops, I meant:http://www.artima.com/forums/threaded.jsp?forum=106&thread=211200 > Thanks. I whish there would be a project for rewritting the C interpreter to make it

Re: Will Python 3.0 remove the global interpreter lock (GIL)

> No. http://www.artima.com/weblogs/viewpost.jsp?thread=211430 Ops, I meant: http://www.artima.com/forums/threaded.jsp?forum=106&thread=211200 -- http://www.advogato.org/person/eopadoan/ Bookmarks: http://del.icio.us/edcrypt -- http://mail.python.org/mailman/listinfo/python-list

Re: Will Python 3.0 remove the global interpreter lock (GIL)

On 9/2/07, llothar <[EMAIL PROTECTED]> wrote: > I'm afraid that the GIL is killing the usefullness of python for some > types of applications now where 4,8 oder 64 threads on a chip are here > or comming soon. > > What is the status about that for the future of python? > > I know that at the moment

Will Python 3.0 remove the global interpreter lock (GIL)

I'm afraid that the GIL is killing the usefullness of python for some types of applications now where 4,8 oder 64 threads on a chip are here or comming soon. What is the status about that for the future of python? I know that at the moment allmost nobody in the scripting world has solved this pro

Regular expressions and the global interpreter lock

Hi, I have encountered a problem with the re module. I have a multi-threaded program that does lots of regular expression searching, with some relatively complex regular expressions. Occasionally, events can conspire to mean that the re search takes minutes. That's bad enough in and of itself, but

Re: global interpreter lock

Thanks, PyThread_release_lock() is implemented in all thread_xxx.h files. So I thought right but specified my question like a stupid ;) //T -- http://mail.python.org/mailman/listinfo/python-list

Re: global interpreter lock

[EMAIL PROTECTED] wrote: >I just need confirmation that I think right. > >Is the files thread_xxx.h (xxx = nt, os2 or whatever) responsible for >the >global interpreter lock in a multithreaded environment? > >I'm currently writing my own thread_VW for VxWorks, thats wh

global interpreter lock

I just need confirmation that I think right. Is the files thread_xxx.h (xxx = nt, os2 or whatever) responsible for the global interpreter lock in a multithreaded environment? I'm currently writing my own thread_VW for VxWorks, thats why I'm asking. //Tommy -- http://mail.python.o

Re: global interpreter lock

Michele Simionato wrote: > It looks like I am reinventing Twisted and/or Kamaelia. If it's /fun/ , is that a problem ? ;) (Interesting implementation BTW :) FWIW, I've about a year ago it wasn't clear if we would be able to release our stuff, so as part of a presentation I included a minimalisti

Re: global interpreter lock

It looks like I am reinventing Twisted and/or Kamelia. This is code I wrote just today to simulate Python 2.5 generator in current Python: import Queue class coroutine(object): def __init__(self, *args, **kw): self.queue = Queue.Queue() self.it = self.__cor__(*args, **kw)

Re: global interpreter lock

Stephen Thorne wrote: > On 15/09/05, Michael Sparks <[EMAIL PROTECTED]> wrote: >> At the moment, one option that springs to mind is this: >> yield WaitDataAvailable("inbox") > > Twisted supports this. > > help("twisted.internet.defer.waitForDeferred") Thanks for this. I'll take a look and e

Re: global interpreter lock

On 15/09/05, Michael Sparks <[EMAIL PROTECTED]> wrote: > At the moment, one option that springs to mind is this: > yield WaitDataAvailable("inbox") Twisted supports this. help("twisted.internet.defer.waitForDeferred") example usage is: @deferredGenerator def thingummy(): thing = waitForDe

Re: global interpreter lock

[ Second time lucky... ] Paul Rubin wrote: ... > I don't see how generators substitute for microthreads. In your example > from another post: I've done some digging and found what you mean by microthreads - specifically I suspect you're referring to the microthreads package for stackless? (I tend

Re: global interpreter lock

arrgh... hit wrong keystroke which caused an early send before I'd finished typing... (skip the message I'm replying to hear for a minute please :-) Michael. -- http://mail.python.org/mailman/listinfo/python-list

Re: global interpreter lock

Paul Rubin wrote: ... > I don't see how generators substitute for microthreads. In your example > from another post: I've done some digging and found what you mean by microthreads - specifically I suspect you're referring to the microthreads package for stackless? (I tend to view an activated gen

Re: global interpreter lock

Michael Sparks <[EMAIL PROTECTED]> writes: > > But I think to do it on Erlang's scale, Python needs user-level > > microthreads and not just OS threads. > > You've just described Kamaelia* BTW, except substitute micro-thread > with generator :-) (Also we call the queues outboxes and inboxes, and

Re: global interpreter lock

Dennis Lee Bieber <[EMAIL PROTECTED]> writes: > On Wed, 31 Aug 2005 22:44:06 -0400, Mike Meyer <[EMAIL PROTECTED]> declaimed > the following in comp.lang.python: >> I don't know what Ada offers. Java gives you pseudo-monitors. I'm > > From the days of mil-std 1815, Ada has supported "tasks" w

Re: global interpreter lock

Mike Meyer wrote: > Bryan Olson writes: >>With Python threads/queues how do I wait for two queues (or >>locks or semaphores) at one call? (I know some methods to >>accomplish the same effect, but they suck.) > > By "not as good as", I meant the model they provide isn't as managable > as the

Re: global interpreter lock

Bryan Olson <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: > > Bryan Olson writes: > >>System support for threads has advanced far beyond what Mr. Meyer > >>dealt with in programming the Amiga. > > > > I don't think it has - but see below. > > > >>In industry, the two major camps are Posix

Re: global interpreter lock

Dennis Lee Bieber wrote: > Well, at that point, you could substitute "waiting on a queue" with > "waiting on a socket" and still have the same problem -- regardless of > the nature of the language/libraries for threading; it's a problem with > the design of the classes as applied to a thre

Re: global interpreter lock

Dennis Lee Bieber wrote: > On Thu, 01 Sep 2005 06:15:38 GMT, Bryan Olson <[EMAIL PROTECTED]> > declaimed the following in comp.lang.python: >>With Python threads/queues how do I wait for two queues (or > > Why have two queues? Use one queue and tag the items with the > sender's "id" (or retu

Re: global interpreter lock

Mike Meyer <[EMAIL PROTECTED]> writes: > > Sure. I tried to be helpful there, but maybe I need to be more > > specific. The ref from my previous post, Google-able as "The > > C10K problem" is good but now a little dated. > > That appears to be a discussion on squeezing the most out of a network >

Re: global interpreter lock

Mike Meyer wrote: > Bryan Olson writes: >>System support for threads has advanced far beyond what Mr. Meyer >>dealt with in programming the Amiga. > > I don't think it has - but see below. > >>In industry, the two major camps are Posix threads, and Microsoft's >>Win32 threads (on NT or bett

Re: global interpreter lock

Bryan Olson <[EMAIL PROTECTED]> writes: > Bengt Richter wrote: > > Bryan Olson wrote: > >>For a long time, > >>the most sophisticated software services generally have used > >>multiple lines of execution, and now that's mostly in the form > >>of threads. No one actually disagrees, but they go

Re: global interpreter lock

Bengt Richter wrote: > Bryan Olson wrote: >>For a long time, >>the most sophisticated software services generally have used >>multiple lines of execution, and now that's mostly in the form >>of threads. No one actually disagrees, but they go right on >>knocking the modern methods. > > I th

Re: global interpreter lock

phil hunt wrote: > Some times concurrency is the best (or only) way to do a job. Other > times, it's more trouble than its worth. A good programmer will know > which is which, and will not use an overly complex solution for the > project he is writing. Also, a good programmer won't conflate concur

Re: global interpreter lock

[EMAIL PROTECTED] (Bengt Richter) writes: > On Tue, 30 Aug 2005 05:15:34 GMT, Bryan Olson <[EMAIL PROTECTED]> wrote: >>Mike Meyer wrote: >> > Bryan Olson <[EMAIL PROTECTED]> writes: >> >> > Bryan Olson writes: >> >> > Trivially, an 'if' statement that depends upon input >> >> >>data is statically p

Re: global interpreter lock

On Tue, 30 Aug 2005 05:15:34 GMT, Bryan Olson <[EMAIL PROTECTED]> wrote: >Mike Meyer wrote: > > Bryan Olson <[EMAIL PROTECTED]> writes: > >> > Bryan Olson writes: > >> > Trivially, an 'if' statement that depends upon input > >> >>data is statically predictable. Use of async I/O means makes the > >

Re: global interpreter lock

On Sun, 28 Aug 2005 19:25:55 -0400, Mike Meyer <[EMAIL PROTECTED]> wrote: >Bryan Olson <[EMAIL PROTECTED]> writes: >> phil hunt wrote: >> > Yes, find solutions. Don't find dangerous dead-ends that look like >> > solutions but which will give you lots of trouble. >> If concurrency is a dead end, w

Re: global interpreter lock

On Sun, 28 Aug 2005 20:34:07 GMT, Bryan Olson <[EMAIL PROTECTED]> wrote: >phil hunt wrote: > > Yes, find solutions. Don't find dangerous dead-ends that look like > > solutions but which will give you lots of trouble. > >If concurrency is a dead end, why do the programs that provide >the most sophis

Re: global interpreter lock

Mike Meyer wrote: > Bryan Olson <[EMAIL PROTECTED]> writes: >> > Bryan Olson writes: >> > Trivially, an 'if' statement that depends upon input >> >>data is statically predictable. Use of async I/O means makes the >> >>programs execution dependent upon external timing. >>Mike Meyer wrote: >>

Re: global interpreter lock

Bryan Olson <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: > > Bryan Olson writes: > > phil hunt wrote: > >> > What's important is *predictability*, e.g. which instruction will > >> > the computer execute next? > >> > If you only have one thread, you can tell by looking at the code > >> > wh

Re: global interpreter lock

Mike Meyer wrote: > Bryan Olson writes: > phil hunt wrote: > >> > What's important is *predictability*, e.g. which instruction will >> > the computer execute next? >> > >> > If you only have one thread, you can tell by looking at the code >> > what gets executed next. It's very simple. >>N

Re: global interpreter lock

Bryan Olson <[EMAIL PROTECTED]> writes: phil hunt wrote: > > What's important is *predictability*, e.g. which instruction will > > the computer execute next? > > > > If you only have one thread, you can tell by looking at the code > > what gets executed next. It's very simple. > Not really. Tr

Re: global interpreter lock

Piet van Oostrum wrote: >>Paul Rubin (PR) wrote: >>PR> Really, the essence of programming is to find ways of organizing the >>PR> program to stay reliable and maintainable in the face of that >>PR> combinatorial explosion. That means facing the problem and findin

Re: global interpreter lock

phil hunt wrote: > It's not the number of paths that's important. Absolutely right. Non-trivial software always has too many paths to consider them individually, so we have to reason generally. > What's important is *predictability*, e.g. which instruction will > the computer execute next? >

Re: global interpreter lock

> Paul Rubin (PR) wrote: >PR> [EMAIL PROTECTED] (phil hunt) writes: >>> >Let's see. Reality is that writing correct programs is hard. Writing >>> >correct programs that use concurrency is even harder, because of the >>> >exponential explosion of the order that operat

Re: global interpreter lock

Paul Rubin writes: > [EMAIL PROTECTED] (phil hunt) writes: >> >Let's see. Reality is that writing correct programs is hard. Writing >> >correct programs that use concurrency is even harder, because of the >> >exponential explosion of the order that operations can happen

Re: global interpreter lock

On 26 Aug 2005 14:35:03 -0700, Paul Rubin wrote: >[EMAIL PROTECTED] (phil hunt) writes: >> >Let's see. Reality is that writing correct programs is hard. Writing >> >correct programs that use concurrency is even harder, because of the >> >exponential explosion of the order

Re: global interpreter lock

[EMAIL PROTECTED] (phil hunt) writes: > >Let's see. Reality is that writing correct programs is hard. Writing > >correct programs that use concurrency is even harder, because of the > >exponential explosion of the order that operations can happen > >in. Personally, I'm willing to use anything I can

Re: global interpreter lock

On Thu, 25 Aug 2005 00:56:10 -0400, Mike Meyer <[EMAIL PROTECTED]> wrote: >> The issue here is whether to confuse reality with what one might >> wish reality to be. > >Let's see. Reality is that writing correct programs is hard. Writing >correct programs that use concurrency is even harder, because

Re: global interpreter lock

Mike Meyer wrote: > Bryan Olson <[EMAIL PROTECTED]> writes: > > The issue here is whether to confuse reality with what one might > > wish reality to be. > > Let's see. Reality is that writing correct programs is hard. Writing > correct programs that use concurrency is even harder, because of the >

Re: global interpreter lock

Bryan Olson <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: > > Bryan Olson writes: > >>Mike Meyer wrote: > >> > The rule I follow in choosing my tools is "Use the least complex tool > >> > that will get the job done." > >>Even if a more complex tool could do the job better? > > In that case,

Re: global interpreter lock

Mike Meyer wrote: > Bryan Olson writes: > >>Mike Meyer wrote: >> > The rule I follow in choosing my tools is "Use the least complex tool >> > that will get the job done." >> >>Even if a more complex tool could do the job better? > > In that case, the simpler model isn't necessarily getting

Re: global interpreter lock

Paul Rubin wrote: > Mike Meyer <[EMAIL PROTECTED]> writes: >> Even simpler to program in is the model used by Erlang. It's more CSP >> than threading, though, as it doesn't have shared memory as part of >> the model. But if you can use the simpler model to solve your problem >> - you probably shoul

Re: global interpreter lock

Dennis Lee Bieber <[EMAIL PROTECTED]> writes: > On Sat, 20 Aug 2005 22:30:43 -0400, Mike Meyer <[EMAIL PROTECTED]> declaimed > the following in comp.lang.python: >> with these issues. If I ever find myself having to have non-trivial >> threads again, I'll check the state of the threading models in

Re: global interpreter lock

Paul Rubin writes: > Mike Meyer <[EMAIL PROTECTED]> writes: >> Even simpler to program in is the model used by Erlang. It's more CSP >> than threading, though, as it doesn't have shared memory as part of >> the model. But if you can use the simpler model to solve your pro

Re: global interpreter lock

km wrote: > > is true parallelism possible in python ? or atleast in the coming versions ? > is global interpreter lock a bane in this context ? I've had absolutely zero problems implementing truly parallel programs in python. All of my parallel programs have been multiprocess

Re: global interpreter lock

Quoth Mike Meyer <[EMAIL PROTECTED]>: [... wandering from the nominal topic ...] | *) The most difficult task was writing horizontal microcode, which | also had serious concurrency issues in the form of device settling | times. I dealt with that by inventing a programming model that hid | most of

Re: global interpreter lock

Mike Meyer <[EMAIL PROTECTED]> writes: > Even simpler to program in is the model used by Erlang. It's more CSP > than threading, though, as it doesn't have shared memory as part of > the model. But if you can use the simpler model to solve your problem > - you probably should. Well, ok, the Python

Re: global interpreter lock

Bryan Olson <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: > > The real problem is that the concurrency models available in currently > > popular languages are still at the "goto" stage of language > > development. Better models exist, have existed for decades, and are > > available in a vari

Re: global interpreter lock

"Donn Cave" <[EMAIL PROTECTED]> writes: > Quoth Paul Rubin : > | Mike Meyer <[EMAIL PROTECTED]> writes: > |> The real problem is that the concurrency models available in currently > |> popular languages are still at the "goto" stage of language > |> development. Better m

Re: global interpreter lock

[Bryan Olson] >>I don't see much point in trying to convince programmers that >>they don't really want concurrent threads. They really do. Some >>don't know how to use them, but that's largely because they >>haven't had them. I doubt a language for thread-phobes has much >>of a future. [Mike Meyer

Re: global interpreter lock

Mike Meyer wrote: > The real problem is that the concurrency models available in currently > popular languages are still at the "goto" stage of language > development. Better models exist, have existed for decades, and are > available in a variety of languages. That's not "the real problem";

Re: global interpreter lock

Quoth Paul Rubin : | Mike Meyer <[EMAIL PROTECTED]> writes: |> The real problem is that the concurrency models available in currently |> popular languages are still at the "goto" stage of language |> development. Better models exist, have existed for decades, and are |>

Re: global interpreter lock

[km] > is true parallelism possible in python ? cpython:no. jython: yes. ironpython: yes. > or atleast in the coming versions ? cpython:unknown. pypy: don't have time to research. Anyone know? > is global interpreter lock a bane in this context ? beauty/bane

Re: global interpreter lock

Mike Meyer <[EMAIL PROTECTED]> writes: > > I don't see much point in trying to convince programmers that > > they don't really want concurrent threads. They really do. Some > > don't know how to use them, but that's largely because they > > haven't had them. I doubt a language for thread-phobes has

Re: global interpreter lock

Bryan Olson <[EMAIL PROTECTED]> writes: > I don't see much point in trying to convince programmers that > they don't really want concurrent threads. They really do. Some > don't know how to use them, but that's largely because they > haven't had them. I doubt a language for thread-phobes has much >

Re: global interpreter lock

Donn Cave wrote: > Bryan Olson wrote: >>On a uniprocessor system, the GIL is no problem. On multi- >>processor/core systems, it's a big loser. > > > I rather suspect it's a bigger winner there. > > Someone who needs to execute Python instructions in parallel > is out of luck, of course, b

Re: global interpreter lock

yan Olson <[EMAIL PROTECTED] > wrote: > km wrote:>  > Hi all,>  >>  > is true parallelism possible in python ? or atleast in the>  > coming versions ? is global interpreter lock a bane in this>  > context ? >> No; maybe; and currently, not usually.>> On a u

Re: global interpreter lock

In article <[EMAIL PROTECTED]>, Bryan Olson <[EMAIL PROTECTED]> wrote: > km wrote: > > Hi all, > > > > is true parallelism possible in python ? or atleast in the > > coming versions ? is global interpreter lock a bane in this > > context ? >

Re: global interpreter lock

km wrote: > Hi all, > > is true parallelism possible in python ? or atleast in the > coming versions ? is global interpreter lock a bane in this > context ? No; maybe; and currently, not usually. On a uniprocessor system, the GIL is no problem. On multi- processor/core syst

Re: global interpreter lock

KM, I eagerly await the answer to this question as well.  I'd love to see this explained in laymen's terms.  From what I understand of this issue, your best bet for getting parrelism is to use whatever the OS provides and just have multiple python instances running... but then I didn't understan

Re: global interpreter lock

On 2005-08-20, km <[EMAIL PROTECTED]> wrote: > is true parallelism possible in python? No, not for some values of "true parallelism". > or atleast in the coming versions? Not that I'm aware of. > is global interpreter lock a bane in this context? In wh

Re: global interpreter lock

Robin Becker <[EMAIL PROTECTED]> writes: > > http://poshmodule.sf.net > Is posh maintained? The page mentions 2003 as the last date. Dunno, and I suspect not. I've been wondering about it myself. -- http://mail.python.org/mailman/listinfo/python-list

  1   2   >