Surely there's a synchronization cost if both cpus are accessing the same resource.
A minor one. Since this is all being done on-die, the bandwidth is huge and the latency is tiny, so synchronisation is pretty painless. Even so, the cost of synchronising two caches is potentially greater than the cost of synchronising two cores using the same cache. In the dual-cache case, one cache entry will need to be invalidated each time a core writes to a shared entry. Then the core with the invalid entry will need to re-read the data from the other core's cache (this adds a temporal consistency issue to the spatial one because the cache being read from needs to be up-to-date). With single-cache, you only need to ensure temporal consistency.
If (1) your kernel did a perfect job of keeping a single process/thread confined to a single CPU and (2) none of your processes/threads were sharing the same memory then a dual cache would perform about the same as a single cache. The main problem here is number (2). When you're running a multi-threaded program, even if the kernel manages the CPUs perfectly, the threads will usually want to share some memory. They may need to pass information to each other or they may just be working on the same data set. In either case, a dual cache makes things worse.
There are plenty of situations where a single cache would perform better than a dual cache, but there are (almost?) no situations where a dual cache would perform better than a single cache. Hence single cache is better performance-wise.
Bear in mind, of course, that this is speculation. I have not carried out any benchmarks of single cache versus dual cache and I don't think there are any publicly available benchmarks comparing them. From a purely academic point of view, however, single cache wins.
Actually, we're talking about fusion here. Fission is the process in which large atoms are split into smaller atoms. In the case of power plants, unstable uranium atoms (with lots of extra neutrons) are split apart by firing neutrons at them. This starts a chain reaction which creates power.
In fission, two smaller atoms are joined into a larger one. In the case of the sun, four hydrogen atoms are joined into one Helium-4 atom. This has the advantage that it doesn't create so much dangerous waste, but it is also hard to control. This principle is used in the hydrogen bomb, where controlled explosions are not one of the things they worry about too much.
and is the principle already used by nuclear power plants
Fission is used in nuclear power plants. Fusion is not, and that is what the bet is about.
Are there situations where two caches might be better? For example, a multi-threaded application with two memory-intensive threads, each locked down onto a specific CPU?
Not really. The problem with 2 caches is duplication. It is quite probable that both cores will want to work on the same thing, in which case cache space will be wasted. It also creates timing complications when one core wants to write to its cache because the other core will have to be told to invalidate its relevant cache entry. On the other hand, you could create a single cache with double the size. This would make sharing memory between CPUs simpler and it wouldn't significantly increase access times (so the situation you mentioned wouldn't be affected). The argument for double caches is about cost, scalability and design simplicity, not performance.
The dual cache simplifies things emormously, especially taking the design of the Opteron into account. Opterons are incredibly scalable--each one has three HyperTransport links that can be connected to memory, I/O or another processor. In order to make dual-core chips, all AMD has to do is take two Opterons, put them in the same package and hard-wire a HT link from one processor to the other.
Of course, they also need to worry about things like size and power consumption but the simplified architecture really makes things a lot easier and will probably contribute to lower prices. It will also accelerate the introduction of multi-core (ie more than two) processors...
If they were to implement a unified cache design, they would have to make significant changes. They would need to implement cache snooping and complicated memory management. Given that the new dual-core processors (AMD ones, at least) are meant to be pin-compatible with current processors, this would be a bit much to ask. Maybe they'll have unified caches sometime, but I don't see it happening anytime soon.
But for us to be considered thieves, you have consider free MP3 downloads as "stealing". And it is only considered "stealing" under the current laws.
I'm sure this has been mentioned many times, but here it is again: copyright infringement is not theft! They are two separate and very different crimes. The only reason the RIAA accuses file sharers of theft is because no one would really care if they were accused of copyright infringement--it doesn't have the same ring to it
I'll say it one more time: downloading music is copyright infringement (assmuing it's copyrighted music, of course). It is not theft.
But probably it'd be best if Firefox got something like a 30% market share that way they can make their tiny extensions or ignore some of the standards.
Why would this be a good thing? Imagine the nightmares web page designers would have to go through if they had to support two completely different non-standards-compliant browsers. We'd need to use several different browsers on a day-to-day basis just to view all the pages correctly.
Now, if firefox could gain a 30% market share while remaining standards compliant, that would be something good because it would destroy Microsoft's attempts to corrupt web languages. If 30% of people used firefox (or any non-IE browser, for that matter), designers would no longer be able to get away with IE-only webpages. And isn't that preferable to having firefox-only pages in addition to the IE ones?
According to my mum (and I can't verify this because I haven't used MS Word in years), Word can read and write.sxw files. Of course, that's no guarantee that they're standards compliant (IE/png anyone?) but its a start. And it would allow "normal" users to open and print the manual.
I can see that it would be an inconvenience to make babies have passports but it shouldn't be such a huge issue. Most babies won't be travelling much anyway and having to update a passport isn't really so onerous.
Compared to things like security wait times and invasive searches, child passports aren't really that bothersome. It isn't an invasion of privacy and it doesn't increase huge wait times so why is everyone getting worked up about it?
So, whereas in the past, a family of British tourists to the US would have a couple of adult passports and one or two for the older kids, with the younger kids and the new baby travelling on one of their parent's passports, they now have to all have their own individual passports...
I was born in Australia when my parents were visiting and I flew out when I was 7 days old. Maybe the laws are different in the UK, but I had to have a passport in order to leave. I have never heard of children flying on their parents' passports and I don't see what's so horrible about requiring children to have their own.
If this setup eventually becomes popular and widespread, and we as a nation are playing these videos games...which soldiers play to get trained for fighting in battle...
How does that make you feel? Knowing that you are playing the same games that are used for training for soldier's in the army?
Slashdot Mirror
A minor one. Since this is all being done on-die, the bandwidth is huge and the latency is tiny, so synchronisation is pretty painless. Even so, the cost of synchronising two caches is potentially greater than the cost of synchronising two cores using the same cache. In the dual-cache case, one cache entry will need to be invalidated each time a core writes to a shared entry. Then the core with the invalid entry will need to re-read the data from the other core's cache (this adds a temporal consistency issue to the spatial one because the cache being read from needs to be up-to-date). With single-cache, you only need to ensure temporal consistency.
If (1) your kernel did a perfect job of keeping a single process/thread confined to a single CPU and (2) none of your processes/threads were sharing the same memory then a dual cache would perform about the same as a single cache. The main problem here is number (2). When you're running a multi-threaded program, even if the kernel manages the CPUs perfectly, the threads will usually want to share some memory. They may need to pass information to each other or they may just be working on the same data set. In either case, a dual cache makes things worse.
There are plenty of situations where a single cache would perform better than a dual cache, but there are (almost?) no situations where a dual cache would perform better than a single cache. Hence single cache is better performance-wise.
Bear in mind, of course, that this is speculation. I have not carried out any benchmarks of single cache versus dual cache and I don't think there are any publicly available benchmarks comparing them. From a purely academic point of view, however, single cache wins.
Actually, we're talking about fusion here. Fission is the process in which large atoms are split into smaller atoms. In the case of power plants, unstable uranium atoms (with lots of extra neutrons) are split apart by firing neutrons at them. This starts a chain reaction which creates power.
In fission, two smaller atoms are joined into a larger one. In the case of the sun, four hydrogen atoms are joined into one Helium-4 atom. This has the advantage that it doesn't create so much dangerous waste, but it is also hard to control. This principle is used in the hydrogen bomb, where controlled explosions are not one of the things they worry about too much.
and is the principle already used by nuclear power plantsFission is used in nuclear power plants. Fusion is not, and that is what the bet is about.
Not really. The problem with 2 caches is duplication. It is quite probable that both cores will want to work on the same thing, in which case cache space will be wasted. It also creates timing complications when one core wants to write to its cache because the other core will have to be told to invalidate its relevant cache entry. On the other hand, you could create a single cache with double the size. This would make sharing memory between CPUs simpler and it wouldn't significantly increase access times (so the situation you mentioned wouldn't be affected). The argument for double caches is about cost, scalability and design simplicity, not performance.
The dual cache simplifies things emormously, especially taking the design of the Opteron into account. Opterons are incredibly scalable--each one has three HyperTransport links that can be connected to memory, I/O or another processor. In order to make dual-core chips, all AMD has to do is take two Opterons, put them in the same package and hard-wire a HT link from one processor to the other.
Of course, they also need to worry about things like size and power consumption but the simplified architecture really makes things a lot easier and will probably contribute to lower prices. It will also accelerate the introduction of multi-core (ie more than two) processors...
If they were to implement a unified cache design, they would have to make significant changes. They would need to implement cache snooping and complicated memory management. Given that the new dual-core processors (AMD ones, at least) are meant to be pin-compatible with current processors, this would be a bit much to ask. Maybe they'll have unified caches sometime, but I don't see it happening anytime soon.
I'm sure this has been mentioned many times, but here it is again: copyright infringement is not theft! They are two separate and very different crimes. The only reason the RIAA accuses file sharers of theft is because no one would really care if they were accused of copyright infringement--it doesn't have the same ring to it
I'll say it one more time: downloading music is copyright infringement (assmuing it's copyrighted music, of course). It is not theft.
Why would this be a good thing? Imagine the nightmares web page designers would have to go through if they had to support two completely different non-standards-compliant browsers. We'd need to use several different browsers on a day-to-day basis just to view all the pages correctly.
Now, if firefox could gain a 30% market share while remaining standards compliant, that would be something good because it would destroy Microsoft's attempts to corrupt web languages. If 30% of people used firefox (or any non-IE browser, for that matter), designers would no longer be able to get away with IE-only webpages. And isn't that preferable to having firefox-only pages in addition to the IE ones?
According to my mum (and I can't verify this because I haven't used MS Word in years), Word can read and write .sxw files. Of course, that's no guarantee that they're standards compliant (IE/png anyone?) but its a start. And it would allow "normal" users to open and print the manual.
I can see that it would be an inconvenience to make babies have passports but it shouldn't be such a huge issue. Most babies won't be travelling much anyway and having to update a passport isn't really so onerous.
Compared to things like security wait times and invasive searches, child passports aren't really that bothersome. It isn't an invasion of privacy and it doesn't increase huge wait times so why is everyone getting worked up about it?
I was born in Australia when my parents were visiting and I flew out when I was 7 days old. Maybe the laws are different in the UK, but I had to have a passport in order to leave. I have never heard of children flying on their parents' passports and I don't see what's so horrible about requiring children to have their own.
have you seen http://www.americasarmy.com/?