Slashdot Mirror

Set XmNmwmDecorations to zero in your application, and you have a free floating drawing area. See the Motif programming manual [pdf alert] ftp://ftp.sgi.com/other/motifz...

Nobody bought SGI systems to run crude 3D accelerated games.

Someone forgot to tell the folks at ID Software.

http://itrunsdoom.tumblr.com/post/99687965744/sgi-workstations-yeah-they-run-doom-during-the

Doom isn't 3D accelerated and - as pointed out quite explicitly in the link you posted - they did it "for funsies" because Nobody* bought SGI systems to run crude 3D accelerated games.

ftp://ftp.sgi.com/sgi/quake/intro.html

Quake indeed is 3D accelerated but this was again done for fun and not a commercial product because of the quote above.

https://www.geek.com/games/joh...

Not even sure why you think this is at all relevant, perhaps you didn't read it but yes John Carmack once used an SGI monitor.

Nobody bought SGI systems to run crude 3D accelerated games.

Someone forgot to tell the folks at ID Software.

http://itrunsdoom.tumblr.com/post/99687965744/sgi-workstations-yeah-they-run-doom-during-the
ftp://ftp.sgi.com/sgi/quake/intro.html
https://www.geek.com/games/joh...

"OpenGL" is not open source,

You would be wrong.

No I am not wrong, you simply misunderstand. To help you along just try and show me Apple's open source OpenGL implementation. Oh you cant do that? Im not surprised, because it is not open source.

So you're saying it's not "available" because it doesn't fit your definition of "available". Can you get Vulkan on macOS? Yes. Is it officially supported by Apple? No.

Do you understand the difference that I pointed out? It seems you do not or you are ignoring it because you dont like it. You could say all Windows and Linux programs run on macOS because you can run them in a VM and that would be very disingenuous in the least but when we are talking about a "down to the metal" API like Vulkan your suggestion that it is available when in fact what you point to is it running on top of another API is downright stupid and you don't even understand why. Even Apple's proposal for WebGPU points out that Vulkan is not available on their platforms because to implement it on top of another 3d graphics API completely defeats the purpose of a low-level API. Do you understand that? Or are you still confused?

"OpenGL" is not open source,

You would be wrong.

That is a layer on top of Metal that translates calls from one API to another, it is not Vulkan on macOS or iOS because those platforms do not support it as Apple quite rightly stated. You are arguing against facts by providing evidence you clearly have absolutely no understanding of whatsoever.

So you're saying it's not "available" because it doesn't fit your definition of "available". Can you get Vulkan on macOS? Yes. Is it officially supported by Apple? No.

Don't know why, but I had a sudden vision of a hacker taking control of a bunch of self-driving chairs and shuffling them, organizing and manipolating them in all the ways allowed by STL. It would be very funny to look at, but not so pleasant being sitting into it...

That's what I was wondering too when I saw the headline. Looks like they managed to pivot to a company that provides high-performance computing to the same company-set that uses Oracle and SAP. (In other words, probably only certain departments at fortune 500 companies).

"There are some computing tasks that can't really be split up among multiple nodes, so they still require gigantic CPU requirements. Usually this is related to legacy databases which cost less to keep on the legacy architecture than spend the time to try to move it to PC clusters."

True but what does that have to do with the usage of Power/Sparc? There do exists 32 and 64 processor xeon systems, and sgi will even sell you a system with 256 cpus and 64 TB ram if you can pay the price.

https://www.sgi.com/products/s...
Let me quote "SGI UV 3000 scales to extraordinary levels - up to 256 CPU sockets and 64TB of cache-coherent shared memory in a single system."

SGI's still around, of course, they have an office within walking distance of my house. Dunno what they do these days.

The company currently calling itself "SGI" was originally called "Rackable Systems" before they bought SGI's assets in 2009.

By the way, the finally stopped releasing bug fixes for IRIX last December. The company still plans to keep phone tech support going on. They say that the MIPS/IRIX products continue to be a viable solution for many customers, with millions of dollars invested over the years.

