Slashdot Mirror

Plus, Ann Arbor is a really nice place in the summer!

Plus, Ann Arbor is a really nice place in the summer!

Plus, Ann Arbor is a really nice place in the summer!

The usual method, which I have had sucess with, is to simply ignore the refresh rates, and specify in your favorite Distro's X configuration program that you have a 1200x1024 or whatever monitor.

Searching google suggest that people have some difficulties with the card on this laptop (not the screen per se) http://www.eecs.umich.edu/~steveh/inspiron/gw9300. html suggests a change to lilo.conf to initialise the adapter on boot.

Welcome to the world of making linux work on less than generic hardware. It's not as bad as that last snetence makes it sound actually, and is getting better all the time.

What you need to do is search ont he web and find people who have already done it and posted their results. And if you find anyhting new, post it yourself. I'd do it for mine, except for my laptop I can't better the work of Graham Williams!

Um, basics of logic? Correlation is not causation? Aren't scientists of all people supposed to know these things?

Maybe it is?

a

I'm not sure this is pro-cooperative. Oh well.

If you know you will be playing only one round, it is indeed not pro-cooperation.

The game becomes much more interesting when you play the game over and over with the same partner. Then cooperation can pay off.

There is a a vast literature on the topic; the original work on the iterated prisoner's dilemma was done by Robert Axelrod at the Univeristy of Michigan. He has also has a web site for his book The Complexity of Cooperation: Agent-Based Models of Competition and Collaboration.

For those interested in the evolution of social behavior, this stuff is fascinating. And it lends itself to all sorts of cool simulations, so there's a high geek enjoyment factor in it all.

I'm not sure this is pro-cooperative. Oh well.

If you know you will be playing only one round, it is indeed not pro-cooperation.

The game becomes much more interesting when you play the game over and over with the same partner. Then cooperation can pay off.

There is a a vast literature on the topic; the original work on the iterated prisoner's dilemma was done by Robert Axelrod at the Univeristy of Michigan. He has also has a web site for his book The Complexity of Cooperation: Agent-Based Models of Competition and Collaboration.

For those interested in the evolution of social behavior, this stuff is fascinating. And it lends itself to all sorts of cool simulations, so there's a high geek enjoyment factor in it all.

I'm not sure this is pro-cooperative. Oh well.

If you know you will be playing only one round, it is indeed not pro-cooperation.

The game becomes much more interesting when you play the game over and over with the same partner. Then cooperation can pay off.

There is a a vast literature on the topic; the original work on the iterated prisoner's dilemma was done by Robert Axelrod at the Univeristy of Michigan. He has also has a web site for his book The Complexity of Cooperation: Agent-Based Models of Competition and Collaboration.

For those interested in the evolution of social behavior, this stuff is fascinating. And it lends itself to all sorts of cool simulations, so there's a high geek enjoyment factor in it all.

AFS + Netatalk is used in many places. You can compile Netatalk with AFS support.

I haven't tried it but it is described here.

There are also AFS clients for Windows, and Samba is supposedly "AFS-Aware."

It's worth a shot.

1) We over-throw democratically elected governments

2) We sponsor right-wing death squads in Latin America

3) We don't honor our international commitments

