<blockquote>
<p>My question is, though i am aware cos() and sin() is fast, how do they compare to simply getting the value precomputed in a buffer instead?</p>
</blockquote>
<p>This will depend on your shader code and GPU model.</p>
<ul>
<li>GPUs utilize latency hiding by executing independent ALU instructions while waiting for data to arrive from memory.</li>
<li>Accessing memory is usually the slowest operation on a GPU.</li>
</ul>
<p>If your shader code allows for latency hiding, it <em>may</em> be faster.</p>
<p>The best option here is to profile the shader performance.</p>
<blockquote>
<p>I don't know how to really bench test shaders properly so i am unsure which is faster.</p>
</blockquote>
<p>I think the easiest way would be to download <a href="https://renderdoc.org/" rel="nofollow noreferrer">RenderDoc</a> and get a frame capture of your application.</p>
<p>After that, you click on the timing icon (shown red) to get some measurements.</p>
<p><a href="https://i.sstatic.net/vbnXI.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/vbnXI.png" alt="enter image description here" /></a></p>
<p>Although these are not super accurate measurements, they're good enough and sort of representative of the application performance.</p>
<p>For precise measurements, you'll need your GPU vendor's graphics profiling tools.</p>
<ul>
<li>AMD has <a href="https://gpuopen.com/rgp/" rel="nofollow noreferrer">Radeon Graphics Profiler (RGP)</a></li>
<li>NVIDIA has <a href="https://developer.nvidia.com/tools-overview" rel="nofollow noreferrer">NSight</a></li>
<li>INTEL has <a href="https://software.intel.com/content/www/us/en/develop/tools/graphics-performance-analyzers.html" rel="nofollow noreferrer">Graphics Performance Analyzers</a></li>
</ul>
<hr />
<p><strong>Update</strong>: Below are some captures from RGP, showing GPU assembly instructions and instruction timings of various instruction types. You can see latency hiding in action below:</p>
<ul>
<li><code>vmem</code> : texture read</li>
<li><code>smem</code> : constant buffer / descriptor&lt;texture/buffer&gt; read</li>
<li><code>ALU</code>  : math ops (arithmetic / logic)</li>
<li><code>sync</code> : waits for vmem/smem instructions to finish loading data from memory</li>
</ul>
<p><a href="https://i.sstatic.net/RDs6a.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/RDs6a.png" alt="enter image description here" /></a></p>
<p>Another capture showing instruction timings while first two texture loads not having latency hiding.</p>
<p><a href="https://i.sstatic.net/CqrG1.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/CqrG1.png" alt="enter image description here" /></a></p>

CC BY-SA 4.0
2020-07-16T20:39:06.533Z
Oh wow accessing memory is the slowest? Did not know that. That seems likely then the trig functions are probably going to win out here. Thanks for the advice on profiling! I will look into it!
wduk
CC BY-SA 4.0
2020-07-16T21:39:43.323Z
@wduk GPU memory is many more times slower than a CPU memory (to access) due to higher latency. However, once the data starts streaming, the bandwidth is much larger than a CPU's mem bandwidth. I've updated the answer and added some screen captures demonstrating latency hiding!
Varaquilex
CC BY-SA 4.0
2020-07-16T08:27:39.667Z
2020-07-16T21:38:22.350Z
2020-07-16T21:38:22.350Z
Varaquilex
<p>I am creating a fast fourier transform algorithm for the compute shader - i am no expert on how GPUs really run optimally so thought i would ask here.</p>
<p>I have the option to calculate on the fly or precompute a lot of the trig function (cos and sin) values and store it in a read only float buffer.</p>
<p>My question is, though i am aware cos() and sin() is fast, how do they compare to simply getting the value precomputed in a buffer instead?</p>
<p>I don't mean a LUT here i do not need to interpolate between values from the buffer so i just get them values directly. I don't know how to really bench test shaders properly so i am unsure which is faster.</p>
<p>Perhaps some one knows more info on this?</p>

<compute-shader><hlsl><optimisation>
Reading from buffer versus calculating on the fly performance
wduk
# Reading from buffer versus calculating on the fly performance

(Asked by: username_0 on 2020-07-16)

I am creating a fast fourier transform algorithm for the compute shader - i am no expert on how GPUs really run optimally so thought i would ask here.

I have the option to calculate on the fly or precompute a lot of the trig function (cos and sin) values and store it in a read only float buffer.

My question is, though i am aware cos() and sin() is fast, how do they compare to simply getting the value precomputed in a buffer instead?

I don't mean a LUT here i do not need to interpolate between values from the buffer so i just get them values directly. I don't know how to really bench test shaders properly so i am unsure which is faster.

Perhaps some one knows more info on this?

**Tags:** compute-shader, hlsl, optimisation


---

## 1 answers

### Answer by username_1 on 2020-07-16. Score: 1 | Accepted answer

> My question is, though i am aware cos() and sin() is fast, how do they compare to simply getting the value precomputed in a buffer instead?

This will depend on your shader code and GPU model.

* GPUs utilize latency hiding by executing independent ALU instructions while waiting for data to arrive from memory.
* Accessing memory is usually the slowest operation on a GPU.

If your shader code allows for latency hiding, it *may* be faster.

The best option here is to profile the shader performance.

> I don't know how to really bench test shaders properly so i am unsure which is faster.

I think the easiest way would be to download [RenderDoc](https://renderdoc.org/) and get a frame capture of your application.

After that, you click on the timing icon (shown red) to get some measurements.

[![enter image description here](https://i.sstatic.net/vbnXI.png)](https://i.sstatic.net/vbnXI.png)

Although these are not super accurate measurements, they're good enough and sort of representative of the application performance.

For precise measurements, you'll need your GPU vendor's graphics profiling tools.

* AMD has [Radeon Graphics Profiler (RGP)](https://gpuopen.com/rgp/)
* NVIDIA has [NSight](https://developer.nvidia.com/tools-overview)
* INTEL has [Graphics Performance Analyzers](https://software.intel.com/content/www/us/en/develop/tools/graphics-performance-analyzers.html)

---

**Update**: Below are some captures from RGP, showing GPU assembly instructions and instruction timings of various instruction types. You can see latency hiding in action below:

* `vmem` : texture read
* `smem` : constant buffer / descriptor<texture/buffer> read
* `ALU` : math ops (arithmetic / logic)
* `sync` : waits for vmem/smem instructions to finish loading data from memory

[![enter image description here](https://i.sstatic.net/RDs6a.png)](https://i.sstatic.net/RDs6a.png)

Another capture showing instruction timings while first two texture loads not having latency hiding.

[![enter image description here](https://i.sstatic.net/CqrG1.png)](https://i.sstatic.net/CqrG1.png)

> **Comments:**
> **username_0**: Oh wow accessing memory is the slowest? Did not know that. That seems likely then the trig functions are probably going to win out here. Thanks for the advice on profiling! I will look into it!  
> **username_1**: @username_0 GPU memory is many more times slower than a CPU memory (to access) due to higher latency. However, once the data starts streaming, the bandwidth is much larger than a CPU's mem bandwidth. I've updated the answer and added some screen captures demonstrating latency hiding!  

---