"tired app icon grid of Android and iOS"

Yeah, it's so tired from ButtonFly days that it stuck around. That kind of tired? Or the kind of tired something gets when it ain't broke?

A quick scan of the second page of the linked article suggests to my "I know very little about this" mind that it is a CC-NUMA like design akin to that which SGI has been using for decades in its systems that scale to quite large numbers - iirc 2048 cores (hyperthreaded) with 64TB RAM. I guess it's a problem that is solved to some degree - ie, yes it can still be an issue that some applications are sensitive to and can require some specialist programming, especially to get the best performance from, but it can also present a massive amount of RAM to a single application. I imagine it works well for applications that process in a pipeline too with data passed through the system in an orderly manner, though I can't think of anything that has quite *that* many steps.

http://www.sgi.com/products/servers/uv/configs.html

Java...and Java GL...in a Web browser? I hope that somebody implements a Java version of Nepomuk so I can justify to my boss the purchase of that SGI Ice Cube I've been wanting.

Passing in registers is not a standard C parameter passing method

There's no such thing as "a standard C parameter passing method". Passing in registers is a perfectly legitimate C parameter passing method, used on several RISC architectures, such as SPARC, MIPS, 32-bit ARM, 64-bit ARM, and 64-bit {PowerPC/Power Architecture} (and probably most other RISC architectures), as well as x86-64 and z/Architecture.

If there are more parameters than fit in the registers available for parameter passing, or if the parameters are in the variable-length portion of the argument list, they might be passed on the stack, and if the called function has no prototype in scope, the compiler might be forced to pass everything on the stack, but, in all other cases, if the ABI supports it, parameters can and will be passed on the stack.

No, Wikipedia is right... as Section 1.1 of the MIPS R10000 Microprocessor User’s Manual says, "MIPS has defined an instruction set architecture (ISA), implemented in the following sets of CPU designs: MIPS IV, implemented in the R8000 and R10000"

The R10000 is MIPS IV, not MIPS V

Iwas just going to suggest the matrox TripleHead2Go, but it's apparently limited to 5760x1080 (3x 1920x1080) or two screens combined to 3840x1200 (2x 1920x1200). I'd say that doesn't qualify as three big screens.

Does anyone know how multiple screens daisy-chained via their display-port outputs appear to the system?

It's really a pity that functionality that's been available since 15 years on SGI Onyx computers hasn't found its way into all desktop systems.

Btw, is there any good reason why the idle power consumption of graphics cards increases significantly when more than one (or in some cases two) monitors are connected?

SGI had something along these lines http://www.google.com/patents?vid=5732138 https://en.wikipedia.org/wiki/Lavarand but links http://lavarand.sgi.com/ don't work too well now.

Go look it up, OpenGL isn't a free "do whatever you like" setup. There is licensing for it for companies like nVidia.

I decided to do exactly that. This is from their licensing website.

The following are the currently available licenses:

Open source license, for use of the S.I.. This is a Free Software License B closely modeled on BSD, X, and Mozilla licenses.

Trademark License. for new licensees who want to use the OpenGL trademark and logo and claim conformance. This license is available free of charge if you are developing open source implementations on open source platforms. For closed source licenses or licenses on proprietary platforms, a charge will be associated with a trademark license.

Emphasis mine. There's also a note on the page that former licensees can open source their code and no longer need a license. If you're making an open source implementation, OpenGL seems pretty open.

VS was a good product. It has some disadvantages compared to Eclipse (lack of refactoring, flexibility), and some advantages (and if you ask me, it is vastly inferior to VI and Make, but that is just preference).

But with VS 2012 they decided to go with the retro look. As in the whole thing looks like it was made in Motif. Hooray for bringing us back to 1980s technology. Except actually I think Motif on SGI looked better than Visual Studio 2012. Wow.

In UNIX-land, no it isn't.

Sorry, but shipping code beats standards based theory, and pretty much every *nix vendor ships dc with the OS.

