Which brings up a point that I find really interesting, and that seems to be often overlooked.
Lots of pop-science articles about natural selection talk about species evolving from this to that, or certain traits being "selected for" over the generations. That's backwards thinking, and it can lead to false conclusions.
Nature doesn't reward individuals with superior traits. The only pressure exerted by natural selection is negative pressure. If a certain set of inherited traits results in an organism that is unable to reproduce, then that organism's genetic pattern is eliminated from the pool. (More likely, the effect will be a reduced degree of reproductive success, meaning the pattern will be culled out of the gene pool or diluted to oblivion over a number of generations.)
I guess the term "natural selection" isn't really accurate. "Natural elimination" might be better, but it makes me think of peeing.
This idea can be summed up this way: if your parents didn't have any kids, then neither will you.;-)
Now, the "infertility happens for a reason" theory is basically a restating of the Gaia hypothesis-- the idea that the earth's biosphere behaves like a cohesive system. My opinion is that that's a "post hoc ergo propter hoc" fallacy-- "after the fact, therefore because of the fact." The interactions among the various elements of a biosphere-- predator-prey, symbosis, competition, whatever-- are numerous and complex, and shouldn't be underestimated. It's the chaos fallacy: just because a butterfly in Peking can lead to rain in Central Park doesn't mean that Chinese butterflies cause bad weather.
In other words, I don't believe there's any mechanism for a large population-- "large" being a rather fuzzy term-- of a single species to somehow induce genetic infertility in selected members of that species. I just don't think it works that way.
(If you want to talk about decreased fertility in environments of scarcity, go ahead. It's widely known, for instance, that pregnant female rabbits will remetabolize their litters if underfed. But that's not the same thing as genetic infertility, not by a long shot. Although, come to think of it, that example explains really well how nature can select for rabbits that can be healthy on one leaf of lettuce a day instead of two. When the food supply declines, the rabbits that need more food won't be able to reproduce as effectively, so the next generation will have a higher fraction of one-leaf rabbits than the parent generation did.)
With all respect to everybody who has replied so far, I'd just like to take a second to emphasize something that I probably could have made clearer in my question.
The PDF collection I want to index and search is not available as a web site that can be spidered with HTTP. As far as I can tell from looking at the docs, ht://dig (for example) is strictly a web-site-spidering tool, and that's not what we need.
I'm looking for a tool to help me index a set of files-- not web pages-- then search the index after the content has been committed to DVD-ROM (or some similar medium). ht://dig is not appropriate for doing that, as best I can tell.
Thanks, but maybe we could try to focus on tools that index files via filesystem interfaces, rather than HTTP calls.
The idea of grio is an app says ahead of time "i need this much disk performance - figure it out", and the OS will say "yes, i can hook you up" or "sorry, throw more money at the problem".
No mixing of IA-64 processors and MIPS processors will be allowed. But the system was designed to accept either type of processor, using different operating systems for each.
MIPS-based systems will run IRIX for as long as anybody can predict. IA-64-based systems will never run IRIX, but will run the Linux kernel with lots of SGI-developed support for things like big memory, large processor counts, fancy filesystems, and such. And probably a better scheduler, but that's me speculating, not anything official.
it sounds like something marketing pushed through because "Linux is very hip".
On the one hand, we have the cost (in man-hours) of porting the IRIX kernel to the IA-64 architecture. It's a very difficult job, but one that would result in a stable, scalable system.
On the other hand, we have the cost (also in man hours) of taking our knowledge gained through years of developing IRIX and improving the scalability and stability of the Linux kernel, which is very easy to port to IA-64.
If B < A, use Linux. In this case, B <<< A. It was a no-brainer choice.
Just so you know, partitions in a single system communicate via TCP/IP over NUMAlink. That's about as high-bandwidth, low-latency a cluster interconnect as you can get. Makes Myrinet look like a flock of carrier pigeons.
You're half right. There are three-and-a-half flavors of Vpro right now. There's V3/VR3, which is an nVidia board with 32 or 64 MB of DDR RAM.
Then there's V6/V8, also known as Odyssey. These are available only in Octane2. They're an all-SGI design with the Buzz chip-- "OpenGL on a Chip!"-- at the heart.
There's talk of a V12, which I think is supposed to be a two-Buzz version of V8. That, if it happens, will be exactly twice the geometry performance of V8.
Odyssey-- V6, V8, V12-- look on paper like they're light-years ahead of the nVidia stuff you find in the 230/330/530 systems. I say "look on paper" because I haven't used one myself. Disclaim, disclaim.
Looking over their web pages, I notice that they are careful to never even mention what clock rates the R12000 and R14000 configurations are available in.
The R12000A is available at 400MHz, and incidentially is also available as an upgrade to 2000-series systems and Onyx2s.
The R14000 is being talked about at 500MHz (this is in the marketing, but I can't remember where).
Soon enough, they're talking about an R14000A at 600MHz, too.
You'd be surprised. The 300 MHz R12000 is a monster CPU; the enclosure with heat sink is about seven inches by three by five. You can burn your hand on one if you're not careful.
The 400 MHz R12000A, heat sink and all, fits in the palm of your hand, and barely gets warm to the touch.
When you open up the CPU brick you're amazed at all the empty space. You could store manuals and stuff in there. Then you learn that the brick has to be that big inside to accomodate the size and heat load of the four Itanium processors that will go in there later this year.
Keep in mind that until a month ago, SGI's top-of-the-line graphics board sets (MXE and IR2) were the same designs that originally appeared as Maximum IMPACT on Indigo2 and InfiniteReality on Onyx R10000. About five years ago, give or take.
During that time, entire graphics hardware companies have come and gone. The really good ones have caught up to, and occasionally surpassed, what SGI was doing in 1994. Impressive. Most impressive.;-)
Now SGI has released Vpro, which despite having one name is actually two totally different workstation graphics designs. The Vpro you can get in the IA-32 workstations is basically high-bin commodity graphics hardware from a company that shall remain nameless.
But the Vpro that comes in the Octane2 looks outstanding. I haven't had a chance to use it yet, so I won't endorse, but the design specs for the Buzz chip make it look like InfiniteReality performance on the desktop. Way better than anything in the commodity market right now, and way more expensive, too. It's one of those things: if you have to ask how much it costs, you can't afford it.
1996: SGI: Here's our latest graphics architecture. The World: Wow!
1998: The World: SGI isn't so great. My NNNN is just as fast as an Onyx! SGI:
1999: The World: SGI sucks! AGP cards are better than dedicated workstations! Sell all your stock! Bleah! SGI:
2000: SGI: Here's our latest graphics architecture. The World: Wow!
And so we are all a part of the great Circle of Life.
3. SGI hasn't made a big deal about it yet, but the system will accept either MIPS or Intel processors in the same CPU modules. The MIPS processors come on one kind of daughtercard, and the Itaniums (Itania?) on another. You can't mix-and-match MIPS and IA-64 CPUs in the same machine, but you can mix-and-match in the same cluster.
4. The IA-64 based versions of the 3000 series will include the Linux kernel along an some IRIX compatibility layer.
Slashdot Mirror
Lots of pop-science articles about natural selection talk about species evolving from this to that, or certain traits being "selected for" over the generations. That's backwards thinking, and it can lead to false conclusions.
Nature doesn't reward individuals with superior traits. The only pressure exerted by natural selection is negative pressure. If a certain set of inherited traits results in an organism that is unable to reproduce, then that organism's genetic pattern is eliminated from the pool. (More likely, the effect will be a reduced degree of reproductive success, meaning the pattern will be culled out of the gene pool or diluted to oblivion over a number of generations.)
I guess the term "natural selection" isn't really accurate. "Natural elimination" might be better, but it makes me think of peeing.
This idea can be summed up this way: if your parents didn't have any kids, then neither will you. ;-)
Now, the "infertility happens for a reason" theory is basically a restating of the Gaia hypothesis-- the idea that the earth's biosphere behaves like a cohesive system. My opinion is that that's a "post hoc ergo propter hoc" fallacy-- "after the fact, therefore because of the fact." The interactions among the various elements of a biosphere-- predator-prey, symbosis, competition, whatever-- are numerous and complex, and shouldn't be underestimated. It's the chaos fallacy: just because a butterfly in Peking can lead to rain in Central Park doesn't mean that Chinese butterflies cause bad weather.
In other words, I don't believe there's any mechanism for a large population-- "large" being a rather fuzzy term-- of a single species to somehow induce genetic infertility in selected members of that species. I just don't think it works that way.
(If you want to talk about decreased fertility in environments of scarcity, go ahead. It's widely known, for instance, that pregnant female rabbits will remetabolize their litters if underfed. But that's not the same thing as genetic infertility, not by a long shot. Although, come to think of it, that example explains really well how nature can select for rabbits that can be healthy on one leaf of lettuce a day instead of two. When the food supply declines, the rabbits that need more food won't be able to reproduce as effectively, so the next generation will have a higher fraction of one-leaf rabbits than the parent generation did.)
With all respect to everybody who has replied so far, I'd just like to take a second to emphasize something that I probably could have made clearer in my question.
The PDF collection I want to index and search is not available as a web site that can be spidered with HTTP. As far as I can tell from looking at the docs, ht://dig (for example) is strictly a web-site-spidering tool, and that's not what we need.
I'm looking for a tool to help me index a set of files-- not web pages-- then search the index after the content has been committed to DVD-ROM (or some similar medium). ht://dig is not appropriate for doing that, as best I can tell.
Thanks, but maybe we could try to focus on tools that index files via filesystem interfaces, rather than HTTP calls.
No mixing of IA-64 processors and MIPS processors will be allowed. But the system was designed to accept either type of processor, using different operating systems for each.
MIPS-based systems will run IRIX for as long as anybody can predict. IA-64-based systems will never run IRIX, but will run the Linux kernel with lots of SGI-developed support for things like big memory, large processor counts, fancy filesystems, and such. And probably a better scheduler, but that's me speculating, not anything official.
it sounds like something marketing pushed through because "Linux is very hip".
On the one hand, we have the cost (in man-hours) of porting the IRIX kernel to the IA-64 architecture. It's a very difficult job, but one that would result in a stable, scalable system.
On the other hand, we have the cost (also in man hours) of taking our knowledge gained through years of developing IRIX and improving the scalability and stability of the Linux kernel, which is very easy to port to IA-64.
If B < A, use Linux. In this case, B <<< A. It was a no-brainer choice.
Just so you know, partitions in a single system communicate via TCP/IP over NUMAlink. That's about as high-bandwidth, low-latency a cluster interconnect as you can get. Makes Myrinet look like a flock of carrier pigeons.
NVidia made SGI's "VPro" graphics chipsets...
You're half right. There are three-and-a-half flavors of Vpro right now. There's V3/VR3, which is an nVidia board with 32 or 64 MB of DDR RAM.
Then there's V6/V8, also known as Odyssey. These are available only in Octane2. They're an all-SGI design with the Buzz chip-- "OpenGL on a Chip!"-- at the heart.
There's talk of a V12, which I think is supposed to be a two-Buzz version of V8. That, if it happens, will be exactly twice the geometry performance of V8.
Odyssey-- V6, V8, V12-- look on paper like they're light-years ahead of the nVidia stuff you find in the 230/330/530 systems. I say "look on paper" because I haven't used one myself. Disclaim, disclaim.
Looking over their web pages, I notice that they are careful to never even mention what clock rates the R12000 and R14000 configurations are available in.
The R12000A is available at 400MHz, and incidentially is also available as an upgrade to 2000-series systems and Onyx2s.
The R14000 is being talked about at 500MHz (this is in the marketing, but I can't remember where).
Soon enough, they're talking about an R14000A at 600MHz, too.
Parallelized software is almost always written to take advantage of N processors, for any N.
Non-parallelized software isn't, though. The worst kind of non-parallelized software isn't threaded, doesn't fork, just runs in one process forever.
A 512-processor machine will run a process like that in exactly the same amount of time as a 1-processor machine.
However, the 512-processor system will also run 511 other instances of the process in the same amount of time.
One woman, nine months, one baby. Nine women, one month, no baby. Nine women, nine months, nine babies.
You'd be surprised. The 300 MHz R12000 is a monster CPU; the enclosure with heat sink is about seven inches by three by five. You can burn your hand on one if you're not careful.
The 400 MHz R12000A, heat sink and all, fits in the palm of your hand, and barely gets warm to the touch.
When you open up the CPU brick you're amazed at all the empty space. You could store manuals and stuff in there. Then you learn that the brick has to be that big inside to accomodate the size and heat load of the four Itanium processors that will go in there later this year.
That system will be hot!
Keep in mind that until a month ago, SGI's top-of-the-line graphics board sets (MXE and IR2) were the same designs that originally appeared as Maximum IMPACT on Indigo2 and InfiniteReality on Onyx R10000. About five years ago, give or take.
During that time, entire graphics hardware companies have come and gone. The really good ones have caught up to, and occasionally surpassed, what SGI was doing in 1994. Impressive. Most impressive. ;-)
Now SGI has released Vpro, which despite having one name is actually two totally different workstation graphics designs. The Vpro you can get in the IA-32 workstations is basically high-bin commodity graphics hardware from a company that shall remain nameless.
But the Vpro that comes in the Octane2 looks outstanding. I haven't had a chance to use it yet, so I won't endorse, but the design specs for the Buzz chip make it look like InfiniteReality performance on the desktop. Way better than anything in the commodity market right now, and way more expensive, too. It's one of those things: if you have to ask how much it costs, you can't afford it.
And so we are all a part of the great Circle of Life.
1. The CDROM is on an internal FireWire bus.
2. The system disk is Fibre Channel.
3. SGI hasn't made a big deal about it yet, but the system will accept either MIPS or Intel processors in the same CPU modules. The MIPS processors come on one kind of daughtercard, and the Itaniums (Itania?) on another. You can't mix-and-match MIPS and IA-64 CPUs in the same machine, but you can mix-and-match in the same cluster.
4. The IA-64 based versions of the 3000 series will include the Linux kernel along an some IRIX compatibility layer.