Thread: Spinlocks on SGI's

Spinlocks on SGI's

From
bruc@stone.congenomics.com (Robert E. Bruccoleri)
Date:
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             |                                    |
+----------------------------------+------------------------------------+


Re: Spinlocks on SGI's

From
Mathijs Brands
Date:
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


Re: Spinlocks on SGI's

From
bruc@stone.congenomics.com (Robert E. Bruccoleri)
Date:
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             |                                    |
+----------------------------------+------------------------------------+


Re: Spinlocks on SGI's

From
The Hermit Hacker
Date:
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? :)



Re: Spinlocks on SGI's

From
bruc@stone.congenomics.com (Robert E. Bruccoleri)
Date:
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             |                                    |
+----------------------------------+------------------------------------+


Re: Spinlocks on SGI's

From
Matthew Kirkwood
Date:
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.



Re: Spinlocks on SGI's

From
Tom Lane
Date:
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


Re: Spinlocks on SGI's

From
The Hermit Hacker
Date:
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 ...




Re: Spinlocks on SGI's

From
Peter Eisentraut
Date:
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/



Re: Spinlocks on SGI's

From
Mathijs Brands
Date:
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


Re: Spinlocks on SGI's

From
bruc@stone.congenomics.com (Robert E. Bruccoleri)
Date:
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             |                                    |
+----------------------------------+------------------------------------+