Oracle (nee Sun) Solaris, IBM AIX, HP HP/UX, SGI IRIX, Apple MacOS X, SCO Openserver, SuSE Enterprise Linux (dc listed on bc page), FreeBSD, OpenBSD ...

You also appear to missed a few things about the Open Group Base Specifications Issue 7 / IEEE Std 1003.1-2008 standard - it is in essence a floor, not a ceiling - vendors can ship more tools if they care to. Also, the discussion on bc notes that some implementations of bc are built on top of dc, and that is OK, as long as the behavior of bc is correct.

It is worth noting that dc was one of the earliest programs to run in Unix, making it in while Unix was still written in assembly language. If for some reason it was to be not only omitted, but actually excluded by the standard, it would still be found in the vast majority of shipping systems for years to come until said vendor decided to migrate their Unix system to the current standard, a process that often takes years.

So yes, for the vast majority of people using Unix, an RPN calculator is often only as far away as a shell prompt.

Every other use I can think of involves comparing size() to and index number, and I cannot figure out a good use of an index number in a list that is not itself O(N).

One interesting example given in another reply was "iterate through first half of the list". You'd still use iterators to access the elements, incrementing them as you go, but you'd also need an int counter, and to compare that against size()/2.

A converse problem is that in gcc std::string(const std::string&) is fast (because they are pointers to reference-counted data) while this is slow in VC++.

Huh, g++ still uses refcounted strings? Are you sure this is still true as of 4.x? I was pretty confident that this was purged from all major implementations quite some time ago, when various problems with making them conform to subtle Standard provisions surfaced with no surprise effects. In particular, every indexing operation and every iterator dereference has to be treated as "write" (since it returns a non-const char reference) for the purposes of COW, and what's worse, since an iterator or a reference can be kept around for later use, any string for which such has been obtained becomes "unshareable" (see http://www.sgi.com/tech/stl/string_discussion.html).

Anyway, C++0x wording makes it downright impossible to have a refcounted std::string implementation, which was very much by design.

- What about a super computer made out of FPGAs ?

It's been done.... more than once, or twice.

New FPGA-based Supercomputer in Scotland
SGI Builds World's Largest FPGA Supercomputer

Linux supports many more CPUS/Cores than that...

If you can afford one, SGI will happily sell you an Altix UV1000 which has 512 sockets and up to 2048 cores, running linux.

http://www.sgi.com/products/servers/altix/uv/

It also looks like they're planning to make even bigger versions of this system in the future.

I believe SGI has a few of these systems, or even bigger versions of this in the top500 list.

http://www.sgi.com/products/servers/altix/uv/

2,048 cores (256 sockets) and 16TB of memory, one OS image.

The OS has also been future-proofed, in the view of the Red Hat executives. It can support up to 16 terabytes of working memory, even though no physical system could now actually run that much memory under a single server.

http://www.sgi.com/products/servers/altix/4000/

"SGI Altix 4700 incorporates the shared-memory NUMAflex® architecture, which simplifies software development, workload management and system administration. It supports up to 1024 cores under one instance of Linux and as much as 128TB of globally shared memory."

http://www.sgi.com/products/servers/altix/uv/

"Altix® UV scales to extraordinary levels-up to 2,048 cores (256 sockets) with architectural support to 262,144 cores (32,768 sockets). Support for up to 16TB of global shared memory in a single system image, enables Altix UV to remain highly efficient at scale for applications ranging from in-memory databases, to a diverse set of data and compute-intensive HPC applications."

"This infrastructure is supported by a complete HPC solution stack running on industry standard Linux® operating systems with the choice of Novell® SUSE Linux Enterprise Server or Red Hat® Enterprise Linux® Advanced Server operating systems."

Someone didn't do his research before spouting off. This is odd considering he simply regurgitated the information Red Hat fed him. I guess the press guy at Red Hat didn't know they already had their OS running on 16TB capable SGI monsters?

Misinformation here too?

Why is the first link posted? While RHEL6 isn't even support on Itaniums. And yes, your quote on the bottom only refers to the Itanium article. Thanks for letting us know that.

