[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/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Octave-bug-tracker] [bug #58768] Non-vectorized performance could use improvement,
anonymous <=