Thread

  1. Spinlocks on SGI's

    Robert E. Bruccoleri <bruc@stone.congenomics.com> — 2001-03-27T13:59:45Z

    I contributed the first working s_lock.c code for the SGI's over three
    years ago (using the test_and_set library calls). It's been working
    for me ever since in a heavy multi-user environment. Please don't
    change it unless there's an overwhelming reason.
    
    Also, the GNU compiler systems works poorly on SGI's. In this
    environment, you need to stick to the SGI provided compilers. Once you
    get used to them, they work fairly well.
    
    Sincerely,
    Bob
    
    +----------------------------------+------------------------------------+
    | Robert E. Bruccoleri, Ph.D.      | Phone: 609 737 6383                |
    | President, Congenomics, Inc.     | Fax:   609 737 7528                |
    | 114 W Franklin Ave, Suite K1,4,5 | email: bruc@acm.org                |
    | P.O. Box 314                     | URL:   http://www.congen.com/~bruc |
    | Pennington, NJ 08534             |                                    |
    +----------------------------------+------------------------------------+
    
    
  2. Re: Spinlocks on SGI's

    Mathijs Brands <mathijs@ilse.nl> — 2001-03-27T14:02:49Z

    On Tue, Mar 27, 2001 at 08:59:45AM -0500, Robert E. Bruccoleri allegedly wrote:
    > I contributed the first working s_lock.c code for the SGI's over three
    > years ago (using the test_and_set library calls). It's been working
    > for me ever since in a heavy multi-user environment. Please don't
    > change it unless there's an overwhelming reason.
    > 
    > Also, the GNU compiler systems works poorly on SGI's. In this
    > environment, you need to stick to the SGI provided compilers. Once you
    > get used to them, they work fairly well.
    
    The problem is that SGI wants a couple of hundred dollars for it :(
    
    Regards,
    
    Mathijs
    -- 
    It's not that perl programmers are idiots, it's that the language
    rewards idiotic behavior in a way that no other language or tool has
    ever done.
                                                        Erik Naggum
    
    
  3. Re: Spinlocks on SGI's

    Robert E. Bruccoleri <bruc@stone.congenomics.com> — 2001-03-27T14:15:50Z

    Dear Mathijs,
    > 
    > > 
    > > Also, the GNU compiler systems works poorly on SGI's. In this
    > > environment, you need to stick to the SGI provided compilers. Once you
    > > get used to them, they work fairly well.
    > 
    > The problem is that SGI wants a couple of hundred dollars for it :(
    
    Unfortunately, the GNU compiler developers have not put much effort
    into support for the SGI platform over the years, and therefore,
    it's not a good alternative for the SGI compiler system. For PostgreSQL,
    we need to provide the right advice on how to build it so it works well.
    
    BTW, SGI is distributing its compilers for Linux/Intel under an open
    source license. Depending on the progress of Intel chips versus MIPS
    chips, the cost issue of the compilers on SGI's will eventually
    disappear.
    
    Regards, Bob
    
    +----------------------------------+------------------------------------+
    | Robert E. Bruccoleri, Ph.D.      | Phone: 609 737 6383                |
    | President, Congenomics, Inc.     | Fax:   609 737 7528                |
    | 114 W Franklin Ave, Suite K1,4,5 | email: bruc@acm.org                |
    | P.O. Box 314                     | URL:   http://www.congen.com/~bruc |
    | Pennington, NJ 08534             |                                    |
    +----------------------------------+------------------------------------+
    
    
  4. Re: Spinlocks on SGI's

    Marc Fournier <scrappy@hub.org> — 2001-03-27T14:22:30Z

    On Tue, 27 Mar 2001, Robert E. Bruccoleri wrote:
    
    > I contributed the first working s_lock.c code for the SGI's over three
    > years ago (using the test_and_set library calls). It's been working
    > for me ever since in a heavy multi-user environment. Please don't
    > change it unless there's an overwhelming reason.
    >
    > Also, the GNU compiler systems works poorly on SGI's. In this
    > environment, you need to stick to the SGI provided compilers. Once you
    > get used to them, they work fairly well.
    
    Robert, any possibility of getting pre-compiled binaries for SGI that we
    can put up on the site?  For those that can't afford the extra cost of the
    compilers? :)
    
    
    
  5. Re: Spinlocks on SGI's

    Robert E. Bruccoleri <bruc@stone.congenomics.com> — 2001-03-27T14:30:41Z

    Dear Marc,
    > 
    > On Tue, 27 Mar 2001, Robert E. Bruccoleri wrote:
    > 
    > > I contributed the first working s_lock.c code for the SGI's over three
    > > years ago (using the test_and_set library calls). It's been working
    > > for me ever since in a heavy multi-user environment. Please don't
    > > change it unless there's an overwhelming reason.
    > >
    > > Also, the GNU compiler systems works poorly on SGI's. In this
    > > environment, you need to stick to the SGI provided compilers. Once you
    > > get used to them, they work fairly well.
    > 
    > Robert, any possibility of getting pre-compiled binaries for SGI that we
    > can put up on the site?  For those that can't afford the extra cost of the
    > compilers? :)
    
    Yes. What exactly do you need from the Postgresql tree after a successful
    compilation and test?
    
    --Bob
    
    +----------------------------------+------------------------------------+
    | Robert E. Bruccoleri, Ph.D.      | Phone: 609 737 6383                |
    | President, Congenomics, Inc.     | Fax:   609 737 7528                |
    | 114 W Franklin Ave, Suite K1,4,5 | email: bruc@acm.org                |
    | P.O. Box 314                     | URL:   http://www.congen.com/~bruc |
    | Pennington, NJ 08534             |                                    |
    +----------------------------------+------------------------------------+
    
    
  6. Re: Spinlocks on SGI's

    Matthew Kirkwood <matthew@hairy.beasts.org> — 2001-03-27T14:52:25Z

    On Tue, 27 Mar 2001, Robert E. Bruccoleri wrote:
    
    > BTW, SGI is distributing its compilers for Linux/Intel under an
    > open source license.  Depending on the progress of Intel chips
    > versus MIPS chips, the cost issue of the compilers on SGI's will
    > eventually disappear.
    
    Do you mean their ia64 compiler?
    
    There's a reason that that one's GPLed -- it uses the
    gcc frontend.
    
    Matthew.
    
    
    
  7. Re: Spinlocks on SGI's

    Marc Fournier <scrappy@hub.org> — 2001-03-27T15:06:20Z

    On Tue, 27 Mar 2001, Robert E. Bruccoleri wrote:
    
    > Dear Marc,
    > >
    > > On Tue, 27 Mar 2001, Robert E. Bruccoleri wrote:
    > >
    > > > I contributed the first working s_lock.c code for the SGI's over three
    > > > years ago (using the test_and_set library calls). It's been working
    > > > for me ever since in a heavy multi-user environment. Please don't
    > > > change it unless there's an overwhelming reason.
    > > >
    > > > Also, the GNU compiler systems works poorly on SGI's. In this
    > > > environment, you need to stick to the SGI provided compilers. Once you
    > > > get used to them, they work fairly well.
    > >
    > > Robert, any possibility of getting pre-compiled binaries for SGI that we
    > > can put up on the site?  For those that can't afford the extra cost of the
    > > compilers? :)
    >
    > Yes. What exactly do you need from the Postgresql tree after a successful
    > compilation and test?
    
    easiest, I think, unless SGI has a special packaging (pkg_add) format, is
    a tar of /usr/local/pgsql ... that *should* have everything required ...
    bin, libs and includes ...
    
    if you could create one based on RC1 and upload that, then we can get some
    testing on whether or not that works before the release?
    
    login info to follow ...
    
    
    
    
  8. Re: Spinlocks on SGI's

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-27T15:26:38Z

    bruc@stone.congenomics.com (Robert E. Bruccoleri) writes:
    > I contributed the first working s_lock.c code for the SGI's over three
    > years ago (using the test_and_set library calls). It's been working
    > for me ever since in a heavy multi-user environment. Please don't
    > change it unless there's an overwhelming reason.
    
    I don't believe anyone was proposing changing the existing __sgi code.
    The discussion was about adding support for non-SGI MIPS hardware.
    
    			regards, tom lane
    
    
  9. Re: Spinlocks on SGI's

    Peter Eisentraut <peter_e@gmx.net> — 2001-03-27T16:40:03Z

    The Hermit Hacker writes:
    
    > Robert, any possibility of getting pre-compiled binaries for SGI that we
    > can put up on the site?  For those that can't afford the extra cost of the
    > compilers? :)
    
    I think this
    
    http://freeware.sgi.com/Installable/postgresql-7.0.html
    
    is the canonical place to put these things, although I don't know how well
    it is maintained.  At least one could try to use their package building
    infrastructure.
    
    -- 
    Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/
    
    
    
  10. Re: Spinlocks on SGI's

    Mathijs Brands <mathijs@ilse.nl> — 2001-03-28T01:04:24Z

    On Tue, Mar 27, 2001 at 11:06:20AM -0400, The Hermit Hacker allegedly wrote:
    > On Tue, 27 Mar 2001, Robert E. Bruccoleri wrote:
    > > Dear Marc,
    > > > On Tue, 27 Mar 2001, Robert E. Bruccoleri wrote:
    > > >
    > > > > I contributed the first working s_lock.c code for the SGI's over three
    > > > > years ago (using the test_and_set library calls). It's been working
    > > > > for me ever since in a heavy multi-user environment. Please don't
    > > > > change it unless there's an overwhelming reason.
    > > > >
    > > > > Also, the GNU compiler systems works poorly on SGI's. In this
    > > > > environment, you need to stick to the SGI provided compilers. Once you
    > > > > get used to them, they work fairly well.
    > > >
    > > > Robert, any possibility of getting pre-compiled binaries for SGI that we
    > > > can put up on the site?  For those that can't afford the extra cost of the
    > > > compilers? :)
    > >
    > > Yes. What exactly do you need from the Postgresql tree after a successful
    > > compilation and test?
    > 
    > easiest, I think, unless SGI has a special packaging (pkg_add) format, is
    > a tar of /usr/local/pgsql ... that *should* have everything required ...
    > bin, libs and includes ...
    > 
    > if you could create one based on RC1 and upload that, then we can get some
    > testing on whether or not that works before the release?
    
    Wouldn't it be best to build IRIX 6.2 binaries? Those should run properly on
    IRIX 6.2 and anything newer. Of course, having both IRIX 6.2 and 6.5 binaries
    wouldn't really hurt...
    
    Cheers,
    
    Mathijs
    -- 
    It's not that perl programmers are idiots, it's that the language
    rewards idiotic behavior in a way that no other language or tool has
    ever done.
                                                        Erik Naggum
    
    
  11. Re: Spinlocks on SGI's

    Robert E. Bruccoleri <bruc@stone.congenomics.com> — 2001-03-28T02:14:16Z

    Dear Mathijs,
    > 
    > Wouldn't it be best to build IRIX 6.2 binaries? Those should run properly on
    > IRIX 6.2 and anything newer. Of course, having both IRIX 6.2 and 6.5 binaries
    > wouldn't really hurt...
    
    It's not feasible to do this, nor is it worth it. Irix 6.5 is much
    more reliable than Irix 6.2. --Bob
    
    +----------------------------------+------------------------------------+
    | Robert E. Bruccoleri, Ph.D.      | Phone: 609 737 6383                |
    | President, Congenomics, Inc.     | Fax:   609 737 7528                |
    | 114 W Franklin Ave, Suite K1,4,5 | email: bruc@acm.org                |
    | P.O. Box 314                     | URL:   http://www.congen.com/~bruc |
    | Pennington, NJ 08534             |                                    |
    +----------------------------------+------------------------------------+