Multithreading and the FPU

[Biterider]

Hi
I've been wondering about a technology question. 
Most current CPUs have a dedicated FPU per physical core, which means we can theoretically run each FPU from different threads in parallel and speed up floating point calculations significantly.
There are still some limits, like memory access, caching, bus bandwidth, etc., but there should still be a noticeable effect.

I've never seen any publication, article or post doing something like that. Does anyone know anything about it or have looked into it?
I can do my own research, but I thought I'd check it first, just to make sure I'm on the right track. 

Biterider

[NoCforMe]

Hmm; I can't say for certain, but wouldn't the burden of proof here be on showing that one wouldn't be able to use a FPU in a different thread? If there are multiple FPUs, when it seems reasonable to assume that each one should be able to be used in a separate thread. Why would you be forced to use all of them in a single thread?

I could be wrong about that ...

[HSE]

Hi Biterider,

There are still some limits, like memory access, caching, bus bandwidth, etc., but there should still be a noticeable effect.

Yes, but you need enough cores, because there are overheads.

I play a time ago in 4 cores machine from UEFI, but happen 2 cores were really available, then not benefit because one core control process and the other run the threads   

Any way you must transform the problem, and some problems could not be well suited for that.

I've never seen any publication, article or post

Historically distribution was first, because threads were going to run in differents machines. Then probably no specific multicore FPU single processor work is of much interest for big problems.


You can ask Gunther, who work in CERN computer farm with 30000 cores, that is interesting 


HSE

[Biterider]

Hi HSE

... in CERN computer farm with 30000 cores, that is interesting 

My goals are much more modest than that.
I thought I would give it a run with a 3D animation application that moves some objects around sequentially using exclusively the CPU and FPU, like in the old days.
Calculating the movements, the scene and the camera is really FPU intensive. 
I created 2 threads, one for each movement (2 objects moving), but the result was disappointing. 
The new version was slightly slower than the sequential one.

My guess is that the creation, destruction and synchronisation outweighs the speed gain.
I can see a ThreadPool being the way to go, but I need to code it first.

Biterider

[HSE]

My goals are much more modest than that.

How many cores you have?

My guess is that the creation, destruction and synchronisation outweighs the speed gain.

I think, also can happen that OS is running threads in same core, then you end with same code + context switching.

Not so easy to know what OS is doing 

I can see a ThreadPool being the way to go, but I need to code it first.

 

[NoCforMe]

Found this on Raymond Chen's blog. Dunno if it's of any help here. There may be more there, but this was all I could find in an initial search.

[Biterider]

@HSE

How many cores you have?

At home, where I do my programming stuff, I have a 10 year old  i7-4770K (Haswell).
It has 4 physical cores and 8 logical cores (https://www.intel.com/.../specifications.html)

Not so easy to know what OS is doing

Absolutely. 

@NoCforMe

Found this on Raymond Chen's blog.

Not directly related, but still interesting reading 

Biterider

[daydreamer]

I tried some SIMT, but 3d transform first came SSE instructions set for speed up,after that graphics card hardware accelerated 3d transform, but I went back to SIMD
Got Simplest SIMT applied on huge fibonnaci numbers worked for me:
Main thread take care of print fibonnaci numbers
Worker thread calculate fibonnaci numbers and sometimes copy number to other memory area, which main thread prints from
It takes out slowest print in addition loop that takes Milliseconds and moves it to main thread, while adding takes clock cycles