Re:Use of Debian -- modems???
on
Debian Freezing
·
· Score: 1
Oh sure, no question. I was assuming a monolithic upgrade with dist-upgrade. I'm just saying that maybe dist-upgrade should be smarter than it is. Perhaps there is some technical issue I don't know about.
--
Re:Use of Debian -- modems???
on
Debian Freezing
·
· Score: 1
When you upgrade, the packages are downloaded into/var/apt/cache (or something like that). Thus an interrupted download is no problem. You'll just start with the package you were on when the connection was broken. I do this all the time to modem upgrade over a couple of days.
The downside is that apt doesn't actually install anything until the download is complete. IMHO this is broken, because it can require enormous amounts of disk space. apt should be smart enough to get all the dependencies for a package and then install it immediately.
The upside is that apt is smart enough to figure out the dependencies, download and install everything for you. Automatically. Couldn't be more painless.
I highly recommend it, and am definately going to try out potato once it's stable (probably on my Alpha as well... it's running RedHat 5.1 right now and is in dire need of an upgrade)
Note that "unstable" really isn't all that unstable, working-wise. Debian has been the most stable, reliable distribution I've ever used. "unstable" is called that mostly because the packages change daily -- or hourly. They haven't been fully tested with the rest of the system, but they work 99% of the time anyway. "stable" tends to get out of date, so I've kept my system in line with "unstable" and have had zero problems.
In my experience, potato has been far more stable than any other distro I've run (haven't tried the latest Red Hats or Mandrake yet, though).
The only drawback with Debian for me was having to sit through the install and answer questions for many packages. That is being worked on however. I don't know what the status for potato is. Can one of the developers comment?
Writing a piece of code to run well on a Cray or Convex is not easy. You need to worry about all sorts of nasties like NUMA, messaging speed and so forth. Even non-parallel code must be concerned about I/O time. Databases have used their own raw partitions and caching schemes for years.
Even some PC software is written with the memory heirarchy in mind. You want your working set to fit in the cache, page table or whatever. RAMBUS just presents a new organization for which to optimize. Writing good code that takes advantage of the hardware makes a big difference. It's for this reason that programmers need to understand the hardware they're working with.
I'm not saying they will beat anyone. What I'm saying is that Intel is concerned. Nothing more, nothing less.
To me, their fears seem justified assuming PSII is everything it's hyped to be.
It's still "only" a console. But does that really matter these days? How many people are playing games on their Palm Pilots? How many are screaming for e-mail, web and general networking support?
Look at what Apple and NEC are putting out. They're practically consoles now, except for an excessively long boot process and unstable OS.
The fact that you can't open up a console does not render it useless as a home PC (or even a light work terminal). I'd argue it makes it a better home PC, as today's $400 computers tend to be disposable anyway.
According to an Intel employee who recently visited these parts, Intel is not overly concerned about AMD.
What they are concerned about is Playstation II. If Sony can actually mass-produce the Emotion Engine, it is going to give Intel (and other chip makers) serious headaches.
What does the average consumer want? A cheap, easy-to-set-up all-in-one word processor/game console/internet application. Playstation II fits the bill. There's no OS to hassle with, no IRQ's and memory conflicts. Just turn it on and it goes. It's what the iMac dreams to be.
AMD may have come out with a superior desktop processor just at the point when it doesn't matter anymore.
GCC is not a good example of a code fork problem. If anything, it proves the value of the ability to fork.
GCC became forked because the FSF sat on changes that were being submitted. For years. EGCS was an attempt to get working C++ code out to the general public (Cygnus had been releasing it as part of GNUPro for some time). EGCS literally saved the project I was working on and I'm sure it did the same for others.
Now that EGCS and GCC are back together as one, some of the other forks are being rolled in (Haifa, FORTRAN and Ada for sure, though I don't know what's happening with PGCC).
The act of forking caused the FSF to get off their collective duff and do something. That's a Good Thing.
Linux would not be forked for the same reason (I hope!). It would be forked if Linus and others didn't like the TurboLinux changes. This (hopefully) prevents cruft from entering the mainstream kernel.
GCC is not a good example of a code fork problem. If anything, it proves the value of the ability to fork.
GCC became forked because the FSF sat on changes that were being submitted. For years. EGCS was an attempt to get working C++ code out to the general public (Cygnus had been releasing it as part of GNUPro for some time). EGCS literally saved the project I was working on and I'm sure it did the same for others.
Now that EGCS and GCC are back together as one, some of the other forks are being rolled in (Haifa, FORTRAN and Ada for sure, though I don't know what's happening with PGCC).
The act of forking caused the FSF to get off their collective duff and do something. That's a Good Thing.
[I tried posting earlier but it didn't take. How odd. Maybe it'll show up later. If so, tough.:)]
I don't really understand the point of this article. Jon seems to want to get the message across that media doesn't trigger violence. Granted. Whether it dulls the emotional reaction to violence is, I think, an open question, but that's another discussion.
Basing this article on a "Christian" action game is pointless at best and inflammatory at worst. Jon makes the mistake (as many others do) of assuming that the extreme right-wing speaks for all of Christianity when he writes,
Religion and freedom have never really gotten along, from the persecution of Galileo to the demands by Orthodox Jews that Jerusalem shut down its cinemas on Friday night to Islamic attacks on writers and reporters in some Middle Eastern countries. Technology, a disseminator of so much information, a force for freedom, has always come under fire as Satan's ally.
Someone forgot to tell me, apparently. Christianity is not about repression and persecution and neither are Islam or Judaism. It's amazing that anyone can hold this view anymore. As our parish pastor once said, there's a difference between religion and faith, and sometimes religion gets in the way of faith.
But without question, many geeks are already on the wrong path, loving stuff like "South Park" and "The Simpsons" as they do, Satan's productions all. (He was even in the last "South Park" movie.)
Now this is simply absurd. Anyone who thinks watching The Simpsons or South Park condemns one to the depths of hell has the wrong priorities. I personally don't care for South Park, but I can appreciate the humor.
tumeric is talking about the CDC 6600 (Scoreboarding) and the IBM 360/91 (Tomasulo). I believe Cray was still at CDC for the 6600 (but someone correct me if I'm wrong).
The rule in computer architecture seems to be that everything was done back in the '60's and IBM holds all the patents.:)
None of the stuff discussed in the artical was particularly revolutionary at the time of RISC I. Bringing it all together on a microprocessor was the missing element.
People talk a lot about (digital) "hardware" and "software," but they're really the same thing (well, if you ignore analog effects). Understanding how the hardware works can provide great insight about how to design software. Hardware design was probably the first type of "object-oriented" or "modular" programming. It's a lot of high-level design, specifying interfaces and plugging components together.
And some of the best hacks were done in hardware.:)
A big issue in digital logic design is latency and synchronization, which is also an issue in software working with ever increasingly, pervasively, parallel systems. People who are good at one of these fields will have developed a good skill set that should transfer well to the other.
Bingo. A microprocessor is really just one big parallel program.
Computer Architecture: A Quantitative Approach by Hennessy and Patterson
This one gets into a more detail on how modern processors work, with branch prediction and dynamic scheduling. It also covers everything in the "Organization and Design" book.
These books assume the reader knows something about digital logic design. Johnson's Superscalar Microprocessor Design is also a good one.
I actually asked someone from Intel about this and what they were doing about it.
The view from this (non-official) person was that AMD is going to be too late. No company will want to produce multiple versions of its 64-bit code (operating system or otherwise).
He's got a point. Just look at Windows and how the various ports have started to disappear. Yes, of course Linux, *BSD and others may be ported. We'll have to see what the fallout will be.
What you describe is essentially the initial MIPS project started by Hennessy at Stanford. MIPS is an acronym for "Microprocessor without Interlock(ed) Pipe Stages."
The problem is, it's very tough for the compiler to do a good job scheduling statically. Most delay slots are never filled. Much more information is available at run-time (in a limited window for the hardware), so it can make some better decisions than a static compiler can.
However, the compiler can look much further ahead than the processor, so it seems that some sort of hybrid solution is called for. Whether that involves profiling and feedback optimization a la FX!32 and others, new ISA or something else is still an open question, I think. IA64 has made steps in this direction.
Some work has been done with this. A threaded architecture might be useful here.
Predication works on a similar assumption. When hard-to-predict branches are predicated, the hardware wastes some time executing useless instructions, but avoids the mispredict overhead of refetch and/or reexecution of everything after the branch.
While marketing probably plays a (small) part, probably more importantly, the parallelism just isn't there. At least not to any degree that the hardware can see it.
Branch prediction is the major problem. Sure, predicting one branch may work 90% of the time, but when you start talking about wide machines, all of a sudden you're predicting 2, 3 or 4+ branches at once. Your prediction rate goes way down. Fast.
A student here did a study that showed >50% of the processor cycles were spent recovering from branches. And I don't think the study was on a particularly aggressive machine (though I can check that).
The encouraging this is, if we can get around branch problems (and that's a huge if), the parallelism is there. But not where the machine can see it. There was a study exploring the limits of ILP in Spec95 (yes, not realistic benchmarks, but it's what was available). If you assume perfect prediction (yes, completely unrealistic, but this was a limit study) and remove the stack pointer (which is often on the critical path of instruction dependencies), you can get parallelism in the hundreds (for integer programs) or thousands (for floating point stuff) of instructions.
But there's catch. If your instruction window is 10k instructions wide or less (a completely unrealistic size, by the way), the parallelism drops by an order of magnitude or more. The hardware doesn't have enough context to see it. But the compiler does. Think about forking threads on function calls when you can and you'll see where I'm going.
Some kind of model like Simultaneous MultiThreading may be needed in the future. Compaq is working hard on this for the Alpha.
What's important to remember is that we've received the biggest speed boosts from the process guys. Cranking the clock and packing in gates (i.e. cache) does much more than adding another pipeline. Remember Moore's Law.
Why is this myth still perpetuated? I'm not talking about men in particular, but engineers in general.
I'm working with 3-4 other graduate students very closely and know at least 10-20 others very well. There's not a single one I know who, after a hard day's work of hacking, goes home and immediately fires up a computer. And grad students tend to be pretty serious hackers.
Everyone I know here has hobbies that have little or nothing to do with electronics. Volleyball, fishing, music, dancing, acting, you name it.
Society seems to view engineers as very one-dimensional people. I submit that engineers are some of the most well-rounded individuals around. They're just very dedicated to their work and thus seem to be completely immersed in it.
Agreed. This is just a great book. I recently re-read it last year (it was also required reading in one of my college courses).
Not only does the book present a gripping account of the engineering problems that were encountered and the various solutions that were developed, it also gives a great look into the personalities involved. This is a very human story, with all its great blunders and triumphs.
My favorite part of the story is the description of the hiring/interviewing procedure for the project. New grads should pay attention to what these guys were looking for. You might be surprised.
This is not a new idea. Emulating the lesser used instructions has been done by lots of processors. The G5 (S/390) has the ability to trap on any opcode and emulate it in software. Makes for an easy patch system to fix processor defects.
IIRC some of the later VAXen did this (micro-VAX, maybe?) and has been pointed out, Apple did this in the transition to PowerPC. Intel might do this in the future to allow flexibility in marketing.
HP is doing this for Merced to execute PA-RISC binaries, and Dynamo may be what they're using to do it.
The x86 instructions are translated in to micro-OPs or macro-OPs depending on if you are talking to AMD or Intel, and then it is these sub instructions that are executed. If They would provide a way to execute these instructions without x86 translation, you would have a very powerful RISC/CISC platform.
This was the original philosophy of RISC - expose what would have been microcode to the compiler and let it go to town.
Really the only differences between x86 and current "RISC" machines are
Variable-length instruction encoding
Complex memory addressing
Prefixes like no tomorrow
Really none of these is inherently bad.
Variable-length instructions can improve I-cache performance. IBM has been using them for years in the 360 and beyond. x86 seems to have gone too far by allowing from 1-15 byte instructions, but a few different sizes isn't so bad.
offset+base+index*scale address can in fact be used by a compiler. Think of accessing a field from an array of structs. Once instruction can do what takes four or five on a RISC machine. Now that one instruction may have a (slightly) higher latency than any one of the four or five RISC instructions, but when you start considering fetch time, the win isn't clear.
Block copy instructions can be very nice for a compiler. Take a look at what gcc does on a MIPS. It inserts a call to memcpy! None of that nonsense is necessary on the x86.
AMD's problem is they'll either have to convince Microsoft to support their new instruction set and implement backwards compatibility, or they'll have to write all of that themselves. Anyone know if this can be done in a way that's OS-independent, or will the backwards-compatibility features need to be OS-specific?
One way to do it is with a virtual machine - not in the sense of Java, but in the sense of OS/360-370, etc. That is, you have a Virtual Machine Monitor (VMM) at the lowest level and the OS's run on top of that. Note the plural. Not only do you have the ability to trap instructions and run them in software in an OS-neutral fashion, you can run multiple OS's simultaneously. There are lots of other benefits, like being able to swap in a new OS without disturbing existing setups and so forth.
Intel, in fact, is working on such a beast. I'm guessing it's for Merced, being an enterprise chip. They also want to use it for marketing purposes, though. Think about a Pentium III without any MMX/KNI/whatever graphics instructions in hardware. You do it in software, get the same functionality and can market your chip for really low-end systems.
I'm a bit confused. Twice the number of instructions (or the same number of 64-bit adds) doesn't matter if I'm still constrained by 32-bit addressing. New addressing modes => new instructions. It's the choice and coding of these instructions that I'm interested in.
AMD should be able to get away with only adding 64-bit instructions for the common x86 operations. There's something like 15,000 different x86 instructions, of which maybe a couple hundred are used extensively (if that). Take this subset, make it orthogonal (and do the same for the 32-bit versions), and you'd be getting a decent chip. Do the rest in software.
Slashdot Mirror
--
The downside is that apt doesn't actually install anything until the download is complete. IMHO this is broken, because it can require enormous amounts of disk space. apt should be smart enough to get all the dependencies for a package and then install it immediately.
The upside is that apt is smart enough to figure out the dependencies, download and install everything for you. Automatically. Couldn't be more painless.
--
Note that "unstable" really isn't all that unstable, working-wise. Debian has been the most stable, reliable distribution I've ever used. "unstable" is called that mostly because the packages change daily -- or hourly. They haven't been fully tested with the rest of the system, but they work 99% of the time anyway. "stable" tends to get out of date, so I've kept my system in line with "unstable" and have had zero problems.
In my experience, potato has been far more stable than any other distro I've run (haven't tried the latest Red Hats or Mandrake yet, though).
The only drawback with Debian for me was having to sit through the install and answer questions for many packages. That is being worked on however. I don't know what the status for potato is. Can one of the developers comment?
--
Writing a piece of code to run well on a Cray or Convex is not easy. You need to worry about all sorts of nasties like NUMA, messaging speed and so forth. Even non-parallel code must be concerned about I/O time. Databases have used their own raw partitions and caching schemes for years.
Even some PC software is written with the memory heirarchy in mind. You want your working set to fit in the cache, page table or whatever. RAMBUS just presents a new organization for which to optimize. Writing good code that takes advantage of the hardware makes a big difference. It's for this reason that programmers need to understand the hardware they're working with.
--
To me, their fears seem justified assuming PSII is everything it's hyped to be.
It's still "only" a console. But does that really matter these days? How many people are playing games on their Palm Pilots? How many are screaming for e-mail, web and general networking support?
Look at what Apple and NEC are putting out. They're practically consoles now, except for an excessively long boot process and unstable OS.
The fact that you can't open up a console does not render it useless as a home PC (or even a light work terminal). I'd argue it makes it a better home PC, as today's $400 computers tend to be disposable anyway.
--
Even so, I'm amazed even now how many @webtv.com addresses I see.
--
What they are concerned about is Playstation II. If Sony can actually mass-produce the Emotion Engine, it is going to give Intel (and other chip makers) serious headaches.
What does the average consumer want? A cheap, easy-to-set-up all-in-one word processor/game console/internet application. Playstation II fits the bill. There's no OS to hassle with, no IRQ's and memory conflicts. Just turn it on and it goes. It's what the iMac dreams to be.
AMD may have come out with a superior desktop processor just at the point when it doesn't matter anymore.
--
GCC became forked because the FSF sat on changes that were being submitted. For years. EGCS was an attempt to get working C++ code out to the general public (Cygnus had been releasing it as part of GNUPro for some time). EGCS literally saved the project I was working on and I'm sure it did the same for others.
Now that EGCS and GCC are back together as one, some of the other forks are being rolled in (Haifa, FORTRAN and Ada for sure, though I don't know what's happening with PGCC).
The act of forking caused the FSF to get off their collective duff and do something. That's a Good Thing.
Linux would not be forked for the same reason (I hope!). It would be forked if Linus and others didn't like the TurboLinux changes. This (hopefully) prevents cruft from entering the mainstream kernel.
--
GCC became forked because the FSF sat on changes that were being submitted. For years. EGCS was an attempt to get working C++ code out to the general public (Cygnus had been releasing it as part of GNUPro for some time). EGCS literally saved the project I was working on and I'm sure it did the same for others.
Now that EGCS and GCC are back together as one, some of the other forks are being rolled in (Haifa, FORTRAN and Ada for sure, though I don't know what's happening with PGCC).
The act of forking caused the FSF to get off their collective duff and do something. That's a Good Thing.
--
I don't really understand the point of this article. Jon seems to want to get the message across that media doesn't trigger violence. Granted. Whether it dulls the emotional reaction to violence is, I think, an open question, but that's another discussion.
Basing this article on a "Christian" action game is pointless at best and inflammatory at worst. Jon makes the mistake (as many others do) of assuming that the extreme right-wing speaks for all of Christianity when he writes,
Someone forgot to tell me, apparently. Christianity is not about repression and persecution and neither are Islam or Judaism. It's amazing that anyone can hold this view anymore. As our parish pastor once said, there's a difference between religion and faith, and sometimes religion gets in the way of faith.
Now this is simply absurd. Anyone who thinks watching The Simpsons or South Park condemns one to the depths of hell has the wrong priorities. I personally don't care for South Park, but I can appreciate the humor.
All IMHO, as always.
--
The rule in computer architecture seems to be that everything was done back in the '60's and IBM holds all the patents. :)
None of the stuff discussed in the artical was particularly revolutionary at the time of RISC I. Bringing it all together on a microprocessor was the missing element.
--
People talk a lot about (digital) "hardware" and "software," but they're really the same thing (well, if you ignore analog effects). Understanding how the hardware works can provide great insight about how to design software. Hardware design was probably the first type of "object-oriented" or "modular" programming. It's a lot of high-level design, specifying interfaces and plugging components together.
And some of the best hacks were done in hardware. :)
A big issue in digital logic design is latency and synchronization, which is also an issue in software working with ever increasingly, pervasively, parallel systems. People who are good at one of these fields will have developed a good skill set that should transfer well to the other.
Bingo. A microprocessor is really just one big parallel program.
--
Computer Architecture: A Quantitative Approach by Hennessy and Patterson
This one gets into a more detail on how modern processors work, with branch prediction and dynamic scheduling. It also covers everything in the "Organization and Design" book.
These books assume the reader knows something about digital logic design. Johnson's Superscalar Microprocessor Design is also a good one.
--
The view from this (non-official) person was that AMD is going to be too late. No company will want to produce multiple versions of its 64-bit code (operating system or otherwise).
He's got a point. Just look at Windows and how the various ports have started to disappear. Yes, of course Linux, *BSD and others may be ported. We'll have to see what the fallout will be.
--
The death of so many architectures...
--
The problem is, it's very tough for the compiler to do a good job scheduling statically. Most delay slots are never filled. Much more information is available at run-time (in a limited window for the hardware), so it can make some better decisions than a static compiler can.
However, the compiler can look much further ahead than the processor, so it seems that some sort of hybrid solution is called for. Whether that involves profiling and feedback optimization a la FX!32 and others, new ISA or something else is still an open question, I think. IA64 has made steps in this direction.
--
Predication works on a similar assumption. When hard-to-predict branches are predicated, the hardware wastes some time executing useless instructions, but avoids the mispredict overhead of refetch and/or reexecution of everything after the branch.
--
When you see Intel put out a 64-bit x86, then you'll know IA64 is dead.
--
Branch prediction is the major problem. Sure, predicting one branch may work 90% of the time, but when you start talking about wide machines, all of a sudden you're predicting 2, 3 or 4+ branches at once. Your prediction rate goes way down. Fast.
A student here did a study that showed >50% of the processor cycles were spent recovering from branches. And I don't think the study was on a particularly aggressive machine (though I can check that).
The encouraging this is, if we can get around branch problems (and that's a huge if), the parallelism is there. But not where the machine can see it. There was a study exploring the limits of ILP in Spec95 (yes, not realistic benchmarks, but it's what was available). If you assume perfect prediction (yes, completely unrealistic, but this was a limit study) and remove the stack pointer (which is often on the critical path of instruction dependencies), you can get parallelism in the hundreds (for integer programs) or thousands (for floating point stuff) of instructions.
But there's catch. If your instruction window is 10k instructions wide or less (a completely unrealistic size, by the way), the parallelism drops by an order of magnitude or more. The hardware doesn't have enough context to see it. But the compiler does. Think about forking threads on function calls when you can and you'll see where I'm going.
Some kind of model like Simultaneous MultiThreading may be needed in the future. Compaq is working hard on this for the Alpha.
What's important to remember is that we've received the biggest speed boosts from the process guys. Cranking the clock and packing in gates (i.e. cache) does much more than adding another pipeline. Remember Moore's Law.
--
I'm working with 3-4 other graduate students very closely and know at least 10-20 others very well. There's not a single one I know who, after a hard day's work of hacking, goes home and immediately fires up a computer. And grad students tend to be pretty serious hackers.
Everyone I know here has hobbies that have little or nothing to do with electronics. Volleyball, fishing, music, dancing, acting, you name it.
Society seems to view engineers as very one-dimensional people. I submit that engineers are some of the most well-rounded individuals around. They're just very dedicated to their work and thus seem to be completely immersed in it.
--
Not only does the book present a gripping account of the engineering problems that were encountered and the various solutions that were developed, it also gives a great look into the personalities involved. This is a very human story, with all its great blunders and triumphs.
My favorite part of the story is the description of the hiring/interviewing procedure for the project. New grads should pay attention to what these guys were looking for. You might be surprised.
--
IIRC some of the later VAXen did this (micro-VAX, maybe?) and has been pointed out, Apple did this in the transition to PowerPC. Intel might do this in the future to allow flexibility in marketing.
HP is doing this for Merced to execute PA-RISC binaries, and Dynamo may be what they're using to do it.
--
This was the original philosophy of RISC - expose what would have been microcode to the compiler and let it go to town.
Really the only differences between x86 and current "RISC" machines are
Really none of these is inherently bad.
Variable-length instructions can improve I-cache performance. IBM has been using them for years in the 360 and beyond. x86 seems to have gone too far by allowing from 1-15 byte instructions, but a few different sizes isn't so bad.
offset+base+index*scale address can in fact be used by a compiler. Think of accessing a field from an array of structs. Once instruction can do what takes four or five on a RISC machine. Now that one instruction may have a (slightly) higher latency than any one of the four or five RISC instructions, but when you start considering fetch time, the win isn't clear.
Block copy instructions can be very nice for a compiler. Take a look at what gcc does on a MIPS. It inserts a call to memcpy! None of that nonsense is necessary on the x86.
--
One way to do it is with a virtual machine - not in the sense of Java, but in the sense of OS/360-370, etc. That is, you have a Virtual Machine Monitor (VMM) at the lowest level and the OS's run on top of that. Note the plural. Not only do you have the ability to trap instructions and run them in software in an OS-neutral fashion, you can run multiple OS's simultaneously. There are lots of other benefits, like being able to swap in a new OS without disturbing existing setups and so forth.
Intel, in fact, is working on such a beast. I'm guessing it's for Merced, being an enterprise chip. They also want to use it for marketing purposes, though. Think about a Pentium III without any MMX/KNI/whatever graphics instructions in hardware. You do it in software, get the same functionality and can market your chip for really low-end systems.
--
AMD should be able to get away with only adding 64-bit instructions for the common x86 operations. There's something like 15,000 different x86 instructions, of which maybe a couple hundred are used extensively (if that). Take this subset, make it orthogonal (and do the same for the 32-bit versions), and you'd be getting a decent chip. Do the rest in software.
--