[mlpack-git] (blog) master: Adds Yannis week 4 (d6324c7)

gitdub at mlpack.org gitdub at mlpack.org
Sun Jun 19 08:55:29 EDT 2016


Repository : https://github.com/mlpack/blog
On branch  : master
Link       : https://github.com/mlpack/blog/compare/cf4bd69310048875ab7508c83f54ff83ebab512e...d6324c7ad5fb2b5640e87548770f1f8fa2b8f00d

>---------------------------------------------------------------

commit d6324c7ad5fb2b5640e87548770f1f8fa2b8f00d
Author: Yannis Mentekidis <mentekid at gmail.com>
Date:   Sun Jun 19 15:55:29 2016 +0300

    Adds Yannis week 4


>---------------------------------------------------------------

d6324c7ad5fb2b5640e87548770f1f8fa2b8f00d
 content/blog/YannisWeekFour.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/content/blog/YannisWeekFour.md b/content/blog/YannisWeekFour.md
index 01c9371..171989b 100644
--- a/content/blog/YannisWeekFour.md
+++ b/content/blog/YannisWeekFour.md
@@ -23,6 +23,7 @@ The way mlpack does this is there is a for loop, inside which, codes are compute
 2. We can instead try to reduce the cost of each individual query, by parallelizing the `ReturnIndicesFromTable` and `BaseCase` functions.
 
 **Option (1)** has several benefits: 
+
  - When ran with a large query set, the processing cores will be utilized very well - there's plenty of work to go around, so we simply spawn threads and divide work among them.
  - It is trivial to implement and embarrassingly parallel, meaning the more threads we spawn (up to the number of queries) the faster we will be.
  - It should cause an immediate and noticeable bump in performance.




More information about the mlpack-git mailing list