The only product of interest is the Altix UV. These products are usually carved into pieces (partitioned into LPARs) and virtualized and I doubt that majority of Red Hat customers are really using "Big Iron" like that. Which brings me to the point of the comment Red Hat's VP made. Something along the lines off:

"The OS has also been future-proofed, in the view of the Red Hat executives. It can support up to 16 terabytes of working memory, even though no physical system could now actually run that much memory under a single server."

Guess what the maximum supported memory for that ALIX UV is? 16TB.
The Altix UV's RHEL Support:
"Red Hat® Enterprise Linux® Planned*"

Please understand what you read and or listen to.

The OS has also been future-proofed, in the view of the Red Hat executives. It can support up to 16 terabytes of working memory, even though no physical system could now actually run that much memory under a single server.

http://www.sgi.com/products/servers/altix/4000/

"SGI Altix 4700 incorporates the shared-memory NUMAflex® architecture, which simplifies software development, workload management and system administration. It supports up to 1024 cores under one instance of Linux and as much as 128TB of globally shared memory."

http://www.sgi.com/products/servers/altix/uv/

"Altix® UV scales to extraordinary levels-up to 2,048 cores (256 sockets) with architectural support to 262,144 cores (32,768 sockets). Support for up to 16TB of global shared memory in a single system image, enables Altix UV to remain highly efficient at scale for applications ranging from in-memory databases, to a diverse set of data and compute-intensive HPC applications."

"This infrastructure is supported by a complete HPC solution stack running on industry standard Linux® operating systems with the choice of Novell® SUSE Linux Enterprise Server or Red Hat® Enterprise Linux® Advanced Server operating systems."

Someone didn't do his research before spouting off. This is odd considering he simply regurgitated the information Red Hat fed him. I guess the press guy at Red Hat didn't know they already had their OS running on 16TB capable SGI monsters?

Misinformation here too?

Why is the first link posted? While RHEL6 isn't even support on Itaniums. And yes, your quote on the bottom only refers to the Itanium article. Thanks for letting us know that.

The only product of interest is the Altix UV. These products are usually carved into pieces (partitioned into LPARs) and virtualized and I doubt that majority of Red Hat customers are really using "Big Iron" like that. Which brings me to the point of the comment Red Hat's VP made. Something along the lines off:

"The OS has also been future-proofed, in the view of the Red Hat executives. It can support up to 16 terabytes of working memory, even though no physical system could now actually run that much memory under a single server."

Guess what the maximum supported memory for that ALIX UV is? 16TB.
The Altix UV's RHEL Support:
"Red Hat® Enterprise Linux® Planned*"

Please understand what you read and or listen to.

The OS has also been future-proofed, in the view of the Red Hat executives. It can support up to 16 terabytes of working memory, even though no physical system could now actually run that much memory under a single server.

http://www.sgi.com/products/servers/altix/4000/

"SGI Altix 4700 incorporates the shared-memory NUMAflex® architecture, which simplifies software development, workload management and system administration. It supports up to 1024 cores under one instance of Linux and as much as 128TB of globally shared memory."

http://www.sgi.com/products/servers/altix/uv/

"Altix® UV scales to extraordinary levels-up to 2,048 cores (256 sockets) with architectural support to 262,144 cores (32,768 sockets). Support for up to 16TB of global shared memory in a single system image, enables Altix UV to remain highly efficient at scale for applications ranging from in-memory databases, to a diverse set of data and compute-intensive HPC applications."

"This infrastructure is supported by a complete HPC solution stack running on industry standard Linux® operating systems with the choice of Novell® SUSE Linux Enterprise Server or Red Hat® Enterprise Linux® Advanced Server operating systems."

Someone didn't do his research before spouting off. This is odd considering he simply regurgitated the information Red Hat fed him. I guess the press guy at Red Hat didn't know they already had their OS running on 16TB capable SGI monsters?

The OS has also been future-proofed, in the view of the Red Hat executives. It can support up to 16 terabytes of working memory, even though no physical system could now actually run that much memory under a single server.