4) We support brutal dictatoships. (That's right -- guess who helped finance the Iraqi war against Iran, before Saddam Hussein conveniently turned into our enemy?)

The list could go on and on, of course, but I should wrap it up before my electricity goes out (damn brown-outs!)

Remember what happens to users who call the BOFH?

The PDP-11 is much different - it's a "mini" and was a LOT cheaper than the 10. In fact, several of the PDP-10's used 11's as front ends. (from the development site)

Well, no. It was too daunting for me. But, I'd like to.

I recently started making a database where I could keep track of all my photos - a "photo database," if you will. (It's here, if you are curious.) I didn't store the photos in the database - primarily because there isn't enough room on the database server. I numbered all the images by hand and serve them from my personal computer - using MySQL and PHP on the database server to access them.

Anyway, I want to organize my photos into groups - and maybe even subgroups. And I want the groups to be able to overlap. I haven't done this yet, because I don't have the time to (re)impliment a file system inside the database! However, a "dbfs" seems to be exactly what I need for this task. It's close to what I envisioned.

OK, I went down to my local Laz-y-Boy Showroom to try out the chair. It was nice black leather. I liked the electrical, phone, and LAN outlets. Too bad they are tucked away in the back of the left arm pocket. The arm pocket open from the inside, up and out. I had to shift around everytime I wanted to open of close the pocket. I'm kinda skinny so wide-bodied folks won't be able to get the pockets open without getting up.
Another bad thing is the keyboard tray. It is on the left side and doesn't center on the person sitting in the chair. It is too high and any REAL ergonomic adjustments that would make it usable by us folks that suffer from carpel tunnel. For a real guide I suggest that the designers at Laz-y-Boy check out The University of Michigan's Center for Ergonomics.
The part that really put me off is that you MUST purchase the M$N/Sony WebTV bundle and subscription. Even my wife (am Internet Neophite) said she thought WebTV stinks.
Someone really needs to let marketeers know that (1) the internet is not like TV, and (2) if I wanted Intenet on my TV I would put a ATI All-In-Wonder board in my Linux box, and grab a Logitech Wireless Keyboard/Trackball combo.

Once upon a time there was a kook on the Usenet that I found amusing. His name was Robert E. McElwaine. His tagline was "UN-altered REPRODUCTION and DISSEMINATION of this IMPORTANT Information is ENCOURAGED, ESPECIALLY to COMPUTER BULLETIN BOARDS."

See the resemblance? Check out the McElwaine classics here

A CS degree may sound a little more prestigious to the first company that hires you, but I think that CE, CS, and CIS all would give you enough of the fundamentals to enable you to grow and take on anything in the software world. The real training begins, not ends with graduation.

A CS degree may sound a little more prestigious to the first company that hires you, but I think that CE, CS, and CIS all would give you enough of the fundamentals to enable you to grow and take on anything in the software world. The real training begins, not ends with graduation.

see the Rio / Vista work by Pete Chen, Dave Lowell, et al. which won best paper at SOSP several years ago...

how about smartcards????
http://www.citi.umich.edu/projects/smartcard/
http://www.citi.umich.edu/projects/smartcard/ssh-s c.html

how about smartcards????
http://www.citi.umich.edu/projects/smartcard/
http://www.citi.umich.edu/projects/smartcard/ssh-s c.html

However, it turns out that register renaming prevents a lot of the stalling that you'd expect with so few registers (write-after-write hazards vanish). Thus, while the small number of registers does degrade performance, it doesn't degrade it catastrophically.

This is false. Lack of registers increases the number of required memory operations. Not only do you increase data cache bandwidth and occupancy, you do the same on the instruction cache as well. Instructions are not free, regardless of whatever "throw hardware at it" myth is popular today. Memory instructions also create headaches for the instruction scheduler. It's much easier to do dependency checking on static indicies.

There are more things to fetch, decode, schedule, execute and retire. What's good about that?

It hurts. A lot. Check out some of our papers on the subject, especially this one, which contains many references to other work.

--

However, it turns out that register renaming prevents a lot of the stalling that you'd expect with so few registers (write-after-write hazards vanish). Thus, while the small number of registers does degrade performance, it doesn't degrade it catastrophically.

This is false. Lack of registers increases the number of required memory operations. Not only do you increase data cache bandwidth and occupancy, you do the same on the instruction cache as well. Instructions are not free, regardless of whatever "throw hardware at it" myth is popular today. Memory instructions also create headaches for the instruction scheduler. It's much easier to do dependency checking on static indicies.

There are more things to fetch, decode, schedule, execute and retire. What's good about that?

It hurts. A lot. Check out some of our papers on the subject, especially this one, which contains many references to other work.

--

A suspend option is very useful for a virtualizer, though. I use it in VMware all the time.

Interestingly enough, "instant restore" (and shutdown) for desktops/servers is available for FreeBSD now via the Rio project and probably could easily be ported to Linux.

--

Eric
--

For anyone who's interested in the physics of quantum dot self-assembly, I've posted some papers and presentations on my website. My recent research proposal deals with a physical simulation of quantum dot growth. I try to write without jargon, so they should be understandable to anyone with a science or engineering background.

Rick Wagner
Department of Chemical Engineering
University of Michigan

For anyone who's interested in the physics of quantum dot self-assembly, I've posted some papers and presentations on my website. My recent research proposal deals with a physical simulation of quantum dot growth. I try to write without jargon, so they should be understandable to anyone with a science or engineering background.

Rick Wagner
Department of Chemical Engineering
University of Michigan

- Predication. You read this part right? This means no more pipeline flushes for missed branch prediction. None. This is a big saver. Although transmetas CPU's do this (to a limited extent) with their VLIW and OS, it is still wrong on occasion (i.e., not perfect branch prediction, which itanium will effectively provide)

Um...no. :)

Itanium most definitely does NOT provide perfect branch prediction. Predication and prediction are related, but very different, beasts.

Prediction tries to get around the added penalty of a branch mispredict over and above the "obvious" penalty of executing the wrong instructions. After a branch is predicted it takes some time for it to trickle down the pipeline and compute the correct answer. If at that time (or often a bit later) the machine compares the answer and finds its prediction to be incorrect, it has already fetched, decoded and executed many instructions from the wrong path of execution. But in addition there is a penalty associated with restoring proper machine state, re-directing the fetch engine and generally getting the pipeline filled back up. This is the penalty predication eliminates.

In fact, I would say that predication performs "perfectly imperfect" branch prediction, in that the machine never executes only from the right path. Prediction trades off the wasted time executing useless instructions to remove the restore/redirect/fill penalty of a misprediction and allow additional scheduling freedom. The scheduling freedom is important for a VLIW-style machine to keep the function units busy and reduce code bloat. However, if used unwisely, a predicated chunk of code can actually execute more useless instructions than a dynamically-predicting machine would, therefore offsetting the advantages of predication. This is why predication is usually reserved for hard-to-predict branches that cover short control sequences.

- Rotating registers. Why are these great? Usually you only have a few registers with CISC architectures. RISC has quite a bit more, but they are much smaller and you end up using them as much as the less populous CISC registers.

This just doesn't make any sense to me. What do you mean by "they are much smaller?"

Having 256 registers with the ability to cycle them means you will be hitting the L1 cache even less. While the L1 is fast, it is still at least twice as slow as hitting a register directly. This is another big bonus

As you corrected below, the number of registers is orthogonal to rotating them. The big advantage of rotating registers is their use in software pipelining, as explained in the wonderful discussion above. Note that software pipelining is especially critical on a VLIW machine for the same reason prediction is -- scheduling. Is anyone noticing a trend here? :)

