octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #60818] delaunayn - 2D code path vectorization


From: Dmitri A. Sergatskov
Subject: [Octave-bug-tracker] [bug #60818] delaunayn - 2D code path vectorization doesn't match nD algorithm
Date: Wed, 30 Jun 2021 23:08:31 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Follow-up Comment #26, bug #60818 (project octave):

I added "whos" at the end of the function. This is what I see for 6D 1000 pt
case:


octave:2> whos
Variables visible from the current scope:

variables in scope: top scope

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  ===== 
        p        1000x1                       8000  double
        q        1000x1                       8000  double
        r        1000x1                       8000  double
        s        1000x1                       8000  double
        x        1000x1                       8000  double
        y        1000x1                       8000  double
        z        1000x1                       8000  double

Total is 7000 elements using 56000 bytes

octave:3> tic; delaunayn([x,y,z,p,q,r]); toc
Variables visible from the current scope:

variables in scope: delaunayn: /home/dima/scratch/delaunayn.m

   Attr Name                 Size                     Bytes  Class
   ==== ====                 ====                     =====  ===== 
        R              3654654x1                   58474480  double
    f   T               608426x7                   34071856  double
        edgvec         3654654x6                  175423392  double
        eqs            3654654x3654654            380084024  double
        idx                  1x683                     5464  double
        l              3654654x3654654            233897864  double
        nd                   1x1                          8  double
        nt                   1x1                          8  double
        p              3654654x1                   29237232  double
    f   pts               1000x6                      48000  double
        q              3654654x1                   29237232  double
        reorderdtriidx       1x3654654             29237232  double
        tol                  1x1                          8  double
        u              3654654x3654654            233897864  double
    f   varargin             0x0                          0  cell

Total is 40069528391356 elements using 1203614664 bytes

Elapsed time is 6.89901 seconds.


Do we actually need "l" matrix? I do not see it being used
anywhere in the code.

Dmitri.
-- 


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60818>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]