http://www.sgi.com/products/servers/altix/4000/

"SGI Altix 4700 incorporates the shared-memory NUMAflex® architecture, which simplifies software development, workload management and system administration. It supports up to 1024 cores under one instance of Linux and as much as 128TB of globally shared memory."

http://www.sgi.com/products/servers/altix/uv/

"Altix® UV scales to extraordinary levels-up to 2,048 cores (256 sockets) with architectural support to 262,144 cores (32,768 sockets). Support for up to 16TB of global shared memory in a single system image, enables Altix UV to remain highly efficient at scale for applications ranging from in-memory databases, to a diverse set of data and compute-intensive HPC applications."

"This infrastructure is supported by a complete HPC solution stack running on industry standard Linux® operating systems with the choice of Novell® SUSE Linux Enterprise Server or Red Hat® Enterprise Linux® Advanced Server operating systems."

Someone didn't do his research before spouting off. This is odd considering he simply regurgitated the information Red Hat fed him. I guess the press guy at Red Hat didn't know they already had their OS running on 16TB capable SGI monsters?

One SGI Altix version comes with 2,048 cores running a single image.

The benchmarks in the paper are a bit suspicious because they avoid disk I/O. tmpfs is used instead, which may skew results significantly. Surprisingly, they do not describe the architecture of the test machine, but perhaps I've missed that. They suggest that a workload which does not spend much time in the kernel cannot have scaling issues caused by the kernel, which seems rather dubious to me.

These take 6TB, and don't cost that much, and if you'll take a full rack version, there's a server in the set that takes 16TB RAM.

Every HPC lab worth the name should be able to afford one :)

Database software is now finally catching up with postgreSQL. You can argue that mysql is getting better too I suppose. With the database software formally reserved to big iron we have no reason to use Solaris/Oracle except on all but the biggest data warehouses.

That is not correct. Linux far out scales Solaris due to the limitations of the largest Sun server. Linux efficiently scales to a higher processor and memory count than any other *nix OS on the planet. Why? SGI. You can now purchase a packaged SGI Altix UV 1000 system with 256 sockets, each containing an 8 core Xeon 7500 CPU for a total of 2048 cores and 16TB of shared memory in 4 standard racks tied together by the NUMALink 5 interconnect with 40GB/s bidirectional interconnect bandwidth to each two socket blade, all running a single copy of standard SuSE Linux.

The largest Sun system, the M9000, tops out at 64 sockets each with a 4 core Fujitsu SPARC64 VII CPU for a total of 256 cores and 4TB of shared memory. On a per core basis the Xeon 7500 is well over 50% faster than the SPARC64 VII and the Altix has 8 times as many cores.

Either of these systems has enough PCIe slots to connect more adapters, bandwidth and storage than any database could ever need.

Assuming PostgreSQL can efficiently fork and/or thread and can create and manage multi terabyte database files, this SGI Altix UV system running SuSE Linux and PostgreSQL would run circles around any other single system available. All with an essentially free Linux distro and FOSS DB. Don't like SuSE? You could install Debian or any other Linux on the Altix UV, although SGI probably wouldn't support it. The NUMA magic is already in the mainline Linux kernel, so any Linux distro, properly configured, could run on this Altix system.

So, you can get a FOSS Linux OS and FOSS DB and likely beat anything on the planet. The cost of the hardware would make you choke, however. It's up in the $2+ million range without storage. It would still be cheaper than the SUN M9000 + OracleDB because the OS and DB are in essence free. You'd automatically pay for a SuSE support contract as SGI won't sell the box(es) without it. You'd want it anyway though, as things do go wrong, and especially on a box with 2048 cores. You'd probably want a support contract for PostgreSQL as well. But, both these contracts will be less than Solaris+Oracle.

Even the "midrange" Altix UV 100 would kick the crap out of SUN's biggest box. The Altix UV 100 is a two rack system with 96 Xeon 7500 CPUs, 768 cores, and 6TB of memory. Cheaper than its big brother, the UV 1000, but probably still over $1 million without storage.