As far as the number of registers go, yes, it is very nice to have lots of them, but it's important to be able to use them as well. Most compilers today cannot make much use of more than about 40 general-purpose registers unless they start doing "unsafe" things like putting global values into registers or using "non-traditional" architectures like register windows. Now I'm ignoring floating-point and scientific benchmarks where software pieplining can chew up registers like nobody's business. The point is that (for example) your kernel compile will not benefit from more than about 40 registers, at least with today's technology.

Some register usage studies we've done are available here and here. In particular, I suggest looking at our workshop paper on ILP, large register file tech. report and especially at our MICRO-33 paper (to be presented next week). These papers highlight how current compilers and/or architectures are artificially crippled to shoehorn programs into 32 registers. Many more can be used if some more tricks are pulled.

It sounds like Intel wont have a top notch compiler for another few years at best, and who knows when the GNU compiler will support even a fraction of the features.

What I can't figure out is why HP isn't developing (or announcing) a compiler. They have some top-notch people there who invented most of this stuff!

One very important thing to remember about IA64 is that all these nifty features are intimately tied together. It's a bit like a house of cards in that if one fails, the others will have a hard time making up the slack. VLIW implies that good scheduling is needed. Predication allows more scheduling freedom. Software pipelining allows more scheduling freedom at the cost of more temporary registers and copying. Rotating registers gets rid of much of the copying. The ALAT allows better more scheduling freedom and possibly more loop optimizations. See how everything works together to keep the machine busy?

--

- Predication. You read this part right? This means no more pipeline flushes for missed branch prediction. None. This is a big saver. Although transmetas CPU's do this (to a limited extent) with their VLIW and OS, it is still wrong on occasion (i.e., not perfect branch prediction, which itanium will effectively provide)

Um...no. :)

Itanium most definitely does NOT provide perfect branch prediction. Predication and prediction are related, but very different, beasts.

Prediction tries to get around the added penalty of a branch mispredict over and above the "obvious" penalty of executing the wrong instructions. After a branch is predicted it takes some time for it to trickle down the pipeline and compute the correct answer. If at that time (or often a bit later) the machine compares the answer and finds its prediction to be incorrect, it has already fetched, decoded and executed many instructions from the wrong path of execution. But in addition there is a penalty associated with restoring proper machine state, re-directing the fetch engine and generally getting the pipeline filled back up. This is the penalty predication eliminates.

In fact, I would say that predication performs "perfectly imperfect" branch prediction, in that the machine never executes only from the right path. Prediction trades off the wasted time executing useless instructions to remove the restore/redirect/fill penalty of a misprediction and allow additional scheduling freedom. The scheduling freedom is important for a VLIW-style machine to keep the function units busy and reduce code bloat. However, if used unwisely, a predicated chunk of code can actually execute more useless instructions than a dynamically-predicting machine would, therefore offsetting the advantages of predication. This is why predication is usually reserved for hard-to-predict branches that cover short control sequences.

- Rotating registers. Why are these great? Usually you only have a few registers with CISC architectures. RISC has quite a bit more, but they are much smaller and you end up using them as much as the less populous CISC registers.

This just doesn't make any sense to me. What do you mean by "they are much smaller?"

