Spinlocks on SGI's
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 | |
+----------------------------------+------------------------------------+
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
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 | |
+----------------------------------+------------------------------------+
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? :)
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 | |
+----------------------------------+------------------------------------+
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.
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 ...
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
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/
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
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 | |
+----------------------------------+------------------------------------+