It's too bad SGI only focuses on the scientific supercomputing market. These new Altix UV systems, especially since based on the x86-64 Xeon instead of Itanium, would just absolutely trounce many traditional Unix systems in the large database market, as well as many other markets.

http://www.sgi.com/products/servers/altix/uv/

Now in C++ I write vector, or in Python I use a_list = [] and POOF! I don't need to keep track of ANY details.

I'm afraid that you are wrong

The SGI implementation of STL is thread-safe only in the sense that simultaneous accesses to distinct containers are safe, and simultaneous read accesses to to shared containers are safe. If multiple threads access a single container, and at least one thread may potentially write, then the user is responsible for ensuring mutual exclusion between the threads during the container accesses.

Do you know how long it takes to build a data center? In most cases it is years and years. And you have to build it to your eventual maximum size. Guess to small and you have to build another one. Guess to large and you have a lot of expensive floorspace going to waste.

With a data center in a shipping container you and build it in less than 6 months from first thinking of need and having it up and running. Yes it will take another 3 months to plan it, get the funding, find a place to put it and install it.

You can buy your data center in 3200 sq. ft. increments. Maybe have a plan to add one every six months.

You can also depreciate it as equipment rather than facilities.

And finally you can move it on a whim. Tornado in Florida, send it overnight to the Midwest. Flooding in the Midwest send it to New Mexico. To hot in New Mexico, move it to Utah. Cheaper power in Washington state, move it again.

It would also make sense to containerize your chillers as well so you can install/move them both. Then all you need to move it is a flat secure location, power and Internet connectivity.

Of the containerized data centers the sgi (Rackable Systems) ICE Cube Modular Data Center is, IMHO, the best design because they deal with power efficiency in the rack with DC/DC power supplies and they talk about containerized chillers as either part of the container or as a separate container.

Take a look at:
http://www.sgi.com/products/data_center/ice_cube

RLH

http://elbitz.net/home.php is good, but they only open up registering every now and then (I remember I waited like 2 months to get my user). In general, though I just use the same popular torrent sites for everything else I get for books, too and I've gotten 6.28GB that way. Also, appear to have just found a .pdf with a huge list of ebook sites (and one for how to swear in all languages!). Haven't tried any of them, but go for it:
O'Reilly online http://www.oreilly.com/openbook/ | http://sysadmin.oreilly.com/ Computer books and manuals http://www.hoganbooks.com/freebook/webbooks.html | http://www.informit.com/itlibrary/ | http://www.fore.com/support/manuals/home/home.htm | http://www.adobe.com/products/acrobat/webbuy/freebooks.html The Network Book http://www.cs.columbia.edu/netbook/ Some #bookwarez.efnet.irc links http://www.extrema.net/books/links.shtml Some #bookwarez.efnet.irc fiction http://194.58.154.90:4431/enscifi/ Pimpas online books (Indonesia) http://202.159.16.55/~pimpa2000 | http://202.159.15.46/~om-pimpa/buku Security, privacy and cryptography http://theory.lcs.mit.edu/~rivest/crypto-security.html | http://www.oberlin.edu/~brchkind/cyphernomicon/ My own misc online reading material http://www.eastcoastfx.com/docs/admin-guides/ | http://www.eastcoastfx.com/~jorn/reading/ Computer books http://solaris.inorg.chem.msu.ru/cs-books/ | http://sweetrude.net/~cab/books/ | http://alaska.mine.nu/books/ | http://poprocks.dyn.ns.ca/dave/books/ | http://58-160.skarland.uaf.edu/books/ | http://202.186.247.194/~ebook/ | http://hooligans.org/reference/ Linux documentation http://www.linuxdoc.org/docs.html FreeBSD documentation http://www.freebsd.org/tutorials/ Sun documentation http://osiris.imw.tu-clausthal.de:8888/ | http://uran.vvsu.ru:8888/ SGI documentation http://newton.unicc.chalmers.se/ebt-bin/nph-dweb/dynaweb;td=2 | http://techpubs.sgi.com/library/tpl/cgi-bin/init.cgi IBM Online Redbooks http://www.redbooks.ibm.com/ Digital Unix documentation http://www.unix.digital.com/faqs/publications/base_doc/DOCUMENTATION/V40D_HTML/V40D_HTML/LIBRARY.HTM Filesystem Hierarchy Standard http://www.pathname.com/fhs/2.0/fhs-toc.html | http://www.linuxbase.com/ UNIX stuff http://ww