Having 256 registers with the ability to cycle them means you will be hitting the L1 cache even less. While the L1 is fast, it is still at least twice as slow as hitting a register directly. This is another big bonus

As you corrected below, the number of registers is orthogonal to rotating them. The big advantage of rotating registers is their use in software pipelining, as explained in the wonderful discussion above. Note that software pipelining is especially critical on a VLIW machine for the same reason prediction is -- scheduling. Is anyone noticing a trend here? :)

As far as the number of registers go, yes, it is very nice to have lots of them, but it's important to be able to use them as well. Most compilers today cannot make much use of more than about 40 general-purpose registers unless they start doing "unsafe" things like putting global values into registers or using "non-traditional" architectures like register windows. Now I'm ignoring floating-point and scientific benchmarks where software pieplining can chew up registers like nobody's business. The point is that (for example) your kernel compile will not benefit from more than about 40 registers, at least with today's technology.

Some register usage studies we've done are available here and here. In particular, I suggest looking at our workshop paper on ILP, large register file tech. report and especially at our MICRO-33 paper (to be presented next week). These papers highlight how current compilers and/or architectures are artificially crippled to shoehorn programs into 32 registers. Many more can be used if some more tricks are pulled.

It sounds like Intel wont have a top notch compiler for another few years at best, and who knows when the GNU compiler will support even a fraction of the features.

What I can't figure out is why HP isn't developing (or announcing) a compiler. They have some top-notch people there who invented most of this stuff!

One very important thing to remember about IA64 is that all these nifty features are intimately tied together. It's a bit like a house of cards in that if one fails, the others will have a hard time making up the slack. VLIW implies that good scheduling is needed. Predication allows more scheduling freedom. Software pipelining allows more scheduling freedom at the cost of more temporary registers and copying. Rotating registers gets rid of much of the copying. The ALAT allows better more scheduling freedom and possibly more loop optimizations. See how everything works together to keep the machine busy?

--

- Predication. You read this part right? This means no more pipeline flushes for missed branch prediction. None. This is a big saver. Although transmetas CPU's do this (to a limited extent) with their VLIW and OS, it is still wrong on occasion (i.e., not perfect branch prediction, which itanium will effectively provide)

Um...no. :)

Itanium most definitely does NOT provide perfect branch prediction. Predication and prediction are related, but very different, beasts.

Prediction tries to get around the added penalty of a branch mispredict over and above the "obvious" penalty of executing the wrong instructions. After a branch is predicted it takes some time for it to trickle down the pipeline and compute the correct answer. If at that time (or often a bit later) the machine compares the answer and finds its prediction to be incorrect, it has already fetched, decoded and executed many instructions from the wrong path of execution. But in addition there is a penalty associated with restoring proper machine state, re-directing the fetch engine and generally getting the pipeline filled back up. This is the penalty predication eliminates.

In fact, I would say that predication performs "perfectly imperfect" branch prediction, in that the machine never executes only from the right path. Prediction trades off the wasted time executing useless instructions to remove the restore/redirect/fill penalty of a misprediction and allow additional scheduling freedom. The scheduling freedom is important for a VLIW-style machine to keep the function units busy and reduce code bloat. However, if used unwisely, a predicated chunk of code can actually execute more useless instructions than a dynamically-predicting machine would, therefore offsetting the advantages of predication. This is why predication is usually reserved for hard-to-predict branches that cover short control sequences.

- Rotating registers. Why are these great? Usually you only have a few registers with CISC architectures. RISC has quite a bit more, but they are much smaller and you end up using them as much as the less populous CISC registers.

This just doesn't make any sense to me. What do you mean by "they are much smaller?"

Having 256 registers with the ability to cycle them means you will be hitting the L1 cache even less. While the L1 is fast, it is still at least twice as slow as hitting a register directly. This is another big bonus

As you corrected below, the number of registers is orthogonal to rotating them. The big advantage of rotating registers is their use in software pipelining, as explained in the wonderful discussion above. Note that software pipelining is especially critical on a VLIW machine for the same reason prediction is -- scheduling. Is anyone noticing a trend here? :)

As far as the number of registers go, yes, it is very nice to have lots of them, but it's important to be able to use them as well. Most compilers today cannot make much use of more than about 40 general-purpose registers unless they start doing "unsafe" things like putting global values into registers or using "non-traditional" architectures like register windows. Now I'm ignoring floating-point and scientific benchmarks where software pieplining can chew up registers like nobody's business. The point is that (for example) your kernel compile will not benefit from more than about 40 registers, at least with today's technology.

Some register usage studies we've done are available here and here. In particular, I suggest looking at our workshop paper on ILP, large register file tech. report and especially at our MICRO-33 paper (to be presented next week). These papers highlight how current compilers and/or architectures are artificially crippled to shoehorn programs into 32 registers. Many more can be used if some more tricks are pulled.

