It depends on three things: 1: Whether the software CAN use multiple cores. 2: How efficiently it uses the extra cores. 3: Whether the program is currently limited by cpu power or by something else.
For "1:", if the program can't use the extra cores, then you'll only see a speed improvement from the fact that the cores are 15% more efficient. i.e. A 2GHz one of these quads performs the same as a 2.3GHz (+15%) dual core from the previous generation for applications in this category.
For "2:", if the program can use the extra cores, but not as efficiently as the first, then you'll see a speed increase equivalent to this. e.g., if the program does two tasks at once, one that takes 70 seconds and one that takes 30, then on one core it'll take 100 seconds. On two cores it would do the 70 second task on one core and the 30 second task on the other, reducing the total time to 70 seconds, a ~40% speed improvement.
For "3:", if the application is limited by something other than the cpu, e.g. "how quickly it can pull data from the hard-disk", you will likely see no improvement whatsoever.
In conclusion, depending on what applications you use, you will see anywhere from no improvement up to 2.3x the previous speed (x2 for double the cores and +15% from the improved efficiency).
Note: As these cpus also have an extra instruction set extension, applications that make use of this could exceed the speed improvements I noted above.
Actually, they sacrificed reliability for capacity, speed AND price. People buy as big a drive as they can afford, from of whoever offers the largest, not paying attention to how reliable it is. OEMs are the same. The only people who really care about reliability buy special server/raid class drives, and they really pay for them.
It wasn't THAT fast, but it handled very well and was very small (Americans mistake them for golf carts apparently), which saved me once or twice. Tearing round a Norfolk country road to see a tractor with a spiky thing on the front taking up his whole lane and half of yours...
I'm glad I was in a Mini.
The least believable part of the story was that I was racing* my dad at the time. * Ok, not technically racing, but he'd put larger wheels on his tuned 1.3L convertible Mini than it came with, and he wanted to know how out the speedo was. The bright idea was that he'd do 60MPH, then I'd follow him, match his speed and tell him how fast it was when we got home. Turns out when his speedo read 60MPH it meant he was doing 90MPH. I could barely keep up, and he wasn't maxed out. It's amazing how fast a car with only 4 gears can go.
Then again, the improved handling (and better sense of speed) in an old Mini comes at a price: hit a tree and the engine goes through the driver. Crash safety? What's that?
In the end the engine died. The water pump broke, the engine overheated and one of the pistons welded itself to the cylinder.
In the UK, BBC Radio 1 run a line called "Flirt Divert". People hand that number out (pretending it's their own) to people who ask and they don't want to give their real number to, and their answering phone messages get played back on the radio. Some people leave multiple messages, and make a real fool of themselves.
It's almost as funny as when they were linking the calls to two Chinese takeaways together, so you had two people speaking bad English arguing over who was the restaurant and who was ordering.
Everyone I know who uses XP boots it at least once a day because power management does not work for them. Actually, most people boot Windows every day because they use "shutdown" instead of even trying (or in some cases knowing about) standby/sleep or hibernate. Score one for ignorance. Though to be fair, it's generally drivers and hardware that cause Windows to fail to suspend/resume, I'd be surprised if Linux running on the same hardware could.
I use hibernate, and I only restart when there's a Windows update to install, or something major goes wrong (very very rare). The last time I needed to restart (not counting updates) was when I'd left Trillian open when hibernating and returning caused it to freeze the entire pc. Quite how it manages to freeze the pc (it does it when it's loading too) I don't know, but apparently it's fixed in the beta of the new version.
The widows [sic] web servers you mentioned with expensive hardware can barely make thirty days on average. I also have a Windows server (running 2003, cost me a few hundred pounds to build) that has only ever been restarted for updates. This happens to be about once a month, but if I really wanted to leave my system potentially insecure I could have longer uptimes. The longest uptime in the log (since January, I cleared the log then) is 3 months, with one unexpected shutdown due to a powercut/UPS failure (hardly Windows's fault). The only messages in the system event log in the past 7 days are uptime messages and messages about the HTTP proxy auto-discovery service starting and stopping, which I have now disabled as it's not needed.
I just said that the number of P2P downloads of songs that people otherwise already own is probably insignificant in the face of the amount of blatantly illegal downloads.
Except that the "money" is specific to each country involved, not shared. If a country is buying (importing) more than it's selling (exporting) other companies end up with a lot of the buyer's money, which they don't really want if that country isn't selling much. That's a trade deficit, and it makes the value of the currency go down. People don't want your money, because they can't buy much with it.
Sorry, I was tired, but my point that the instruction L1 cache at least had to be completely reworked for the 64-bit instruction set stands, even if they did use the same general layout.
The L1 cache was indeed on-die for all athlons, it was the L2 that was originally off-die (in the original slot version of the cpu). There seems to be an error in the wikipedia article if they have indeed never made a 16-way L1 cache: "Athlon was the first x86 processor with a 128 KiB split level 1 cache; a 2-way associative, later 16-way, cache separated into 2×64 KiB for data and instructions (Harvard architecture)." AMD's spec sheets confirm that the Athlon and Athlon 64s do indeed only have a 2-way L1 cache. The L1 data cache does seem to be the same spec for both Athlon and Athlon 64, "supporting 2 concurrent 64-bit reads/writes" according to the athlon sheet and "Two 64-bit operations per cycle, 3-cycle latency" according to the athlon 64 one. As the original doesn't quote latency, that might have changed, and "two simultaneous ops" vs "2 ops per cycle" could be different too, but at first glance it seems to be the same.
I still think that they re-used existing cpu sections that worked perfectly fine (updated for the new instruction set if necessary), but saying that the whole cpu only an incremental improvement over the K6 Athlon is stretching it a bit.
Oh, and the "K7" in that section of my post you quoted should have said "K6". Typo there.
My god, there are too many errors in that article. Eg, the first one that jumped out at me: "Both Athlon and Hammer have a 128KB, two-way set associative, on-die L1 cache." The original athlon had a 2-way associative cache, but it wasn't on-die, or 128kB. Later chips (also "K7" and "Athlon", but with a redesigned core) were 16-way, 128kB, on die. Which are they comparing against? Do they even know?
Reading through it, it sounds like they're saying that AMD re-used parts of the K6 core that worked fine, but almost completely re-worked them for the new instruction (x86-64) set, 64-bit addressing, the new on-die northbridge/memory controller, or the new data bus. eg. K7 has the same size L1 cache as the later K6s, with the same associativity, but it's been completely rebuilt to work with 64-bit addresses and x86_64 instructions (remember the L1 is a specialized instruction and data cache). They both have an instruction decoder, but again, it's nothing like the old one. The cpu's pipeline is even significantly different. They draw parallels, saying "x step is like the old y step" and then claim it's only an incremental improvement.
It's more of an improvement than K6 over K5, that's for sure.
Wait, So you're saying that the upgrade from the Athlon (native 32-bit core, external memory controller, FSB based) to Athlon 64 (native 64-bit core, on-die memory controller, hypertransport bus based) is an incremental improvement?
I have a screenshot of my X2 3800+ running at 2.8GHz (40% overclock), and it would go higher if my motherboard could do more than a 5% increase in cpu voltage. That's on air too.
That doesn't help with the fact that I can't run a 16-bit executable (16-bit code) under a 64-bit OS. It's physically impossible to switch the cpu from 64-bit mode to 16-bit mode, so a full emulator is the only option (and wine is not one).
It's the only way I can run 16-bit software, as you can't run 16-bit programs under today's 64-bit OSs. Not that big of a loss really, and I get the authentic feel of running it in Win3.1.
The problem isn't with Windows, it's with device manufacturers releasing shoddy drivers. I've never seen sleep or hibernate fail on a stock laptop for example, because all the hardware (and drivers) for them are designed to support it.
If a driver initializes the device in the windows "powered on" message but not the "resuming from sleep" message, then the pc might never return from sleep.
Sleep and hibernate both work on my amd/nvidia machine (in both Windows XP and Ubuntu Linux). Intel generally handles sleep well, I don't know about ati graphics cards or other chipsets (via, sys, etc).
Oh yea. 1.0, 3.1, 95, 98, 2000, ME, XP, Vista...real coherent scheme there. Goes from small decimal numbers to large two digit numbers to four digit numbers to two letters to words. Actually there were versions between 1.0 and 3.1, and it diverged at 3.1 into 2 lines. One which was the 9x series (now discontinued, thankfully), and one which kept the decimal numbering up right up to 7.0 (so far), though presenting a friendly name for home buyers: 1.0, 2.0, 3.0, 3.1, 95 (9x.1), 98 (9x.2), ME (9x.3), discontinued 1.0, 2.0, 3.0, NT 3.1, NT 3.5, NT 4.0, NT 5.0 (2000), NT 5.1 (XP), NT 5.2 (Server 2003/XP x64), NT 6.0 (Vista), NT 6.1 (Server 2008), NT 7.0 (Vista 2?)
There are many private torrent sites, and they tend to have one advantage over public ones: Fewer leechers. People on a private tracker get their download/upload exposed, and can be kicked out if they don't upload enough, so there is incentive to upload, which makes everyone's downloads go faster.
Remember, in bittorrent, total download rate = total upload rate, so the fewer people that only download and don't upload, the faster everyon else's downloads go.
No, it's not the only kind of font anti-aliasing windows has, it has "standard" anti-aliasing too.
My guess is that you either have a BGR (reversed) TFT, or a crt. Cleartype is set up for RGB TFTs by default, and can be set up for BGR TFTs, but it doesn't work on a CRT (and it's not supposed to either).
Slashdot Mirror
It depends on three things:
1: Whether the software CAN use multiple cores.
2: How efficiently it uses the extra cores.
3: Whether the program is currently limited by cpu power or by something else.
For "1:", if the program can't use the extra cores, then you'll only see a speed improvement from the fact that the cores are 15% more efficient. i.e. A 2GHz one of these quads performs the same as a 2.3GHz (+15%) dual core from the previous generation for applications in this category.
For "2:", if the program can use the extra cores, but not as efficiently as the first, then you'll see a speed increase equivalent to this. e.g., if the program does two tasks at once, one that takes 70 seconds and one that takes 30, then on one core it'll take 100 seconds. On two cores it would do the 70 second task on one core and the 30 second task on the other, reducing the total time to 70 seconds, a ~40% speed improvement.
For "3:", if the application is limited by something other than the cpu, e.g. "how quickly it can pull data from the hard-disk", you will likely see no improvement whatsoever.
In conclusion, depending on what applications you use, you will see anywhere from no improvement up to 2.3x the previous speed (x2 for double the cores and +15% from the improved efficiency).
Note: As these cpus also have an extra instruction set extension, applications that make use of this could exceed the speed improvements I noted above.
It would be voice activated. Like, uh, your mobile can do.
Yeah.
Actually, they sacrificed reliability for capacity, speed AND price. People buy as big a drive as they can afford, from of whoever offers the largest, not paying attention to how reliable it is. OEMs are the same. The only people who really care about reliability buy special server/raid class drives, and they really pay for them.
They weren't 50% oversized, IIRC they only went from 10" to 12". Something else must have contributed to the difference as well.
As for the overheating thing, I was young and stupid.
My first car was an old 1.0L Mini :)
It wasn't THAT fast, but it handled very well and was very small (Americans mistake them for golf carts apparently), which saved me once or twice.
Tearing round a Norfolk country road to see a tractor with a spiky thing on the front taking up his whole lane and half of yours...
I'm glad I was in a Mini.
The least believable part of the story was that I was racing* my dad at the time.
* Ok, not technically racing, but he'd put larger wheels on his tuned 1.3L convertible Mini than it came with, and he wanted to know how out the speedo was. The bright idea was that he'd do 60MPH, then I'd follow him, match his speed and tell him how fast it was when we got home. Turns out when his speedo read 60MPH it meant he was doing 90MPH. I could barely keep up, and he wasn't maxed out. It's amazing how fast a car with only 4 gears can go.
Then again, the improved handling (and better sense of speed) in an old Mini comes at a price: hit a tree and the engine goes through the driver. Crash safety? What's that?
In the end the engine died. The water pump broke, the engine overheated and one of the pistons welded itself to the cylinder.
In the UK, BBC Radio 1 run a line called "Flirt Divert". People hand that number out (pretending it's their own) to people who ask and they don't want to give their real number to, and their answering phone messages get played back on the radio. Some people leave multiple messages, and make a real fool of themselves.
It's almost as funny as when they were linking the calls to two Chinese takeaways together, so you had two people speaking bad English arguing over who was the restaurant and who was ordering.
My god some of these anonymous guys are mean.
I hope all of you never have to watch someone you know die, I really do.
I have 2 of those: "2xAthlon MP 2400+, 2GB DDR" :)
Not my desktop though.
Even my parent's 3-year-old pc is better (just, XP 2700+).
Though to be fair, it's generally drivers and hardware that cause Windows to fail to suspend/resume, I'd be surprised if Linux running on the same hardware could.
I use hibernate, and I only restart when there's a Windows update to install, or something major goes wrong (very very rare). The last time I needed to restart (not counting updates) was when I'd left Trillian open when hibernating and returning caused it to freeze the entire pc. Quite how it manages to freeze the pc (it does it when it's loading too) I don't know, but apparently it's fixed in the beta of the new version. The widows [sic] web servers you mentioned with expensive hardware can barely make thirty days on average. I also have a Windows server (running 2003, cost me a few hundred pounds to build) that has only ever been restarted for updates. This happens to be about once a month, but if I really wanted to leave my system potentially insecure I could have longer uptimes. The longest uptime in the log (since January, I cleared the log then) is 3 months, with one unexpected shutdown due to a powercut/UPS failure (hardly Windows's fault).
The only messages in the system event log in the past 7 days are uptime messages and messages about the HTTP proxy auto-discovery service starting and stopping, which I have now disabled as it's not needed.
I can one-up you there, I have a few modern games that don't run on my modern hardware, because of drm that only works on XP and not XP x64 edition.
Cracked to remove the drm and then it's all fine.
The games I play the most don't have drm, at least not any more. EVE online and NWN.
I didn't say they were lost sales :)
I just said that the number of P2P downloads of songs that people otherwise already own is probably insignificant in the face of the amount of blatantly illegal downloads.
Except that the "money" is specific to each country involved, not shared. If a country is buying (importing) more than it's selling (exporting) other companies end up with a lot of the buyer's money, which they don't really want if that country isn't selling much. That's a trade deficit, and it makes the value of the currency go down. People don't want your money, because they can't buy much with it.
This is bad.
Probably an insignificant amount in the face of the illegal downloads going on.
Sorry, I was tired, but my point that the instruction L1 cache at least had to be completely reworked for the 64-bit instruction set stands, even if they did use the same general layout.
The L1 cache was indeed on-die for all athlons, it was the L2 that was originally off-die (in the original slot version of the cpu). There seems to be an error in the wikipedia article if they have indeed never made a 16-way L1 cache: "Athlon was the first x86 processor with a 128 KiB split level 1 cache; a 2-way associative, later 16-way, cache separated into 2×64 KiB for data and instructions (Harvard architecture)." AMD's spec sheets confirm that the Athlon and Athlon 64s do indeed only have a 2-way L1 cache. The L1 data cache does seem to be the same spec for both Athlon and Athlon 64, "supporting 2 concurrent 64-bit reads/writes" according to the athlon sheet and "Two 64-bit operations per cycle, 3-cycle latency" according to the athlon 64 one. As the original doesn't quote latency, that might have changed, and "two simultaneous ops" vs "2 ops per cycle" could be different too, but at first glance it seems to be the same.
I still think that they re-used existing cpu sections that worked perfectly fine (updated for the new instruction set if necessary), but saying that the whole cpu only an incremental improvement over the K6 Athlon is stretching it a bit.
Oh, and the "K7" in that section of my post you quoted should have said "K6". Typo there.
And the cost of the panel compared to that $230?
My god, there are too many errors in that article.
Eg, the first one that jumped out at me: "Both Athlon and Hammer have a 128KB, two-way set associative, on-die L1 cache."
The original athlon had a 2-way associative cache, but it wasn't on-die, or 128kB. Later chips (also "K7" and "Athlon", but with a redesigned core) were 16-way, 128kB, on die. Which are they comparing against? Do they even know?
Reading through it, it sounds like they're saying that AMD re-used parts of the K6 core that worked fine, but almost completely re-worked them for the new instruction (x86-64) set, 64-bit addressing, the new on-die northbridge/memory controller, or the new data bus. eg. K7 has the same size L1 cache as the later K6s, with the same associativity, but it's been completely rebuilt to work with 64-bit addresses and x86_64 instructions (remember the L1 is a specialized instruction and data cache). They both have an instruction decoder, but again, it's nothing like the old one. The cpu's pipeline is even significantly different. They draw parallels, saying "x step is like the old y step" and then claim it's only an incremental improvement.
It's more of an improvement than K6 over K5, that's for sure.
Everyone's too scared.
Wait, So you're saying that the upgrade from the Athlon (native 32-bit core, external memory controller, FSB based) to Athlon 64 (native 64-bit core, on-die memory controller, hypertransport bus based) is an incremental improvement?
I have a screenshot of my X2 3800+ running at 2.8GHz (40% overclock), and it would go higher if my motherboard could do more than a 5% increase in cpu voltage. That's on air too.
Still, it has nothing on a core 2.
That doesn't help with the fact that I can't run a 16-bit executable (16-bit code) under a 64-bit OS. It's physically impossible to switch the cpu from 64-bit mode to 16-bit mode, so a full emulator is the only option (and wine is not one).
Windows 3.1 runs on dosbox.
It's the only way I can run 16-bit software, as you can't run 16-bit programs under today's 64-bit OSs. Not that big of a loss really, and I get the authentic feel of running it in Win3.1.
The problem isn't with Windows, it's with device manufacturers releasing shoddy drivers. I've never seen sleep or hibernate fail on a stock laptop for example, because all the hardware (and drivers) for them are designed to support it.
If a driver initializes the device in the windows "powered on" message but not the "resuming from sleep" message, then the pc might never return from sleep.
Sleep and hibernate both work on my amd/nvidia machine (in both Windows XP and Ubuntu Linux). Intel generally handles sleep well, I don't know about ati graphics cards or other chipsets (via, sys, etc).
1.0, 2.0, 3.0, 3.1, 95 (9x.1), 98 (9x.2), ME (9x.3), discontinued
1.0, 2.0, 3.0, NT 3.1, NT 3.5, NT 4.0, NT 5.0 (2000), NT 5.1 (XP), NT 5.2 (Server 2003/XP x64), NT 6
That's not flamebait, it's a fair point.
There are many private torrent sites, and they tend to have one advantage over public ones: Fewer leechers. People on a private tracker get their download/upload exposed, and can be kicked out if they don't upload enough, so there is incentive to upload, which makes everyone's downloads go faster.
Remember, in bittorrent, total download rate = total upload rate, so the fewer people that only download and don't upload, the faster everyon else's downloads go.
No, it's not the only kind of font anti-aliasing windows has, it has "standard" anti-aliasing too.
My guess is that you either have a BGR (reversed) TFT, or a crt. Cleartype is set up for RGB TFTs by default, and can be set up for BGR TFTs, but it doesn't work on a CRT (and it's not supposed to either).