New multi-threading technique promises to double processing speeds

K

kac77

2[H]4U
Joined
Dec 13, 2008
Messages
3,319

New multi-threading technique promises to double processing speeds​

'SHMT' also sliced power usage by 51% compared to existing techniques​

By Zane Khan Today 11:12 AM

Researchers at the University of California Riverside developed a technique called Simultaneous and Heterogeneous Multithreading (SHMT), which builds on contemporary simultaneous multithreading. Simultaneous multithreading splits a CPU core into numerous threads, but SHMT goes further by incorporating the graphics and AI processors.
 
Also sounds like what Intel is doing with their new schedulers as well.
 
1_rick said:
Nobody else is getting Itanium flashbacks? Just like this, that required a lot of heavy lifting on the compilers part to get results, and it was one of the reasons Itanium died.
Click to expand...

Yeah,, except that if Itanium had the magic compiler they were betting on it would speed up more general code than just "AI".
 
micro23-41-fig3.jpg


Good luck to the people trying to make this work well, must be quite the challenge
 
The reason SMT works so well is that it's completely invisible to the program. It's just another core. If this requires ANY and I mean ANY consideration from ANY developer aside from the OS, then it's enterprise-only.
 
KazeoHin said:
then it's enterprise-only.
Click to expand...
Gaming development is quite hardcore, they jumped on GPU hard, avx-512, etc... look at what they can run on a PS4. It is so competitive and some engine like Unreal-COD-what they do for GTA-etc... get so much budget and some of the best people in the world on them, it is not needing consideration from their team that would ever stop them I think, how much issue it create and % of target audience in the field that have hardware that support it, if the PS6 has something like this that need the code to made in some ways to take advantage of it, that Gran Turismo 9 team will do it.

CUDA and many other use of GPU is not software invisible and quite used by user facing software.

Specially with how much of a performance difference using the TPU-GPU or CPU can be for different operation, if you make it easier not harder to use them versus now, it will be inviting.

And in a way programmer needed to change their code to take advantage of computer becoming multithread otherwise it only helped in a running many app at the same time type of scenario (which is common on PC, but you get what I mean)
 
Last edited:
I think that there is potential here. One of the big problems with new features is adoption. If everything is done through a virtualized hardware interface, then the actual underlying hardware could potentially change without affecting compatibility. Specific hardware is used if it exists, otherwise it's passed on to the next best processor for that task, or eventually the CPU if nothing else can do it.

We just need to avoid proprietary standards that purposefully excludes certain brands of hardware and/or require unrealistic time/effort on the part of software developers to integrate.
 
GotNoRice said:
We just need to avoid proprietary standards that purposefully excludes certain brands of hardware and/or require unrealistic time/effort on the part of software developers to integrate.
Click to expand...
There is work going on there. General ways of making a problem set, describing assets, the cost of computations on that asset, and away we go.

It is of course - a really hard problem to solve without a priori knowledge of problem set.
 
Nobu said:
Sounds like what AMD was trying to do with HSA on APUs, just going by the summary in the OP. Wouldn't surprise me if someone picked up the pieces and finally found something that worked, but otoh I'm sure there are still tradeoffs.
Click to expand...
AMD actually was able to put out a driver on Linux that worked with the Fusion processors and Sea Island GCN cards (Bonaire,Curacao, etc) . However, when Lisa Su came she focused work on putting together Zen and eventually ROCm.
 
This is why you get maximum threads available on your CPU and dont settle for the "6 or 8 cores is enough"
 
Lepardi said:
This is why you get maximum threads available on your CPU and dont settle for the "6 or 8 cores is enough"
Click to expand...
In general, sound like terrible advice and here sending more work that the CPU would have done to the NPU, TPU, GPU instead maybe could end up making easier to maximise CPU threads but could be the other way around, make cpu multithreading performance less important.
 
westrock2000 said:
Ready your PhysX Cards boys, we ride again!
Click to expand...

It's easy to dismiss new tech so quick, but just keep in mind that there was a time when even a GPU was a new thing with an uncertain future. Early first-person shooters (Doom, etc) were played with all graphics rendered using the CPU.
 
Phone-Laptop-Consoles sold with already NPU-TPU present (when not attach to the CPU as one of the cores) is also an easier entry than consumer buying a discrete card like the physics cards attempt of the past, GPU, soundcard for a while worked well.

We could be a situation where all customer has it, without a race of we need game that use PhysX card for people to buy them butwe need people to have PhysX card for game to put effort in it.

About all Apple device, AMD/Intel laptop will have them, I imagine soon Intel desktop CPU will have them, everyone has a GPU, consoles could simply ship with them
 
Looking forward to the Intel implementation....
Process 4444 core 22 Save Cache data
Process 4445 core 36 requests load Cache data
Hypervisor check privilege level for process 4445...... NAAA just give em the data checks take too long.
 
  • Like
Reactions: erek
like this
You must log in or register to reply here.
Back
Top