You just proved my point. You ran a test with the most ideal case (pure integer code) and it ran slower when on the same module. Run more real world code with two threads and the performance hit gets bigger. Try the same test on an i7. The code will run the same speed no matter which cores it uses, as it doesn't lie to the OS can claim the SMT units are full cores.
This is the whole reason why Windows 7 has problems scheduling on the FX CPUs. AMD LIES to the OS and claims the SMT units are full cores. This causes performance problems when Windows schedules as if it was true. If AMD had been truthful then the FX CPUs would perform to their fullest potential on any OS, and Linux and Win 8 would not have had to be modified to work around the issue.
Call it hyper-threading, SMT or whatever, the second integer unit on FX CPUs are not full cores. AMD did SMT better than Intel, but it's still not a full core.
No, "Almost all parts" are not duplicated. Only the integer units and the L1 data caches are duplicated. The L1 instruction cache, the instruction fech, instruction decode (the big performance hit), branch predictor, instruction dispatcher, FPU and bus interface are all shared. Running almost any two threads that max out the "cores" on the same module is slower than running them on two separate modules.
Just because AMD calls them cores does not make it true.
The problem is that AMD called its version of hyper-threading a full core, which it clearly is not. Even though they put a second integer unit in the module, most other parts are shared and the performance of the second half of the module suffers. The FX-8150 is really a 4 core CPU with a good hyper-threading implementation, not an 8 core CPU. If the FX CPUs had claimed to have hyper-threading instead of full cores then Windows 7 would have scheduled properly on them.
DOS did have multi monitor support from day 1, but not in the way we think of it today. You could combine a CGA card (or later EGA, VGA, etc) with an MDA (monochrome, text only) card. The idea was to use the MDA for high resolution (at the time) text and the CGA for low res graphics. Software had to be specifically written for it, but it was possible. Later, some DOS debuggers could use the MDA as a debug output separate from the main screen.
Are you sure they are 32 bit and not 16 bit, ie Windows 3.X apps? Lots of old apps are 16 bit and many older 32 bit Windows programs have 16 bit installers. 64 bit Windows tries to work around the 16 bit installer problem, but it's not perfect.
Probably an outlier, but I remember that Scorched Earth ran much better after I added a 387 to my 386 machine back in the early 90s. Specifically the projectile trajectories were calculated much quicker.
Spinrite has been useless for over 25 years. IDE came out in 1986. Since then, low level access to drives has been impossible. AHCI is not an issue, as Spinrite doesn't actually use the low level commands it claims to. SSDs aren't an issue either, at least as far as what Spinrite can actually do which is very little. Spinrite can't actually tell it is running on an SSD and thinks it is a mechanical drive. Doesn't stop it from spewing BS about magnetics of SSDs!
Which tools did you try? Were they actually meant to deal with bad sectors or were they just tools for dealing with fileystem/OS corruption?
Spinrite can deal with bad sectors in that it can continue copying after an error and it can retry many times. However, it is not unique in this. There are other tools that can do this as well, including free and open source ones. Where Spinrite fails in this task is that it only writes the recovered data to the same drive. This can cause other data to get overwritten or just lost as you are writing from one spot on a bad drive to another spot on the same bad drive.
If you need a tool that can deal with bad sectors look at dd_rescue or Roadkil's Unstoppable Copier
You seem to have it in for Spinrite, but it's not clear why. If you listen to Steve's podcast (Security Now), you'll know that he is very careful on how he describes the technical aspects of his products (including Spinrite). I'd be very surprised if you or anyone could point to any of GRC's literature on Spinrite that would prove he's "lying" about anything.
http://www.grc.com/spinrite.htm "and ALL OTHER file systems". Tell me, how well does Spinrite support UFS? EXT4? ZFS? Given that the ZFS driver code alone is several times the size of Spinrite that's not really possible. And filesystem support is important given Spinrite's braindead data recovery. If there is no knowledge of the underlying filesystem then Spinrite has no way of knowing if it is overwriting data, filesystem structure or empty space. Even if it was lucky and got empty space, there is no way for it to update the filesystem so you can recover the data.
How about this beauty from http://www.grc.com/srphysics.htm: "SpinRite is actually able to lower the amplification of the drive's internal read-amplifier". I don't think I even need to explain why that is BS. Tell me, which ATA or BIOS commands can do that?
My point about the ATA command is that Spinrite is only using standard commands; not undocumented commands or anything secret like that. However, what is "special" are the sequence of commands used to help the drive recover sectors that get a read error.
Ok, using what you just said, explain the "Dynastat Data Recovery" in Spinrite. To refresh your memory, that is where it claims to be working down to the bit level. You cannot address individual bits or even bytes on a drive, either with BIOS or direct ATA commands. And before you say something stupid about "averaging" or other mathematical BS, a modern drive can only return one of two things for a sector request. The correct data when the ecc matches, or an error.
You obviously have never really read what Spinrite claims to do. Look at that "physics" link. Anyone with even passing knowledge of basic science and how computers work can figure out that it is BS.
Your example of a USB drive is just another way of saying "flash", for which Spinrite is not targeted to fix.
Indeed, there are no more "low level" commands like in the day of old HDD technology. However, Spinrite uses the standard ATA command set to do everything possible to get your data off your drive. It does this very well and you'll be hard pressed to find other programs that do it better that don't cost a lot, lot more money (think data recovery repair center).
The fact that USB is flash isn't the point, the point is a USB key is not an ATA device. A USB mechanical hard drive would work just the same. A USB device booted in this way does not support ATA, only BIOS INT 13h calls. Same as if you used it against a SCSI drive in DOS. Spinrite is lying about even using ATA commands.
Spinrite may do an OK job of exercising disks, but 90% of what it claims to do is BS.
An easy test to prove that Spinrite is BS is run it against a USB key. Not a SATA SSD, but a USB flash drive. Make the USB key bootable with DOS, put Spinrite on and boot a PC with no other drives. Run its "tests" against the USB key. All the "low level" tests Spinrite claims to do will appear to work, but are impossible on a USB device.
Infact, they are impossible on a modern mechanical HD as well. As yacc143 pointed out, modern drives are not the same as MFM/RLL drives of the past. The low level tests that Spinrite claims to do are simply impossible.
It's also a terrible data recovery program, since it can only write recovered data back to the same disk. That's a data recovery 101 no-no, and Spinrite fails.
Closer to two decades.... 128MB RAM machines would have been around at the launch of Windows 95.
The first consumer level Pentium chip-set to properly support more than 64 MB of RAM, the HX, came out in Feb 1996. Even then, the HX was the high end model, most of the Intel chip-sets over the Pentium's life fully supported only 64 MB of RAM properly. You could put 128 MB in them, but that would actually reduce performance as only the first 64 MB would get cached. 128 MB was definitely not common when Windows 95 came out.
If you have a proper server then you can do all that troubleshooting over ILO or whatever remote access card your vendor supplies, no physical display required. Some x86 servers have console serial ports, but that is of limited use for a Windows server.
My point was that neither x86 or Windows require a video card to function. I used the example of a desktop board specifically because it lacks an ILO emulating a video card (no on board video either).
This is completely untrue. I have a few desktop class boards that boot up fine without any video cards. They do make the no video card beep but they continue booting just fine. Windows server (at least 2008 R2) seems quite fine with this and doesn't care about the lack of video.
Windows is "not optimized" for Bulldozer because BD lies to the OS. A BD claims to have twice as many cores as it really has and Windows schedules as if this were true. In reality the BD "cores" are just a better form of hyper-threading. If BD said it had hyper-threading instead of real cores then Windows would schedule properly. All Linux and Windows 8 do is ignore the lies from the chip and use the hyper-threading scheduler.
The AMD chips had a significantly better GPU, at the cost of a slightly slower CPU (which is a good tradeoff). Apple didn't go with it because AMD couldn't guarantee the volumes that Apple needed.
Umm, no. AMD doesn't have a chip that competes with Intel's ultra low power Sandy Bridge chips like in the Air.
The AMD Brazos chips compete on power consumption, but they are way slower. They are an Atom competitor, something they do very well but SB chips are in a completely different performance bracket.
The AMD Llano chips would qualify as "significantly better GPU, at the cost of a slightly slower CPU", but at much higher power consumption. Not suitable for the AIR either.
No, that is not correct. Hyper-threading gives each thread the same amount of resources, assuming they can use them equally. The only difference between hyper-threading and a BD module is that the BD module has a dedicated integer execution unit and L1 D cache for each thread. Everything else is shared just like in Intel cores. It is simply a better hyper-threading, not real cores.
I wouldn't say it was that good, maybe more like 50-60%, but you are correct that Bulldozer is better than hyper-threading. The point is that BD is still not as good as real cores and thus scheduling it like hyper-threading works better than scheduling it like real cores.
It's not like hyper threading. For integer operations, the AMD chips are much better. What AMD doesn't have is two floating point units so that's what gets bogged down. There are two instruction decoders and two units to handle integer math, but one floating point unit per component.
It's a lot closer to hyper-threading than you think. The BD chips do *NOT* have two instruction decoders per module, just one. The only duplicated parts are the integer execution units and the L1 Data caches. The Instruction fetch+decode, L1 Instruction Cache, Branch prediction, FPU, L2 Cache and Bus interface are all shared.
It's pretty obvious how limited each BD "core" really is given these benchmarks. AMD should have presented the CPU as having hyper-threading to the OS.
No, It's because AMD is lying to the OS. The "8 core" BD is not really 8, core. It only has 4 cores with some duplicated integer resources. Basically a better version of hyper-threading, but not a proper 8 core design.
The problem is that the BD says to Windows "I have 8 cores" and thus Windows schedules assuming that is true. If BD said "I have 4 cores with 8 threads" then Windows would schedule it just like it does with Intel CPUs and performance would improve just like in the FA.
There shouldn't need to be any OS level tweaks because Windows already knows how to schedule for hyper-threading optimally. If BD reported it's true core count properly then no OS level changes would be needed.
While security updates stopped in July 2010 for 2k, other updates such as directx, IE, and silverlight stopped long before then. Also long before 2010 was the end of support for adobe flash and many other non-MS products for 2k.
All of those things stopped being supported for Win2K long after XP took off. Your examples are rather poor given that the final supported DirectX and Silverlight versions for Win2k are the same as XP (9.0c and 4 respectively).
XP took off when MS stopped offering any updates for (the only 1-year-older) win2k. Soon other companies followed suit and stopped supporting 2k for their software and it died abruptly while XP, with very few actual advantages beyond software support, took off.
I'm pretty sure XP took off long before July 2010, because that is when updates for Win2k stopped.
The JRE issue is simple. The JRE is being exploited to deliver Windows malware. Linux or other OSes can get "infected" by the same exploit, but since the payload code is for Windows it won't run on other OSes. The JRE is just the delivery method, it's not actually running the malware.
The big issue with Java is that while it is platform independent, it is not version independent. There are many many Java apps that require a specific version of the JRE and will not run on a newer one. So if you need to run an app that needs an old JRE you can't patch and secure your system. At a previous employer about 80% of our comprimised systems were because of Java with almost all the rest because of Adobe products. That was despite our default browser being IE6.
Slashdot Mirror
You just proved my point. You ran a test with the most ideal case (pure integer code) and it ran slower when on the same module. Run more real world code with two threads and the performance hit gets bigger. Try the same test on an i7. The code will run the same speed no matter which cores it uses, as it doesn't lie to the OS can claim the SMT units are full cores.
This is the whole reason why Windows 7 has problems scheduling on the FX CPUs. AMD LIES to the OS and claims the SMT units are full cores. This causes performance problems when Windows schedules as if it was true. If AMD had been truthful then the FX CPUs would perform to their fullest potential on any OS, and Linux and Win 8 would not have had to be modified to work around the issue.
Call it hyper-threading, SMT or whatever, the second integer unit on FX CPUs are not full cores. AMD did SMT better than Intel, but it's still not a full core.
No, "Almost all parts" are not duplicated. Only the integer units and the L1 data caches are duplicated. The L1 instruction cache, the instruction fech, instruction decode (the big performance hit), branch predictor, instruction dispatcher, FPU and bus interface are all shared. Running almost any two threads that max out the "cores" on the same module is slower than running them on two separate modules.
Just because AMD calls them cores does not make it true.
The problem is that AMD called its version of hyper-threading a full core, which it clearly is not. Even though they put a second integer unit in the module, most other parts are shared and the performance of the second half of the module suffers. The FX-8150 is really a 4 core CPU with a good hyper-threading implementation, not an 8 core CPU. If the FX CPUs had claimed to have hyper-threading instead of full cores then Windows 7 would have scheduled properly on them.
I have a drive like this, a WD Elements 1TB. It's a 2.5" drive and the board only has a micro-USB connector.
Not my pictures, just the first thing that poped up on GIS: http://www.techsupportforum.com/forums/f16/damaged-micro-usb-soldered-on-wd-elements-se-1tb-external-635019.html
Then again, DOS might be the very first use...
DOS did have multi monitor support from day 1, but not in the way we think of it today. You could combine a CGA card (or later EGA, VGA, etc) with an MDA (monochrome, text only) card. The idea was to use the MDA for high resolution (at the time) text and the CGA for low res graphics. Software had to be specifically written for it, but it was possible. Later, some DOS debuggers could use the MDA as a debug output separate from the main screen.
Are you sure they are 32 bit and not 16 bit, ie Windows 3.X apps? Lots of old apps are 16 bit and many older 32 bit Windows programs have 16 bit installers. 64 bit Windows tries to work around the 16 bit installer problem, but it's not perfect.
Probably an outlier, but I remember that Scorched Earth ran much better after I added a 387 to my 386 machine back in the early 90s. Specifically the projectile trajectories were calculated much quicker.
Spinrite has been useless for over 25 years. IDE came out in 1986. Since then, low level access to drives has been impossible. AHCI is not an issue, as Spinrite doesn't actually use the low level commands it claims to. SSDs aren't an issue either, at least as far as what Spinrite can actually do which is very little. Spinrite can't actually tell it is running on an SSD and thinks it is a mechanical drive. Doesn't stop it from spewing BS about magnetics of SSDs!
Which tools did you try? Were they actually meant to deal with bad sectors or were they just tools for dealing with fileystem/OS corruption?
Spinrite can deal with bad sectors in that it can continue copying after an error and it can retry many times. However, it is not unique in this. There are other tools that can do this as well, including free and open source ones. Where Spinrite fails in this task is that it only writes the recovered data to the same drive. This can cause other data to get overwritten or just lost as you are writing from one spot on a bad drive to another spot on the same bad drive.
If you need a tool that can deal with bad sectors look at dd_rescue or Roadkil's Unstoppable Copier
You seem to have it in for Spinrite, but it's not clear why. If you listen to Steve's podcast (Security Now), you'll know that he is very careful on how he describes the technical aspects of his products (including Spinrite). I'd be very surprised if you or anyone could point to any of GRC's literature on Spinrite that would prove he's "lying" about anything.
http://www.grc.com/spinrite.htm "and ALL OTHER file systems". Tell me, how well does Spinrite support UFS? EXT4? ZFS? Given that the ZFS driver code alone is several times the size of Spinrite that's not really possible. And filesystem support is important given Spinrite's braindead data recovery. If there is no knowledge of the underlying filesystem then Spinrite has no way of knowing if it is overwriting data, filesystem structure or empty space. Even if it was lucky and got empty space, there is no way for it to update the filesystem so you can recover the data.
How about this beauty from http://www.grc.com/srphysics.htm: "SpinRite is actually able to lower the amplification of the drive's internal read-amplifier". I don't think I even need to explain why that is BS. Tell me, which ATA or BIOS commands can do that?
In fact, that whole page is BS. Take a look at https://groups.google.com/group/comp.dcom.xdsl/msg/9aeee32323c2978e?dmode=source&hl=en&pli=1 That explains it better than I can.
My point about the ATA command is that Spinrite is only using standard commands; not undocumented commands or anything secret like that. However, what is "special" are the sequence of commands used to help the drive recover sectors that get a read error.
Ok, using what you just said, explain the "Dynastat Data Recovery" in Spinrite. To refresh your memory, that is where it claims to be working down to the bit level. You cannot address individual bits or even bytes on a drive, either with BIOS or direct ATA commands. And before you say something stupid about "averaging" or other mathematical BS, a modern drive can only return one of two things for a sector request. The correct data when the ecc matches, or an error.
You obviously have never really read what Spinrite claims to do. Look at that "physics" link. Anyone with even passing knowledge of basic science and how computers work can figure out that it is BS.
Your example of a USB drive is just another way of saying "flash", for which Spinrite is not targeted to fix.
Indeed, there are no more "low level" commands like in the day of old HDD technology. However, Spinrite uses the standard ATA command set to do everything possible to get your data off your drive. It does this very well and you'll be hard pressed to find other programs that do it better that don't cost a lot, lot more money (think data recovery repair center).
The fact that USB is flash isn't the point, the point is a USB key is not an ATA device. A USB mechanical hard drive would work just the same. A USB device booted in this way does not support ATA, only BIOS INT 13h calls. Same as if you used it against a SCSI drive in DOS. Spinrite is lying about even using ATA commands.
Spinrite may do an OK job of exercising disks, but 90% of what it claims to do is BS.
An easy test to prove that Spinrite is BS is run it against a USB key. Not a SATA SSD, but a USB flash drive. Make the USB key bootable with DOS, put Spinrite on and boot a PC with no other drives. Run its "tests" against the USB key. All the "low level" tests Spinrite claims to do will appear to work, but are impossible on a USB device.
Infact, they are impossible on a modern mechanical HD as well. As yacc143 pointed out, modern drives are not the same as MFM/RLL drives of the past. The low level tests that Spinrite claims to do are simply impossible.
It's also a terrible data recovery program, since it can only write recovered data back to the same disk. That's a data recovery 101 no-no, and Spinrite fails.
While you are technically correct that the Mac Mini has an i7, it is a mobile i7. Only has two cores and significantly lower clock.
This thing has a desktop i7. Quad core and higher clock. It handily outclasses the Mini, but still way overpriced.
Closer to two decades.... 128MB RAM machines would have been around at the launch of Windows 95.
The first consumer level Pentium chip-set to properly support more than 64 MB of RAM, the HX, came out in Feb 1996. Even then, the HX was the high end model, most of the Intel chip-sets over the Pentium's life fully supported only 64 MB of RAM properly. You could put 128 MB in them, but that would actually reduce performance as only the first 64 MB would get cached. 128 MB was definitely not common when Windows 95 came out.
If you have a proper server then you can do all that troubleshooting over ILO or whatever remote access card your vendor supplies, no physical display required. Some x86 servers have console serial ports, but that is of limited use for a Windows server.
My point was that neither x86 or Windows require a video card to function. I used the example of a desktop board specifically because it lacks an ILO emulating a video card (no on board video either).
This is completely untrue. I have a few desktop class boards that boot up fine without any video cards. They do make the no video card beep but they continue booting just fine. Windows server (at least 2008 R2) seems quite fine with this and doesn't care about the lack of video.
Windows is "not optimized" for Bulldozer because BD lies to the OS. A BD claims to have twice as many cores as it really has and Windows schedules as if this were true. In reality the BD "cores" are just a better form of hyper-threading. If BD said it had hyper-threading instead of real cores then Windows would schedule properly. All Linux and Windows 8 do is ignore the lies from the chip and use the hyper-threading scheduler.
The L110 and L310 are still way slower than a SB. The clock on them is so low that they are still in Atom performance territory.
The AMD chips had a significantly better GPU, at the cost of a slightly slower CPU (which is a good tradeoff). Apple didn't go with it because AMD couldn't guarantee the volumes that Apple needed.
Umm, no. AMD doesn't have a chip that competes with Intel's ultra low power Sandy Bridge chips like in the Air.
The AMD Brazos chips compete on power consumption, but they are way slower. They are an Atom competitor, something they do very well but SB chips are in a completely different performance bracket.
The AMD Llano chips would qualify as "significantly better GPU, at the cost of a slightly slower CPU", but at much higher power consumption. Not suitable for the AIR either.
No, that is not correct. Hyper-threading gives each thread the same amount of resources, assuming they can use them equally. The only difference between hyper-threading and a BD module is that the BD module has a dedicated integer execution unit and L1 D cache for each thread. Everything else is shared just like in Intel cores. It is simply a better hyper-threading, not real cores.
I wouldn't say it was that good, maybe more like 50-60%, but you are correct that Bulldozer is better than hyper-threading. The point is that BD is still not as good as real cores and thus scheduling it like hyper-threading works better than scheduling it like real cores.
It's not like hyper threading. For integer operations, the AMD chips are much better. What AMD doesn't have is two floating point units so that's what gets bogged down. There are two instruction decoders and two units to handle integer math, but one floating point unit per component.
It's a lot closer to hyper-threading than you think. The BD chips do *NOT* have two instruction decoders per module, just one. The only duplicated parts are the integer execution units and the L1 Data caches. The Instruction fetch+decode, L1 Instruction Cache, Branch prediction, FPU, L2 Cache and Bus interface are all shared.
It's pretty obvious how limited each BD "core" really is given these benchmarks. AMD should have presented the CPU as having hyper-threading to the OS.
No, It's because AMD is lying to the OS. The "8 core" BD is not really 8, core. It only has 4 cores with some duplicated integer resources. Basically a better version of hyper-threading, but not a proper 8 core design.
The problem is that the BD says to Windows "I have 8 cores" and thus Windows schedules assuming that is true. If BD said "I have 4 cores with 8 threads" then Windows would schedule it just like it does with Intel CPUs and performance would improve just like in the FA.
There shouldn't need to be any OS level tweaks because Windows already knows how to schedule for hyper-threading optimally. If BD reported it's true core count properly then no OS level changes would be needed.
While security updates stopped in July 2010 for 2k, other updates such as directx, IE, and silverlight stopped long before then. Also long before 2010 was the end of support for adobe flash and many other non-MS products for 2k.
All of those things stopped being supported for Win2K long after XP took off. Your examples are rather poor given that the final supported DirectX and Silverlight versions for Win2k are the same as XP (9.0c and 4 respectively).
XP took off when MS stopped offering any updates for (the only 1-year-older) win2k. Soon other companies followed suit and stopped supporting 2k for their software and it died abruptly while XP, with very few actual advantages beyond software support, took off.
I'm pretty sure XP took off long before July 2010, because that is when updates for Win2k stopped.
The JRE issue is simple. The JRE is being exploited to deliver Windows malware. Linux or other OSes can get "infected" by the same exploit, but since the payload code is for Windows it won't run on other OSes. The JRE is just the delivery method, it's not actually running the malware.
The big issue with Java is that while it is platform independent, it is not version independent. There are many many Java apps that require a specific version of the JRE and will not run on a newer one. So if you need to run an app that needs an old JRE you can't patch and secure your system. At a previous employer about 80% of our comprimised systems were because of Java with almost all the rest because of Adobe products. That was despite our default browser being IE6.