Not really my fault, but I bought a motherboard that was advertised as AM2+ despite being AM3. So I had to get that replaced. I won't name the company here as they've been fantastic about the whole affair and I don't think it was their fault as it looks to me like at some point the socket was replaced on that board and they probably weren't told about that.

I've already bought from them again since so there definitely aren't any hard feelings. It's good to know a company that is so customer focussed.

I bought an xClio case.
.
.
.
.
.
.
I'm still using it. I haven't had time to swap out with a better brand. I'm thinking Corsair or Xigmatek, or any other manufacturer whose cases aren't so "stylishly" designed (read: shaped like a Frank Lloyd Wright project) so that I can fit any other brand's 5.25"-to-3.5" "3-in-1" HDD cage in it (ex. a Cooler Master cage in a Thermaltake case). Honestly, the cage wouldn't even be an issue if xClio had remembered to include HDD brackets with the case. They included plenty of optical drive brackets, and even three sets of FDD brackets, but not one set of HDD brackets. I have yet to get a response from them about the issue.

We are in agreement there ;).

Well, yes, multi-core = additional CPU power as long as you can multi-task.

However, virtual CPU = 1 core supporting 2 threads...

I fail to see this as revolutionary as I've taken this for granted since the event of threads (which first appeared on single core CPUs).

Now, crackedegg implies that there is some multi-threading support at the hardware level for 1 core... so the main implication would be a faster context switch between threads and that's it?

Yes, more powerful implies that you can do more with it. In this case, more power without the system being overwhelmed with the task.

However, stability implies the ability to run a long time without crashing and to handle more scenarios gracefully.

Multi-threaded programs have more bugs (this isn't an 'if', its a reality) and are therefore less stable.

In theory, it wouldn't make a difference for a perfect programmer, but people coding software are human.

Usually, read/writes on permanent storage devices such as hard disks are SLOW.

Read/writes on temporary storage devices like RAM tends to be MUCH FASTER.

If you have 2 tasks that need to be done, one which involves the hard disk and the other involving the RAM only, you don't want the task involving the RAM only to have to wait for the task involving the hard disk.

There is some concurrency there even on a single core CPU in that the CPU/RAM can do some work while the hard disk is busy.

Hello, there Magnitus hope you're doing fine ;) (was great yesterday with EA announcement and all...)

Well, I can't tell exactly how it's working on the raw technicalside of things but you get an almost parallel calculation of 2 threads on one core by 'interlacing' the 2 of them. On normal single core cpus threads would have to be truncated at strategic positions to give another thread the chance of being computed.
Well, it's quite revolutionary since Intel introduced it (:P) and is the only one with that technology and most importantly it's pretty cool. From doing tests giving all 8 virtual cores something to do you really wouldn't notice you only have 4 real cores working

You're right. In practice however (Linux desktop environements for instance) there's rarely a bug related to multi-threading/race conditions and the software is pretty useable so far. They've either a very robust plan/understanding of threads or are pretty good which isn't mutually exclusive ;)

What goes in and out (or happens inside) block devices is orchestrated/controlled by the central processing unit, now the operating truncates threads by cutting it in blocks and giving them more or less weight (which in turn decides of their priority).

Fair enough, was being overly specific. Relative and absolute addressing is another aspect.

Maybe the hardware does part of the work, but I highly doubt it does all the work, because process memory looks different in Linux than in Windows and actually, memory access behavior can vary between flavors of Linux (in some cases, accessing memory that is not yours will cause undefined behavior and in others, it will fail with an error).


Actually, I think programmer convenience is high on the list along with standardization between software producers.

Ok, so it's really just to improve performance when handling multiple threads (not in terms of raw CPU power, but in terms of managing the threads themselves).

The OS very much manages the memory. The CPU does the grunt work: translating addresses when reading and writing, and throwing exceptions. Normally, you would have needed a whole other CPU to run more than one thread at once. It's not revolutionary, now, as the idea has been around since 1968, according to Wikipedia. But, it is different than having one CPU run one thread. If a thread has to switch contexts, it takes about as long. On x86, that's pretty much forever. With HT, one core can execute two threads at the same time. When one is not executing anything, the other can be, offering a performance boost, for cases where performance is limited by stalls and bubbles. When both can be executing, both will be, which is why the improvement tends to be fairly mild, most of the time. The end result is more or less like having 2x the cores, each 60% as fast. It is being taken care of. Programming languages that have widespread support have been lagging behind, and are now catching up. Until very recently, it has been far too hard not because it should be, but because programming languages have still been assuming that memory is precious, and that CPUs will get faster, instead of having more at your disposal. C#, as one example, does an excellent job of making threads dead nuts simple for the programmer. C++ will take some time, and using added libraries for the work will remain common, but 0x is moving in the right direction.