It sounds like Intel wont have a top notch compiler for another few years at best, and who knows when the GNU compiler will support even a fraction of the features.

What I can't figure out is why HP isn't developing (or announcing) a compiler. They have some top-notch people there who invented most of this stuff!

One very important thing to remember about IA64 is that all these nifty features are intimately tied together. It's a bit like a house of cards in that if one fails, the others will have a hard time making up the slack. VLIW implies that good scheduling is needed. Predication allows more scheduling freedom. Software pipelining allows more scheduling freedom at the cost of more temporary registers and copying. Rotating registers gets rid of much of the copying. The ALAT allows better more scheduling freedom and possibly more loop optimizations. See how everything works together to keep the machine busy?

--

- Predication. You read this part right? This means no more pipeline flushes for missed branch prediction. None. This is a big saver. Although transmetas CPU's do this (to a limited extent) with their VLIW and OS, it is still wrong on occasion (i.e., not perfect branch prediction, which itanium will effectively provide)

Um...no. :)

Itanium most definitely does NOT provide perfect branch prediction. Predication and prediction are related, but very different, beasts.

Prediction tries to get around the added penalty of a branch mispredict over and above the "obvious" penalty of executing the wrong instructions. After a branch is predicted it takes some time for it to trickle down the pipeline and compute the correct answer. If at that time (or often a bit later) the machine compares the answer and finds its prediction to be incorrect, it has already fetched, decoded and executed many instructions from the wrong path of execution. But in addition there is a penalty associated with restoring proper machine state, re-directing the fetch engine and generally getting the pipeline filled back up. This is the penalty predication eliminates.

In fact, I would say that predication performs "perfectly imperfect" branch prediction, in that the machine never executes only from the right path. Prediction trades off the wasted time executing useless instructions to remove the restore/redirect/fill penalty of a misprediction and allow additional scheduling freedom. The scheduling freedom is important for a VLIW-style machine to keep the function units busy and reduce code bloat. However, if used unwisely, a predicated chunk of code can actually execute more useless instructions than a dynamically-predicting machine would, therefore offsetting the advantages of predication. This is why predication is usually reserved for hard-to-predict branches that cover short control sequences.

- Rotating registers. Why are these great? Usually you only have a few registers with CISC architectures. RISC has quite a bit more, but they are much smaller and you end up using them as much as the less populous CISC registers.

This just doesn't make any sense to me. What do you mean by "they are much smaller?"

Having 256 registers with the ability to cycle them means you will be hitting the L1 cache even less. While the L1 is fast, it is still at least twice as slow as hitting a register directly. This is another big bonus

As you corrected below, the number of registers is orthogonal to rotating them. The big advantage of rotating registers is their use in software pipelining, as explained in the wonderful discussion above. Note that software pipelining is especially critical on a VLIW machine for the same reason prediction is -- scheduling. Is anyone noticing a trend here? :)

As far as the number of registers go, yes, it is very nice to have lots of them, but it's important to be able to use them as well. Most compilers today cannot make much use of more than about 40 general-purpose registers unless they start doing "unsafe" things like putting global values into registers or using "non-traditional" architectures like register windows. Now I'm ignoring floating-point and scientific benchmarks where software pieplining can chew up registers like nobody's business. The point is that (for example) your kernel compile will not benefit from more than about 40 registers, at least with today's technology.

Some register usage studies we've done are available here and here. In particular, I suggest looking at our workshop paper on ILP, large register file tech. report and especially at our MICRO-33 paper (to be presented next week). These papers highlight how current compilers and/or architectures are artificially crippled to shoehorn programs into 32 registers. Many more can be used if some more tricks are pulled.

It sounds like Intel wont have a top notch compiler for another few years at best, and who knows when the GNU compiler will support even a fraction of the features.

What I can't figure out is why HP isn't developing (or announcing) a compiler. They have some top-notch people there who invented most of this stuff!

One very important thing to remember about IA64 is that all these nifty features are intimately tied together. It's a bit like a house of cards in that if one fails, the others will have a hard time making up the slack. VLIW implies that good scheduling is needed. Predication allows more scheduling freedom. Software pipelining allows more scheduling freedom at the cost of more temporary registers and copying. Rotating registers gets rid of much of the copying. The ALAT allows better more scheduling freedom and possibly more loop optimizations. See how everything works together to keep the machine busy?

--

- Predication. You read this part right? This means no more pipeline flushes for missed branch prediction. None. This is a big saver. Although transmetas CPU's do this (to a limited extent) with their VLIW and OS, it is still wrong on occasion (i.e., not perfect branch prediction, which itanium will effectively provide)

