Here's a counter argument. My knowledge is mostly based on linux.
For very special conditions (i.e. custom hpc apps) where you know almost *exactly* how much resource is going to be used, some of the platform design aspects can impact performance in writing to disk even if swapping is never needed.
In general: -Inactive pages are speculatively copied to disk, but not overwritten unless needed. -If application needs to access memory if both in memory and paged out, no swap reads necessary, no harm, no foul. -An application comes and needs to alloc memory. If inactive pages are using memory, but marked disposable as they are already copied to swap/pagefile, they are overwritten and the allocation of memory is quick. -If nothing was speculatively swapped out, memory allocations in the above situation would crawl, being blocked on I/O writes to disk. This is a tremendous price to pay if memory usage indicates this to be a realistic possibility. Keep in mind the OS has no way of knowing what you are about to do, and can only make assumptions based on general principles.
However, those I/O write operations can be expensive, particularly if otherwise the system isn't needing to touch the storage at all during this time. Invoking the storage driver to do lengthy writes of pages to swap can be devastating to performance. If your environment is *very* tightly controlled and deterministic with respect to resource usage (i.e. customized apps running with little else in the background, not serving and not doing typical desktop/workstation stuff), the OS assumptions/worst case provisions hurt more than help.
Nowadays linux is pretty tunable with how aggresive it is about copying pages to swap, but even still it happens pretty often and those writes can affect HPC applications.
Note that you are still write about the general case, and that people shouldn't flip out about seeing swap/paging file usage while they still have free memory, or even seeing almost no free memory (actually, for those really concerned in linux at least, ignore the first row free number and look at the second row under free, it shows free memory not counting disk buffers and cache, and is a more true reflection of available physical memory).
Not so strangely, each set of 4 DIMM banks is hard wired to the memory controller of each processor.
Accesses from one processor to the further away bank must go through hypertransport, but as long as the OS scheduler is NUMA-aware, jobs should tend to run on the processor which is local to the memory it has been allocated, making for some screaming memory performance relative to single memory controller solutions (most Intel SMP setups).
My post is going to assume that people like the 3D potential of the display, as many other posters have already pointed out how software and current hardware can already do alpha blending for overlay. Here is another analogy:
Two-layer LCD display would be able to give 3D in much the same way that the classic parallax shooters projected into 2D in the early nineties. Few 2D layers. Those by the way were pathetic with only two layers, and the more layers, the cooler it seemed.
However, something that does what modern 3D games do but in real life would actually be interesting. Some places are working on it (actually, with high-speed shutter glasses and syncronized high refresh display, it is already done today.
AMD's design will do nothing more than Intel's for single threaded apps. If you have an environment with one heavy thread and some number of typical lightweight threads, you will be slowed down as the clocks in both instances are slowed due to cooling difficulties.
Also, shared memory controller is *not* cool, though with Intel you have one memory controller for all CPUs (one issue with multi-socket Intel systems is that all processors create contension for memory controller usage, with multi-socket AMD systems, each processor has it's own memory and if each processor's DIMM banks are populated, performance scales well. This is why single-core, multi-socket AMD SMP setups can deliver astounding memory throughput relative to Intel's solution, and also why multi-socket dual core setups will still smoke Intel solutions (each processor will have 2-way like SMP contention, but a NUMA-like setup overall, where, say, a 2-way Intel dual core would now have 4 processors contending for memory controller use.
Also, I have trouble seeing a shared L2 cache as much of a benefit. Yes, it makes cache coherency less trouble, but it is a pretty important place where having cores contend for the resource could be troublesome.
You are right that SMP systems have been around for a while, and haven't been a success in the home market. Essentially, while raw performance has been there, price performance has not. SMP boards are a little more expensive to design, and somewhat more expensive to build. Add to that the cost of populating two sockets, and the extra performance comes at a high premium. Now assuming dual core CPUs will come at some premium less than the cost of 2 single core processors, the price-performance of a dual-core box would be compelling compared to that of a dual-core, dual-socket system.
That makes it hardly useful at all. A lot of apps will break as all traffic from lo interface only gets the first packet through.
Additionally, responding packets get dropped from outgoing connections.
I *think* you wanted at the beginning:
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
The chief differentiator being that RHEL is bought only because of support, not on technical merit of the product by itself. For individual applications particularly, if successful you could guarantee: a) It *will* be re-released for free. b) Unless really complicated, the support alone will not be enough incentive for people to chose the pay option enough to justify any business case.
Let's face it, to do exactly as the GPL expects for products that inherently require little/no support/service, it is near impossible to make money. A lot of companies find the LGPL much more palletable, and can build commercial, non-free software on free libraries and not go against the spirit of those authors.
I like the GPL for my projects, as I don't like the thought of some company or person grabbing my work, putting the slightest bit of spit and polish, and making money off of it while I get nothing for building the base for them, not even code contributions for what they've done.
Another thing to keep in mind, last year at this time, the x86 server market looked like this: 1. HP 2. Dell 3. IBM
Last I heard: 1. HP 2. IBM 3. Dell
In other words, for the first time in a long while, Dell's server marketshare has slipped in a rather significant milestone.
What do HP and IBM have in common in x86 land? AMD offerings. Was this the sole cause of the slip? Probably not, but it is a factor. If Dell's analysis shows that AMD's role in this market shift is significant, it may be more serious about it.
Of course, Intel will probably come through with some incredible offer for Dell, but those incentives are going to have to be better and better if AMD gives success to HP and IBM in marketshare.
On a more amusing note, I like to 'assist' people with remote systems who are with me. I ssh @machine, and hand over the keyboard for them to type. After they give up, usually after 5-15 tries, I switch the layout to qwerty...
I actually have a couple of passwords I don't care much about that are dictionary words, but it is typing dvorak on a qwerty keyboard, so, for example, if I like slashdot a lot, a password might be:;pa;jhsk Not very secure, but it isn't a common strategy to shift by dvorak on a dictionary crack, and plus it lets me start typing dvorak sooner on systems.
My strategy for other things are a bunch of random characters punched onto a keyboard. Thankfully, my memory is pretty good. Pissed off other admins in environments where root password was known by multiple people and it was my turn to pick a password... Of course now the system I set up for shared access has a disabled root account, since I've finally gotten in a position where people understand no direct root login=better accounting practices.
To the first point, laziness and concern do not preclude each other, and they probably deal frequently with the circumstance, small business employee travel, family member treating another family member, etc...
The second point, police work isn't all like it is on TV. From their perspective, they witnessed it, probably retained enough for some evidence, and had the rest tossed.
As to VISA cutting them off, it never says if they had attempted to use it after the card company cut them off. Sure, pending charges might have been rejected, but they would never know that. Besides, what would they do otherwise? They probably assumed they had plenty of time. I had a card stolen once and it turned out just the opposite, the card was cancelled, charges paid by company, and not a damn thing anyone could do to figure out who did it.
I can say that the Logo certification requires a significant amount of technical work, not just some buy off. So yes, the logo does actually mean something on a solid, technical level with respect to accomodating Windows and working with the Windows environment.
I do not do the work, but I have had products I'm working on impacted by some pretty low-level technical changes on the product required to meet WHQL from other groups.
I had the same thought, but in his defense, if everyone was in the habit of doing it, it would train cashiers in general to register that something is weird if ID does not accompany a card.
That being said, it is useless unless you get many masses of people to do it to in order to train retail cashier workers.
Are they demonstratively motivated to care to attempt interpretation of stuff plopped in front of them even if you do the radio receiving, compute translating for them (which would change the outcome as the translation from a radio signal to a form that will be seen will certainly be a key part of sorting it out)? A target species for broadcasts would certainly have to be motivated to mull the point over and try to make sense of it, while the dolphin will think 'I don't give a damn about your dots, now give me a fish'. It is simply completely impossible without prior knowledge of a species communication to have a message so obvious that they will listen even if they don't care to think at all.
Essentially, we are not merely looking for intelligent life, we are looking for sufficiently technologically evolved life to have any hope of them receiving a message, and species that, like us, are actively searching for non random signals, and would jump on a signal and antagonize over it immediately to sort it out. You simply cannot produce a sample of life to prove whether or not it works on anything but other humans.
However, if relations do go south with aliens, the Dolphin's may leave a note: So long, and thanks for all the fish.
I understand your point that theory and reality don't always mesh, buth theory in this case should be a decent approximation of reality.
My question to respond with is are you sure Blizzard is allocating adequate server resources to provide content via Bittorrent, or is BitTorrent their red-headed stepchild with little dedicated bandwidth relying on the miracle of BitTorrent to bridge the gap, reserving most of the bandwidth for the http/ftp servers?
In short, are there any cases of someone actually doing a verifiably fair comparison, where the primary servers of the content are *known* to be on equal bandwidth footing? We can go back and forth all day about 'provider X's torrents are slower than their http/ftp servers', but without more knowledge of the whole picture, a lot of points for either side of the debate cannot be made effectively. Leave out peer clients just to see how in a one-to-one scenario, how does BitTorrent compare to comparable http/ftp setups.
I will say that a scenario where http/ftp is given priority over bittorrent with the expectation of clients picking up the slack for torrents can be a serious degradation in performance, particularly for things like game updates, where occasional players are particularly screwed, as they come into updates at times when no one else is really caring and only the under-resourced official bittorrent servers are providing the torrent content.
Argument doesn't hold very well. It is true that download performance in bittorrent-style scenarios has a much higher amount of variability. However, theoretically, the lower bound of the performance should be on par with the sustained performance of a single server http/ftp servicing the same load, and that should be a rare low. The reason why so many torrents don't deliver what users expect is that there are no providers involved with a really decent pipe. If the resources used for a traditional http/ftp download site were largely repurposed for bittorrent serving, then you see really good numbers to, worst case, maginally better than http/ftp for the site's content.
As you say, the clients are increasing downstream more and more without significant upstream increases, and while this unbalanced growth does negatively impact bittorrent behavior, it even more so impacts traditional single-server downloads such as http/ftp. Any resources spent to increase the provider pipe for http/ftp has an equal effect on bittorrent-style service level (in raw numbers, proportionally if the upstream on clients never improves, bittorrent's advantages become more marginal).
Though I'm not familiar with DTE, but it probably would be the case that daily dte updates would not rock at all. If not updating daily, you get the better ideas, if updating irregularly, the comic comes when good ideas come, hence more consistently good comics out of the irregularly scheduled comics.
Everyone keeps flipping out over the lack of a firewire cable and saying it means iPod+firewire is doomed, no, it is a freaking cable, and the cable would mean absolutely nothing if a dock was built in, which would connect directly to the iPod.
As mentioned before, demo tech frequently runs above the spec that the released product can achieve in stable fashion.
Also, keep in mind, that single core AMD chips are running at higher speeds than 2.4 GHz in their near-production future, so a 2.4 GHz *demo* is *reall* an indication of lower clock speed. By the time it releases, it will probably be lower than demo, *and* the single cores will have moved beyond 2.4 GHz...
The problem here is that the multi-core will inevitably mean slower cores, and a lower speed at which any one thread can possibly be processed. In gaming, for example, it may be multithreaded, but most of the threads are pathetic (user input monitoring is actually really easy and insignificant for example), and one thread (maybe two very rarely) is a resource hog. Therefore even if you have overall 150% more clocks, but each core constitutes 75% of the clock speed of the single core alternative, then the resource-hog thread will actually see about 15-20% reduction in performance (allowing for 5-10% of the processor to handle the threads the other core would have offloaded). The unbalanced nature of gaming threaded tasks historically has been why SMP in gaming systems has been not worth the trouble/expense, and in a multi-core setup could be a liability.
The true benefit is in HPC/server/workstation environments, where there are computational tasks that have much more balanced threading models (*GREAT* cluster nodes, since applications are already written to balance as much as possible work amongst threads.
Now maybe if game developers manage to develop things right, this will change and things will be more balanced, but right now threads are used more as cheap ways to multiplex things that have to happen simultaneously in UP environments, and not designed to leverage SMP configurations.
The big deal is that it is a way to get *cheap* SMP, motherboard sockets x2, the downsides being cooling such densities (read: reduced clock per core), and sharing a memory controller per two cores (which is what Intel SMP has been doing forever, AMD used memory controllers per processor in a NUMA fashion full time, and Hyper Transport to access memory not associated with the current processor).
Theoretically, the dual core clocks will add up to more cycles overall than a single core, but the single core will have more clocks per individual thread, so unless a game leverages threading very nicely in the processor intensive segments, a multi-core may be slower than a single-core for the high-end gaming scene, however for workstation/server/HPC fields, it is very exciting.
That is what a good realtime OS scheduler is supposed to do, time multiplex appropriately your processor. Not perfect, but for the kind of stuff you describe, you can get away with far from perfect and not experience a perceptible difference.
HT is a way of letting one processing unit work with mulitple threads at once. Multi-core technology is identical to SMP, meaning more physical processors actually doing work, so it isn't token.
However, expect lower clockspeeds, two cores in that proximity causes a severe power/heat problem that would mandate reduced clock over single processor solution.
Slashdot Mirror
Well, for examples of large scale AMD deployments, look at the top500, those do not have exotic cooling configurations relative to Intel solutions.
Additionally, AMD has been making their own chipsets for a while, the IBM e325/e326 uses AMD's chipset.
Stop spouting out-of-date nonsense and research things before you flame.
Here's a counter argument. My knowledge is mostly based on linux.
For very special conditions (i.e. custom hpc apps) where you know almost *exactly* how much resource is going to be used, some of the platform design aspects can impact performance in writing to disk even if swapping is never needed.
In general:
-Inactive pages are speculatively copied to disk, but not overwritten unless needed.
-If application needs to access memory if both in memory and paged out, no swap reads necessary, no harm, no foul.
-An application comes and needs to alloc memory. If inactive pages are using memory, but marked disposable as they are already copied to swap/pagefile, they are overwritten and the allocation of memory is quick.
-If nothing was speculatively swapped out, memory allocations in the above situation would crawl, being blocked on I/O writes to disk. This is a tremendous price to pay if memory usage indicates this to be a realistic possibility. Keep in mind the OS has no way of knowing what you are about to do, and can only make assumptions based on general principles.
However, those I/O write operations can be expensive, particularly if otherwise the system isn't needing to touch the storage at all during this time. Invoking the storage driver to do lengthy writes of pages to swap can be devastating to performance. If your environment is *very* tightly controlled and deterministic with respect to resource usage (i.e. customized apps running with little else in the background, not serving and not doing typical desktop/workstation stuff), the OS assumptions/worst case provisions hurt more than help.
Nowadays linux is pretty tunable with how aggresive it is about copying pages to swap, but even still it happens pretty often and those writes can affect HPC applications.
Note that you are still write about the general case, and that people shouldn't flip out about seeing swap/paging file usage while they still have free memory, or even seeing almost no free memory (actually, for those really concerned in linux at least, ignore the first row free number and look at the second row under free, it shows free memory not counting disk buffers and cache, and is a more true reflection of available physical memory).
Not so strangely, each set of 4 DIMM banks is hard wired to the memory controller of each processor.
Accesses from one processor to the further away bank must go through hypertransport, but as long as the OS scheduler is NUMA-aware, jobs should tend to run on the processor which is local to the memory it has been allocated, making for some screaming memory performance relative to single memory controller solutions (most Intel SMP setups).
My post is going to assume that people like the 3D potential of the display, as many other posters have already pointed out how software and current hardware can already do alpha blending for overlay.
Here is another analogy:
Two-layer LCD display would be able to give 3D in much the same way that the classic parallax shooters projected into 2D in the early nineties. Few 2D layers. Those by the way were pathetic with only two layers, and the more layers, the cooler it seemed.
However, something that does what modern 3D games do but in real life would actually be interesting. Some places are working on it (actually, with high-speed shutter glasses and syncronized high refresh display, it is already done today.
AMD's design will do nothing more than Intel's for single threaded apps. If you have an environment with one heavy thread and some number of typical lightweight threads, you will be slowed down as the clocks in both instances are slowed due to cooling difficulties.
Also, shared memory controller is *not* cool, though with Intel you have one memory controller for all CPUs (one issue with multi-socket Intel systems is that all processors create contension for memory controller usage, with multi-socket AMD systems, each processor has it's own memory and if each processor's DIMM banks are populated, performance scales well. This is why single-core, multi-socket AMD SMP setups can deliver astounding memory throughput relative to Intel's solution, and also why multi-socket dual core setups will still smoke Intel solutions (each processor will have 2-way like SMP contention, but a NUMA-like setup overall, where, say, a 2-way Intel dual core would now have 4 processors contending for memory controller use.
Also, I have trouble seeing a shared L2 cache as much of a benefit. Yes, it makes cache coherency less trouble, but it is a pretty important place where having cores contend for the resource could be troublesome.
You are right that SMP systems have been around for a while, and haven't been a success in the home market. Essentially, while raw performance has been there, price performance has not. SMP boards are a little more expensive to design, and somewhat more expensive to build. Add to that the cost of populating two sockets, and the extra performance comes at a high premium. Now assuming dual core CPUs will come at some premium less than the cost of 2 single core processors, the price-performance of a dual-core box would be compelling compared to that of a dual-core, dual-socket system.
That makes it hardly useful at all. A lot of apps will break as all traffic from lo interface only gets the first packet through. Additionally, responding packets get dropped from outgoing connections. I *think* you wanted at the beginning:
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
The chief differentiator being that RHEL is bought only because of support, not on technical merit of the product by itself. For individual applications particularly, if successful you could guarantee:
a) It *will* be re-released for free.
b) Unless really complicated, the support alone will not be enough incentive for people to chose the pay option enough to justify any business case.
Let's face it, to do exactly as the GPL expects for products that inherently require little/no support/service, it is near impossible to make money. A lot of companies find the LGPL much more palletable, and can build commercial, non-free software on free libraries and not go against the spirit of those authors.
I like the GPL for my projects, as I don't like the thought of some company or person grabbing my work, putting the slightest bit of spit and polish, and making money off of it while I get nothing for building the base for them, not even code contributions for what they've done.
Another thing to keep in mind, last year at this time, the x86 server market looked like this:
1. HP
2. Dell
3. IBM
Last I heard:
1. HP
2. IBM
3. Dell
In other words, for the first time in a long while, Dell's server marketshare has slipped in a rather significant milestone.
What do HP and IBM have in common in x86 land? AMD offerings. Was this the sole cause of the slip? Probably not, but it is a factor. If Dell's analysis shows that AMD's role in this market shift is significant, it may be more serious about it.
Of course, Intel will probably come through with some incredible offer for Dell, but those incentives are going to have to be better and better if AMD gives success to HP and IBM in marketshare.
Then list them for the sake of comparison...
I know I'm getting bombarded with rails rails rails and no one else seems to bother to talk about what other things are similar in other languages..
In their defense, they must defend against their brading becomin generic, or else they lose rights.
Example: Escalator once was a brand,
now it is a generic term.
On a more amusing note, I like to 'assist' people with remote systems who are with me. I ssh @machine, and hand over the keyboard for them to type. After they give up, usually after 5-15 tries, I switch the layout to qwerty...
;pa;jhsk
I actually have a couple of passwords I don't care much about that are dictionary words, but it is typing dvorak on a qwerty keyboard, so, for example, if I like slashdot a lot, a password might be:
Not very secure, but it isn't a common strategy to shift by dvorak on a dictionary crack, and plus it lets me start typing dvorak sooner on systems.
My strategy for other things are a bunch of random characters punched onto a keyboard. Thankfully, my memory is pretty good. Pissed off other admins in environments where root password was known by multiple people and it was my turn to pick a password... Of course now the system I set up for shared access has a disabled root account, since I've finally gotten in a position where people understand no direct root login=better accounting practices.
To the first point, laziness and concern do not preclude each other, and they probably deal frequently with the circumstance, small business employee travel, family member treating another family member, etc...
The second point, police work isn't all like it is on TV. From their perspective, they witnessed it, probably retained enough for some evidence, and had the rest tossed.
As to VISA cutting them off, it never says if they had attempted to use it after the card company cut them off. Sure, pending charges might have been rejected, but they would never know that. Besides, what would they do otherwise? They probably assumed they had plenty of time. I had a card stolen once and it turned out just the opposite, the card was cancelled, charges paid by company, and not a damn thing anyone could do to figure out who did it.
As for using the hotel computer, why not?
I can say that the Logo certification requires a significant amount of technical work, not just some buy off. So yes, the logo does actually mean something on a solid, technical level with respect to accomodating Windows and working with the Windows environment.
I do not do the work, but I have had products I'm working on impacted by some pretty low-level technical changes on the product required to meet WHQL from other groups.
I had the same thought, but in his defense, if everyone was in the habit of doing it, it would train cashiers in general to register that something is weird if ID does not accompany a card.
That being said, it is useless unless you get many masses of people to do it to in order to train retail cashier workers.
Intelligent, possibly, build-radio-receiver intelligent, no.
Are they demonstratively motivated to care to attempt interpretation of stuff plopped in front of them even if you do the radio receiving, compute translating for them (which would change the outcome as the translation from a radio signal to a form that will be seen will certainly be a key part of sorting it out)? A target species for broadcasts would certainly have to be motivated to mull the point over and try to make sense of it, while the dolphin will think 'I don't give a damn about your dots, now give me a fish'. It is simply completely impossible without prior knowledge of a species communication to have a message so obvious that they will listen even if they don't care to think at all.
Essentially, we are not merely looking for intelligent life, we are looking for sufficiently technologically evolved life to have any hope of them receiving a message, and species that, like us, are actively searching for non random signals, and would jump on a signal and antagonize over it immediately to sort it out. You simply cannot produce a sample of life to prove whether or not it works on anything but other humans.
However, if relations do go south with aliens, the Dolphin's may leave a note:
So long, and thanks for all the fish.
I understand your point that theory and reality don't always mesh, buth theory in this case should be a decent approximation of reality.
My question to respond with is are you sure Blizzard is allocating adequate server resources to provide content via Bittorrent, or is BitTorrent their red-headed stepchild with little dedicated bandwidth relying on the miracle of BitTorrent to bridge the gap, reserving most of the bandwidth for the http/ftp servers?
In short, are there any cases of someone actually doing a verifiably fair comparison, where the primary servers of the content are *known* to be on equal bandwidth footing? We can go back and forth all day about 'provider X's torrents are slower than their http/ftp servers', but without more knowledge of the whole picture, a lot of points for either side of the debate cannot be made effectively. Leave out peer clients just to see how in a one-to-one scenario, how does BitTorrent compare to comparable http/ftp setups.
I will say that a scenario where http/ftp is given priority over bittorrent with the expectation of clients picking up the slack for torrents can be a serious degradation in performance, particularly for things like game updates, where occasional players are particularly screwed, as they come into updates at times when no one else is really caring and only the under-resourced official bittorrent servers are providing the torrent content.
Argument doesn't hold very well. It is true that download performance in bittorrent-style scenarios has a much higher amount of variability. However, theoretically, the lower bound of the performance should be on par with the sustained performance of a single server http/ftp servicing the same load, and that should be a rare low. The reason why so many torrents don't deliver what users expect is that there are no providers involved with a really decent pipe. If the resources used for a traditional http/ftp download site were largely repurposed for bittorrent serving, then you see really good numbers to, worst case, maginally better than http/ftp for the site's content.
As you say, the clients are increasing downstream more and more without significant upstream increases, and while this unbalanced growth does negatively impact bittorrent behavior, it even more so impacts traditional single-server downloads such as http/ftp. Any resources spent to increase the provider pipe for http/ftp has an equal effect on bittorrent-style service level (in raw numbers, proportionally if the upstream on clients never improves, bittorrent's advantages become more marginal).
Nowadays, Firefox has made a name for itself, more so than netscape I would dare say.
Though I'm not familiar with DTE, but it probably would be the case that daily dte updates would not rock at all. If not updating daily, you get the better ideas, if updating irregularly, the comic comes when good ideas come, hence more consistently good comics out of the irregularly scheduled comics.
Everyone keeps flipping out over the lack of a firewire cable and saying it means iPod+firewire is doomed, no, it is a freaking cable, and the cable would mean absolutely nothing if a dock was built in, which would connect directly to the iPod.
As mentioned before, demo tech frequently runs above the spec that the released product can achieve in stable fashion.
Also, keep in mind, that single core AMD chips are running at higher speeds than 2.4 GHz in their near-production future, so a 2.4 GHz *demo* is *reall* an indication of lower clock speed. By the time it releases, it will probably be lower than demo, *and* the single cores will have moved beyond 2.4 GHz...
The problem here is that the multi-core will inevitably mean slower cores, and a lower speed at which any one thread can possibly be processed. In gaming, for example, it may be multithreaded, but most of the threads are pathetic (user input monitoring is actually really easy and insignificant for example), and one thread (maybe two very rarely) is a resource hog. Therefore even if you have overall 150% more clocks, but each core constitutes 75% of the clock speed of the single core alternative, then the resource-hog thread will actually see about 15-20% reduction in performance (allowing for 5-10% of the processor to handle the threads the other core would have offloaded). The unbalanced nature of gaming threaded tasks historically has been why SMP in gaming systems has been not worth the trouble/expense, and in a multi-core setup could be a liability.
The true benefit is in HPC/server/workstation environments, where there are computational tasks that have much more balanced threading models (*GREAT* cluster nodes, since applications are already written to balance as much as possible work amongst threads.
Now maybe if game developers manage to develop things right, this will change and things will be more balanced, but right now threads are used more as cheap ways to multiplex things that have to happen simultaneously in UP environments, and not designed to leverage SMP configurations.
The big deal is that it is a way to get *cheap* SMP, motherboard sockets x2, the downsides being cooling such densities (read: reduced clock per core), and sharing a memory controller per two cores (which is what Intel SMP has been doing forever, AMD used memory controllers per processor in a NUMA fashion full time, and Hyper Transport to access memory not associated with the current processor).
Theoretically, the dual core clocks will add up to more cycles overall than a single core, but the single core will have more clocks per individual thread, so unless a game leverages threading very nicely in the processor intensive segments, a multi-core may be slower than a single-core for the high-end gaming scene, however for workstation/server/HPC fields, it is very exciting.
That is what a good realtime OS scheduler is supposed to do, time multiplex appropriately your processor. Not perfect, but for the kind of stuff you describe, you can get away with far from perfect and not experience a perceptible difference.
HT is a way of letting one processing unit work with mulitple threads at once. Multi-core technology is identical to SMP, meaning more physical processors actually doing work, so it isn't token.
However, expect lower clockspeeds, two cores in that proximity causes a severe power/heat problem that would mandate reduced clock over single processor solution.