bugGNU Octave - Bugs: bug #58768, Non-vectorized performance could...

 
 

bug #58768: Non-vectorized performance could use improvement

Submitter:  None
Submitted:  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:  -email is unavailable-
Open/Closed:  * Open Release:  * 5.2.0
Operating System:  * BSD Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 06 Feb 2023 10:11:46 PM UTC, comment #1: 

Works with a mouse always for bigger data but should not be using a mouse still for big data.

Anonymous
Wed 15 Jul 2020 10:51:29 PM UTC, original submission:  


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.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code