Thread: 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.
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
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 ...
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 | | +----------------------------------+------------------------------------+