[ 
https://issues.apache.org/jira/browse/MAHOUT-1640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15184061#comment-15184061
 ] 

ASF GitHub Bot commented on MAHOUT-1640:
----------------------------------------

Github user dlyubimov commented on the pull request:

    https://github.com/apache/mahout/pull/81#issuecomment-193517651
  
    Ok here are the quick sparse multiplication performance results in our unit 
tests. In short, looks like 30% improvement for sparse opeartions on average. 
Which is decent. I will test the rest of the tests and report back. If 
everything is ok, looks like a very valuable addition for the time being. Thank 
you very much @vigna !
    
    Fastutil PR over current master (the second numbers are pragmatically 
important): 
    
    Asr %*% Bsr: (26.0,14.333333333333334)
    Asr' %*% Bsr: (1214.0,16.0)
    Asr %*% Bsr': (96.0,19.0)
    Asr' %*% Bsr': (1002.6666666666666,13.666666666666666)
    Asr'' %*% Bsr'': (14.333333333333334,14.333333333333334)
    
    Asm %*% Bsm: (1523.3333333333333,18.0)
    Asm' %*% Bsm: (1929.0,21.0)
    Asm %*% Bsm': (1428.6666666666667,20.666666666666668)
    Asm' %*% Bsm': (1669.6666666666667,17.333333333333332)
    Asm'' %*% Bsm'': (1541.3333333333333,14.333333333333334)
    
    Asm %*% Bsr: (1160.0,14.0)
    Asm' %*% Bsr: (1609.3333333333333,20.333333333333332)
    Asm %*% Bsr': (1142.3333333333333,17.666666666666668)
    Asm' %*% Bsr': (1408.6666666666667,14.333333333333334)
    Asm'' %*% Bsr'': (1154.6666666666667,14.0)
    
    Current master:
    
    Asr %*% Bsr: (30.0,22.0)
    Asr' %*% Bsr: (1918.6666666666667,26.0)
    Asr %*% Bsr': (118.66666666666667,27.0)
    Asr' %*% Bsr': (1551.6666666666667,21.666666666666668)
    Asr'' %*% Bsr'': (22.333333333333332,21.666666666666668)
    
    Asm %*% Bsm: (2191.0,26.333333333333332)
    Asm' %*% Bsm: (2543.6666666666665,30.333333333333332)
    Asm %*% Bsm': (2067.0,30.333333333333332)
    Asm' %*% Bsm': (2274.0,22.666666666666668)
    Asm'' %*% Bsm'': (2167.0,22.666666666666668)
    
    Asm %*% Bsr: (1717.3333333333333,21.666666666666668)
    Asm' %*% Bsr: (2254.0,32.0)
    Asm %*% Bsr': (1762.3333333333333,26.666666666666668)
    Asm' %*% Bsr': (2004.6666666666667,21.666666666666668)
    Asm'' %*% Bsr'': (1711.0,24.333333333333332)



> Better collections would significantly improve vector-operation speed
> ---------------------------------------------------------------------
>
>                 Key: MAHOUT-1640
>                 URL: https://issues.apache.org/jira/browse/MAHOUT-1640
>             Project: Mahout
>          Issue Type: Improvement
>          Components: collections
>         Environment: Darwin lithium.local 14.1.0 Darwin Kernel Version 
> 14.1.0: Mon Dec 22 23:10:38 PST 2014; root:xnu-2782.10.72~2/RELEASE_X86_64 
> x86_64 i386 MacBookPro10,1 Darwin
> java version "1.8.0_31"
> Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
>            Reporter: Sebastiano Vigna
>            Assignee: Suneel Marthi
>              Labels: legacy, math, scala
>         Attachments: fastutil.patch, speed-fastutil, speed-std
>
>
> The collections currently used by Mahout to implement sparse vectors are 
> extremely slow. The proposed patch (localized to RandomAccessSparseVector) 
> uses fastutil's maps and the speed improvements in vector benchmarks are very 
> significant. It would be interesting to see whether these improvements 
> percolate to high-level classes using sparse vectors.
> I had to patch two unit tests (an off-by-one bug and an overfitting bug; both 
> were exposed by the different order in which key/values were returned by 
> iterators).
> The included files speed-std and speed-fastutil show the speed improvement. 
> Some more speed might be gained by using everywhere the standard 
> java.util.Map.Entry interface instead of Element.
> DISCLAIMER: The "Times" set of tests has been run multiplying two identical 
> vectors. The standard tests multiply two random vectors, so in fact they just 
> test the speed of the underlying map remove() method, as almost all products 
> are zero. This is not very realistic and was heavily penalizing fastutil's 
> "true deletions". Better tests, with a typical overlap of nonzero entries, 
> would be even more realistic.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to