python threads on multi-CPU machines

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Thomas Womack

    python threads on multi-CPU machines

    If I have a dual-processor hyperthreaded machine (so with four CPU
    contexts), will a python program distribute threads over all four
    logical processors?

    I ask because I'm fairly sure that this *does* happen using the
    threading extensions in MFC, and fairly sure that it *doesn't* when
    using Java, so I don't see that the result is obvious for python.

    Tom
  • Duncan Booth

    #2
    Re: python threads on multi-CPU machines

    Thomas Womack <twomack@chiark .greenend.org.u k> wrote in
    news:vQn*aWb0p@ news.chiark.gre enend.org.uk:
    [color=blue]
    > If I have a dual-processor hyperthreaded machine (so with four CPU
    > contexts), will a python program distribute threads over all four
    > logical processors?
    >
    > I ask because I'm fairly sure that this *does* happen using the
    > threading extensions in MFC, and fairly sure that it *doesn't* when
    > using Java, so I don't see that the result is obvious for python.[/color]

    The C implementation of Python uses a global interpreter lock that only
    allows one thread to interpret bytecode at a time, so while the threads may
    be distributed across multiple processors you will get little or no speedup
    over a single processor. (If your threads spend most of their time in a
    non-Python extension, they may be able to get some benefit from multiple
    processors).

    The only way to take advantage of multiple processors with Python is to run
    at least one separate process for each processor. For example, I believe
    Zope will take advantage of multiple processor systems if you run it in ZEO
    client/server mode with several Zope client processes.

    I believe that Jython simply does whatever the Java implementation does.

    --
    Duncan Booth duncan@rcp.co.u k
    int month(char *p){return(1248 64/((p[0]+p[1]-p[2]&0x1f)+1)%12 )["\5\x8\3"
    "\6\7\xb\1\x9\x a\2\0\4"];} // Who said my code was obscure?

    Comment

    • Andrew Dalke

      #3
      Re: python threads on multi-CPU machines

      Thomas Womack:[color=blue]
      > If I have a dual-processor hyperthreaded machine (so with four CPU
      > contexts), will a python program distribute threads over all four
      > logical processors?[/color]

      Yes, unless you are CPU bound in the Python interpreter.
      (CPU bound in an extension is fine, and I/O bound, as when
      doing network is also fine.)

      For a longer answer, see back threads concerning the global
      interpreter lock and "free-threading".

      Andrew
      dalke@dalkescie ntific.com


      Comment

      • Kevin Cazabon

        #4
        Re: python threads on multi-CPU machines

        > However, C extensions can release the[color=blue]
        > GIL, and almost all I/O code in Python does that, so I/O-heavy programs
        > will make good use of the SMP.[/color]

        FYI, I'm also working on adding that functionality to the PIL library,
        seeing as imaging operations can be fairly expensive too. It makes
        these processes more "friendly" to other threads (and Tk) even on
        single-CPU boxes, and allows taking advantage of multiple CPUs where
        available.

        I'll be posting links on the PIL mailing list when it's complete (just
        needs exhaustive testing now... it'll be a while), and Fred has agreed
        to merge it into the core distribution afterwards.

        Kevin.

        Comment

        • Aahz

          #5
          Re: python threads on multi-CPU machines

          In article <5a4226f0.03081 80945.34f96eca@ posting.google. com>,
          Kevin Cazabon <kevin@cazabon. com> wrote:[color=blue]
          >Aahz:[color=green]
          >>
          >> However, C extensions can release the GIL, and almost all I/O code
          >> in Python does that, so I/O-heavy programs will make good use of the
          >> SMP.[/color]
          >
          >FYI, I'm also working on adding that functionality to the PIL library,
          >seeing as imaging operations can be fairly expensive too. It makes
          >these processes more "friendly" to other threads (and Tk) even on
          >single-CPU boxes, and allows taking advantage of multiple CPUs where
          >available.[/color]

          Cool! When you're done, I'd appreciate it if you could write up a short
          summary of the problems you ran into and post it here. I'm interested
          in pushing computational threading in Python, but I haven't written
          enough C code to have any idea how it differs from other kinds of
          threading issues.
          --
          Aahz (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

          This is Python. We don't care much about theory, except where it intersects
          with useful practice. --Aahz

          Comment

          • Lothar Scholz

            #6
            Re: python threads on multi-CPU machines

            Thomas Womack <twomack@chiark .greenend.org.u k> wrote in message news:<vQn*aWb0p @news.chiark.gr eenend.org.uk>. ..[color=blue]
            > If I have a dual-processor hyperthreaded machine (so with four CPU
            > contexts), will a python program distribute threads over all four
            > logical processors?[/color]

            Okay others told you already about the GIL.
            [color=blue]
            > I ask because I'm fairly sure that this *does* happen using the
            > threading extensions in MFC, and fairly sure that it *doesn't* when
            > using Java,[/color]

            Of couse java *does* this. It's the number one reason for SUN to
            develop and maintain Java: selling a reason to buy some of there
            overpriced multiprocessor machines. Maybe you don't know anything
            about Java.

            Comment

            • Paul McGuire

              #7
              Re: python threads on multi-CPU machines

              Just one general caveat, based on some multi-thread code I worked on about a
              year ago: if you want to support your users running your multithread code on
              multi-CPU machines, you *must, must, must* stress test on multi-CPU
              machines!

              We had a very nasty intermittent bug (collision with threads in Tcl
              interpreter) that I could *not* reproduce on my single-processor development
              box, but which showed up in the field on the customer's quad-processor
              machine.
              Finally, after about a day and a half, I moved over to our dual processor
              test machine, and the bug showed up after about 20 minutes of stress
              testing. It turned out that the 3rd party thread library we were using was
              built to be compatible with the Win98 (!) thread API - once I rebuilt to run
              using the WinNT thread API, the window was closed, and the app ran great on
              the multiCPU servers.

              I'm sorry if this is off-topic, and I am fairly new in this newsgroup, but I
              know we were very eager to push multiCPU machines on our customers, and we
              did not realize what risk we were taking on.

              Sincerely,
              -- Paul McGuire
              Austin, TX



              Comment

              Working...