partial blog posts

app/tag-data.json

@@ -1 +1 @@
-{"placeholder":1}
+{"performance":1,"dyslexia":1}

data/blog/frontend-parallelizable-tasks-using-the-gpu.mdx

@@ -0,0 +1,46 @@
+---
+title: Front-End Parallelizable Tasks Using The GPU
+date: '2023-12-21'
+tags: ['performance']
+draft: false
+summary: soon to be a great new post
+images: ['/static/images/posts/cpu_gpu_benchmark.png', '/static/images/posts/cpu_gpu_benchmark_2.png']
+---
+
+### Why would we want to run parallel computational tasks on a client machine?
+
+A simple heuristic is that we should run computational tasks on a server and only run I/O tasks on a client machine.
+
+If for no other reason then simply for an unnamed principle that we should work a component with known characteristics. I'm calling this The Principle of Known Reliability. We don't know what machine our user has or what other tasks it's running. We know what’s running on our server and have load balancers to ensure it’s not overloaded.
+
+In recent years, we've seen some server-side tasks written in JavaScript (node.js) to handle the I/O tasks that have to be run on a server as JavaScript is optimised for I/O. But what about when we run computational tasks on the client machine?
+
+There are a few reasons we may choose to run computations on a client machine:
+
+- **Security**: We might have data we don’t want to leave the client's machine.
+
+- **Cost**: Maybe we aren’t provisioning a distributed server with multiple high-end CPUs; if we are, we may not need to run them as often.
+
+- **Speed**: If we can work within The Principle of Known Reliability, it might be faster to work on the client. especially when security concerns might ass in an SSH handshake or costs might mean we didn’t get the best CPUs available.
+
+We already run concurrent computations on our GPU all the time. We run huge numbers of concurrent computations on our GPU. Video encoding or geometric calculations for 3d animations. Writing fragments to run computations on the GPU has become easier thanks to libraries like GPU.JS
+
+But can we use it to distribute front-end tasks, and how does it compare? Why would we want to? Can we achieve this without breaking The Principle of Known reliability?
+
+### How can we benchmark execution times to assess when to use the GPU?
+
+Using [The Matrix Multiplication Example](https://gpu.rocks/#/) from the GPU.JS website, I ran a set number of concurrent computations on my CPU and on my GPU and kept track of the execution times.
+
+![](/static/images/posts/cpu_gpu_benchmark.png)
+
+My first interesting observation was that the CPU performs better at executing tens of thousands of computations before it becomes optimal to use the GPU, and several others have made a similar observation.
+
+Once we get above half a million computations, my CPU simply can’t handle it. My GPU could easily run tens of millions of computations before I started running into issues.
+
+But probably the most interesting observation was that the point where running computations on the GPU on my machine was around 80,000 computations. And that I can consistently identify this point after running at most 8 benchmark tests.
+
+![](/static/images/posts/cpu_gpu_benchmark_2.png)
+
+Or, to put it another way, it only takes around 3 seconds for me to identify exactly where the sweet spot is and this wasn’t affected too much by other processes on the CPU or GPU.
+
+### A Practical Application of running parallel computational tasks on the client

data/blog/my-fancy-title.mdx → data/blog/on-being-a-dyslexic-developer.mdx

@@ -1,10 +1,9 @@
 ---
-title: Place Holder Blog Posts
+title: On Being A Dyslexic Developer
 date: '2023-12-21'
-tags: ['placeholder']
+tags: ['dyslexia']
 draft: false
 summary: soon to be a great new post
 images: []
 ---
 
-Draft post which should not display