According the datasheet on their site, helpfully not linked in either the summary or article, it ships with RHEL5, SLES 10 or 11, or Windows Server 2008 or HPC Server 2008.

The only benefit that I can think of when going over the specs and datasheet is the fact that it can support a shipload of memory. But I agree that it's definitely not worth the 8 Gs.

The only benefit that I can think of when going over the specs and datasheet is the fact that it can support a shipload of memory. But I agree that it's definitely not worth the 8 Gs.

nah. What put the boot into SGI systems was their premature jump to Intel Itanium processors. We (the CG industry) had been quite happy spending lots of cash for these pretty blue machines with Mips processors, and then one day Sgi declared they were dropping mips for Intel Itanium CPU's. The Itanium then had problems, and so SGi hastily crapped out a new mips CPU on their Fuel workstations. We didn't buy them, because we were waiting for the Itanium ones. So they switched to Intel Xeon CPU's running NT, and we didn't buy them, because as we know, the Itanium hit problems, and a dell workstation running linux was a cheaper option. Over the course of a couple of years Sgi machines literally vanished from the Cg industry.

Then to make matters worse, most of the engineers from the graphics dept of Sgi jumped ship, and all went to join Nvidia (Mark Kilgard et al). The comsumer grade Geforce cards had better OpenGL support + features than an Sgi unit at a fraction of the cost.

This is probably the only realistic comparison you can make between SGI and Apple. Apple (having seen a computer company crash and burn due to a switch to Intel) must have studied what went wrong with Sgi, and made damn sure they didn't repeat the same mistakes.... If Sgi had managed the transition as well as Apple, it would still be a powerhouse in the industry.

If you only need a single dual-socket board, that is obviously a superior choice. Most of the 8k price on the base model is paying for the hardware you have the option to add, not the hardware you are getting.

Assuming you actually need one of the higher end configurations, though, the mac pro isn't going to cut it. A mac pro supports 2 quad core xeons. This SGI box supports 20 quad core xeons in a box of roughly equivalent size. Not to mention that each node on the SGI box supports 3 times as much RAM as the mac pro. Not playing the same game.

That said, the two other configurations they offer (see here) seem much less useful. The "intel 2-way" configuration gives you up to 20 xeons and 960GB of RAM. That is pretty impressive power for a box of the size. The "Intel 1-way" is based on dual-core Atoms. 2GB max of RAM per node and the extremely feeble Atom seems like a very odd choice. 19 Atoms in a box of that size is pretty blah density, and for most applications you'd probably have a faster, cheaper, and easier time with a basic quad-socket board running processors that weren't designed for netbooks. The "Graphics workstation" configuration is a single dual socket workstation board. Lots of PCIe slots; but probably not worth SGI's price for a basic workstation level performance.

The developers are pretty helpful.
Try posting your question on the PCP mailing list or IRC channel.
Details on the "Developers" page at http://oss.sgi.com/projects/pcp/

Disclaimer: I was a PCP developer in a previous life. ;)

I'm curious, how does this package handle snmp data? Looking through their commit tree, I found one commit which mentioned snmp, and nothing at all in a full text search of the docs. http://oss.sgi.com/cgi-bin/gitweb.cgi?p=pcp/pcp.git;a=commit;h=1500bd088898317c42eede0f0748f1fd09989c69

This is hardly news and partly mistaken.

The statement that sockets limit throughput by copying between kernel and application processes is a bit simplistic. The copy of Rx data to an application usually primes the cache. If data isn't touched and loaded into the cache at this point, it will have to be loaded shortly, anyway. Granted, for Tx this trick does not hold.

