From 91cc44e407a860fa4b8d19a386f0d8205feab7ba Mon Sep 17 00:00:00 2001 From: Warren Jacinto Date: Thu, 1 Aug 2024 19:28:12 +0530 Subject: [PATCH] fix typo --- _posts/2024-07-14-ExploringFurther.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_posts/2024-07-14-ExploringFurther.md b/_posts/2024-07-14-ExploringFurther.md index 638736b..0d2935e 100644 --- a/_posts/2024-07-14-ExploringFurther.md +++ b/_posts/2024-07-14-ExploringFurther.md @@ -151,7 +151,7 @@ Then, using the GPU is almost pointless, unless you use the same data over and o "Well, cant I just load the data on the GPU directly?" Thats not possible, atleast not to my knowledge. This is the tradeoff with GPUs. -On a CPU, you have 4/8/16 highly specialised and capable cores(math, I/O), while on the GPU you have 1000s of some very primitive math operations(only math, no I/O) +On a CPU, you have 4/8/16 highly specialised and capable cores(math, I/O), while on the GPU you have 1000s of some very primitive cores only capable of basic operations(only math, no I/O) So you always have to load it into CPU RAM first and then go to GPU RAM. So how can we fix this problem? @@ -159,5 +159,5 @@ Well, one of the options is to use Shared Virtual Memory(OpenCL SVM), which enab However, I still have yet to test SVM in the context of gnuastro, to see if its useful. Besides, SVM also fixes the problem of structs containing pointers(for another post). -Documentation for OpenCL is already sparse, and to add insult to injury, documentation on OpenCL SVM is even more sparse. +Documentation for OpenCL is already scarce, and to add insult to injury, documentation on OpenCL SVM is even more scarce. But I like the challenge...