Re: [SLE] Threaded Perl

From: Randall R Schulz (rschulz_at_sonic.net)
Date: 09/07/04

  • Next message: Mark Gray: "Re: [SLE] Threaded Perl" 
    To: suse-linux-e@suse.com
Date: Mon, 6 Sep 2004 16:37:15 -0700

    Kolja,

    On Monday 06 September 2004 16:08, Kolja Kauder wrote:
    > Mark Gray wrote:
    > >...
    > >
    > >On a multiprocessor (or hyper-threading) machine it buys you a WHOLE
    > >lot because the threads can execute at the same time.
    >
    > That depends VERY MUCH on the machine, especially the memory setup,
    > caches and FSB, as well as on the specific application. I've written
    > some multithreaded numerical stuff myself, and I get very good
    > performance on a dual-opteron machine and very sad results on older
    > Pentium-III Hardware because if the problem is essentially memory bound
    > you gain nothing. That said, it buys the lot for day to day stuff when
    > one application operates on a small set of data while another one, e.g.
    > X or seti, runs on the other node. However, this does NOT necessarily
    > apply to hyper-threading, for this technique requires the actual
    > instructions to be parallelizable. This is not possible in my case, so
    > hyper threading only buys me a confused top, time(), etc. I find it
    > hard to write good MT code and impossible to write good HT code, though
    > examples of the latter are said to exist. Maybe that's why I'm only
    > Optio and not Centurio (Asterix and the soothsayer) :-)

    Performance analysis, let alone optimization, just gets harder and harder
    as hardware gets more and more sophisticated. Oops. I mean it gets more
    and more interesting...

    I'm not familiar with the breakdown of execution units and how they relate
    to x86 instructions (let alone to high-level language constructs) nor how
    much redundancy there is in execution units and data pathways within a
    Hyper-Threaded Pentium 4 or Xeon processor. My intuition is that a priori
    there'd be considerable opportunity for overlap within the CPU itself and
    that patterns of primary storage access (especially overall L2 and L3
    cache hit rates) are the dominant ones. After all, for lots of common
    execution patterns, access to RAM is the limiting factor.

    > >On a single
    > >processor it is wasteful of machine cycles, but does allow the
    > >programmer to background process things in a slightly more efficient
    > >manner than forking allows for.
    >
    > If I understand this right that's not true:
    > man fork:
    > ...
    > Under Linux, fork is implemented using copy-on-write
    > pages, so the only penalty incurred by fork is the time
    > and memory required to duplicate the parent's page tables,
    > and to create a unique task structure for the child.
    > ...
    > I take this to mean that fork()'ing and pthread_create()'ing are
    > essentially the same. I have no clue though about native pthreads.
    > Again, I'm only optio, if that much.

    Creating a thread does not require a full set of new page table entries,
    since all the threads of a given process share with their siblings all of
    their virtual memory environment except for their stacks.

    > ...
    >
    > KK

    Randall Schulz 

    -- 
Check the headers for your unsubscription address
For additional commands send e-mail to suse-linux-e-help@suse.com
Also check the archives at http://lists.suse.com
Please read the FAQs: suse-linux-e-faq@suse.com
  • Next message: Mark Gray: "Re: [SLE] Threaded Perl"

    Relevant Pages

    • Re: [Full-disclosure] [Dailydave] What RedHat doesnt want you to know about ExecShield (without
      ... buffer overflow attacks by performing executable memory checks. ... This is not the case with ExecShield without NX. ... code execution, in the other you do not. ...
      (Full-Disclosure)
    • [NT] Defeating Microsoft Windows XP SP2 Heap Protection and DEP Bypass
      ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... and bypassing DEP (Data Execution Prevention). ... Buffer overrun attacks are among the most common mechanisms, or vectors, ... a long string to an input stream or control longer than the memory ...
      (Securiteam)
    • Re: Can you write code directly in CIL ???
      ... I don't care if a GC occurs during the execution of my code. ... always needs all of this memory the whole time that it is executing. ... and the CLR isn't going to care what your function is doing. ... >>> You don't understand a fundamental concept to .NET and CIL. ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: Structure of large link libraries in f95
      ... about memory space while the program is running. ... that all of the program has to be brought into memory so that execution ... where a properly installed program will be paged in from its executable ... and the executable file format does not have a repeated initialization ...
      (comp.lang.fortran)
    • RE: Defeating Microsoft Windows XP SP2 Heap protection
      ... Fact is XP SP2 is still far less likely to be vulnerable to buffer overflow ... > than the memory buffer allocated to hold it. ... > the operating system is now more careful to reduce both stack and heap ... > Execution Protection ...
      (microsoft.public.windowsxp.general)