SteevoParent thread launches on core 0, it copies in a large dataset for comparison, it then launches a child thread that starts at the top of the thread, and it starts at the bottom, and it then has to check up on a flag being set by the child thread to see if it found a match thus reducing its performance. Try to find customer 123456789 in a dataset that is alpha numeric and customers numbers are randomized so either you have to sort, search the whole table, or you could have it check using a smarter algorithm. Depending on the size of the dataset and processor speed it might be as fast to sort on a single core as it is to search and compare on multiple cores.

I see what you're trying to say, but sorting is a bad example because it's working with immutable data and some algorithms can be implemented to be multi-threaded (and algorithms like merge sort are a great example of the divide and conquer strategy.) So consider this example.

You have 4 variables, A, B, C, and D.
A is assigned an initial value of 4.
B is assigned an initial value of 7.
C is assigned an initial value of C is A plus B.
D is assigned an initial value of C plus B.
C is reassigned a value of current C plus D.
D is reassigned the value of C.

If you try to make this application multi-threaded, to successfully get the intended result, all of the used variables have to be locked to prevent another thread for accessing them, but lets consider there is absolutely no thread safety and we say "Thread 1 does even instructions, thread 2 does odd."

What if this is a single core machine running multiple threads? If thread 2 runs first, it will seg fault or null exception will get thrown because D isn't set yet on instruction 3.

So thread 1 has some instructions that look like this (assuming variables were declared in a serial fashion before threads are spun up.)

1. B is assigned an initial value of 7.
2. D is assigned an initial value of C plus B.
3. D is reassigned the value of C.

So thread 2 has something that looks like this:

1. A is assigned an initial value of 4.
2. C is assigned an initial value of C is A plus B.
3. C is reassigned a value of current C plus D.

Tell me, what happens first, instruction 1 on thread 1 or instruction 1 on thread 2? Welcome to the world of race conditions, where you require locking to be able to deterministically know that stuff happens in order. So lets say it doesn't matter. Instruction one and two and independent using different spots in memory, instruction 2 on either though expects that C is already set. So now you're hitting a case where Thread 1 and 2 need to be aware of what the other is doing. That's overhead and wasted time because a single thread could have been done already. Then consider instruction 3 on either, you're already in a non-deterministic state because of the race condition on the C variable, so now D will be unreliable.

This only begins to touch on the complications of SMP and implementing software to effectively utilize it. Add locking and it will run in lock step fine, but you're probably taking twice as long to do it to handle the coordination.

Applicable experience: I've written a priority based, multi-threaded, system integration service at work that can make hundreds of API calls per second based on database state changes compared to a similar PHP tool we have that does a mere ~450 API calls in 5 minutes. Trust me, I know what more cores can do but, I also know what they can't do as a result.

AquinusI see what you're trying to say, but sorting is a bad example because it's working with immutable data and some algorithms can be implemented to be multi-threaded (and algorithms like merge sort are a great example of the divide and conquer strategy.) So consider this example.

You have 4 variables, A, B, C, and D.
A is assigned an initial value of 4.
B is assigned an initial value of 7.
C is assigned an initial value of C is A plus B.
D is assigned an initial value of C plus B.
C is reassigned a value of current C plus D.
D is reassigned the value of C.

If you try to make this application multi-threaded, to successfully get the intended result, all of the used variables have to be locked to prevent another thread for accessing them, but lets consider there is absolutely no thread safety and we say "Thread 1 does even instructions, thread 2 does odd."

What if this is a single core machine running multiple threads? If thread 2 runs first, it will seg fault or null exception will get thrown because D isn't set yet on instruction 3.

So thread 1 has some instructions that look like this (assuming variables were declared in a serial fashion before threads are spun up.)

1. B is assigned an initial value of 7.
2. D is assigned an initial value of C plus B.
3. D is reassigned the value of C.

So thread 2 has something that looks like this:

1. A is assigned an initial value of 4.
2. C is assigned an initial value of C is A plus B.
3. C is reassigned a value of current C plus D.

Tell me, what happens first, instruction 1 on thread 1 or instruction 1 on thread 2? Welcome to the world of race conditions, where you require locking to be able to deterministically know that stuff happens in order. So lets say it doesn't matter. Instruction one and two and independent using different spots in memory, instruction 2 on either though expects that C is already set. So now you're hitting a case where Thread 1 and 2 need to be aware of what the other is doing. That's overhead and wasted time because a single thread could have been done already. Then consider instruction 3 on either, you're already in a non-deterministic state because of the race condition on the C variable, so now D will be unreliable.

This only begins to touch on the complications of SMP and implementing software to effectively utilize it. Add locking and it will run in lock step fine, but you're probably taking twice as long to do it to handle the coordination.

If you want it even more difficult add time constraints to that problem, like a real time machine, and languages like Ada and Occam starts to sound fun.

But there is a reason for CPUs for consumers still being stuck on 4 cores, while the server cpus now have 18 cores and 36 threads, and that is the fact that the normal stuff people does on their computer is not optimized for many cores, being because of serialized problems or because the consumer software is considered good enough not to warrant the extra cost having engineers drastically change the program to make them preform better, just look at the Lime mp3 encoder.

AquinusAll 8 of the SATA ports in my tower are used. One M.2 and be done with it, but it's really not designed for mass storage. SATA will always have a place in my book until something better rolls around that doesn't require the device to be attached to the motherboard. (Imagine mounting a spinning drive to a motherboard, that makes for some pretty funny images. :p

Side note: I had more issues with IDE cables than SATA, so I'm not complaining.

That is what NAS is for, I have one SSD and no ODD in my tower.