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

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.

First, that is a ridiculous cooler, even for after market. If you are not over clocking the tiny stock cooler will do fine.

Second, a 486 barely has any concept of power saving, has lots of power eating support chips, a hot slow hard drive all powered by a pathetically inefficient power supply.

While the i7 will max out higher at 150+ W, it will idle very low, often well under 50 W for a not crazy system. The 486 will use 100-120 or so W all the time, no matter what it is doing. Unless the i7 is running full tilt all the time it will use less power. That of course ignores the fact that the i7 can complete a given task way faster and then be turned off.

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

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.

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.

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.

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.