Why would Intel be embarassed or whatever to "follow in AMD's footsteps"?
It's all about PR and marketing. Intel has invested billions of dollars and years of R&D into IA-64 (something that originated in HP's labs), and said that they're committed to IA-64. x86 is a dirty ISA, and with shrinking transistors and increasing hardware complexity, their rationale was that wire delays will become a major limiting factor in performance (not that I'm arguing against it). Itanium 1 comes out years late and performance is lackluster. The power consumption is quite high (and it's even an in-order core).
So then comes IDF, and they demo 64-bit x86, something that they've been denying that they've been working on. If Intel had confirmed the rumors that they were working on x86-64 (AMD64), I think they would have been worried about it cannabilizing their Itanium sales. Worse, they're adopting a technology developed by a company a fraction of their size with a fraction of the resources. It gives AMD much more credibility.
I think the problem was obvious when looking through forum posts of users who had 75GXP drives. It wasn't the number of failures as much as it was the number of failures per user. Sure, some people didn't have any problems, but many others had multiple drive failures, and the failure distribution was statistically abnormal.
As much as I'm happy that this is out in the open and that there's a class action suit, what will the users get out of this? In the tech world, two+ years is an eternity. Will they get the typical $20 voucher towards a new Hitachi drive while the class action lawyers get the millions? I had two fail on me in two months (on my VIA 686B south bridge while they worked fine on someone else's AMD south bridge). I had to fight IBM red tape as they kept trying to pawn me off on Acer but couldn't even give me the right point of contact at Acer (but I finally got through after six months).
You know what they say... in a lawsuit, the only winners are the lawyers.
"What we do know is that every condition needed for fraud did exist. The question is not whether it has happened. The question is whether it can happen."
Granted, there's no perfect security. But electronic voting companies seem to have a problem at least making an attempt to fix any possible vulnerabilities. When the Patriot Act passed 98-1 in the Senate, the lone dissenter (Russ Feingold of WI) said that it's not whether or not people have abused the law... it's that the potential exists. Sometimes it's really hard to teach someone the value of security until they've been victimized/directly affected by it. The problem, unfortunately, is proving that it happened.
With regard to Cox's response on a paper trail:
"It really adds nothing to the system, [and] the people who think it will don't understand the history of voter fraud we've had with paper."
Personally, I don't think removing one potential of fraud and replacing it with another really solves any problem. And suppose something does go wrong (massive failure, serious bug, fraud)? Is there anything to fall back on? And at least if you want to fix the elections, it makes it a bit more difficult.
My first thought was, "Woah" until I read the article. The first thought that comes to my mind when someone says "gamer" is someone who plays an FPS or RTS, but with "games" defined in the much broader sense, this is less shocking (although the late hours are somewhat of a surprise). Plus, most computers can play these games without the latest hardware or fastest connection.
You won't see 1 MB L1 caches, at least not in the forseeable future. The reason there is a memory hierarchy is to reduce access time due to address decoding and (especially) wire delays while keeping costs low since cache is expensive in terms of transistors... 1 MB is simply too large for the L1 to have a reasonable access time. L1 is performance critical, so a large L1 could hurt performance more than it helps, regardless of the hit rate. Plus, if you plan on implementing multiple processors (Xbox Next?), it may be a good idea to have inclusion (where data in L1 is guaranteed to also reside in L2) to shield the L1 from remote probe requests. This in turn means that your L2 should be much larger than your L1 (or else your L2 really doesn't serve much of a purpose).
You're right about DRAM, but sense amps are used in microprocessor caches as well - not for functionality, but for speed. It'll be a lot faster to have sense amps and related circuitry pull a line to rail whenever it detects a change instead of waiting for the transistors in the bits drive the line.
Don't forget the extra pipe stages... those count for a lot. I can't say how many transistors, but it should make a dent in the numbers.
A 1 MB L2 cache will be at least 50 million transistors, assuming 6T/bit (1024 * 1024 * 8 * 6), not including sense amps, decoders, tags, coherence, predecode bits, etc.
Separate processor-memory boards isn't what defines NUMA; it's the way the processor and memory are organized. Each processor has a local memory which has a lower latency than the remote memory access. It's for scalability, since SMP systems don't scale as well when it comes to bandwidth and memory access times.
I think what you're getting at is, "Why build/sell a fast uniprocessor when you can use cheap processors and connect them into multiprocessor systems for high performance?"
There are some issues with this. Parallel programming is hard, and not every application supports it. In fact, most programs aren't optimized for MP systems, because worrying about that stuff is a pain in the ass (synchronization, locks, etc.). So on an application level, it doesn't really benefit most consumers. The best way to sum it up is with Amdahl's Law, which states that your speedup for an application is limited by the fraction of your code that is parallelizable. In short, you'll get the greatest benefit by working on your single threaded performance.
Second, and you probably already know this, but adding processors does not linearly increase your performance (e.g. adding a second processor does not double your performance). Sometimes it is linear (or even superlinear), but usually, it's not. There's overhead with cache coherence involved, and some contention with memory accesses, and (back to Amdahl's Law), you're limited by how much of the code is actually parallelizable (which is likely to be much less than 100%).
But one benefit of MP systems is that the OS can load balance computationally intensive apps on separate processors. The real question is, do the majority of users out there really hammer their systems like that? I think the answer is no, and those that do are willing to pay the premium.
So after all this, if you're still adamant about buying a multiprocessor system, consider the tradeoffs. On one hand, the Athlon MP only goes up to 2P. It's also a point-to-point SMP, which can mean a bit higher latency on coherence activity than a shared bus. The Opteron is glueless, so the latency of coherence activity should be quite low. But, the Opteron is not SMP, it's NUMA, which often requires some optimization for memory placement. But it is the future for AMD, it scales well, software support is getting better by the day, and it's 64-bit (if that matters to you).
Do you mean a Tualatin core, or the P6 core that is the basis of the Pentium Pro, Pentium II, Pentium III, and Pentium M (and Celeron counterparts)
Well, when I was writing this, I was only thinking of the PIII/Tualatin. You're right about the Pentium M... but it does have some major design changes. For example, up to the PIII, the core uses micro-ops (uops). According to this, the Pentium M uses macro-ops. This says so too, even though they don't specifically call it a macro-op. I tend to think of the Pentium M as somewhat "loose" implementation of the P6 core.
Anand mentioned this, but the decision to add pipeline stages, whether it be 1 or 11, wasn't done on a whim. In fact, just to go through with the design, verification, and implementation processes would take over a year (probably closer to two).
Even when you add one pipe stage, you have to worry about creating new hazards/bugs and making sure that the chip is functionally correct. In fact, I'm surprised that Prescott is even considered a P4 core. To me it seems like a radical design change.
My guess is that Intel's goal was greater absolute performance. In the end, they'll get better performance w/ Prescott than Northwood because they'll be able to hit higher frequencies. The performance that Northwood is achieving right now would probably be much more difficult to hit on a Pentium 3 core. And if the extra frequency will help sell the product and impress the naive consumer, then it's extra marketing firepower for them.
The problem with increasing the number of pipe stages is that it becomes more difficult to maintain your IPC... every branch misprediction, cache miss, TLB miss, etc. hurts more, and no amount of out of order execution can keep the pipe filled. We're seeing a trend towards SMT (like the Power5) and chip multiprocessing (Power5 also) just to make better use of our transistor budget.
What I think is really hurting the initial performance is the increased cache latency, at least for the short term. The side effects are probably mitigated by the trace cache. But they waited until 90 nm to release Prescott, and that's probably because of the extra power consumption and area of the extra pipeline registers, but there's also an increase in leakage, so it's a tradeoff. They shouldn't have any problem ramping up their clock frequency. Maybe this wasn't the right way to go, but one thing is for sure - they didn't take the easy route.
Yes, I agree. My guess is that they're trying to achieve higher absolute performance. What surprises me is that this is still considered a P4 core, since adding pipeline stages (even 1 stage) is a very non-trivial task.
This'll also kill the benefits of reduced power consumption of 90 nm technology (increase in area from the additional pipeline registers, increase in frequency), which is important in server design. An argument about the benefits of having a trace cache is the reduction in power consumption since you can remove some decoders (x86 decoders are horribly complex, yet having enough to feed the rest of the processor is critical for high performance). The P4 only has one x86 decoder (plus the uROM) and is able to perform well in general.
It'll be interesting to see the power consumption numbers (average and max) as well as the die size. Also, I wonder how AMD's CPU rating system will change as a result of this.
Good point, but it's a tradeoff. However (and this may offset the benefits of having my e-mail address displayed as an image), but people can look me up in the school directory. In fact, that's probably where most of my spam is coming from.
On the one hand, I really don't like how the record companies treat customers
I agree, but I also don't like how a lot of record companies treat their bands (see below).
On the other hand, I also see the value in having a record company which can front money to new and old bands to keep music fresh and flowing to the audience ears
You should read this article by Courtney Love. It's a bit dated, but still interesting nonetheless. She gives insight into how much money new bands really get with their contracts. A lot of the money that the record companies spend on artists is charged back to them in the end. I'm not justifying or criticizing P2P... I'm only saying that artists are mostly treated as commodities (which I'm sure a lot of people already knew).
Because TIMTOWTDI, your ten-line Perl script either
Gets very complex very quickly
Sure, but if a lot of people use something rudimentary like user at domain dot com or user@NOSPAM.domain.com, it's pretty trivial, and a simple script will get a pretty good return rate. Screw the extra work for a few more addresses. If I searched for those two patterns on the web, that would probably get me a significant number of addresses for very little work.
Doesn't correctly un-obfuscate every address
I don't think it matters that much, since they're not using their own relays anyway.
I may post mine as
user2@no_spam_damnit.domain.com
To me, using relatively simple tricks like this to make the job of a spammer harder is definitely worthwile.
I agree. I took the no-holds-barred approach. I have spamtrap addresses set up on my domain, and my school address is displayed as a JPEG.
I know you're all joking, but I've actually been asked this sort of question a few times during my days when I did work in a fab. I started of on 6" wafers until we converted to 8" (200 mm) wafers. One of the challenges was film uniformity for deposition processes. Slight variations in film thickness can result in varying yields.
The other problem with 8" wafers was that they were a lot more sensitive to stress. Without going into too much detail, we'd have spare/scratch wafers that would go through some processes repeatedly (kind of like the seat filler at the Academy Awards). Certain processes/films such as thick silicon nitride would cause a lot of stress on the wafer, and they'd fracture, although we never saw that on 6" wafers (I put in a suggestion to mitigate the problem, it got accepted, and I got two free movie tickets out of it for saving the company millions). So this sort of problem could get worse as wafer sizes increase.
The better question is, why dont they switch to SQUARE WAFERS!
I guess the best way would be to make you watch a video on the wafer manufacturing process.
As for the article post, I apologize for making it vague. I could have clarified it and saved everyone some confusion... but then it'd be less interesting:)
> SMT allows one thread to do a bit of processing for a while, until it runs out of data. It requests data from memory and then goes off to lala-land for a little while while the other thread takes over.
I believe that's a bit off. Multiple threads will excute simultaneously, not take turns (hence, the 'S' in SMT). The point of SMT is to keep your pipe stages full, and the reasoning is that a single thread won't have enough instruction level parallelism to do that at all times. If I remember correctly, the now-defunct Alpha EV8 (21464) was supposed to be 4-way SMT. The Pentium 4 (aka HyperThreading) is 2-way. To execute two separate threads concurrently, you'll have to have two program counters.
The one thing to note about the P4's HyperThreading is that (AFAIK) the OS sees two logical processors, not one SMT processor. The significance of that is that you could actually have two separate processes run simultaneously on the CPU (as opposed to two threads of a process). My theory on why some benchmarks perform worse with HyperThreading enabled is because multiple processes will cause TLB thrashing. This is why you're more likely to get better performance from a dual core CPU.
Unfortunately, I haven't done too much reading into SMT. If you want more info, you can go here.
> Memory bandwidth has gone up by a factor of about 64, but latency has only decreased by a factor of about 10 or less.
DRAM vendors have been focusing on capacity and manufacturing costs over speed. DRAM is a commodity part, driven more by yields and manufacturing than design (not saying that design isn't important). One reason latency hasn't improved is because every bit on a DRAM cell is stored in a capacitor. Not only do capacitors leak (so you have to refresh every so often), but capacitance itself means that voltage swings will be slow. The speed gap between DRAMs and processors will get worse unless industry moves to a different storage mechanism.
To clear up any confusion, RackinFrackin was right... what I meant was that if you were caught cheating, your final grade for the assignment would be -20 points (as opposed to having 20 points taken off your final score).
(And no, I did undergrad here).
I know a lot of people have suggested zeros. I had a prof who would dish out negative points on an assignment if you were caught cheating. So you could get -20 points on a 100 point assignment.
But in the same class, we had a discussion board where people could talk about problems in the open. Maybe they won't be able to post specific pieces of code (from their homework), but at least people will have a forum to post questions where everyone can read them and help each other.
I used to be a sysadmin here when I was an undergrad, and while the lab grew quite a bit during my time there, there's still a lot that I wanted to do (although sometimes, we were funds-challenged).
You will also need to think about 1) setting up good security policies and enforcing them, and 2) physical security. There are other things, but I can't think of them right now.
With regard to policy, you have to remember that security and convenience are often conflicting. Security is a habit that needs to be engrained into users' minds. I'm not saying that you should never compromise, just know when to draw the line. We went through some growing pains, and our policy became more restrictive as we got more and more students. For example, shutting off telnet was a pain in the ass, even though I was extremely proactive and sent out directions and warnings several weeks before making the move.
Run network tests (like worms) on a private, disconnected network. If you have to run things on the open (highly unlikely) that may generate suspicious packet activity, make sure you get permission from the higher ups! For example, things like having an unauthorized vulnerable box on the open network, even for research purposes, can be a bad idea and it can piss off people more powerful than you.
As someone mentioned before, a lawyer is important. At least do some research into the legality of certain actions.
Also, good security involves knowing what not to do. Sometimes they're obvious (don't write down the root password, don't finger punch the root password), and sometimes they're not.
Yes, patch your machines, upgrade your kernels, lock your doors, lock your workstations, and make good passwords. But the scope of security spans many disciplines, such as psychology, business, and law... it's not about just hardware and software.
Slashdot Mirror
Why would Intel be embarassed or whatever to "follow in AMD's footsteps"?
It's all about PR and marketing. Intel has invested billions of dollars and years of R&D into IA-64 (something that originated in HP's labs), and said that they're committed to IA-64. x86 is a dirty ISA, and with shrinking transistors and increasing hardware complexity, their rationale was that wire delays will become a major limiting factor in performance (not that I'm arguing against it). Itanium 1 comes out years late and performance is lackluster. The power consumption is quite high (and it's even an in-order core).
So then comes IDF, and they demo 64-bit x86, something that they've been denying that they've been working on. If Intel had confirmed the rumors that they were working on x86-64 (AMD64), I think they would have been worried about it cannabilizing their Itanium sales. Worse, they're adopting a technology developed by a company a fraction of their size with a fraction of the resources. It gives AMD much more credibility.
I think the problem was obvious when looking through forum posts of users who had 75GXP drives. It wasn't the number of failures as much as it was the number of failures per user. Sure, some people didn't have any problems, but many others had multiple drive failures, and the failure distribution was statistically abnormal.
As much as I'm happy that this is out in the open and that there's a class action suit, what will the users get out of this? In the tech world, two+ years is an eternity. Will they get the typical $20 voucher towards a new Hitachi drive while the class action lawyers get the millions? I had two fail on me in two months (on my VIA 686B south bridge while they worked fine on someone else's AMD south bridge). I had to fight IBM red tape as they kept trying to pawn me off on Acer but couldn't even give me the right point of contact at Acer (but I finally got through after six months).
You know what they say... in a lawsuit, the only winners are the lawyers.
One of the best arguments in the article is this:
"What we do know is that every condition needed for fraud did exist. The question is not whether it has happened. The question is whether it can happen."
Granted, there's no perfect security. But electronic voting companies seem to have a problem at least making an attempt to fix any possible vulnerabilities. When the Patriot Act passed 98-1 in the Senate, the lone dissenter (Russ Feingold of WI) said that it's not whether or not people have abused the law... it's that the potential exists. Sometimes it's really hard to teach someone the value of security until they've been victimized/directly affected by it. The problem, unfortunately, is proving that it happened.
With regard to Cox's response on a paper trail:
"It really adds nothing to the system, [and] the people who think it will don't understand the history of voter fraud we've had with paper."
Personally, I don't think removing one potential of fraud and replacing it with another really solves any problem. And suppose something does go wrong (massive failure, serious bug, fraud)? Is there anything to fall back on? And at least if you want to fix the elections, it makes it a bit more difficult.
My first thought was, "Woah" until I read the article. The first thought that comes to my mind when someone says "gamer" is someone who plays an FPS or RTS, but with "games" defined in the much broader sense, this is less shocking (although the late hours are somewhat of a surprise). Plus, most computers can play these games without the latest hardware or fastest connection.
You won't see 1 MB L1 caches, at least not in the forseeable future. The reason there is a memory hierarchy is to reduce access time due to address decoding and (especially) wire delays while keeping costs low since cache is expensive in terms of transistors... 1 MB is simply too large for the L1 to have a reasonable access time. L1 is performance critical, so a large L1 could hurt performance more than it helps, regardless of the hit rate. Plus, if you plan on implementing multiple processors (Xbox Next?), it may be a good idea to have inclusion (where data in L1 is guaranteed to also reside in L2) to shield the L1 from remote probe requests. This in turn means that your L2 should be much larger than your L1 (or else your L2 really doesn't serve much of a purpose).
Since mozilla.org is slashdotted, here are the primary mirrors:
ISC (FTP)ISC (HTTP)
Georgia (FTP)
Georgia (HTTP)
Indiana (FTP)
Indiana (HTTP)
Oregon (FTP)
Oregon (HTTP)
And the google cache for more mirrors.
You're right about DRAM, but sense amps are used in microprocessor caches as well - not for functionality, but for speed. It'll be a lot faster to have sense amps and related circuitry pull a line to rail whenever it detects a change instead of waiting for the transistors in the bits drive the line.
Don't forget the extra pipe stages... those count for a lot. I can't say how many transistors, but it should make a dent in the numbers.
A 1 MB L2 cache will be at least 50 million transistors, assuming 6T/bit (1024 * 1024 * 8 * 6), not including sense amps, decoders, tags, coherence, predecode bits, etc.
Separate processor-memory boards isn't what defines NUMA; it's the way the processor and memory are organized. Each processor has a local memory which has a lower latency than the remote memory access. It's for scalability, since SMP systems don't scale as well when it comes to bandwidth and memory access times.
I think what you're getting at is, "Why build/sell a fast uniprocessor when you can use cheap processors and connect them into multiprocessor systems for high performance?"
There are some issues with this. Parallel programming is hard, and not every application supports it. In fact, most programs aren't optimized for MP systems, because worrying about that stuff is a pain in the ass (synchronization, locks, etc.). So on an application level, it doesn't really benefit most consumers. The best way to sum it up is with Amdahl's Law, which states that your speedup for an application is limited by the fraction of your code that is parallelizable. In short, you'll get the greatest benefit by working on your single threaded performance.
Second, and you probably already know this, but adding processors does not linearly increase your performance (e.g. adding a second processor does not double your performance). Sometimes it is linear (or even superlinear), but usually, it's not. There's overhead with cache coherence involved, and some contention with memory accesses, and (back to Amdahl's Law), you're limited by how much of the code is actually parallelizable (which is likely to be much less than 100%).
But one benefit of MP systems is that the OS can load balance computationally intensive apps on separate processors. The real question is, do the majority of users out there really hammer their systems like that? I think the answer is no, and those that do are willing to pay the premium.
So after all this, if you're still adamant about buying a multiprocessor system, consider the tradeoffs. On one hand, the Athlon MP only goes up to 2P. It's also a point-to-point SMP, which can mean a bit higher latency on coherence activity than a shared bus. The Opteron is glueless, so the latency of coherence activity should be quite low. But, the Opteron is not SMP, it's NUMA, which often requires some optimization for memory placement. But it is the future for AMD, it scales well, software support is getting better by the day, and it's 64-bit (if that matters to you).
Do you mean a Tualatin core, or the P6 core that is the basis of the Pentium Pro, Pentium II, Pentium III, and Pentium M (and Celeron counterparts)
Well, when I was writing this, I was only thinking of the PIII/Tualatin. You're right about the Pentium M... but it does have some major design changes. For example, up to the PIII, the core uses micro-ops (uops). According to this, the Pentium M uses macro-ops. This says so too, even though they don't specifically call it a macro-op. I tend to think of the Pentium M as somewhat "loose" implementation of the P6 core.
Anand mentioned this, but the decision to add pipeline stages, whether it be 1 or 11, wasn't done on a whim. In fact, just to go through with the design, verification, and implementation processes would take over a year (probably closer to two).
Even when you add one pipe stage, you have to worry about creating new hazards/bugs and making sure that the chip is functionally correct. In fact, I'm surprised that Prescott is even considered a P4 core. To me it seems like a radical design change.
My guess is that Intel's goal was greater absolute performance. In the end, they'll get better performance w/ Prescott than Northwood because they'll be able to hit higher frequencies. The performance that Northwood is achieving right now would probably be much more difficult to hit on a Pentium 3 core. And if the extra frequency will help sell the product and impress the naive consumer, then it's extra marketing firepower for them.
The problem with increasing the number of pipe stages is that it becomes more difficult to maintain your IPC... every branch misprediction, cache miss, TLB miss, etc. hurts more, and no amount of out of order execution can keep the pipe filled. We're seeing a trend towards SMT (like the Power5) and chip multiprocessing (Power5 also) just to make better use of our transistor budget.
What I think is really hurting the initial performance is the increased cache latency, at least for the short term. The side effects are probably mitigated by the trace cache. But they waited until 90 nm to release Prescott, and that's probably because of the extra power consumption and area of the extra pipeline registers, but there's also an increase in leakage, so it's a tradeoff. They shouldn't have any problem ramping up their clock frequency. Maybe this wasn't the right way to go, but one thing is for sure - they didn't take the easy route.
You're absolutely right. He may have known that, and I don't think he was being careless. I think he was spinning it for the audience:
It'll most likely be slower per clock cycle.
Yes, I agree. My guess is that they're trying to achieve higher absolute performance. What surprises me is that this is still considered a P4 core, since adding pipeline stages (even 1 stage) is a very non-trivial task.
This'll also kill the benefits of reduced power consumption of 90 nm technology (increase in area from the additional pipeline registers, increase in frequency), which is important in server design. An argument about the benefits of having a trace cache is the reduction in power consumption since you can remove some decoders (x86 decoders are horribly complex, yet having enough to feed the rest of the processor is critical for high performance). The P4 only has one x86 decoder (plus the uROM) and is able to perform well in general.
It'll be interesting to see the power consumption numbers (average and max) as well as the die size. Also, I wonder how AMD's CPU rating system will change as a result of this.
Good point, but it's a tradeoff. However (and this may offset the benefits of having my e-mail address displayed as an image), but people can look me up in the school directory. In fact, that's probably where most of my spam is coming from.
On the one hand, I really don't like how the record companies treat customers
I agree, but I also don't like how a lot of record companies treat their bands (see below).
On the other hand, I also see the value in having a record company which can front money to new and old bands to keep music fresh and flowing to the audience ears
You should read this article by Courtney Love. It's a bit dated, but still interesting nonetheless. She gives insight into how much money new bands really get with their contracts. A lot of the money that the record companies spend on artists is charged back to them in the end. I'm not justifying or criticizing P2P... I'm only saying that artists are mostly treated as commodities (which I'm sure a lot of people already knew).
Because TIMTOWTDI, your ten-line Perl script either
Sure, but if a lot of people use something rudimentary like user at domain dot com or user@NOSPAM.domain.com, it's pretty trivial, and a simple script will get a pretty good return rate. Screw the extra work for a few more addresses. If I searched for those two patterns on the web, that would probably get me a significant number of addresses for very little work.
I don't think it matters that much, since they're not using their own relays anyway.
I may post mine as
user2@no_spam_damnit.domain.com
To me, using relatively simple tricks like this to make the job of a spammer harder is definitely worthwile.
I agree. I took the no-holds-barred approach. I have spamtrap addresses set up on my domain, and my school address is displayed as a JPEG.
But I think the farmer (with his Tornado in a Can idea) has been watching too many Roadrunner cartoons.
Why don't they skip to 10 foot wafers?
I know you're all joking, but I've actually been asked this sort of question a few times during my days when I did work in a fab. I started of on 6" wafers until we converted to 8" (200 mm) wafers. One of the challenges was film uniformity for deposition processes. Slight variations in film thickness can result in varying yields.
The other problem with 8" wafers was that they were a lot more sensitive to stress. Without going into too much detail, we'd have spare/scratch wafers that would go through some processes repeatedly (kind of like the seat filler at the Academy Awards). Certain processes/films such as thick silicon nitride would cause a lot of stress on the wafer, and they'd fracture, although we never saw that on 6" wafers (I put in a suggestion to mitigate the problem, it got accepted, and I got two free movie tickets out of it for saving the company millions). So this sort of problem could get worse as wafer sizes increase.
The better question is, why dont they switch to SQUARE WAFERS!
I guess the best way would be to make you watch a video on the wafer manufacturing process.
As for the article post, I apologize for making it vague. I could have clarified it and saved everyone some confusion... but then it'd be less interesting :)
Matt is from Portland although I argue that the Springfield vs. Shelbyville rivalry comes from Eugene and Springfield
That may make sense. There was an episode of Futurama which had a spoof of the Iron Chef, and in the beginning, Bender was a robo (Robot Hobo):
Hobo: Welcome to Bumbase Alpha, the biggest hobo jungle in the quadrant.
Bender: I've seen bigger. Oh wait, I'm thinking of Eugene, Oregon.
gates used to be metal in the first place (before polysilicon). MOS = Metal Oxide Semiconductor.
> SMT allows one thread to do a bit of processing for a while, until it runs out of data. It requests data from memory and then goes off to lala-land for a little while while the other thread takes over.
I believe that's a bit off. Multiple threads will excute simultaneously, not take turns (hence, the 'S' in SMT). The point of SMT is to keep your pipe stages full, and the reasoning is that a single thread won't have enough instruction level parallelism to do that at all times. If I remember correctly, the now-defunct Alpha EV8 (21464) was supposed to be 4-way SMT. The Pentium 4 (aka HyperThreading) is 2-way. To execute two separate threads concurrently, you'll have to have two program counters.
The one thing to note about the P4's HyperThreading is that (AFAIK) the OS sees two logical processors, not one SMT processor. The significance of that is that you could actually have two separate processes run simultaneously on the CPU (as opposed to two threads of a process). My theory on why some benchmarks perform worse with HyperThreading enabled is because multiple processes will cause TLB thrashing. This is why you're more likely to get better performance from a dual core CPU.
Unfortunately, I haven't done too much reading into SMT. If you want more info, you can go here.
> Memory bandwidth has gone up by a factor of about 64, but latency has only decreased by a factor of about 10 or less.
DRAM vendors have been focusing on capacity and manufacturing costs over speed. DRAM is a commodity part, driven more by yields and manufacturing than design (not saying that design isn't important). One reason latency hasn't improved is because every bit on a DRAM cell is stored in a capacitor. Not only do capacitors leak (so you have to refresh every so often), but capacitance itself means that voltage swings will be slow. The speed gap between DRAMs and processors will get worse unless industry moves to a different storage mechanism.
To clear up any confusion, RackinFrackin was right... what I meant was that if you were caught cheating, your final grade for the assignment would be -20 points (as opposed to having 20 points taken off your final score). (And no, I did undergrad here).
I know a lot of people have suggested zeros. I had a prof who would dish out negative points on an assignment if you were caught cheating. So you could get -20 points on a 100 point assignment.
But in the same class, we had a discussion board where people could talk about problems in the open. Maybe they won't be able to post specific pieces of code (from their homework), but at least people will have a forum to post questions where everyone can read them and help each other.
I used to be a sysadmin here when I was an undergrad, and while the lab grew quite a bit during my time there, there's still a lot that I wanted to do (although sometimes, we were funds-challenged).
You will also need to think about 1) setting up good security policies and enforcing them, and 2) physical security. There are other things, but I can't think of them right now.
With regard to policy, you have to remember that security and convenience are often conflicting. Security is a habit that needs to be engrained into users' minds. I'm not saying that you should never compromise, just know when to draw the line. We went through some growing pains, and our policy became more restrictive as we got more and more students. For example, shutting off telnet was a pain in the ass, even though I was extremely proactive and sent out directions and warnings several weeks before making the move.
Run network tests (like worms) on a private, disconnected network. If you have to run things on the open (highly unlikely) that may generate suspicious packet activity, make sure you get permission from the higher ups! For example, things like having an unauthorized vulnerable box on the open network, even for research purposes, can be a bad idea and it can piss off people more powerful than you.
As someone mentioned before, a lawyer is important. At least do some research into the legality of certain actions.
Also, good security involves knowing what not to do. Sometimes they're obvious (don't write down the root password, don't finger punch the root password), and sometimes they're not.
Yes, patch your machines, upgrade your kernels, lock your doors, lock your workstations, and make good passwords. But the scope of security spans many disciplines, such as psychology, business, and law... it's not about just hardware and software.