Um...no. :)

Itanium most definitely does NOT provide perfect branch prediction. Predication and prediction are related, but very different, beasts.

Prediction tries to get around the added penalty of a branch mispredict over and above the "obvious" penalty of executing the wrong instructions. After a branch is predicted it takes some time for it to trickle down the pipeline and compute the correct answer. If at that time (or often a bit later) the machine compares the answer and finds its prediction to be incorrect, it has already fetched, decoded and executed many instructions from the wrong path of execution. But in addition there is a penalty associated with restoring proper machine state, re-directing the fetch engine and generally getting the pipeline filled back up. This is the penalty predication eliminates.

In fact, I would say that predication performs "perfectly imperfect" branch prediction, in that the machine never executes only from the right path. Prediction trades off the wasted time executing useless instructions to remove the restore/redirect/fill penalty of a misprediction and allow additional scheduling freedom. The scheduling freedom is important for a VLIW-style machine to keep the function units busy and reduce code bloat. However, if used unwisely, a predicated chunk of code can actually execute more useless instructions than a dynamically-predicting machine would, therefore offsetting the advantages of predication. This is why predication is usually reserved for hard-to-predict branches that cover short control sequences.

- Rotating registers. Why are these great? Usually you only have a few registers with CISC architectures. RISC has quite a bit more, but they are much smaller and you end up using them as much as the less populous CISC registers.

This just doesn't make any sense to me. What do you mean by "they are much smaller?"

Having 256 registers with the ability to cycle them means you will be hitting the L1 cache even less. While the L1 is fast, it is still at least twice as slow as hitting a register directly. This is another big bonus

As you corrected below, the number of registers is orthogonal to rotating them. The big advantage of rotating registers is their use in software pipelining, as explained in the wonderful discussion above. Note that software pipelining is especially critical on a VLIW machine for the same reason prediction is -- scheduling. Is anyone noticing a trend here? :)

As far as the number of registers go, yes, it is very nice to have lots of them, but it's important to be able to use them as well. Most compilers today cannot make much use of more than about 40 general-purpose registers unless they start doing "unsafe" things like putting global values into registers or using "non-traditional" architectures like register windows. Now I'm ignoring floating-point and scientific benchmarks where software pieplining can chew up registers like nobody's business. The point is that (for example) your kernel compile will not benefit from more than about 40 registers, at least with today's technology.

Some register usage studies we've done are available here and here. In particular, I suggest looking at our workshop paper on ILP, large register file tech. report and especially at our MICRO-33 paper (to be presented next week). These papers highlight how current compilers and/or architectures are artificially crippled to shoehorn programs into 32 registers. Many more can be used if some more tricks are pulled.

It sounds like Intel wont have a top notch compiler for another few years at best, and who knows when the GNU compiler will support even a fraction of the features.

What I can't figure out is why HP isn't developing (or announcing) a compiler. They have some top-notch people there who invented most of this stuff!

One very important thing to remember about IA64 is that all these nifty features are intimately tied together. It's a bit like a house of cards in that if one fails, the others will have a hard time making up the slack. VLIW implies that good scheduling is needed. Predication allows more scheduling freedom. Software pipelining allows more scheduling freedom at the cost of more temporary registers and copying. Rotating registers gets rid of much of the copying. The ALAT allows better more scheduling freedom and possibly more loop optimizations. See how everything works together to keep the machine busy?

--

.coop: The most ridiculous TLD of the bunch...some ICANN folks flew the coop when they chose to approve this one...coop is a totally useless TLD.

aren't you ignorant?
I live in a housing cooperative in Chicago and I've found it very rewarding.
Plus there was a story about spindletop, the open-source hardware thingie, earlier this week that runs on coop principles

from http://www.umich.edu/~nasco/main_coop.h tml :
What is a Co-op?

A cooperative is a business controlled by the people who use it. It is a democratic organization whose earnings and assets belong to its members. By patronizing and becoming an active member of a co-op, you invest yourself with the power to shape that business. You control the politics and economics of what is truly your organization.

This localized member control allows co-ops to be as varied as the people they serve. Thus, there are different types of co-ops including: food co-ops, housing co-ops, arts and crafts co-ops, book co-ops, bakery co-ops, bike co-ops, farm co-ops, rural electric co-ops, financial co-ops (credit unions), and insurance co-ops. And each of these has a flavor of its own, reflective of the desires of its individual memberships. Despite the diversity in type and tradition of co-ops, most have several things in common, particularly the ideals and principles from which they emerge.

not "totally useless" at all

...was the headline in the campus newspaper for our own local anime festival. The article is good for many laughs.

