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

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

[Octave-bug-tracker] [bug #58768] Non-vectorized performance could use i


From: anonymous
Subject: [Octave-bug-tracker] [bug #58768] Non-vectorized performance could use improvement
Date: Wed, 15 Jul 2020 18:51:30 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0

URL:
  <https://savannah.gnu.org/bugs/?58768>

                 Summary: Non-vectorized performance could use improvement
                 Project: GNU Octave
            Submitted by: None
            Submitted on: Wed 15 Jul 2020 10:51:29 PM UTC
                Category: Performance
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Performance
                  Status: None
             Assigned to: None
         Originator Name: Jason Bacon
        Originator Email: bacon4000@gmail.com
             Open/Closed: Open
                 Release: 5.2.0
         Discussion Lock: Any
        Operating System: BSD

    _______________________________________________________

Details:


Hi there,

Just sharing an observation about performance of non-vectorized code compared
with Matlab.

I've been an Octave proponent for years and just generated some benchmark data
that uncovers both good and bad news.

The good news is that running vectorized code to find the lowest element
remaining, Octave outperformed Matlab 2018a and used far less memory.  Not
only that, but it outperformed all other interpreted languages I tested,
except for being edged out by a very narrow margin by py+numba.

The bad news is that using an explicit loop, Octave performance was
rock-bottom, taking hours where other languages took minutes.  I realize that
users should vectorize their code and that the JIT might help with this, but
I'm wondering if you might want to investigate the performance issue without
JIT.  This is a very simple loop that might be representative of the kind of
code new users write.  If they see such a drastic drop in performance compared
with Matlab, they might be dissuaded from using Octave before learning to
vectorize their code.

The data below show time in seconds, virtual and resident memory use.

Octave 5.2.0 vectorized Interpreted
(use min(list(start:list_size)) compiler (no JIT))
39.4 345 MB (103 resident)

MATLAB 2018a vectorized Interpreted + JIT compiler
(use min(list(start:list_size))
51.7 5,676 MB (251 resident)

MATLAB 2018a explicit loop Interpreted + JIT compiler
112.2 (1.87 minutes) 5,678 MB (248 resident)

Octave 5.2.0 explicit loop Interpreted (no JIT
Gave up after waiting hours 345 MB (103 resident)

The benchmark is a set of selection sort implementations to ball-park relative
language performance across many popular languages.  The source code is
available here:

https://github.com/outpaddling/Lang-speed

Maybe you could quickly try it out and see if you get the same performance
profile that I did.




    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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