[HN Gopher] Why I sometimes like to write my own number crunchin...
       ___________________________________________________________________
        
       Why I sometimes like to write my own number crunching code
        
       Author : dragandj
       Score  : 56 points
       Date   : 2021-06-25 15:58 UTC (1 days ago)
        
 (HTM) web link (dragan.rocks)
 (TXT) w3m dump (dragan.rocks)
        
       | queuebert wrote:
       | The author is overconfident and underestimates library writers to
       | a fault. Packing a bunch of dot products into a matrix is only
       | the fastest way to compute a batch of cosine similarities if you
       | are relegated to a parallel matrix product function.
       | 
       | If you write the procedure in raw CUDA, for example, it is faster
       | to simply broadcast the dot products across threads. That is
       | exactly what the matrix multiply is doing except without the
       | overhead of matrix creation and with potentially greater locality
       | of memory accesses.
       | 
       | Edit: I do think it is worthwhile to write your own code so that
       | you better understand what is happening under the hood, so good
       | on the author for that.
        
         | inimino wrote:
         | This pattern comes up a lot in comments on this type of post.
         | Author makes a dumb but easy-to-follow example to make a point,
         | and then someone points out how the example is dumb. Try to
         | avoid getting hung up on examples -- in this case nobody
         | reading this post should come away thinking they now know more
         | about cosine similarity than a library author. I dare say the
         | author's main points were:
         | 
         | - it's not that much code
         | 
         | - it's not terrifyingly hard to understand
         | 
         | - you might open up performance benefits in your specific
         | circumstance just by knowing how it's calculated after writing
         | the code to do it yourself
        
           | exmadscientist wrote:
           | > in this case nobody reading this post should come away
           | thinking they now know more about cosine similarity than a
           | library author
           | 
           | However, if this post leaves you open to the option that you
           | _might_ know more about $THING than a library author... that
           | is probably a very healthy possibility to consider.
           | 
           | ( _Consider._ Some are that grad student who got assigned to
           | write the library because they were too useless to do
           | anything else. Others are David M Gay.)
        
         | Blackthorn wrote:
         | The author is a library writer!
        
           | queuebert wrote:
           | My mistake. I took this statement in isolation: "...consider
           | that machine learning libraries are frequently written by
           | grad students on their path to discovery. It's a domain
           | expert with poor programming skills. Or it might be a case of
           | a good programmer who only barely understands the domain..."
        
         | klyrs wrote:
         | > The author is overconfident and underestimates library
         | writers to a fault.
         | 
         | Clicking around the website a bit, it would seem that the
         | author _is_ a library writer (some specifically targeting
         | GPUs), and the article is a plug for the books he 's written
         | about numerical analysis. How confident are _you_?
        
           | queuebert wrote:
           | Not very confident in general. But I have written a LOT of
           | raw CUDA code.
        
       | im3w1l wrote:
       | So uhm why did the cosine similarity give values bigger than one
       | in the library and how can we be confident that this code does
       | not have that issue?
        
         | tectonicfury wrote:
         | good question
        
       | tectonicfury wrote:
       | I felt that it was a good article, very straightforward, and he
       | made an interesting point about numerical packages being often
       | written by graduate students.
       | 
       | Personally, I would like to learn the math, but I would want to
       | first learn from the 'established' books (i.e. the books the
       | author read on his way to this point), only then will I be in a
       | position to judge the real worth of the author's books.
        
       | lordnacho wrote:
       | The author has written books about this area, so he's pretty
       | confident that he can write numerical libs. That might be right,
       | but for most people, when you come across some need, that's going
       | to not be your speciality.
       | 
       | I might need a numerical lib at some point, but I also know that
       | there are things like numerical instability, gremlins in this
       | area that I know some of but not all of.
       | 
       | Something popular with lots of people working on it is likely to
       | be far better for me than rolling my own.
       | 
       | Of course this does mean that for most things by far, the best
       | way forward is to research which lib is best supported and go
       | with that.
        
       | Zababa wrote:
       | I wonder if sometimes always telling people to not do anything
       | themselves and use already made libraries is robbing the industry
       | (and especially juniors) of lots of opportunities to learn.
       | Instead of being in control of what you do, you learn to use
       | something made by other people to simplify things. This is a bit
       | like cooking where in the last 10-20 years I've seen appliances
       | appearing everywhere. Some are very good (I love my slow cooker),
       | some I'm more perplexed about (A stand mixer? I usually get by
       | either with my hand for dense doughs like pizza or bread or a
       | hand mixer for more liquid/light doughs). If everybody uses
       | libraries, how are we training new libraries writers? Maybe part
       | of the solution would be to tell people to use libraries, and
       | then read the code, try to understand them and contribute.
        
       | aliasEli wrote:
       | In general it is a horrible idea to write your own number
       | crunching code, unless you were a brilliant student in your
       | numerical analysis course.
        
       | dagw wrote:
       | Another case where writing your numerical algorithms can be
       | faster than using the standard lib is if you know you're only
       | working on a small subset of the possible input domain and can
       | write a highly specialized function.
       | 
       | For example, a certain function may take arbitrary dimensional
       | complex matrices as input. However if you know that you will only
       | be passing in 3x3 Real positive semidefinite matrices you can
       | probably write a faster function that only works on those
       | matrices by using all that extra information you have. In Matlab
       | I've gotten order of magnitude speedups over the standard
       | functions by rolling my own highly specialized functions.
        
       | mjburgess wrote:
       | It seems like there's been a crash in the FP language market:
       | Scala, F#, ... Clojure.
       | 
       | Anyone any idea why?
       | 
       | Scala 3 almost looks _attractive_.
        
         | toomanyducks wrote:
         | In my experience, OOP is taught to basically everyone in
         | schools (AP CS is usually in Java, and so was my DSA class)
         | which makes the jump into FP hard to wrap your head around:
         | I've tried a few things in Haskell, and I kept trying to use
         | weird facsimiles of objects in places they should not go.
         | 
         | And then Rust came along and wrapped a ton of FP concepts into
         | easy to conceptualize OOP packages, and that reduced my
         | motivation to actually learn FP properly.
         | 
         | Still slowly trying to learn these things, though, I don't
         | think Rust really managed to capture all the advantages.
        
           | R0b0t1 wrote:
           | FP is also just not as suitable for solving many common CRUD
           | problems as an OOP or imperative design is. A FP solution
           | will be some combination of more verbose, slower, harder to
           | maintain, and less flexible.
        
             | Zababa wrote:
             | I don't think that's true. I've used Phoenix with Elixir
             | and it was a joy to use, easy to understand and pretty
             | fast. More verbose and harder to maintain, I don't think
             | it's true for statically typed functional programming
             | language, the compiler does a lot of work that would be
             | tests in other languages, and they're usually quite terse.
             | 
             | For the "slower" part, it depends. Slower compared to what?
             | Most will be faster than Ruby or Python, most will be
             | slower than C++, they're usually in the ballpark of Java
             | (by that I mean with less features but faster than Spring,
             | at least these are the results on TechEmpower).
             | 
             | For the less flexible, I don't know what you mean by that.
             | Harder to extend since you don't have reflection/dynamism?
             | That may be true, but for me these mechanism usually make a
             | codebase harder to maintain.
        
         | nicoburns wrote:
         | Perhaps because a lot of the idea have been picked up by other
         | languages with bigger ecosystems: Swift, Kotlin, Rust, etc?
        
           | Zababa wrote:
           | Swift itself has almost no market share in the web space,
           | just like Scala, F#, Clojure, OCaml have almost no market
           | share in the Apple ecosystem. Scala also wasn't used in the
           | android ecosystem, which is I think still the major user of
           | Kotlin. On the other hand, Kotlin is also on the server now,
           | but I don't know if it's replacing Java or Scala (maybe
           | both?). Another thing is that Java itself is adopting lots of
           | functional programming features (records, pattern matching
           | recently).
           | 
           | I don't think I've seen any mention of migration from F#,
           | Clojure, OCaml, Haskell, Scala, ... to Rust, but maybe it's
           | easier to pick up than C++ when high performance is needed by
           | teams already used to a ML-like?
        
         | wrnr wrote:
         | what do you mean, the FP job market?
        
       ___________________________________________________________________
       (page generated 2021-06-26 23:01 UTC)