He's right. Learning some things will definitely help the way you think about things. The incredibly strong typing of something like pascal will definitely kick your *ss if you've been doing nothing but C for a while, and I think that's actually a Good Thing. Learning Eiffel if you already know smalltalk is a very different experience.

Even something like Algol will probably change your views and get you closer to the hardware in many respects (not that you can get Algol to run on most machines anymore....;-)

What about Ada? Programming by Contract really will teach you something serious about how you actually interact with the rest of your application, and while you'll curse it ("I KNOW what I'm trying to do and it's correct, dammit!") you'll be happier for learning it. Older, but happier.

And as long as the languages keep coming, there'll pretty much never be a chance to really run out.

My list would include:

• C
• C++
• Pascal& lt;/a>
• Lisp (anything but eLisp)
• Python
• Perl
• Smalltalk
• ML
• prolog&l t;/a>
• Eiffel
• Ada
• a RISC Assembler
• Cobol (those who do not learn from history are doomed to repeat it)
• Java
• BASIC (the non-Visual kind).

Will these do?

http://www -pe rsonal.umd.umich.edu/~nhughes/htmldocs/deepthought s.html

J

Only one problem... it didn't happen.

Instead, IBM's Ope nAF S web site contains only a FAQ and documention. The downloads page contains only: "Source Downloads are not yet available. Please check back later!"

Unfortantly, the FAQ page still doesn't answer the frequently asked question on everyone's minds: When can we expect the source code or was the announcements for vapor-code?

In the mean time, the Arla, NFS v4 and Coda projects provide alternatives to OpenAFS while also delivering something International Business Machines has failed to follow through on... providing the source code.

