Slashdot Mirror

I hope Microsoft aren't taking inspiration from the British comedy show "The Fast Show"'s 'Channel 9' sketches.... :o)

For those of you who are wondering what I'm on about... see here, and here, and here, and here, and here....... Scorchio!

check out Ian Mapleson's site. It has some verry good SGI information about installing 6.5 from CD.

Some computer magazine wrote a review of the Indigo2 dated 1993. It's a fascinating look back at the days when SGI workstations just totally pissed all over PCs.

Alex

So it ain't true.


It's still a bus therefore anything that wants to do anything along the bus has to compete with everything else. The crossbar in the Octane provides a sustainable 1.2GB/sec connection to the crossbar with a peak of 1.6GB/sec.

For more information visit http://www.futuretech.vuurwerk.nl/octnarch.html.

Yes, MHz does make a difference, but people need to please stop touting SPEC results without taking into account other factors when comparing CPU performance...

SPEC benchmarks are designed with minuscule datasets to reduce RAM and Cache bottlenecks... some interesting articles found at the STREAM homepage discuss how some CPU manufacturers boosted L2 cache on their chips, while ignoring RAM bandwidth considerations, simply to get higher SPEC results...
Memory bandwidth results (MByte/s) for recent HP, RS/6000, and esp. Alphas single-CPU workstations show they can play around with much more data located in RAM alot quicker than a 733 PIII, even at low clock speeds (400MHz for POWER3 and PA-RISC 8500... the Alphas were 21264s clocked at equal to or slightly less than 733MHz, with results being about double those of the PIII)... note that the PIII wasn't a xeon... shouldn't make a big diff though, because the architecture is similar (nearly identical) for PIII and PIII-xeon... look at the results yourselves, it's innarestin...

that being said, all Sun Ultra workstations performed a little worse than 'equivalent' HP, IBM, and DEC(Compaq) workstations regarding RAM bandwidth... Ultra60-360s perform so poorly that the PIII 733 gets twice as many MFLOPS on a particular test (but the lead is much less on two others... a 450MHz-Ultra might tie or surpass them)...

And ALL that to say that SPEC is only useful if you're comparing systems which will be doing computations on teeny tiny datasets. At least that's the case for SPECcpu95, I don't know about SPECcpu2000. Furthermore, the SPECfp benchmarks focus mainly on double-precision floats, to the expense of single-precision floats... this might indicate why results for SGI machines make them look pokey, considering some of their CPUs (r5000) are optimized for single-precision MADD instructions, because of their ubiquity in doing 3D work...

Here are some sites that contain benchmark results and/or link to sites with benchmark results:
SPEC website
the CPU Info Center
FutureTech SGI info

nuh unh... their IRIS 1000/2000/3000 series' use 680x0. I believe it was only around 1986 that the move towards MIPS began. The 3000 series finally ended production in 1989.

• You win, because you're now no longer coding on a specific project to satisfy only a stupid customer who, at the end, doesn't even grasp the amount of work you did for him/her.
• Your employer wins, because they can offer the same solution to multiple customers without extra overhead. They also get more stable code out of you because of the benefits that come from it being an open source solution.
• The world wins, since it gains another useful program.

XFS is fast and it does support big files. Here are some more XFS ressources: SGI Performance Comparisons, a text about Myths about SGI dispelled (see Myth 8 for more information about what XFS does: 6.4 GB/sec sustained rates for a 16 processor Origin) and the text of the Sweeney Paper.

In the Sweeney Paper, read chapter 5. Allocation groups allow XFS concurrent activity, where current ext2 blocks the entire filesystem when a single process grows a file. Sparse large file support works well with a 64 bit filesizes, while producing only little overhead for many small files. Dynamic allocation of inodes and organizing these inodes in B+-trees allows for a dynamic number of inodes and for a very large number (64 bit again) of files per FS. B+-tree organizing directories makes searching very large directories very fast. Log structure makes crash recovery fast even for TB sized filesystems.

By delaying allocation and not assigning physical block numbers until the buffer cache is being flushes, XFS can cluster blocks in a file much better than ext2 can do this. Integrating this change into Linux will need some work on the caching subsystem, though.