Second, the interface is not the implementation. Just because sockets are traditionally implemented as system calls does not state that they have to. User level networking is a well known alternative to OS services for high-bandwidth and low-latency communication (e.g., U-net developed around '96). I know, because I myself built a network stack with large shared buffers that implements the socket API through local function calls (blatant plug, but on topic. The implementation is still shoddy, but good enough for UDP benchmarking).

User level networking can also offers low latency. My implementation doesn't, but U-net does.

This leaves the third point of the article, on multihoming. As sockets abstract away IP addresses and network interfaces, I don't see why they cannot support multihoming behind the socket interface. Note that IP addresses do not have to mapped 1:1 onto NICs. Operating systems generally support load-balancing or fail-over behind the interface through virtual interfaces (in IRIX) or some other means (Netfilter in Linux).

Not need to replace sockets just yet.

No, their real innovation was in graphics and system architecture, IMO

Very true. However, if you look at their current products page, you'll be hard-pressed to find a system on there that uses a graphics card that they designed. It appears they have become more dedicated to raw speed above other things; though you can also buy storage appliances from them - which I suspect don't use their graphics technology either.

'There should be no disruption to Silicon Graphics customers'.

Yes. Both of you.

http://www.sgi.com/company_info/newsroom/press_releases/2009/february/ti_09.html

They make some claims as to have "given back" to the linux community
Well, they were the first to port Linux to a serious parallel architecture. Still not many vendors that will support a 512-core and 1-kernel system...
About the giving back: http://oss.sgi.com/projects/ if you want to check

Does this mean IRIX will be developed again? I'm not seeing any info one way or the other.

As a Linux and BSD guy, I'm pretty ignorant about IRIX other than the MIPS support. Does IRIX do anything innovative that makes developing it worthwhile?

No. And I'm fairly certain of that.

IRIX was discontinued in 2006 by SGI - http://www.sgi.com/support/mips_irix.html - and most of the cool technical features of IRIX were ported over to Linux ages ago - like xfs http://oss.sgi.com/projects/xfs/. Actually, the correct question is will this new, improved and revived SGI continue to support the open source efforts of the old SGI regime? http://oss.sgi.com/projects/ . I don't see a point in reviving IRIX, but there was a lot of OSS work done out of that shop and I'd hate to see it disappear. Right?

Does this mean IRIX will be developed again? I'm not seeing any info one way or the other.

As a Linux and BSD guy, I'm pretty ignorant about IRIX other than the MIPS support. Does IRIX do anything innovative that makes developing it worthwhile?

No. And I'm fairly certain of that.

IRIX was discontinued in 2006 by SGI - http://www.sgi.com/support/mips_irix.html - and most of the cool technical features of IRIX were ported over to Linux ages ago - like xfs http://oss.sgi.com/projects/xfs/. Actually, the correct question is will this new, improved and revived SGI continue to support the open source efforts of the old SGI regime? http://oss.sgi.com/projects/ . I don't see a point in reviving IRIX, but there was a lot of OSS work done out of that shop and I'd hate to see it disappear. Right?

Does this mean IRIX will be developed again? I'm not seeing any info one way or the other.

As a Linux and BSD guy, I'm pretty ignorant about IRIX other than the MIPS support. Does IRIX do anything innovative that makes developing it worthwhile?

No. And I'm fairly certain of that.

IRIX was discontinued in 2006 by SGI - http://www.sgi.com/support/mips_irix.html - and most of the cool technical features of IRIX were ported over to Linux ages ago - like xfs http://oss.sgi.com/projects/xfs/. Actually, the correct question is will this new, improved and revived SGI continue to support the open source efforts of the old SGI regime? http://oss.sgi.com/projects/ . I don't see a point in reviving IRIX, but there was a lot of OSS work done out of that shop and I'd hate to see it disappear. Right?

You beat me to the punch. I was just going to point out that SGI is also in on the joke.

Not that I didn't preview or anything, but I could have also linked in the SGI customer letter. Rackable is getting SGI without getting their debt.