The Everest Story got 2.1 Million hits in 12 hours. Just in case this one ever gets truly slashdotted (it's slow at 2:45am EST) here are copies of the files on a nice, quick connection.

Build1a.avi
Build5a.avi
Car7a.avi ;
Car9a.avi ;
Car8a.avi ;

The Everest Story got 2.1 Million hits in 12 hours. Just in case this one ever gets truly slashdotted (it's slow at 2:45am EST) here are copies of the files on a nice, quick connection.

Build1a.avi
Build5a.avi
Car7a.avi ;
Car9a.avi ;
Car8a.avi ;

The Everest Story got 2.1 Million hits in 12 hours. Just in case this one ever gets truly slashdotted (it's slow at 2:45am EST) here are copies of the files on a nice, quick connection.

Build1a.avi
Build5a.avi
Car7a.avi ;
Car9a.avi ;
Car8a.avi ;

The Everest Story got 2.1 Million hits in 12 hours. Just in case this one ever gets truly slashdotted (it's slow at 2:45am EST) here are copies of the files on a nice, quick connection.

Build1a.avi
Build5a.avi
Car7a.avi ;
Car9a.avi ;
Car8a.avi ;

The Everest Story got 2.1 Million hits in 12 hours. Just in case this one ever gets truly slashdotted (it's slow at 2:45am EST) here are copies of the files on a nice, quick connection.

Build1a.avi
Build5a.avi
Car7a.avi ;
Car9a.avi ;
Car8a.avi ;

http://brighton.ncsa.uiuc.edu/~prajlich/caveQuake/

I'm not sure how much the whole system would cost, but you can read the specs on the site.

I know someone at the University of Michigan that let a group of us play around with it. Very cool stuff. It's really strange becoming a character in Quake.

I've read rumors that someone is working on a Half-Life port for this system. Imagine actually becoming Gordon Freeman.

The sundown machines are behind a firewall, so pinging them would be futile. In addition to that, this test occured about two weeks ago, so you couldn't do anything with it. Compaq (seeing as Digital is owned by them, not on their own) doesn't let their machines that are as big as three refridgerators (sp?) sit running all the time (something about power consumption comes to mind...). An intresting thing about these machines is that they are prototypes. They are for sale (they model type), but they cost somewhere in the 2 Million Dollar range. As far as the Linux Scalability issue, here is a really intresting report from a UofM alumni, now a worker for Compaq on their zk3 campus (practically Hemos's back yard, it's in New Hampsire I belive). Yes it is only a coincidence.

-Mr. Macx

Moof!
******

Rodney Brooks has been working on his Cog project for the last several years, but before that he worked on a very similar idea to yours, called the subsumption architecture. A good quick overview can be gotten from one of Brooks's early papers, Elephants Don't Play Chess.

OK, let's see here:

• So many CAPITAL LETTERS whenever he's REALLY CONCERNED that you DON'T GET HIS POINT. The guy reads like Robert McElwaine. You know, "UN-altered REPRODUCTION and DISSEMINATION of this IMPORTANT Information is ENCOURAGED."

• Abysmal English skills. This guy's a CEO?
  • "reversed engineered"?
  • "intellectually property"?
  • "we loose any remedies"?
  • "the Linux Community could of inadvertently" Could OF?
  This in just two paragraphs. Jesus H. Christ, I've seen kids in grade school with better English skills. Call FuckedCompany now!

• "if we don't PROTECT our IP, we loose any remedies under law to PROTECT our IP"

  No, you dipsticks, that's trademark law. If I create something called the CueCat (without the dippy colon in front of the "C"), and it's a plastic cat-shaped barcode thingy, and he doesn't sue me, he stands to lose the right to use the word ":CueCat" to describe his plastic cat-shaped barcode thingy.

Netpliance (with the I-Opener and the resulting arms race of BIOS upgrades and anti-hack measures they wasted time with) missed the clue train, but at least can claim they faced a genuine threat. And even they didn't try to sue anyone.

But these guys, good Lord, they haven't just missed the Cluetrain, they aren't even at the friggin' station!

In closing, I'm pretty sure think there's more than one reason the "threatening letter" was merely a vaguely-threatening letter and not a real cease-and-desist.

1) As flamed ad infinitum on /. last week, any case against the developers of :CueCat(tm)-related hacks is likely to be extremely weak.

2) If Digital Convergence doesn't even have proofreaders, what the fuck are they using for corporate counsel?

3) And on that corporate counsel, if they do have corporate counsel, could one of them kindly bitchslap their management team and explain the difference between trademark law and "whatever the ring-tailed rambling fuck" (that's waht I'm calling it, because they've utterly failed to explain it - again) they're trying to use as grounds to sue an open-source developer with a funny domain name?

Certainly, there are manmade objects that have lasted that long.
Just think of all the paleolithic stone tools that have been found. They're pretty primitive, but there can be no doubt that they are manmade.

But, this is beside the point - the real question is whether humanity will even be around, 50,000 years from now.
After all, even if you're not a subscriber to linear evolutionary progression, and not the more radical theories of the imminence of the Singularity, you have to admit that humanity has changed a great deal since the Paleolithic. It is only reasonable to assume that the same will be true of the coming 50 millennia.

-Ravn (born_to_live_forever)

You asked for it, you got it.
More Schoolhouse Rock then you can shake a verb at.

Schoolhouse Rock - everything about Schoolhouse Rock, including the lyrics, sound files, history, events, products, and more.
Schoolhouse Rock [Yak.net] - Lyrics
Schoolhouse Rock - More Lyrics.
Unofficial SHR - Even more Lyrics and links.
SHR Sound clips - Plays SHR sound clips using a Java applet.
And if all that isn't quite enought for you.. here is a page for info on Schoolhouse Rock Live.

i believe the university of michigan is a repository of all u.s. dissertations (for perhaps 40+ years); though i couldn't find it on the site, might be a start.

Last year, I group of us at school (U of Michigan) did a project to do generic distributed computing... We didn't do anything with the project after the semester but maybe it could be revived now... It's basically a client-server system to apply distributed computing to different tasks..... the URL for the project homepage is here

No, I don't forget. I work for the National Archive of Criminal Justice Data and I have heard and seen things that make me want to cry for people's ignorance, stupidity, and need to control others. Before I started to work here, I had much firmer views in terms of censorship and the means I considered necessary to protect children. (I also didn't realise how much "reverse" domestic abuse goes on, either, you're right-- and here's a page I put up about that last year.)

I have heard too many people who are in charge of their local legislation demand restrictions that I disagree with to be willing to even consider a federal set of standards. Or even a federal rule that can be interpreted more loosely, community by community.

You would (I hope) be shocked by some of the things that communities will do to rationalise their opinions. They know that they disapprove of something, and so they find a way or a reason or a loophole that will allow them to make that thing illegal in their small area. People didn't come to America originally to advocate religious freedom; they came to a new world to practice their own religion and teach it to their children without interference. The origional colonies were incredibly segregated by religious beliefs. This this is irrelevant? You're wrong. The U.S. today continues to be a fractious bag of different religious, moral, ethical, and cultural beliefs, and everyone seems to think that having the right to their beliefs means that everyone else has to respect those specific beliefs by not making you face any others. If you want the right to choose for yourself, you have to give that right to others, too.

The media is very slanted, this is very true. You can't always get all the "truth" you want, but there is very little information that is actually restricted. (Though I agree that too much of it is avoided and more of it is forcibly promoted.) These things, though, usually come because you're listening to a slanted source (and all sources are slanted, just different directions and for different reasons.) If you want to go out and find information, you should be able to. You are able to if you put some effort into it. For the time being. Let us each make as informed a decision as we are capable of, and leave it at that. Let me restrict my own kids-- you and your morals, you stay away from them.