[Tell It Right]

Maybe I'm not seeing the advantage. I thought we've already had something like this for years, including in Intel processors for desktops/laptops. Hasn't this been accessible in multi-threading apps already with things like what C# .Net provides in the example:

use System.Threading;

Thread T1 = new Thread(work);
Thread T2 = new Thread(work);

T1.Priority = ThreadPriority.Highest;
T2.Priority = ThreadPriority.BelowNormal;

I use something like that in my homemade app for downloading market data I use for a little swing trading (very little, more like a hobby) from 3 free sources and writing it to a database, all in the background so it doesn't hog up my system. And with a sister app I have it generate reports and graphs for me at high priority so that it gives me the reports quickly since I'm manually calling for them.

[Skywise]

“Hyper threads” aren’t the same as system threads. System threads are OS based and run simultaneously in the background like apps. The OS sends all these to the CPU which then executes all the different instruction lines. During execution it can “interweave” the various threads and apps into the same core for processing (hyper threading) to speed things up.

If I’m reading this right - Their new system is going to do the same thing but at the core level now. So execution blocks are going to get chunked off and sent to various cores rather than try to interweave the executions. Basically it’s a different load balancing/multitasking strategy.

I suspect it’s also more secure to go this route as it will help prevent microcode data hacking by keeping the code lines on separate cores.

[Myrddin]

Many languages support threading that can be leveraged by hyper-threaded processors. Most developers ignore the capability unless there is real value to splitting off threads. The downside of multiple threads is controlling concurrent access to data. The code gets a lot more complex. There must be a tangible payback for the effort required to build a multi-threaded app.