The reservations are on land that settlers didn't want. Native Americans who live on the reservations are often barred from working off the reservation, either by law (in some cases they're not considered U.S. citizens) or because of discrimination. Most of the reservations have no economy to speak of other than a small amount of tourism (and maybe the casinos you mentioned, but only in some cases). Poverty and alcoholism are usually rampant, and if there is a casino, many of the folks on the reservation don't see any money from it because of corruption.
A few years ago I went on a service trip to Oaks Indian School, which is basically an Lutheran-run orphanage on the Cherokee reservation in Oklahoma. It was an eye-opening experience. I'm originally from a rural area of Ohio just on the edge of the Rust Belt, so I had a little bit of an idea what poverty looks like. I had no idea it would be as bad as it was. Just absolutely heartbreaking.
The kernel is mature he thinks. Everyone he works with agrees with him. Such a failure of imagination....
I think this is the difference between researcher/architect types and coders.
To a researcher, there is so much that needs to be done to enhance the kernel that
the problem is picking one thing to focus on.
Oh, horsehockey. I work with a bunch of computer science researchers who work on high performance computing topics. Guess how most of 'em do their OS-level research? They take Linux and make their wacky new file system/interconnect/etc. ideas work with it. Seems to work pretty well for them.
Another thing to remember is that a lot of CS researchers write half-arsed code that isn't ready for prime-time. They're usually thinking proof-of-concept, not production deployment. That isn't unique to academia, either; it amazes me how much utter crap escapes from big corporate research labs claiming to be a "product".
[/me decides to quit before this degenerates into YA rant about the fact that physicists are often better at production-quality software engineering than computer scientists]
You're trying to say they could have overestimated the performance by almost 100%?
No, the original poster was saying that the 65TF number from NEC is theoretical peak performance based on the maximum possible number of FP operations per clock cycle (which can never happen in real code, due to pesky little things like having to access memory), while the ~35TF number for the Blue Gene/L prototype is measured performance on an actual piece of code called the Parallel Linpack benchmark. It's not unusual for systems to perform as low as 50% of peak on Parallel Linpack, although 70-90% is more typical on systems with decent memory bandwidth (which the SX8 presumably has).
(Note that I'm deliberately sidestepping the debate over whether Parallel Linpack bears any resemblence to reality.)
IB has slightly lower latency than Myrinet (about 1 to 1.5 microseconds less IIRC), but 3-4 times better bandwidth. The IB network management tools are IMHO better than the equivalents for Myrinet too.
Most of the parallel applications on our clusters are scientific simulation codes, written in Fortran, C, or C++ using MPI for inter-process communication.
Actually, as far as I can tell, their interconnect is IB at the hardware level, but without a PCI bus between the HCA and the memory controller. That drops their latency by a couple microseconds, and it means they don't need PCI Express to get full bandwidth out of the network. The claim is that they use their own software stack in place of the VAPI stuff, and that they don't use MVAPICH from Ohio State like most IB sites do. I haven't had a chance to look at our XD1 (we've had 3 chassis' worth for almost a month) to see if that's true or not.
Their story as far as storage is kinda lame; I think they're praying Lustre won't suck.
Look under initiatives on the Cray products page; the MTA-2 is shown there.
The MTA idea is neat, but nobody's ever been able to find a problem that runs all that well on them. The original MTA didn't have enough memory bandwidth to make it competitve with a vector machine, and the small number of them in the field (less than 10 IIRC) are notoriously cantankerous. When Tera bought Cray, the one of the main things they were buying, aside from name recognition, was Cray's CMOS design experience; they were hoping Cray's designers could help with the problems they'd run into with MTA.
Does anything like that ever REALLY run anything other than benchmarks? We have clusters where I work, but they rarely see any real computations.
If anything, we have the opposite problem where I work. Our clusters are so heavily utilized (averaging around 80-90% for the last couple months) that we've had a hard time freeing up enough nodes to run benchmarks and do preventative maintenance.
Remember how Va. Tech replaced all 1100 G5 nodes with G5 XServes a few months ago? Well, when you do something like that, you have to rerun and resubmit the benchmark. Va. Tech were not able to get the machine back together soon enough to rerun the benchmark in time to make the last list; there's even a big caveat about it on the Top 500 home page.
(It's also not clear that the original version of the Va. Tech machine ever did anything other than run that benchmark, but that's another matter.)
Maybe I'm the only person who feel this way, but I always thought Zahn's Star Wwars books read like he was playing the old West End Star Wars RPG and writing down what happened. The idea of a lifeform that suppresses Force abilities doesn't quite compute for me either. (OTOH, don't get me started on the "mitichlorians" horse-hockey from TPM...)
The Truce at Bakura was probably my favorite of the post-RotJ books, although the Dark Horse comic miniseries Dark Empire was a lot of fun too.
Is Apple's new (or current) Filesystem really Apple's?
I thought it was a neutered Berkely FFS from the Darwin/Freebsd/Netbsd code they've taken.
Current Apple systems ship with an HFS+ root filesystem, or at least the iBook I bought a few months ago did. HFS+ is journalled AFAICT, but it's pretty much the same old Mac HFS (resource forks, etc.) other than that. It's not even really case-sensitive; "touch a ; touch A" will only create one file.
So far as I can tell, the big feature of OSX 10.4 is Spotlight, which looks like a version of locatedb that knows about file contents to me. This really isn't an OS-level thing IMHO; it could be implemented in an FS-independent way in user-land without too much trouble. It seems like this would be functionality you'd want in the file browser (eg. Nautilus or Konqueror) rather than in the filesystem... although this kind of metadata indexing might be where the HFS resource forks might come in handy.
Re:How will this affect IBM's GPFS
on
Red Hat announces GFS
·
· Score: 2, Interesting
GFS is more like IBM's SAN Filesystem (a.k.a. Storage Tank) or SGI's CXFS than GPFS, which is more analogous to parallel filesystems like Lustre or PVFS2. The difference is how the clients talk to the underlying storage devices; clients of GFS, SANFS, and CXFS talk directly to the storage devices via Fibre Channel or iSCSI, whereas clients of GPFS, Lustre, and PVFS2 go through some number of intermediate I/O servers.
The author doesn't really explain why he didn't compile with -O3 aside from a very slight amount of hand-waving about space-speed tradeoffs, which quite frankly I don't buy. If you're benchmarking, why wouldn't you optimize as heavily as possible? If he was really interested in benchmarking this stuff objectively, he could've at least shown that there wasn't much different between -O2 and -O3. Not to mention the question of whether g++ generates good binary code on a given platform...
This didn't exactly fill me with optimism either:
I don't have an automated means of building and benchmarking these things (and the scripts that came with the original shootout didn't run for me). I really do want you to test it on your own machine, but it's going to take some work, I guess.
This would seem to imply that the author does not know much about either shell scripting or Makefiles. I'm not sure I'm willing to trust benchmarks from somebody who can't figure out an automated way to build and run them.
There's a similar setting for terminal, and probably other native applications.
I have yet to see any evidence that this is possible for J. Random Aqua App without buying additional 3rd-party software, and believe me, I've been looking on and off for the last month and a half.
My Mac laptop sees less use than either of my Linux desktops (at home and at work) for precisely this reason -- I've been using focus-follows-mouse for so long that it's very painful for me to go back to click-to-focus. The only general purpose solution I've seen for this is Virtual Desktop Pro, and I haven't gotten around to buying it because part of me has a hard time paying US$40 for two things (virtual desktops and focus-follows-mouse) that I've had on Linux for free for nigh unto ten years...
My guess is that both they and Apple wanted to have a spot on the last Top 500 list, with all the associated press at the Supercomputing 2003 conference. Apple's been trying to convince somebody, anybody to build a large HPC cluster with their hardware since the G3 came out. Until the G5 came out, it made very little sense economically -- the per-system price for Apple kit was 30-40% more than comparable Intel-based stuff, and the memory bandwidth and 64-bit floating point performance was the same or worse. The G5 fixed that, for the most part
Nobody in their right mind wants to build a cluster out of machines in desktop/deskside chasses. We've done it once, with the first generation Itanium systems where there was no rackmount option for a 2-way box, and we'll never do it again -- remote management of those machines was and is actively painful. (Our 1st-gen Itanium cluster is out of production service now, but it's been partitioned up into smaller clusters at universities around the state as part of the Cluster Ohio project, which we still manage.)
The Infiniband NICs are made by Mellanox, and IB switches are made by Mellanox, Voltaire, and one other company whose name eludes me. I don't know who developed the OSX drivers (maybe Mellanox, maybe Apple, maybe both), but AFAIK the high-level MPI library that pretty much everybody (including Va. Tech) uses for IB is a channel driver for MPICH developed by D.K. Panda's group at Ohio State. (I know this because Pete Wyckoff, a co-worker of mine at OSC, has done a whole bunch of debugging and stress testing for Panda's crew; his name's on most of their IB-related papers too.)
In short, the only thing Apple might have bought to the table as far as the IB interconnect on the Va. Tech machine is some driver development.
Not having the Silmarillion (spelling??) in front of me, but if I recall the Wizards and Sauron were of the caste/order of beings in Valinor (spelling??). Does anyone remember what beings the Balrog were corrupted from, it was briefly stated in the book?
IIRC, the Balrogs were Maiar, the same as Sauron and the Istari (Wizards).
If the station is strapped for fuel and can't spare any, I understand that too! But I haven't seen any indication of that.
I take it you missed the bit where the Kiwis said they don't have the right kind of fuel, and they're pretty sure the Americans don't either.
--Troy
Re:That's how discovery works in litigation
on
SCOrched Earth
·
· Score: 1
IBM wins this case if they can prove (ie, get the court to agree) that any of several different things are true:
The contract is not binding, or
AIX is not "derived from" the old UNIX after some point in history (and if the development of the particular features postdate that), or
The features over which SCO is suing were developed in an environment not covered by the contract and ported to Linux from there, or
SCO's distribution of Linux source that includes the code in question provided implicit approval for revealing the secrets.
Based on the AT&T/IBM side letter, it's hard to see how SCOG can claim that IBM isn't allowed to use its own tech (JFS, RCU, etc.) any way it pleases:
2. Regarding Section 2.01, we agree that modifications and derivative works prepared by or for you are owned by you. However, ownership of any portion or portions of SOFTWARE PRODUCTS included in any such modification or derivative work remains with us.
(Here SOFTWARE PRODUCTS==SysV UNIX source)
SCOG has been very careful not to bring up this particular clause.
The ISO 9660 standard is a specification for PC's and has two levels.
Level one looks like the DOS filing system. File names consist of eight characters a dot and an extension of three characters. The only characters allowed are the alphanumeric and the underscore. Directories, contrary to DOS, can have no extensions. All alphabetics are in UPPER case; some software maps this to lower case. Either the file name or the extension may be empty, but not both ("F." and ".E" are both legal file names).
...
For Unix there is the "Rock Ridge" extension of the ISO 9660.
The Rock Ridge extensions use some undefined fields in the ISO-9660 standard to allow full unix-like filenames, symbolic links, and deep directories. "Rock Ridge" is named after the town in the movie "Blazing Saddles" for no particular reason.
(Emphasis mine)
IANAPL, but this would seem to be prior art if it appeared when I think it did (ca. 1994). I'm pretty sure the first couple Linux CD collections I got in early '95 had Rock Ridge extensions.
If I have legal problems that prevent me from agreeing with the GPL, I cannot use SAMBA on my network, period.
Actually, I don't think that's true. The way the GPL is worded, you can use (install, configure, run, etc.) GPLed software any way you want... but if you want to distribute binaries or modified versions of the software to someone else, you have to agree to the GPL first.
Here's the part of Section 0 in the GPL that talks about use:
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
The fact that SCO still has a Linux kernel source RPM on their website after publically declaring that they don't agree to the license should make for an entertaining copyright infringement suit by IBM, OSDL, SGI, etc.
The Linpack benchmark, as compiled to the G5, is not utilizing the processor to its fullest. The school is still in the process of adding Altivec compiler optimizations, which should drastically improve the results.
The AltiVec instructions support only single precision (32-bit) floating point operations, and the core routine in the Parallel Linpack Benchmark is DGEMM() which is double precision (64-bit). The G5 already has two double precision FPUs, each of which can do a multiply/add op every clock cycle.
My feeling is that the ~40% efficiency seen on the larger scale run is an indication that either VA Tech spent very little time tuning the problem size or they didn't design their InfiniBand fabric to really handle 1100 nodes hammering away at Parallel Linpack. (Given that they've been extremely vague about how their IB network is structured, I fear it may be the latter.)
Right now, the processor is behaving essentially as a G4 with a bigger fan and more memory addresses. Rumor has it that tweeking the compiler to abuse the Altivec unit may push the system above the theoretical limit in some calculations.
I doubt that's true, especially if they're using the IBM PPC compilers. The G4 has both significantly less memory bandwidth and a single double-precision-capable FPU, whereas the G5 is basically a single-core Power4 with an AltiVec unit in place of some cache. IBM's compilers (despite being a little wonky as far as naming and argument syntax) generally produce pretty fast code.
Still, an 80% performance mark over 128 nodes is impressive, and we'll have to wait and see what the final architecture does.
80% is pretty decent. I think our (OSC's) Itanium II cluster with Myrinet gets something like 86% of peak on Parallel Linpack at 128 nodes (256 procs total).
Slashdot Mirror
The reservations are on land that settlers didn't want. Native Americans who live on the reservations are often barred from working off the reservation, either by law (in some cases they're not considered U.S. citizens) or because of discrimination. Most of the reservations have no economy to speak of other than a small amount of tourism (and maybe the casinos you mentioned, but only in some cases). Poverty and alcoholism are usually rampant, and if there is a casino, many of the folks on the reservation don't see any money from it because of corruption.
A few years ago I went on a service trip to Oaks Indian School, which is basically an Lutheran-run orphanage on the Cherokee reservation in Oklahoma. It was an eye-opening experience. I'm originally from a rural area of Ohio just on the edge of the Rust Belt, so I had a little bit of an idea what poverty looks like. I had no idea it would be as bad as it was. Just absolutely heartbreaking.
Oh, horsehockey. I work with a bunch of computer science researchers who work on high performance computing topics. Guess how most of 'em do their OS-level research? They take Linux and make their wacky new file system/interconnect/etc. ideas work with it. Seems to work pretty well for them.
Another thing to remember is that a lot of CS researchers write half-arsed code that isn't ready for prime-time. They're usually thinking proof-of-concept, not production deployment. That isn't unique to academia, either; it amazes me how much utter crap escapes from big corporate research labs claiming to be a "product".
[/me decides to quit before this degenerates into YA rant about the fact that physicists are often better at production-quality software engineering than computer scientists]
--Troy
No, the original poster was saying that the 65TF number from NEC is theoretical peak performance based on the maximum possible number of FP operations per clock cycle (which can never happen in real code, due to pesky little things like having to access memory), while the ~35TF number for the Blue Gene/L prototype is measured performance on an actual piece of code called the Parallel Linpack benchmark. It's not unusual for systems to perform as low as 50% of peak on Parallel Linpack, although 70-90% is more typical on systems with decent memory bandwidth (which the SX8 presumably has).
(Note that I'm deliberately sidestepping the debate over whether Parallel Linpack bears any resemblence to reality.)
IB has slightly lower latency than Myrinet (about 1 to 1.5 microseconds less IIRC), but 3-4 times better bandwidth. The IB network management tools are IMHO better than the equivalents for Myrinet too.
Most of the parallel applications on our clusters are scientific simulation codes, written in Fortran, C, or C++ using MPI for inter-process communication.
Their story as far as storage is kinda lame; I think they're praying Lustre won't suck.
The MTA idea is neat, but nobody's ever been able to find a problem that runs all that well on them. The original MTA didn't have enough memory bandwidth to make it competitve with a vector machine, and the small number of them in the field (less than 10 IIRC) are notoriously cantankerous. When Tera bought Cray, the one of the main things they were buying, aside from name recognition, was Cray's CMOS design experience; they were hoping Cray's designers could help with the problems they'd run into with MTA.
If anything, we have the opposite problem where I work. Our clusters are so heavily utilized (averaging around 80-90% for the last couple months) that we've had a hard time freeing up enough nodes to run benchmarks and do preventative maintenance.
Except that it's not on the most recent Top 500 list anywhere.
Remember how Va. Tech replaced all 1100 G5 nodes with G5 XServes a few months ago? Well, when you do something like that, you have to rerun and resubmit the benchmark. Va. Tech were not able to get the machine back together soon enough to rerun the benchmark in time to make the last list; there's even a big caveat about it on the Top 500 home page.
(It's also not clear that the original version of the Va. Tech machine ever did anything other than run that benchmark, but that's another matter.)
The Truce at Bakura was probably my favorite of the post-RotJ books, although the Dark Horse comic miniseries Dark Empire was a lot of fun too.
--Troy
Current Apple systems ship with an HFS+ root filesystem, or at least the iBook I bought a few months ago did. HFS+ is journalled AFAICT, but it's pretty much the same old Mac HFS (resource forks, etc.) other than that. It's not even really case-sensitive; "touch a ; touch A" will only create one file.
So far as I can tell, the big feature of OSX 10.4 is Spotlight, which looks like a version of locatedb that knows about file contents to me. This really isn't an OS-level thing IMHO; it could be implemented in an FS-independent way in user-land without too much trouble. It seems like this would be functionality you'd want in the file browser (eg. Nautilus or Konqueror) rather than in the filesystem... although this kind of metadata indexing might be where the HFS resource forks might come in handy.
Dunno how I missed it in preview... http://www.lustre.org
This didn't exactly fill me with optimism either:
This would seem to imply that the author does not know much about either shell scripting or Makefiles. I'm not sure I'm willing to trust benchmarks from somebody who can't figure out an automated way to build and run them.I have yet to see any evidence that this is possible for J. Random Aqua App without buying additional 3rd-party software, and believe me, I've been looking on and off for the last month and a half.
My Mac laptop sees less use than either of my Linux desktops (at home and at work) for precisely this reason -- I've been using focus-follows-mouse for so long that it's very painful for me to go back to click-to-focus. The only general purpose solution I've seen for this is Virtual Desktop Pro, and I haven't gotten around to buying it because part of me has a hard time paying US$40 for two things (virtual desktops and focus-follows-mouse) that I've had on Linux for free for nigh unto ten years...
My guess is that both they and Apple wanted to have a spot on the last Top 500 list, with all the associated press at the Supercomputing 2003 conference. Apple's been trying to convince somebody, anybody to build a large HPC cluster with their hardware since the G3 came out. Until the G5 came out, it made very little sense economically -- the per-system price for Apple kit was 30-40% more than comparable Intel-based stuff, and the memory bandwidth and 64-bit floating point performance was the same or worse. The G5 fixed that, for the most part
Nobody in their right mind wants to build a cluster out of machines in desktop/deskside chasses. We've done it once, with the first generation Itanium systems where there was no rackmount option for a 2-way box, and we'll never do it again -- remote management of those machines was and is actively painful. (Our 1st-gen Itanium cluster is out of production service now, but it's been partitioned up into smaller clusters at universities around the state as part of the Cluster Ohio project, which we still manage.)
The Infiniband NICs are made by Mellanox, and IB switches are made by Mellanox, Voltaire, and one other company whose name eludes me. I don't know who developed the OSX drivers (maybe Mellanox, maybe Apple, maybe both), but AFAIK the high-level MPI library that pretty much everybody (including Va. Tech) uses for IB is a channel driver for MPICH developed by D.K. Panda's group at Ohio State. (I know this because Pete Wyckoff, a co-worker of mine at OSC, has done a whole bunch of debugging and stress testing for Panda's crew; his name's on most of their IB-related papers too.)
In short, the only thing Apple might have bought to the table as far as the IB interconnect on the Va. Tech machine is some driver development.
IIRC, the Balrogs were Maiar, the same as Sauron and the Istari (Wizards).
I take it you missed the bit where the Kiwis said they don't have the right kind of fuel, and they're pretty sure the Americans don't either.
Based on the AT&T/IBM side letter, it's hard to see how SCOG can claim that IBM isn't allowed to use its own tech (JFS, RCU, etc.) any way it pleases:
(Here SOFTWARE PRODUCTS==SysV UNIX source)SCOG has been very careful not to bring up this particular clause.
From http://www.itc.nl/~bakker/info/rs-data/cd-family.h tml:
(Emphasis mine)IANAPL, but this would seem to be prior art if it appeared when I think it did (ca. 1994). I'm pretty sure the first couple Linux CD collections I got in early '95 had Rock Ridge extensions.
Actually, I don't think that's true. The way the GPL is worded, you can use (install, configure, run, etc.) GPLed software any way you want... but if you want to distribute binaries or modified versions of the software to someone else, you have to agree to the GPL first.
Here's the part of Section 0 in the GPL that talks about use:
The fact that SCO still has a Linux kernel source RPM on their website after publically declaring that they don't agree to the license should make for an entertaining copyright infringement suit by IBM, OSDL, SGI, etc.
My feeling is that the ~40% efficiency seen on the larger scale run is an indication that either VA Tech spent very little time tuning the problem size or they didn't design their InfiniBand fabric to really handle 1100 nodes hammering away at Parallel Linpack. (Given that they've been extremely vague about how their IB network is structured, I fear it may be the latter.)
I doubt that's true, especially if they're using the IBM PPC compilers. The G4 has both significantly less memory bandwidth and a single double-precision-capable FPU, whereas the G5 is basically a single-core Power4 with an AltiVec unit in place of some cache. IBM's compilers (despite being a little wonky as far as naming and argument syntax) generally produce pretty fast code.